Chris Wright wrote: > * Gregory Haskins (ghaskins@xxxxxxxxxx) wrote: > >> Chris Wright wrote: >> >>> * Avi Kivity (avi@xxxxxxxxxx) wrote: >>> >>>> Gregory Haskins wrote: >>>> >>>>> Cool, I will code this up and submit it. While Im at it, Ill run it >>>>> through the "nullio" ringer, too. ;) It would be cool to see the >>>>> pv-mmio hit that 2.07us number. I can't think of any reason why this >>>>> will not be the case. >>>>> >>>>> >>>> Don't - it's broken. It will also catch device assignment mmio and >>>> hypercall them. >>>> >>> Not necessarily. It just needs to be creative w/ IO_COND >>> >> Hi Chris, >> Could you elaborate? How would you know which pages to hypercall and >> which to let PF? >> > > Was just thinking of some ugly mangling of the addr (I'm not entirely > sure what would work best). > Right, I get the part about flagging the address and then keying off that flag in IO_COND (like we do for PIO vs MMIO). What I am not clear on is how you would know to flag the address to begin with. Here's a thought: "PV" drivers can flag the IO (e.g. virtio-pci knows it would never be a real device). This means we route any io requests from virtio-pci though pv_io_ops->mmio(), but not unflagged addresses. This is not as slick as boosting *everyones* mmio speed as Avi's original idea would have, but it is perhaps a good tradeoff between the entirely new namespace created by my original dynhc() proposal and leaving them all PF based. This way, its just like using my dynhc() proposal except the mmio-addr is the substitute address-token (instead of the dynhc-vector). Additionally, if you do not PV the kernel the IO_COND/pv_io_op is ignored and it just slow-paths through the PF as it does today. Dynhc() would be dependent on pv_ops. Thoughts? -Greg
Attachment:
signature.asc
Description: OpenPGP digital signature
