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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan

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