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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
