Re: [Xen-devel] Altp2m/#VE page issue

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Fri, Jun 29, 2018 at 9:25 AM Razvan Cojocaru
<rcojocaru@xxxxxxxxxxxxxxx> wrote:
>
> Hello,
>
> We're trying to get #VE to work with a "regular" guest page (that is,
> not a page that we get via xc_domain_increase_reservation_exact() /
> xc_domain_populate_physmap_exact()).
>
> However, the way Xen's code works now, it doesn't seem to be possible:
>
> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/hvm/vmx/vmx.c;h=20a8a69fbe412aa928c75b5d7756816bf55178fc;hb=refs/heads/staging#l2150
>
> because get_gfn_query_unlocked() calls ept_get_entry(), which returns
> INVALID_MFN if gfn > p2m->max_mapped_pfn.

It's certainly weird to have a "regular" gfn that's also above
max_mapped_pfn. That to me sounds like a bug with how max_mapped_pfn
is set. To be honest, I've ran into issues with max_mapped_gfn in the
past too and it was annoying so I do actually end up just running:

rc = xc_domain_setmaxmem(drakvuf->xen->xc, drakvuf->domID, ~0);

to make it go away. It's fugly but didn't have time yet to investigate
further ¯\_(ツ)_/¯. Maybe it's time for a proper fix.

Tamas

Tamas

>
> max_mapped_pfn is only ever updated in ept_set_entry(), and so unless
> ept_set_entry() gets called previously to vmx_vcpu_update_vmfunc_ve(),
> we will fail to enable #VE for any given (valid) GFN.
>
> I believe that this works with the
> xc_domain_increase_reservation_exact() /
> xc_domain_populate_physmap_exact() strategy because somewhere at the end
> of the callchain, ept_set_entry() _does_ get called for the new GFN.
>
> Forcing max_mapped_pfn should work, but I can't help thinking that
> there's a better way. Maybe George and Tamas have a suggestion here?
>
>
> Thanks,
> Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel