Re: [PATCH v2 18/30] xen/x86: setup PVHv2 Dom0 ACPI tables

[Roger Pau Monne <roger.pau@citrix.com>]

On Wed, Oct 26, 2016 at 08:10:50AM -0600, Jan Beulich wrote:
> >>> On 26.10.16 at 13:35, <roger.pau@citrix.com> wrote:
> > On Wed, Oct 12, 2016 at 09:55:44AM -0600, Jan Beulich wrote:
> >> Taking an abstract perspective I agree with Andrew that we should
> >> be whitelisting here. However, as you already see from the list you
> >> provided (which afaict is far from complete wrt ACPI 6.1), this may
> >> become cumbersome already initially, not to speak of down the road.
> > 
> > I've initially used a back-listing approach. We can always change this later 
> > on.
> > 
> > So I've ended up crafting a new MADT, XSDT and RSDP. Note that I'm not 
> > crafting a new custom RSDT (and in fact I'm setting rsdt_physical_address = 
> > 0 in the RSDP together with revision = 2). This is all placed in RAM stolen 
> > from the guest memory map and marked as E820_ACPI, which means that the new 
> > RSDP no longer resides below 1MB, and that the Dom0 kernel _must_ use the 
> > rsdp_paddr provided in the start info, or else it's going to access the 
> > native RSDP.
> 
> Hmm, for the RSDP I'm not sure. It might be better if we put it at the
> same spot where the host one is, mapping a RAM page there with a
> copy of the respective host page data. Otoh your approach allows
> Dom0 to still find the real tables if need be, which has both up and
> down sides.

The problem with putting it at the same page is that AFAICT there's a big 
chance that other things (like EBDA or ROM) being at the same page, and 
we would be shadowing them by mapping a RAM page over it, even if the 
original data is copied. This hole area below 1MB is just a mess to deal 
with TBH.

> >> I'm afraid there are systems where the EBDA is not marked reserved.
> >> But maybe there are no current (64-bit capable) ones of that sort.
> > 
> > Hm, I would say that we leave this as it is currently, and then we can 
> > always play more tricks later on if we found any of such systems.
> 
> As long as the code is experimental, and there's a note to that effect
> which can be easily found (and has to be gone for the code to become
> non-experimental), I'm fine with that.
> 
> >> > Might it be possible to solve this by identity mapping the first 1MB, and 
> >> > marking the RAM regions there as p2m_ram_rw? Or would that create even 
> >> > further problems?
> >> 
> >> Hmm, not sure - the range below 1Mb is marked as MMIO in
> >> frame_table[], so there would be a (benign?) conflict at least there.
> > 
> > As said before, I would leave the current implementation and look into that 
> > option if needed.

Right, I've added to following note as a comment:

NB2: regions marked as RAM in the memory map are backed by RAM pages
in the p2m, and the original data is copied over. This is done because
at least FreeBSD places the AP boot trampoline in a RAM region found
below the first MB, and the real-mode emulator found in Xen cannot
deal with code that resides in guest pages marked as MMIO. This can
cause problems if the memory map is not correct, and for example the
EBDA or the video ROM region is marked as RAM.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel