Avi Kivity wrote: > On 06/22/2009 07:08 PM, Michael S. Tsirkin wrote: >> On Mon, Jun 22, 2009 at 11:45:00AM -0400, Gregory Haskins wrote: >> >>> Michael S. Tsirkin wrote: >>> >>>> It seems that a lot of complexity and trickiness with iosignalfd is >>>> handling the group/item relationship, which comes about because kvm >>>> does >>>> not currently let a device on the bus claim a write transaction >>>> based on the >>>> value written. This could be greatly simplified if the value written >>>> was passed to the in_range check for write operation. We could then >>>> simply make each kvm_iosignalfd a device on the bus. >>>> >>>> What does everyone think of the following lightly tested patch? >>>> >>>> >>> Hi Michael, >>> Its interesting, but I am not convinced its necessary. We >>> created the >>> group/item layout because iosignalfds are unique in that they are >>> probably the only IO device that wants to do some kind of address >>> aliasing. >>> >> >> We actually already have aliasing: is_write flag is used for this >> purpose. Actually, it's possible to remove is_write by passing >> a null pointer in write_val for reads. I like this a bit less as >> the code generated is less compact ... Avi, what do you think? >> > > Greg, won't Michael's patch eliminate a big chunk from your iosignalfd > patches? Seems like a win to me.
Well, it really just moves that hunk from eventfd.c to kvm_main.c, where I don't think anyone else will use it by iosignalfd. But if that is what everyone wants, I guess I have no choice. > >> One is enough :) >> Seriously, do you see that this saves you all of RCU, linked lists and >> counters? You don't need to keep track of iofds, you don't need to >> implement your own lookup logic - you just use the kvm device >> and that's it. >> >> > > Yup. >
signature.asc
Description: OpenPGP digital signature