|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |