xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: xen-devel@lists.xen.org, roger.pau@citrix.com
Subject: Re: [PATCH RFC 00/20] Make ACPI builder available to components other than hvmloader
Date: Thu, 02 Jun 2016 06:40:35 -0600	[thread overview]
Message-ID: <5750456302000078000F0F86@prv-mh.provo.novell.com> (raw)
In-Reply-To: <1459905949-10358-1-git-send-email-boris.ostrovsky@oracle.com>

>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> This is an RFC for making hvmloader's ACPI builder available to both the
> toolstack and the hypervisor, as discussed in
> http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg01228.html 
> 
> The series
> * Removes dependency of today's builder on hvmloader interfaces
> * Makes many of the tables built optionally.
> * Moves tools/hvmloader/acpi directory to xen/common/libacpi
> * Builds tables for PVHv2 domU guests in libxc
> 
> There is still a number of questions about this implementation, thus it's
> an RFC. Examples of things that need to be discussed are
> 
> * ACPI tables are built for PVHv2 guests unconditionally. We probably want
>   to make this an option.
> * Not sure about header files, especially xen/common/libacpi/x86.h and 
>   tools/firmware/hvmloader/{stdio.h,string.h} 
> * The builder is compiled into the hypervisor even though currently
>   there are no users (PVHv2 dom0 will be the one)

Is that really what we want? I thought we don't really mean to
build ACPI tables from scratch for Dom0, but rather follow ARM's
customization approach. And if we don't want this, then the
placement of this now shared code would need reconsidering.

Jan


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

  parent reply	other threads:[~2016-06-02 12:40 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
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 [this message]
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=5750456302000078000F0F86@prv-mh.provo.novell.com \
    --to=jbeulich@suse.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=roger.pau@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).