Avi Kivity wrote: > Michael S. Tsirkin wrote: >> On Tue, Jun 02, 2009 at 01:41:05PM -0400, Gregory Haskins wrote: >> >>>> And having close not clean up the state unless you do an ioctl >>>> first is >>>> very messy IMO - I don't think you'll find any such examples in >>>> kernel. >>>> >>>> >>> I agree, and that is why I am advocating this POLLHUP solution. It was >>> only this other way to begin with because the technology didn't exist >>> until Davide showed me the light. >>> >>> Problem with your request is that I already looked into what is >>> essentially a bi-directional reference problem (for a different reason) >>> when I started the POLLHUP series. Its messy to do this in a way that >>> doesn't negatively impact the fast path (introducing locking, etc) or >>> make my head explode making sure it doesn't race. Afaict, we would >>> need >>> to solve this problem to do what you are proposing (patches welcome). >>> >>> If this hybrid decoupled-deassign + unified-close is indeed an >>> important >>> feature set, I suggest that we still consider this POLLHUP series for >>> inclusion, and then someone can re-introduce DEASSIGN support in the >>> future as a CAP bit extension. That way we at least get the desirable >>> close() properties that we both seem in favor of, and get this advanced >>> use case when we need it (and can figure out the locking design). >>> >>> >> >> FWIW, I took a look and yes, it is non-trivial. >> I concur, we can always add the deassign ioctl later. >> > > I agree that deassign is needed for reasons of symmetry, and that it > can be added later. > Cool.
FYI: Davide's patch has been accepted into -mm (Andrew CC'd). I am not sure of the protocol here, but I assume this means you can now safely pull it from -mm into kvm.git so the prerequisite for 2/2 is properly met. -Greg
signature.asc
Description: OpenPGP digital signature
