Re: [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests

From: "Jan Beulich" <JBeulich@suse.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: xen-devel@lists.xen.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	roger.pau@citrix.com
Subject: Re: [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests
Date: Tue, 07 Jun 2016 08:10:23 -0600	[thread overview]
Message-ID: <5756F1EF02000078000F2A23@prv-mh.provo.novell.com> (raw)
In-Reply-To: <5756D331.2040706@oracle.com>

>>> On 07.06.16 at 15:59, <boris.ostrovsky@oracle.com> wrote:
> On 06/07/2016 02:17 AM, Jan Beulich wrote:
>>>>> On 06.06.16 at 18:59, <boris.ostrovsky@oracle.com> wrote:
>>> On 06/06/2016 09:29 AM, Jan Beulich wrote:
>>>>>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
>>>>> +#define RESERVED_MEMORY_DYNAMIC_START 0xFC001000
>>>>> +#define ACPI_PHYSICAL_ADDRESS         0x000EA020
>>>>> +
>>>>> +/* Initial allocation for ACPI tables */
>>>>> +#define NUM_ACPI_PAGES  16
>>>> With which other definitions do these three need to remain in sync?
>>> NUM_ACPI_PAGES is private to this file.
>>>
>>> ACPI_PHYSICAL_ADDRESS (RSDP pointer) needs to be between 0xe0000 and 
>>> 0xfffff, I picked this number because that's where most systems that I have 
>>> appear to have it. (And by "most" I mean the two that I checked ;-))
>> With there not being a BIOS, I can see this being pretty arbitrary.
>> Yet in that case I'm not convinced of this getting put at a random
>> address in the middle. 
> 
> I can put it in the beginning, at 0xe0000.

I'd rather see it put higher up, close below 1Mb.

>> Plus I'm not sure I see the connection to the
>> reservations done in the E820 map the guest gets to see.
> 
> I thought ACPI data is supposed to live in reserved areas (ACPI data,
> actually)?

Correct - but where is such an E820 entry being produced for the
guest?

>>> RESERVED_MEMORY_DYNAMIC_START is one page after DSDT's SystemMemory (aka 
>>> ACPI_INFO_PHYSICAL_ADDRESS). But then it looks like PVHv2 doesn't need 
>>> SystemMemory so it can be anywhere (and e820 should presumably be aware of 
>>> this, which it is not right now)
>> So you say there's no connection to the end of hvmloader's window
>> for PCI MMIO assignments (an equivalent of which is going to be
>> needed for PVHv2)?
> 
> I haven't thought about this but then we don't have MMIO hole now. I can
> try finding available memory chunk in guest's memory under 4G.

Well, we first need to settle on the intended memory layout.
And then we need to put this down in exactly one place, for all
players to consume (and adhere to).

>> But note that as soon as
>> you report processors in MADT, the combined set of tables holding
>> AML code can't be empty anymore: Processors need to be
>> declared using Processor() (legacy) or Device(). Maybe we don't
>> need as much as an ordinary HVM guest, but nothing seems too little.
> 
> I will add Processor.

And did you check whether there's something else that's
mandatory (or even just kind of, due to e.g. ACPI CA relying
on it)?

Jan

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