On Wed, 2018-02-21 at 10:58 +0100, Paolo Bonzini wrote: > On 19/02/2018 06:44, KarimAllah Ahmed wrote: > > > > 1- It ensures that user-space tools that does not understand nesting > > can still see the expected guest state when querying guest state or > > even when trying to read memory, translate an address, etc. > > How does it work when L1 assigns an MMIO region or PIO region for direct > L2 access, and then L2 requests MMIO from userspace? You cannot do a > vmexit in that case. Ah, right! I was testing with a real device that is passed through to L1! and with QEMU/KVM running as L1 hypervisor that emulates e1000 for L2 on L1 Technically I can solve this problem, but it would not satisfy the (1) stated above. So the solution would be slightly more ugly (or significantly more). > > > > > 2- It is very simple and does not require a whole lot of state in user- > > space. > > It's still requires _some_ state. If you need a new API, the amount of > state that the API saves/restores is not particularly interesting. I thought at some point about creating a new MSR and add it in the MSRs to save list. The issue you mentioned above pretty much killed this approach for me :) Ironically it still works fine in our environment but it will not work fine for the general use-case. > > Paolo > Amazon Development Center Germany GmbH Berlin - Dresden - Aachen main office: Krausenstr. 38, 10117 Berlin Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger Ust-ID: DE289237879 Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
