Messages in this thread | | | Date | Wed, 01 Apr 2009 00:05:50 +0300 | From | Avi Kivity <> | Subject | Re: [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.
| |