From: Boris Ostrovsky <boris.ostrovsky@oracle.com>
To: Jan Beulich <JBeulich@suse.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, 7 Jun 2016 10:47:16 -0400 [thread overview]
Message-ID: <5756DE74.6010204@oracle.com> (raw)
In-Reply-To: <5756F1EF02000078000F2A23@prv-mh.provo.novell.com>
On 06/07/2016 10:10 AM, Jan Beulich wrote:
>>>> 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?
It's not. I actually mentioned this in cover letter.
I prototyped this at some point in libxl__arch_domain_construct_memmap().
>
>>>> 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).
On the few systems that I looked at they are placed right before the
MMIO region.
How about (HVM_BELOW_4G_RAM_END - NUM_ACPI_PAGES)?
>
>>> 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)?
I didn't check the spec but as far as ACPICA is concerned --- this was
tested with PVHv2 Linux and I think Roger ran this version on FreeBSD.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-06-07 14:47 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-06 1:25 [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 01/20] hvmloader: Provide hvmloader_acpi_build_tables() Boris Ostrovsky
2016-06-02 12:42 ` Jan Beulich
2016-06-02 16:39 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 02/20] acpi/hvmloader: Move acpi_info initialization out of ACPI code Boris Ostrovsky
2016-06-02 12:54 ` Jan Beulich
2016-06-02 16:54 ` Boris Ostrovsky
2016-06-03 12:13 ` Jan Beulich
2016-06-03 14:42 ` Boris Ostrovsky
2016-06-03 14:55 ` Jan Beulich
2016-06-03 15:29 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 03/20] acpi/hvmloader: Initialize vm_gid data outside " Boris Ostrovsky
2016-06-02 13:03 ` Jan Beulich
2016-06-02 17:01 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 04/20] acpi/hvmloader: Decide which SSDTs to build in hvmloader Boris Ostrovsky
2016-06-02 13:07 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 05/20] acpi/hvmloader: Move passthrough initialization from ACPI code Boris Ostrovsky
2016-06-02 13:52 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 06/20] acpi/hvmloader: Collect processor and NUMA info in hvmloader Boris Ostrovsky
2016-06-02 14:05 ` Jan Beulich
2016-06-02 17:18 ` Boris Ostrovsky
2016-06-03 12:16 ` Jan Beulich
2016-06-03 14:49 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 07/20] acpi/hvmloader: Set TIS header address " Boris Ostrovsky
2016-06-02 14:09 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 08/20] acpi/hvmloader: Make providing IOAPIC in MADT optional Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 09/20] acpi/hvmloader: Build WAET optionally Boris Ostrovsky
2016-06-02 14:32 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 10/20] acpi/hvmloader: Provide address of acpi_info as an argument to ACPI code Boris Ostrovsky
2016-06-03 16:03 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 11/20] acpi/hvmloader: Translate all addresses when assigning addresses in ACPI tables Boris Ostrovsky
2016-06-06 10:48 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 12/20] acpi/hvmloader: Link ACPI object files directly Boris Ostrovsky
2016-06-06 11:04 ` Jan Beulich
2016-06-06 14:20 ` Boris Ostrovsky
2016-06-06 14:29 ` Jan Beulich
2016-06-06 14:49 ` Boris Ostrovsky
2016-06-06 14:57 ` Jan Beulich
2016-06-06 15:31 ` Andrew Cooper
2016-06-06 15:41 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 13/20] acpi/hvmloader: Add stdio.h, string.h and x86.h Boris Ostrovsky
2016-06-06 11:31 ` Jan Beulich
2016-06-06 15:08 ` Boris Ostrovsky
2016-06-06 15:22 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 14/20] acpi/hvmloader: Replace mem_alloc() and virt_to_phys() with memory ops Boris Ostrovsky
2016-06-06 12:58 ` Jan Beulich
2016-06-06 15:46 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 15/20] acpi: Move ACPI code to xen/common/libacpi Boris Ostrovsky
2016-06-06 13:05 ` Jan Beulich
2016-06-06 16:09 ` Boris Ostrovsky
2016-06-07 6:20 ` Jan Beulich
2016-06-07 12:24 ` Roger Pau Monné
2016-06-07 14:32 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 16/20] x86/vlapic: Don't try to accept 8259 interrupt if !has_vpic() Boris Ostrovsky
2016-06-03 16:14 ` Jan Beulich
2016-06-03 17:50 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 17/20] x86: Allow LAPIC-only emulation_flags for HVM guests Boris Ostrovsky
2016-06-03 16:18 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 18/20] libxc/acpi: Build ACPI tables for HVMlite guests Boris Ostrovsky
2016-06-02 16:26 ` Roger Pau Monné
2016-06-06 12:03 ` Wei Liu
2016-06-06 15:15 ` Boris Ostrovsky
2016-06-16 8:54 ` Wei Liu
2016-06-16 13:07 ` Boris Ostrovsky
2016-06-06 13:29 ` Jan Beulich
2016-06-06 16:59 ` Boris Ostrovsky
2016-06-07 6:17 ` Jan Beulich
2016-06-07 13:59 ` Boris Ostrovsky
2016-06-07 14:10 ` Jan Beulich
2016-06-07 14:47 ` Boris Ostrovsky [this message]
2016-06-07 15:00 ` Jan Beulich
2016-04-06 1:25 ` [PATCH RFC 19/20] acpi: Set HW_REDUCED_ACPI in FADT if IOAPIC is not supported Boris Ostrovsky
2016-06-06 13:38 ` Jan Beulich
2016-06-06 17:31 ` Boris Ostrovsky
2016-06-07 6:06 ` Jan Beulich
2016-06-07 14:02 ` Boris Ostrovsky
2016-06-07 14:12 ` Jan Beulich
2016-06-07 15:17 ` Boris Ostrovsky
2016-06-07 15:41 ` Jan Beulich
2016-06-08 22:04 ` Boris Ostrovsky
2016-06-09 8:13 ` Roger Pau Monné
2016-06-09 8:41 ` Jan Beulich
2016-06-09 14:09 ` Boris Ostrovsky
2016-04-06 1:25 ` [PATCH RFC 20/20] acpi: Make ACPI builder available to hypervisor code Boris Ostrovsky
2016-06-06 13:48 ` Jan Beulich
2016-05-09 20:10 ` [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader Boris Ostrovsky
2016-05-10 7:25 ` Jan Beulich
2016-06-02 12:40 ` Jan Beulich
2016-06-02 16:37 ` Boris Ostrovsky
2016-06-03 7:18 ` Roger Pau Monné
2016-06-03 10:08 ` Jan Beulich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5756DE74.6010204@oracle.com \
--to=boris.ostrovsky@oracle.com \
--cc=JBeulich@suse.com \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).