Avi Kivity wrote: > On 06/16/2009 05:40 PM, Gregory Haskins wrote: >> >> Something else to consider: For iosignalfd, we can assume we will >> always be called from vcpu process context so we might not really need >> official affirmation from the system. For irqfd, we cannot predict who >> may be injecting the interrupt (for instance, it might be a >> PCI-passthrough hard-irq context). I am not sure if this knowledge >> actually helps to simplify the problem space, but I thought I should >> mention it. >> > > We can't assume anything. Userspace might hand out that eventfd to > anyone. Yeah agreed, and I misspoke (mistyped? ;). It's not that I assume its from a vcpu. Its that it doesn't matter (at least for vbus). The reason is that the memory context is established in vbus via a different channel (i.e. I never look at "current" in the context of the eventfd callback). The eventfd is just telling me that the previously established memory context needs to be looked at (e.g. the virtio-ring changed). Therefore, the origin of the signal doesn't actually matter (at least w.r.t. safe handling of the request). Obviously, the question of whether something has really changed in the memory and whether an errant signal could cause problems is a separate issue. But we need to be robust against that anyway, for a multitude of other reasons (e.g. malicious/broken guest scribbling over the virtio-ring, etc). -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
