From: SeongJae Park
On Tue, 24 Aug 2021 23:24:51 -0700 CGEL wrote:
> From: Jing Yangyang
>
> Use BUG_ON instead of a if condition followed by BUG.
>
> Generated by: scripts/coccinelle/misc/bugon.cocci
>
> Reported-by: Zeal Robot
> Signed-off-by: Jing Yangyang
Reviewed-by: SeongJae Park
branch xen-4.14-testing
xenbranch xen-4.14-testing
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
On 25.08.2021 07:44, Oleksandr Andrushchenko wrote:
> Hi, Jan!
>
> On 24.08.21 19:09, Jan Beulich wrote:
>> On 19.08.2021 14:02, Rahul Singh wrote:
>>> --- a/xen/drivers/passthrough/pci.c
>>> +++ b/xen/drivers/passthrough/pci.c
>>> @@ -767,6 +767,13 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
From: Jing Yangyang
Use BUG_ON instead of a if condition followed by BUG.
Generated by: scripts/coccinelle/misc/bugon.cocci
Reported-by: Zeal Robot
Signed-off-by: Jing Yangyang
---
drivers/xen/xenbus/xenbus_client.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a
From: Jing Yangyang
Use BUG_ON instead of a if condition followed by BUG.
Generated by: scripts/coccinelle/misc/bugon.cocci
Reported-by: Zeal Robot
Signed-off-by: Jing Yangyang
---
drivers/xen/events/events_base.c | 21 -
1 file changed, 8 insertions(+), 13 deletions(-)
On 16.08.2021 20:31, Andrew Cooper wrote:
> On 16/08/2021 16:31, Jan Beulich wrote:
>> While already the case for PVH, there's no reason to treat PV
>> differently here (except of course where to take the addresses from).
>>
>> Signed-off-by: Jan Beulich
>
> Honestly, this is already a mess but I
Hi, Jan!
On 24.08.21 19:09, Jan Beulich wrote:
On 19.08.2021 14:02, Rahul Singh wrote:
--- a/xen/drivers/passthrough/pci.c
+++ b/xen/drivers/passthrough/pci.c
@@ -767,6 +767,13 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
else
iommu_enable_device(pdev);
+#ifdef CONFIG_ARM
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2021年8月25日 1:41
> To: Wei Chen ; xen-devel@lists.xenproject.org;
> sstabell...@kernel.org; jbeul...@suse.com
> Cc: Bertrand Marquis
> Subject: Re: [XEN RFC PATCH 11/40] xen/x86: Move NUMA nodes and memory
> block ranges to comm
flight 164423 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164423/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
flight 164406 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164406/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8dd4fc5be6189666b37e5b00131a4173c6a2b085
baseline version:
ovmf ef56f55d19e1b0b4ba6f9
On 18/08/2021 13:44, Andrew Cooper wrote:
> On 18/08/2021 12:30, Marek Marczykowski-Górecki wrote:
>> set_xcr0() and set_msr_xss() use cached value to avoid setting the
>> register to the same value over and over. But suspend/resume implicitly
>> reset the registers and since percpu areas are not d
flight 164390 xen-4.15-testing real [real]
flight 164452 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164390/
http://logs.test-lab.xenproject.org/osstest/logs/164452/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
flight 164371 xen-4.13-testing real [real]
flight 164442 xen-4.13-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/164371/
http://logs.test-lab.xenproject.org/osstest/logs/164442/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On Tue, 24 Aug 2021, Julien Grall wrote:
> > Some of the thinness of this release in particular relates to an
> > unusual combination of substantial leave taken by many key
> > contributors, so maybe this is a thing we should consider.
> > Even my proposing this schedule was rather late, in part fo
Hi Wei,
On 11/08/2021 11:23, Wei Chen wrote:
These data structures and functions are used to create the
mapping between node and memory blocks. In device tree based
NUMA, we will reuse these data structures and functions, so
we move this part of code from x86 to common.
Signed-off-by: Wei Chen
branch xen-4.12-testing
xenbranch xen-4.12-testing
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
On Tue, Aug 24, 2021 at 04:23:22PM +0100, Julien Grall wrote:
> Hi Anthony,
>
> On 24/08/2021 16:00, Anthony PERARD wrote:
> > Changes to XEN_LDFLAGS may or may not apply to targets in for
> > example "common/" depending on whether one runs `make` or `make
> > common/`.
> >
> >
On 19.08.2021 14:02, Rahul Singh wrote:
> --- a/xen/drivers/passthrough/pci.c
> +++ b/xen/drivers/passthrough/pci.c
> @@ -767,6 +767,13 @@ int pci_add_device(u16 seg, u8 bus, u8 devfn,
> else
> iommu_enable_device(pdev);
>
> +#ifdef CONFIG_ARM
> +ret = vpci_add_handlers(pdev);
>
On 19.08.2021 14:02, Rahul Singh wrote:
> --- /dev/null
> +++ b/xen/drivers/passthrough/msi.c
> @@ -0,0 +1,96 @@
> +/*
> + * Copyright (C) 2008, Netronome Systems, Inc.
While generally copying copyright statements when splitting source
files is probably wanted (or even necessary) I doubt this is
On 24.08.2021 12:28, Juergen Gross wrote:
> It should be mentioned that a similar series has been posted some years
> ago by Marek Marczykowski-Górecki, but this series has not been applied
> due to a Xen header not having been available in the Xen git repo at
> that time. Additionally my series is
On 24.08.2021 12:28, Juergen Gross wrote:
> Today netfront will trust the backend to send only sane response data.
> In order to avoid privilege escalations or crashes in case of malicious
> backends verify the data to be within expected limits. Especially make
> sure that the response always refer
On 24.08.2021 12:28, Juergen Gross wrote:
> In order to avoid a malicious backend being able to influence the local
> processing of a request build the request locally first and then copy
> it to the ring page. Any reading from the request influencing the
> processing in the frontend needs to be do
Hi Anthony,
On 24/08/2021 16:00, Anthony PERARD wrote:
On Tue, Aug 24, 2021 at 01:50:33PM +0100, Julien Grall wrote:
Hi Anthony,
Can you explain why this is moved?
Well, it was in the wrong place, it is best to avoid making changes to
XEN_CFLAGS or XEN_LDFLAGS in Makefile in subdirectories a
Hi Anthony,
On 24/08/2021 16:12, Anthony PERARD wrote:
On Tue, Aug 24, 2021 at 01:53:11PM +0100, Julien Grall wrote:
Hi Anthony,
On 24/08/2021 11:49, Anthony PERARD wrote:
head.o is been built twice, once because it is in $(ALL_OBJS) and a
second time because it is in $(extra-y) and thus it i
On 24.08.2021 15:39, Andrew Cooper wrote:
> On 19/08/2021 15:59, Jan Beulich wrote:
>> On 17.08.2021 16:30, Andrew Cooper wrote:
>>> The opencoded legacy Memory Disambiguation logic in init_amd() neglected
>>> Fam19h for the Zen3 microarchitecture.
>>>
>>> In practice, all Zen2 based system (AMD Fa
On 24.08.2021 15:26, Andrew Cooper wrote:
> On 19/08/2021 15:47, Jan Beulich wrote:
>> On 17.08.2021 16:30, Andrew Cooper wrote:
>>> There is a step change in speculation protections between the Zen1 and Zen2
>>> microarchitectures.
>>>
>>> Zen1 and older have no special support. Control bits in n
On Tue, Aug 24, 2021 at 01:53:11PM +0100, Julien Grall wrote:
> Hi Anthony,
>
> On 24/08/2021 11:49, Anthony PERARD wrote:
> > head.o is been built twice, once because it is in $(ALL_OBJS) and a
> > second time because it is in $(extra-y) and thus it is rebuilt when
> > building "arch/arm/built_in
On 24.08.21 15:38, Ian Jackson wrote:
Julien Grall writes ("Re: Xen 4.16: Proposed release manager and schedule"):
On 19/08/2021 16:36, Ian Jackson wrote:
One option is to slip the whole release, in the expectation (hope!) of
collecting more input. In practical terms because of the impact of
C
On Tue, Aug 24, 2021 at 01:50:33PM +0100, Julien Grall wrote:
> Hi Anthony,
>
> Can you explain why this is moved?
Well, it was in the wrong place, it is best to avoid making changes to
XEN_CFLAGS or XEN_LDFLAGS in Makefile in subdirectories as those are
exported variable and may not work as expe
On Tue, Aug 24, 2021, 2:20 PM Jan Beulich wrote:
> On 18.08.2021 22:29, Bobby Eshleman wrote:
> > --- /dev/null
> > +++ b/xen/include/asm-x86/gdbsx.h
> > @@ -0,0 +1,17 @@
> > +#ifndef __X86_GDBX_H
> > +#define __X86_GDBX_H__
> > +
> > +#ifdef CONFIG_GDBSX
> > +
> > +int gdbsx_guest_mem_io(domid_t
On 24.08.2021 16:26, Jan Beulich wrote:
> For one none of the three IOMMU implementations on Arm specify a dumping
> hook. Generalize VT-d's "don't dump shared page tables" to cover for
> this.
>
> Further in the past I was told that on Arm in principle there could be
> multiple different IOMMUs,
map_domain_page() et al never fail; no need to check their return values
against NULL, and no need to carry dead printk()s.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/pci_amd_iommu.c
+++ b/xen/drivers/passthrough/amd/pci_amd_iommu.c
@@ -530,12 +530,6 @@ static void amd_dump_pag
Besides the addresses this is the next crucial bit of information one
might be after.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2822,10 +2822,12 @@ static void vtd_dump_page_table_level(pa
vtd_dump_page_table_l
For one none of the three IOMMU implementations on Arm specify a dumping
hook. Generalize VT-d's "don't dump shared page tables" to cover for
this.
Further in the past I was told that on Arm in principle there could be
multiple different IOMMUs, and hence different domains' platform_ops
pointers c
... depending on feature availability (and absence of quirks).
Also make the page table dumping function aware of superpages.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -756,18 +756,37 @@ static int __must_check iommu_flush_
Hi Claire,
On Thu, Jun 24, 2021 at 11:55:24PM +0800, Claire Chang wrote:
> Add the initialization function to create restricted DMA pools from
> matching reserved-memory nodes.
>
> Regardless of swiotlb setting, the restricted DMA pool is preferred if
> available.
>
> The restricted DMA pools pr
No separate feature flags exist which would control availability of
these; the only restriction is HATS (establishing the maximum number of
page table levels in general), and even that has a lower bound of 4.
Thus we can unconditionally announce 2M, 1G, and 512G mappings. (Via
non-default page size
In order to free intermediate page tables when replacing smaller
mappings by a single larger one callers will need to know the full PTE.
Flush indicators can be derived from this in the callers (and outside
the locked regions). First split set_iommu_pte_present() from
set_iommu_ptes_present(): Only
This is to aid diagnosing issues and largely matches VT-d's behavior.
Since I'm adding permissions output here as well, take the opportunity
and also add their displaying to amd_dump_page_table_level().
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu.h
+++ b/xen/drivers/passth
I think this flush was overlooked when flushing was moved out of the
core (un)mapping functions. The flush the caller is required to invoke
anyway will satisfy the needs resulting from the splitting of a
superpage.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xe
For vendor specific code to support superpages we need to be able to
deal with a superpage mapping replacing an intermediate page table (or
hierarchy thereof). Consequently an iommu_alloc_pgtable() counterpart is
needed to free individual page tables while a domain is still alive.
Since the freeing
For large page mappings to be easily usable (i.e. in particular without
un-shattering of smaller page mappings) and for mapping operations to
then also be more efficient, pass batches of Dom0 memory to iommu_map().
In dom0_construct_pv() and its helpers (covering strict mode) this
additionally requ
While already the case for PVH, there's no reason to treat PV
differently here, though of course the addresses get taken from another
source in this case. Except that, to match CPU side mappings, by default
we permit r/o ones. This then also means we now deal consistently with
IO-APICs whose MMIO i
Introduce a helper function to determine the largest possible mapping
that allows covering a request (or the next part of it that is left to
be processed).
In order to not add yet more recurring dfn_add() / mfn_add() to the two
callers of the new helper, also introduce local variables holding the
flight 164435 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/164435/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Or really, in the case of ->map_page(), accommodate it in th existing
"flags" parameter. All call sites will pass 0 for now.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu.h
+++ b/xen/drivers/passthrough/amd/iommu.h
@@ -225,6 +225,7 @@ int __must_check amd_iommu_map_page(stru
Generic code will use this information to determine what order values
can legitimately be passed to the ->{,un}map_page() hooks. For now all
ops structures simply get to announce 4k mappings (as base page size),
and there is (and always has been) an assumption that this matches the
CPU's MMU base p
In order to be able to insert/remove super-pages we need to allow
callers of the walking function to specify at which point to stop the
walk.
For intel_iommu_lookup_page() integrate the last level access into
the main walking function.
dma_pte_clear_one() gets only partly adjusted for now: Error
In order to be able to insert/remove super-pages we need to allow
callers of the walking function to specify at which point to stop the
walk. (For now at least gcc will instantiate just a variant of the
function with the parameter eliminated, so effectively no change to
generated code as far as the
Both callers only care about the target (level 1) MFN. I also cannot
see what we might need higher level MFNs for down the road. And even
modern gcc doesn't recognize the optimization potential.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthroug
For a long time we've been rather inefficient with IOMMU page table
management when not sharing page tables, i.e. in particular for PV (and
further specifically also for PV Dom0) and AMD (where nowadays we never
share page tables). While up to about 2.5 years ago AMD code had logic
to un-shatter pa
On 24.08.2021 15:38, Ian Jackson wrote:
> Julien Grall writes ("Re: Xen 4.16: Proposed release manager and schedule"):
>> On 19/08/2021 16:36, Ian Jackson wrote:
>>> One option is to slip the whole release, in the expectation (hope!) of
>>> collecting more input. In practical terms because of the
On 19/08/2021 15:59, Jan Beulich wrote:
> On 17.08.2021 16:30, Andrew Cooper wrote:
>> The opencoded legacy Memory Disambiguation logic in init_amd() neglected
>> Fam19h for the Zen3 microarchitecture.
>>
>> In practice, all Zen2 based system (AMD Fam17h Model >= 0x30 and Hygon Fam18h
>> Model >= 0
Julien Grall writes ("Re: Xen 4.16: Proposed release manager and schedule"):
> On 19/08/2021 16:36, Ian Jackson wrote:
> > One option is to slip the whole release, in the expectation (hope!) of
> > collecting more input. In practical terms because of the impact of
> > Christmas and New Year on man
On 19/08/2021 15:47, Jan Beulich wrote:
> On 17.08.2021 16:30, Andrew Cooper wrote:
>> There is a step change in speculation protections between the Zen1 and Zen2
>> microarchitectures.
>>
>> Zen1 and older have no special support. Control bits in non-architectural
>> MSRs are used to make lfence
On 24.08.2021 15:03, Costin Lupu wrote:
> On 8/23/21 8:16 PM, Julien Grall wrote:
>> On 20/08/2021 10:26, Jan Beulich wrote:
>>> On 20.08.2021 11:08, Julien Grall wrote:
On 20/08/2021 08:44, Costin Lupu wrote:
> On 8/20/21 9:52 AM, Jan Beulich wrote:
>>> --- /dev/null
>>> +++ b/xen
On 24.08.2021 14:57, Andrew Cooper wrote:
> On 19/08/2021 15:38, Jan Beulich wrote:
>> On 17.08.2021 16:30, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/spec_ctrl.c
>>> +++ b/xen/arch/x86/spec_ctrl.c
>>> @@ -317,23 +317,30 @@ static void __init print_details(enum ind_thunk
>>> thunk, uint64_t caps)
On 24.08.2021 14:41, Andrew Cooper wrote:
> On 24/08/2021 13:16, Jan Beulich wrote:
>> On 18.08.2021 22:29, Bobby Eshleman wrote:
>>> Unlike debugger_trap_fatal() and debugger_trap_immediate(),
>>> debugger_trap_entry() is specific to guest debugging and *NOT* the
>>> debugging of Xen itself. That
On 19.08.2021 18:26, Andrew Cooper wrote:
> In some configurations, it is safe to not overwrite the RSB on entry to Xen.
> Both Intel and AMD have guidelines in this area, because of the performance
> difference it makes for native kernels.
I don't think I've come across AMD's guidelines - would y
Hi guys,
On 8/23/21 8:16 PM, Julien Grall wrote:
> Hi Jan,
>
> On 20/08/2021 10:26, Jan Beulich wrote:
>> On 20.08.2021 11:08, Julien Grall wrote:
>>> On 20/08/2021 08:44, Costin Lupu wrote:
On 8/20/21 9:52 AM, Jan Beulich wrote:
>> --- /dev/null
>> +++ b/xen/include/public/page.h
>>
On 19/08/2021 15:38, Jan Beulich wrote:
> On 17.08.2021 16:30, Andrew Cooper wrote:
>> Separate the read-only hints from the features requiring active actions on
>> Xen's behalf.
>>
>> Also take the opportunity split the IBRS/IBPB and IBPB mess. More features
>> with overlapping enumeration are on
Hi Anthony,
On 24/08/2021 11:49, Anthony PERARD wrote:
head.o is been built twice, once because it is in $(ALL_OBJS) and a
second time because it is in $(extra-y) and thus it is rebuilt when
building "arch/arm/built_in.o".
Fix this by adding a dependency of "head.o" on the directory
"arch/arm/"
Hi Anthony,
Can you explain why this is moved?
Cheers,
On 24/08/2021 11:49, Anthony PERARD wrote:
Signed-off-by: Anthony PERARD
---
xen/arch/arm/Makefile | 8
xen/arch/arm/arch.mk | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/Makefile
Hi,
On 18/08/2021 21:29, Bobby Eshleman wrote:
This commit allows non-x86 architecture to omit the file asm/debugger.h
if they do not require it. It changes debugger.h to be a general
xen/debugger.h which, if CONFIG_CRASH_DEBUG, resolves to include
asm/debugger.h.
It also changes all asm/debug
Hi Bobby,
On 18/08/2021 21:29, Bobby Eshleman wrote:
ARM doesn't actually use debugger_trap_* anything, and is stubbed out.
I am guessing the plan was to add support for debugging support on Arm.
But it never made it and it should be easy to re-introduce. So...
This commit simply removes the
On 24/08/2021 13:16, Jan Beulich wrote:
> On 18.08.2021 22:29, Bobby Eshleman wrote:
>> Unlike debugger_trap_fatal() and debugger_trap_immediate(),
>> debugger_trap_entry() is specific to guest debugging and *NOT* the
>> debugging of Xen itself. That is, it is part of gdbsx functionality and
>> not
On 18.08.2021 22:29, Bobby Eshleman wrote:
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -36,6 +36,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -58,7 +59,6 @@
> #include
> #include
> #include
> -#include
>
On 18.08.2021 22:29, Bobby Eshleman wrote:
> --- a/xen/arch/x86/gdbsx.c
> +++ b/xen/arch/x86/gdbsx.c
> @@ -151,33 +151,23 @@ static unsigned int dbg_rw_guest_mem(struct domain *dp,
> unsigned long addr,
> return len;
> }
>
> -/*
> - * addr is guest addr
> - * buf is debugger buffer.
> - *
On 18.08.2021 22:29, Bobby Eshleman wrote:
> --- /dev/null
> +++ b/xen/include/asm-x86/gdbsx.h
> @@ -0,0 +1,17 @@
> +#ifndef __X86_GDBX_H
> +#define __X86_GDBX_H__
> +
> +#ifdef CONFIG_GDBSX
> +
> +int gdbsx_guest_mem_io(domid_t domid, struct xen_domctl_gdbsx_memio *iop);
> +
> +#else
> +
> +static
On 18.08.2021 22:29, Bobby Eshleman wrote:
> Unlike debugger_trap_fatal() and debugger_trap_immediate(),
> debugger_trap_entry() is specific to guest debugging and *NOT* the
> debugging of Xen itself. That is, it is part of gdbsx functionality and
> not the Xen gdstub. This is evidenced by debugger
On 24.08.2021 11:50, Penny Zheng wrote:
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -609,6 +609,29 @@ static void __init init_pdx(void)
> }
> }
>
> +#ifdef CONFIG_STATIC_MEMORY
> +/* Static memory initialization */
> +static void __init init_staticmem_pages(void)
> +{
> +
On 18/08/2021 21:29, Bobby Eshleman wrote:
> diff --git a/xen/include/xen/debugger.h b/xen/include/xen/debugger.h
> new file mode 100644
> index 00..166fad9d2e
> --- /dev/null
> +++ b/xen/include/xen/debugger.h
> @@ -0,0 +1,51 @@
> +/*
On 18/08/2021 21:29, Bobby Eshleman wrote:
> Because dbg_rw_mem() has only a single call site, this commit
> expands it inline.
Missing a SoB.
Otherwise, looks ok.
On 18/08/2021 21:29, Bobby Eshleman wrote:
> diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
> index fe38cfd544..ef8c2c4770 100644
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -20,7 +20,7 @@ obj-y += cpuid.o
> obj-$(CONFIG_PV) += compat.o
> obj-$(CONFIG_PV32) += x86
On 18/08/2021 21:29, Bobby Eshleman wrote:
> diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
> index e60af16ddd..d0a4c0ea74 100644
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -858,13 +858,20 @@ static void do_trap(struct cpu_user_regs *regs)
> if ( regs->error_code
On 24.08.2021 11:50, Penny Zheng wrote:
> +/*
> + * Acquire nr_mfns contiguous reserved pages, starting at #smfn, of
> + * static memory.
> + * This function needs to be reworked if used outside of boot.
> + */
> +static struct page_info * __init acquire_staticmem_pages(mfn_t smfn,
> +
Temporary fix the list of headers that cmdline.c and reloc.c depends
on, until the next time the list is out of sync again.
Also, add the linker script to the list.
Signed-off-by: Anthony PERARD
---
xen/arch/x86/boot/Makefile | 9 ++---
xen/arch/x86/boot/build32.mk | 2 +-
2 files changed
GNU Make will try to rebuild every Makefile included with the
"include" directive, so everytime Config.mk is used, make will try to
build ".config". This would normally not be an issue, unless we happen
to have a rules which match. This is the case with Kconfig in xen/.
While we had a workaround i
A subdirectory is now built by setting "$(obj)" instead of changing
directory. "$(obj)" should always be set when using "Rules.mk" and
thus a shortcut "$(build)" is introduced and should be used.
A new variable "$(need-builtin)" is introduce. It is to be used
whenever a "built_in.o" is wanted from
Signed-off-by: Anthony PERARD
---
xen/arch/x86/Makefile | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 8d789d25a3ff..4ea8ade7202c 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -81,6 +81,10
Rather than preparing the efi source file, we will copy them as needed
from the build location.
Avoid the links as they seems fragile in out-of-tree builds. Also by
making a copy, we don't need to figure out the relative path or we
don't need to use absolute path.
Signed-off-by: Anthony PERARD
-
Signed-off-by: Anthony PERARD
---
xen/Makefile | 1 +
xen/scripts/Makefile.clean | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/xen/Makefile b/xen/Makefile
index 1dad20a95be6..f07c9251c030 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -382,6 +382,7 @@ _clean
This will allow $(HOSTCFLAGS) to actually be used when building
programmes for the build-host.
The other variable don't exist in our build system.
Also remove $(KBUILD_EXTMOD) since it should always be empty.
Signed-off-by: Anthony PERARD
---
xen/scripts/Makefile.host | 26
For two reasons: this macro is used to generate a "linker script" and
is not by the linker, and name starting with an underscore '_' are
supposed to be reserved, so better avoid them when not needed.
Signed-off-by: Anthony PERARD
---
xen/Rules.mk | 2 +-
xen/arch/arm/include
Listing public headers when out-of-tree build are involved becomes
more annoying where every path to every headers needs to start with
"$(srctree)/$(src)", or $(wildcard ) will not work. This means more
repetition.
This patch attempt to reduce the amount of duplication and make better
use of make'
This will make out-of-tree build easier.
Signed-off-by: Anthony PERARD
---
xen/Makefile | 8
xen/tools/Makefile | 17 ++---
2 files changed, 6 insertions(+), 19 deletions(-)
diff --git a/xen/Makefile b/xen/Makefile
index 0da08bc39930..8381ffd5d168 100644
--- a/xen/Ma
This rework the livepatch/Makefile to make it less repetitive and make
use of the facilities. All the targets to be built are now listed in
$(extra-y) which will allow Rules.mk to build them without the need of
a local target in a future patch.
There are some changes/fixes in this patch:
- when "x
This will avoid regenerating "compile.h" if the content hasn't changed.
As it's currently the case, the file isn't regenerated during `sudo
make install` if it exist and does belong to a different user, thus we
can remove the target "delete-unfresh-files". Target "$(TARGET)" still
need a phony dep
Avoid different spelling for the location of "xen-syms", and simply
use the dependency variable. This avoid the assumption about $(TARGET)
value.
Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
---
Notes:
v7:
- fix typo in title
xen/arch/x86/Makefile | 2 +-
1 file changed, 1 inse
This just remove duplication.
Signed-off-by: Anthony PERARD
---
xen/Makefile | 3 +++
xen/arch/arm/arch.mk | 3 ---
xen/arch/riscv/arch.mk | 2 --
xen/arch/x86/arch.mk | 2 --
4 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/xen/Makefile b/xen/Makefile
index 8381ffd5d
This is to avoid arch/$arch/Makefile having to recurse into parents
directories.
This avoid duplication of the logic to build prelink.o between arches.
In order to do that, we cut the $(TARGET) target in the main Makefile in
two, there is a "prepare" phase/target runned before starting to build
"
Currently, the xen/Makefile is re-parsed several times: once to start
the build process, and several more time with Rules.mk including it.
This makes it difficult to reason with a Makefile used for several
purpose, and it actually slow down the build process.
So this patch introduce "build.mk" whi
I guess it's easier to remember that %.E does "$(CC) -E" or "$(CPP)".
Suggested-by: Andrew Cooper
Signed-off-by: Anthony PERARD
---
xen/Makefile | 4 ++--
xen/Rules.mk | 5 +
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/xen/Makefile b/xen/Makefile
index d27c213c3aa9..91b34
This will be used for xen/tools/.
Signed-off-by: Anthony PERARD
---
xen/Rules.mk | 10 +-
xen/scripts/Makefile.clean | 3 ++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index 760ccff0e8f1..1e1839c4b629 100644
--- a/xen/Rules
This will allow "clean" to work from an out-of-tree build when
it will be available.
Some of the file been removed in current "clean" target aren't added
to $(clean-files) because they are already listed in $(extra-) or
$(extra-y).
Also clean files in "arch/x86/boot" from that directory by allowi
$(public-y) contains "public/arch-%" but when used by
$(PUBLIC_HEADERS) $(public-y) is filtered-out by the pattern
"public/arch-%". So $(public-y) content is never used.
Signed-off-by: Anthony PERARD
---
Notes:
v7:
- new patch
xen/include/Makefile | 5 +
1 file changed, 1 insertion
$(srctree) is a better description for the source directory than
$(BASEDIR) that has been used for both source and build directory
(which where the same).
"clean" is still changing directory, so we need to use absolute path
for it.
Signed-off-by: Anthony PERARD
---
xen/Kconfig |
When assigning a value a target-specific variable, that also affect
prerequisite of the target. This is mostly fine, but there is one case
where we will not want the COV_FLAGS added to the CFLAGS.
In arch/x86/boot, we have "head.o" with "cmdline.S" as prerequisite
and ultimately "cmdline.o", we do
Rework "arch/x86/boot/Makefile" to allow it to build both file
"cmdline.S" and "reloc.S" without "build32.mk".
These will now use the main rules for "%.o: %.c", and thus generate a
dependency file. (We will not need to track the dependency manually
anymore.)
But for that, we need to override the
This macro does compare command line like if_changed, but it also
rewrite the dependencies generated by $(CC) in order to depend on a
CONFIG_* as generated by kconfig instead of depending on autoconf.h.
This allow to make a change in kconfig options and only rebuild the
object that uses that CONFIG
1 - 100 of 151 matches
Mail list logo
