[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH 2/2] x86/dom0: attempt to fixup p2m page-faults for PVH dom0
On Mon, Feb 17, 2025 at 09:44:28AM +0100, Jan Beulich wrote: > On 17.02.2025 09:25, Roger Pau Monné wrote: > > On Fri, Feb 14, 2025 at 02:07:05PM +0100, Jan Beulich wrote: > >> On 14.02.2025 13:38, Roger Pau Monné wrote: > >>> On Fri, Feb 14, 2025 at 12:53:01PM +0100, Jan Beulich wrote: > >>>> On 14.02.2025 10:29, Roger Pau Monne wrote: > >>>>> +{ > >>>>> + unsigned long gfn = paddr_to_pfn(addr); > >>>>> + struct domain *currd = current->domain; > >>>>> + p2m_type_t type; > >>>>> + mfn_t mfn; > >>>>> + int rc; > >>>>> + > >>>>> + ASSERT(is_hardware_domain(currd)); > >>>>> + ASSERT(!altp2m_active(currd)); > >>>>> + > >>>>> + /* > >>>>> + * Fixups are only applied for MMIO holes, and rely on the > >>>>> hardware domain > >>>>> + * having identity mappings for non RAM regions (gfn == mfn). > >>>>> + */ > >>>>> + if ( !iomem_access_permitted(currd, gfn, gfn) || > >>>>> + !is_memory_hole(_mfn(gfn), _mfn(gfn)) ) > >>>>> + return -EPERM; > >>>>> + > >>>>> + mfn = get_gfn(currd, gfn, &type); > >>>>> + if ( !mfn_eq(mfn, INVALID_MFN) || !p2m_is_hole(type) ) > >>>>> + rc = mfn_eq(mfn, _mfn(gfn)) ? 0 : -EEXIST; > >>>> > >>>> I understand this is to cover the case where two vCPU-s access the same > >>>> GFN > >>>> at about the same time. However, the "success" log message at the call > >>>> site > >>>> being debug-only means we may be silently hiding bugs in release builds, > >>>> if > >>>> e.g. we get here despite the GFN having had an identity mapping already > >>>> for > >>>> ages. > >>> > >>> Possibly, but what would be your suggestion to fix this? I will think > >>> about it, but I can't immediately see a solution that's not simply to > >>> make the message printed by the caller to be gprintk() instead of > >>> gdprintk() so catch such bugs. Would you agree to that? > >> > >> My thinking was that it might be best to propagate a distinguishable error > >> code (perhaps -EEXIST, with its present use then replaced) out of the > >> function, > >> and make the choice of gprintk() vs gdprintk() depend on that. Accompanied > >> by a > >> comment explaining things a little. > > > > I think it would be easier if I just made those gprintk() instead of > > gdprintk(), all with severity XENLOG_DEBUG except for the one that > > reports the failure of the fixup function that is XENLOG_WARNING. > > Would you be OK with that? > > Hmm. Okay-ish at best. Even if debug+guest-level messages are suppressed by > default, I think it wouldn't be nice if many of them might appear in release > builds with guest_loglevel=all. What I find difficult is to predict how high > the chances are to see any of them (and then possibly multiple times). I think getting those messages even in non-debug builds might be helpful for debugging purposes. Sometimes it's difficult for users to switch to a debug build of Xen if not provided by their upstream. FWIW, on my Intel NUC I see three of those: (XEN) [ 5.418855] arch/x86/hvm/emulate.c:391:d0v0 fixup p2m mapping for page fedc7 added (XEN) [ 5.474574] arch/x86/hvm/emulate.c:391:d0v0 fixup p2m mapping for page fd6a0 added (XEN) [ 8.712784] arch/x86/hvm/emulate.c:391:d0v2 fixup p2m mapping for page fe410 added Would you be fine with this approach: bool __ro_after_init opt_dom0_pf_fixup; static int hwdom_fixup_p2m(paddr_t addr) { unsigned long gfn = paddr_to_pfn(addr); struct domain *currd = current->domain; p2m_type_t type; mfn_t mfn; int rc; ASSERT(is_hardware_domain(currd)); ASSERT(!altp2m_active(currd)); /* * Fixups are only applied for MMIO holes, and rely on the hardware domain * having identity mappings for non RAM regions (gfn == mfn). */ if ( !iomem_access_permitted(currd, gfn, gfn) || !is_memory_hole(_mfn(gfn), _mfn(gfn)) ) return -EPERM; mfn = get_gfn(currd, gfn, &type); if ( !mfn_eq(mfn, INVALID_MFN) || !p2m_is_hole(type) ) rc = mfn_eq(mfn, _mfn(gfn)) ? -EEXIST : -ENOTEMPTY; else rc = set_mmio_p2m_entry(currd, _gfn(gfn), _mfn(gfn), 0); put_gfn(currd, gfn); return rc; } [...] int inner_rc = hwdom_fixup_p2m(addr); if ( !inner_rc || inner_rc == -EEXIST ) { gdprintk(XENLOG_DEBUG, "fixup p2m mapping for page %lx %s\n", paddr_to_pfn(addr), !inner_rc ? "added" : "already present"); rc = X86EMUL_RETRY; vio->req.state = STATE_IOREQ_NONE; break; } gprintk(XENLOG_WARNING, "unable to fixup memory %s to %#lx size %u: %d\n", dir ? "read" : "write", addr, size, inner_rc); Thanks, Roger.
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |