[lkml]   [2009]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 01/17] shm-signal: shared-memory signals
Gregory Haskins wrote:
>>> +struct shm_signal_irq {
>>> + __u8 enabled;
>>> + __u8 pending;
>>> + __u8 dirty;
>>> +};
>> Some ABIs may choose to pad this, suggest explicit padding.
> Yeah, good idea. What is the official way to do this these days? Are
> GCC pragmas allowed?

I just add a __u8 pad[5] in such cases.

>>> +
>>> +struct shm_signal;
>>> +
>>> +struct shm_signal_ops {
>>> + int (*inject)(struct shm_signal *s);
>>> + void (*fault)(struct shm_signal *s, const char *fmt, ...);
>> Eww. Must we involve strings and printf formats?
> This is still somewhat of a immature part of the design. Its supposed
> to be used so that by default, its a panic. But on the host side, we
> can do something like inject a machine-check. That way malicious/broken
> guests cannot (should not? ;) be able to take down the host. Note today
> I do not map this to anything other than the default panic, so this
> needs some love.
> But given the asynchronous nature of the fault, I want to be sure we
> have decent accounting to avoid bug reports like "silent MCE kills the
> guest" ;) At least this way, we can log the fault string somewhere to
> get a clue.

I see.

This raises a point I've been thinking of - the symmetrical nature of
the API vs the assymetrical nature of guest/host or user/kernel
interfaces. This is most pronounced in ->inject(); in the host->guest
direction this is async (host can continue processing while the guest is
handling the interrupt), whereas in the guest->host direction it is
synchronous (the guest is blocked while the host is processing the call,
unless the host explicitly hands off work to a different thread).

I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

 \ /
  Last update: 2009-03-31 23:07    [W:0.125 / U:6.388 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site