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

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Thu, Oct 27, 2016 at 01:25:40AM -0600, Jan Beulich wrote:
> >>> On 26.10.16 at 18:03, <roger.pau@xxxxxxxxxx> wrote:
> > On Wed, Oct 26, 2016 at 09:16:55AM -0600, Jan Beulich wrote:
> >> >>> On 26.10.16 at 17:08, <roger.pau@xxxxxxxxxx> wrote:
> >> > On Wed, Oct 26, 2016 at 08:10:50AM -0600, Jan Beulich wrote:
> >> >> >>> On 26.10.16 at 13:35, <roger.pau@xxxxxxxxxx> 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.
> >> 
> >> Unless it's page zero, what bad could such shadowing do?
> > 
> > You where the one that warmed me of this in 
> > http://marc.info/?l=xen-devel&m=147576851115855 that shadowing regions 
> > below 1MB could prevent the OS from properly interacting with the firmware, 
> > or at least this was my understanding. The RSDP is usually located in the 
> > same page as the EBDA, so we would be shadowing the EBDA area.
> 
> Oh, right, for a moment I did forget that the EBDA is a permissible
> place for the RSDPTR to live in. Only mapping a page over a ROM
> one (E0000...FFFFF) would be reasonable. So as said - there are
> positive aspects to keeping the original pointer visible; the main
> issue I foresee is that once again user mode tools will (unless made
> Xen-aware) have a different view of the system than the kernel.

Yes, that's certainly possible. On FreeBSD acpidump will try to fetch the 
address of the RSDP from sysctl, and that's going to be right (because it's 
set by the kernel based on the RSDP that's using). I guess Linux is using 
some similar functionality, or else tools like acpidump won't work on UEFI 
environments (where AFAIK the RSDP can be anywhere in memory).

Roger.

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