Jeremy Fitzhardinge wrote:The main thing keeping me from doing this ATM is what I perceive as lack of interest in a generic interface. I think it's also a little premature given that we don't have any features on the plate yet. However, I don't think that means that we cannot turn KVM's PV into a generic one. So here's what I propose. Let's start building the KVM PV interface on 4000 0000. That means that Xen cannot initially use it but that's okay. Once KVM-lite is merged and we have some solid features (and other guests start implementing them), we can also advertise this interface as a "generic interface" by also supporting the signature on leave 4000 1000 and using the MSR trickery that you propose. As long as we all agree not to use 4000 1000 for now, it leaves open the possibility of having a generic interface in the future. Regards, Anthony Liguori -
| Greg Kroah-Hartman | [PATCH 005/196] Chinese: add translation of SubmittingDrivers |
| Nick Piggin | [patch] my mmu notifier sample driver |
| Sean | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
| Arjan van de Ven | [Patch v2] Make PCI extended config space (MMCONFIG) a driver opt-in |
git: | |
| Antonio Almeida | HTB accuracy for high speed |
| Gerrit Renker | [PATCH 0/37] dccp: Feature negotiation - last call for comments |
| Jens Axboe | Re: [BUG] New Kernel Bugs |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
