From: "Jan Beulich" <JBeulich@suse.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
xen-devel@lists.xen.org,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Wei Liu <wei.liu2@citrix.com>,
roger.pau@citrix.com
Subject: Re: [PATCH RFC 13/20] acpi/hvmloader: Add stdio.h, string.h and x86.h
Date: Mon, 06 Jun 2016 05:31:36 -0600 [thread overview]
Message-ID: <57557B3802000078000F1FB3@prv-mh.provo.novell.com> (raw)
In-Reply-To: <1459905949-10358-14-git-send-email-boris.ostrovsky@oracle.com>
>>> On 06.04.16 at 03:25, <boris.ostrovsky@oracle.com> wrote:
> Users of ACPI builder will need to provide their own implemetations of
> strncpy(), memcpy, memset() and printf declared in stdio.h and string.h.
> For hvmloader we provide those two as wrappers around utul.h.
>
> Some x86-specific definitions move to ACPI builder's x86.h file so that
> users won't have to re-define them themselves.
>
> Explicitly define a few things that are currently available to to build.c
> via util.h.
Considering the first paragraph, this last sentence was more
confusing than clarifying to me: I expected util.h to get changed
in some way, but aiui having gone through the entire patch this is
just a (very different) re-statement of what you've said already.
> create mode 100644 tools/firmware/hvmloader/acpi/x86.h
> create mode 100644 tools/firmware/hvmloader/stdio.h
> create mode 100644 tools/firmware/hvmloader/string.h
I have to admit that I'm not really looking forward to see the
hypervisor gain a file stdio.h. I'm also not convinced libxc'e
planned use of the libacpi/ would fit well with uses of printf() in
that subtree.
> --- a/tools/firmware/hvmloader/Makefile
> +++ b/tools/firmware/hvmloader/Makefile
> @@ -36,7 +36,7 @@ ACPI_PATH = $(XEN_ROOT)/tools/firmware/hvmloader/acpi
> vpath %.c $(ACPI_PATH)
> ACPI_FILES = dsdt_anycpu.c dsdt_15cpu.c static_tables.c
> dsdt_anycpu_qemu_xen.c build.c
> ACPI_SRC = $(patsubst %.c,$(ACPI_PATH)/%.c,$(ACPI_FILES))
> -CFLAGS += -I$(ACPI_PATH)
> +CFLAGS += -I$(ACPI_PATH) -I.
With the subtree symlink approach, such an addition could then be
limited to just the libacpi/ files, i.e. not affecting core hvmloader ones.
> @@ -30,6 +32,12 @@
>
> #define align16(sz) (((sz) + 15) & ~15)
> #define fixed_strcpy(d, s) strncpy((d), (s), sizeof(d))
> +#ifndef offsetof
> +#define offsetof(t, m) ((unsigned long)&((t *)0)->m)
> +#endif
> +#ifndef NULL
> +#define NULL ((void *)0)
> +#endif
These should be provided by the consumer too, I would say
(stddef.h).
> @@ -41,6 +49,11 @@ extern struct acpi_20_waet Waet;
> /* Number of processor objects in the chosen DSDT. */
> static unsigned int nr_processor_objects;
>
> +static inline int __test_bit(unsigned int b, void *p)
> +{
> + return !!(((uint8_t *)p)[b>>3] & (1u<<(b&7)));
> +}
This one too, without the leading underscores (bitops.h or some
other sbtraction). All three potential consumers of this code already
have test_bit().
> @@ -238,8 +251,6 @@ static struct acpi_20_srat *construct_srat(struct acpi_config *config)
> memory++;
> }
>
> - ASSERT(((unsigned long)memory) - ((unsigned long)p) == size);
I think this was put here for a reason, and hence shouldn't be
removed without good reason (I wouldn't count ASSERT() not being
available as one).
> --- /dev/null
> +++ b/tools/firmware/hvmloader/acpi/x86.h
> @@ -0,0 +1,14 @@
> +#ifndef __ACPI_X86_H__
> +#define __ACPI_X86_H__
> +
> +#define IOAPIC_BASE_ADDRESS 0xfec00000
> +#define IOAPIC_ID 0x01
> +#define IOAPIC_VERSION 0x11
> +
> +#define LAPIC_BASE_ADDRESS 0xfee00000
> +#define LAPIC_ID(vcpu_id) ((vcpu_id) * 2)
> +
> +#define PCI_ISA_DEVFN 0x08 /* dev 1, fn 0 */
> +#define PCI_ISA_IRQ_MASK 0x0c20U /* ISA IRQs 5,10,11 are PCI connected */
Only the latter of those last two is used by build.c. Please limit what
you move to the very minimum. I.e. IOAPIC_VERSION shouldn't move
either imo (and I notice there's a disconnect between it and the
hypervisor's VIOAPIC_VERSION_ID, but that's a pre-existing issue).
> --- a/tools/firmware/hvmloader/hvmloader.c
> +++ b/tools/firmware/hvmloader/hvmloader.c
> @@ -24,6 +24,7 @@
> #include "config.h"
> #include "pci_regs.h"
> #include "apic_regs.h"
> +#include "x86.h"
Looking at an inclusion point like this, it is completely unclear that this
comes from libacpi/. One more argument in favor of keeping the
subtree.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-06-06 11:31 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 [this message]
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
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=57557B3802000078000F1FB3@prv-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=roger.pau@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--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).