Re: [PATCH] x86/HVM: Merge HVM and PVH hypercall tables

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

On 12/10/2015 07:30 AM, Jan Beulich wrote:
>>>> On 08.12.15 at 15:20, <boris.ostrovsky@oracle.com> wrote:
>> The tables are almost identical and therefore there is little reason to
>> keep both sets.
>>
>> PVH needs 3 extra hypercalls:
>> * mmuext_op. PVH uses MMUEXT_TLB_FLUSH_MULTI and MMUEXT_INVLPG_MULTI to
>>    optimize TLB flushing. Since HVMlite guests may decide to use them as
>>    well we can allow these two commands for all guests in an HVM container.
> I must be missing something here: Especially for the INVLPG variant
> I can't see what use it could be for a PVH guest, as it necessarily
> would act on a different address space (the other one may have at
> least some effect due to hvm_flush_guest_tlbs()).

This is done out of xen_flush_tlb_others(), which is what PVH guests use.

And yes --- there indeed seems to be little reason to do that. But it is 
there now so I am not sure we can make this not work anymore for PVH guests.

>
> And then, if those two really are meant to be enabled, why would
> their _LOCAL and _ALL counterparts not be? And similarly,
> MMUEXT_FLUSH_CACHE{,_GLOBAL} may then be valid to expose.

This is only used by PVH guests as optimization (see comment in 
xen_init_mmu_ops()). So there is no need to do a hypercall for LOCAL 
operations. For ALL/GLOBAL --- maybe we should allow those too, even 
though they are not currently used (in Linux).

(In principle we could allow LOCAL ones too. Assuming this all is needed 
at all)

>
> Wasn't it much rather that PVH Dom0 needed e.g. MMUEXT_PIN_Ln_TABLE
> to deal with foreign guests' page tables?

That I haven't considered.

Especially given that PVH dom0 is not booting for me, as I just found out:

...
(XEN) d0v0 EPT violation 0x1aa (-w-/r-x) gpa 0x000000c0008116 mfn 
0xc0008 type 5
(XEN) d0v0 Walking EPT tables for GFN c0008:
(XEN) d0v0  epte 800000082bf50007
(XEN) d0v0  epte 800000082bf19007
(XEN) d0v0  epte 800000043c6f9007
(XEN) d0v0  epte 80500000c0008805
(XEN) d0v0  --- GLA 0xffffc90020008116
(XEN) domain_crash called from vmx.c:2816
(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
(XEN) ----[ Xen-4.7-unstable  x86_64  debug=y  Tainted:    C ]----
(XEN) CPU:    0
(XEN) RIP:    0010:[<ffffffff816150dc>]
(XEN) RFLAGS: 0000000000010046   CONTEXT: hvm guest (d0v0)
(XEN) rax: 000000000000001d   rbx: 0000000000000000   rcx: ffff88014700f9b8
(XEN) rdx: 00000000000000ff   rsi: 0000000000000000   rdi: 0000000000000000
(XEN) rbp: ffff88014700fa18   rsp: ffff88014700f9e8   r8: ffff88014700f9c0
(XEN) r9:  000000000000001d   r10: ffffffff8189c7f0   r11: 0000000000000000
(XEN) r12: ffffc90020008000   r13: ffffc90020008116   r14: 0000000000000002
(XEN) r15: 000000000000001d   cr0: 0000000080050033   cr4: 00000000000406f0
(XEN) cr3: 0000000001c0e000   cr2: 0000000000000000
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0000   cs: 0010
(XEN) Guest stack trace from rsp=ffff88014700f9e8:
(XEN)   Fault while accessing guest memory.
(XEN) Hardware Dom0 crashed: rebooting machine in 5 seconds.


We haven't been running regression tests for PVH dom0 so I don't know 
how long this has been broken.

-boris