[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 07/18] x86/hvm: introduce per-vCPU L3 page-table



On Thu, Oct 8, 2026 at 9:40 AM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 07.10.2026 12:40, George Dunlap wrote:
> > @@ -1835,7 +1853,7 @@ static int promote_l4_table(struct page_info *page)
> >      if ( !rc )
> >      {
> >          init_xen_l4_slots(pl4e, l4mfn,
> > -                          d, INVALID_MFN, VM_ASSIST(d, m2p_strict));
> > +                          d, NULL, INVALID_MFN, VM_ASSIST(d, m2p_strict));
>
> Nit: Take the opportunity and re-flow the statement (i.e. move more args
> onto the 1st line)?

Ack

> > --- a/xen/arch/x86/pv/domain.c
> > +++ b/xen/arch/x86/pv/domain.c
> > @@ -127,7 +127,7 @@ static int setup_compat_l4(struct vcpu *v)
> >      mfn = page_to_mfn(pg);
> >      l4tab = map_domain_page(mfn);
> >      clear_page(l4tab);
> > -    init_xen_l4_slots(l4tab, mfn, v->domain, INVALID_MFN, false);
> > +    init_xen_l4_slots(l4tab, mfn, v->domain, v, INVALID_MFN, false);
>
> This being PV-only code, don't you want to pass NULL here? The description
> talks about this, but (a) it's not quite clear why PV32 would want handling
> differently from PV64 at this point and (b) in sh_make_shadow() you do pass
> NULL unconditionally.

This is actually left over from the previous iteration of the series
which supports PV guests; and apparently it would be a lot easier for
implement per-vCPU pagetables for 32-bit PV guests, since the L4
doesn't belong to the guest.  But it's outside of the scope of the
current work.

At any rate, I'm going to try passing a single vcpu, as Roger
suggested.  That restricts toolstacks to not being able to promote PV
L4s before calling XEN_DOMCTL_max_vcpus, but that seems fine to me.

 -George



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.