On Thu, 2023-01-19 at 13:02 +0000, Alex Bennée wrote: > > David Woodhouse <dw...@infradead.org> writes: > > > From: Joao Martins <joao.m.mart...@oracle.com> > > > > There are already some partial headers in include/hw/xen/interface/ > > which will be removed once we migrate users to the new location. > > > > To start with, define __XEN_TOOLS__ in hw/xen/xen.h to ensure that any > > internal definitions needed by Xen toolstack libraries are present > > regardless of the order in which the headers are included. A reckoning > > will come later, once we make the PV backends work in emulation and > > untangle the headers for Xen-native vs. generic parts. > > > > Signed-off-by: Joao Martins <joao.m.mart...@oracle.com> > > [dwmw2: Update to Xen public headers from 4.16.2 release, add some in io/, > > define __XEN_TOOLS__ in hw/xen/xen.h] > > Signed-off-by: David Woodhouse <d...@amazon.co.uk> > > Reviewed-by: Paul Durrant <p...@xen.org> > > --- > > include/hw/xen/xen.h | 16 +- > > include/standard-headers/xen/arch-x86/cpuid.h | 118 ++ > > Hmm is the sanitising done here by hand? Because for other stuff in > standard-headers we have a script update-linux-headers.sh which says: >
There isn't any sanitising here; these headers are be lifted directly from Xen's xen/include/public/ directory. > # - include/standard-headers/ for files that are used for guest > # device emulation and are required on all hosts. For instance, we > # get our definitions of the virtio structures from the Linux > # kernel headers, but we need those definitions regardless of which > # host OS we are building for. This script has to be careful to > # sanitize the headers to remove any use of Linux-specifics such as > # types like "__u64". This work is done in the cp_portable function. > > Are we just trying to work around having xen-devel (or equivalent) > installed which is where we get definitions for the actual Xen support. Partly (since the point here is to support Xen guests without Xen itself or any of its libraries being present). But it's also to ensure in the emulation parts, we have precisely the version of Xen headers that we expect. We already had *some* of these headers in include/hw/xen/interface/ which I've removed in the next round of patches after some header untangling: https://lore.kernel.org/qemu-devel/20230116221919.1124201-15-dw...@infradead.org/
smime.p7s
Description: S/MIME cryptographic signature
