We change the dependencies of prelink-efi.o so that we can use the
same command line. The dependency on efi/built_in.o isn't needed
because, we already have:
efi/*.o: efi/built_in.o
to build efi/*.o files that prelink-efi.o needs.
Signed-off-by: Anthony PERARD
---
xen/arch/x86/Makefile | 8
In the case where $(obj-y) is empty, we also replace $(c_flags) by
$(XEN_CFLAGS) to avoid generating an .%.d dependency file. This avoid
make trying to include %.h file in the ld command if $(obj-y) isn't
empty anymore on a second run.
Signed-off-by: Anthony PERARD
---
xen/Rules.mk | 13
Rework symbols so it prefer file symbols that names an object file to
file symbols that have a directory component.
But have symbols still prefer the first file symbol if one of the above
is true, or prefer the second file symbols if it names a source file
without directory component.
In a
From: Anthony PERARD
In a later patch ("xen/build: have the root Makefile generates the
CFLAGS), we want to generate the CFLAGS in xen/Makefile, then export
it and have Rules.mk use a CFLAGS from the environment variables. That
changes the flavor of the CFLAGS and flags intended for one target
Use $(dot-target) to have the target name prefix with a dot.
Now, when the CC command has run, it is recorded in .*.cmd
file, then if_changed_rules will compare it on subsequent runs.
Signed-off-by: Anthony PERARD
---
xen/Rules.mk | 26 +-
1 file changed, 17
Only xen/ uses as-option-add and as-insn, so there aren't needed in
Config.mk.
Signed-off-by: Anthony PERARD
---
Notes:
v3:
- new patch
Config.mk | 17 -
xen/scripts/Kbuild.include | 17 +
2 files changed, 17 insertions(+), 17
Those targets make use of $(all_sources) which depends on TARGET_ARCH,
so we just need to set TARGET_ARCH earlier and once.
XEN_TARGET_ARCH isn't expected to change during the build, so
TARGET_SUBARCH and TARGET_ARCH aren't going to change either. Set them
once and for all in the Xen root
The if_changed macro from Linux can record the command used to build a
target then compare it on rebuild. Thus if a command has changed, for
example due to introducing new flags in CFLAGS or due to using a
different compiler, the target will be rebuilt.
if_changed_rule checks dependencies like
Instead of generating the CFLAGS in Rules.mk everytime we enter a new
subdirectory, we are going to generate most of them a single time, and
export the result in the environment so that Rules.mk can use it. The
only flags left to generates are the one that depends on the targets,
but the variable
In Arm and X86 makefile, generating the linker script is the same, so
we can simply have both call the same macro.
We need to add *.lds files into extra-y so that Rules.mk can find the
.*.cmd dependency file and load it.
Signed-off-by: Anthony PERARD
---
xen/Rules.mk | 8
It is unnecessary to make _tests via Rules.mk because the target
use Rules.mk as well.
Signed-off-by: Anthony PERARD
Reviewed-by: Jan Beulich
---
xen/Makefile | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/Makefile b/xen/Makefile
index
It isn't necessary to include Config.mk here because this Makefile is
only used by xen/Rules.mk which already includes Config.mk.
Signed-off-by: Anthony PERARD
Reviewed-by: Jan Beulich
---
xen/include/Makefile | 2 --
1 file changed, 2 deletions(-)
diff --git a/xen/include/Makefile
The top-level makefile make uses of internal implementation detail of
the xen build system. Avoid that by creating a new target
"install-tests" in xen/Makefile, and by fixing the top-level Makefile
to not call xen/Rules.mk anymore.
Signed-off-by: Anthony PERARD
Reviewed-by: Jan Beulich
---
And simply add directly to AFLAGS.
Signed-off-by: Anthony PERARD
---
Notes:
v3:
- new patch
xen/Rules.mk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/Rules.mk b/xen/Rules.mk
index c21203351a9f..154269bfd96c 100644
--- a/xen/Rules.mk
+++ b/xen/Rules.mk
@@
In common/libelf/Makefile, when SECTIONS gets defined
SPECIAL_DATA_SECTIONS doesn't exist, so only "text data" sections are
been renamed. This was different before 48115d14743e ("Move more
kernel decompression bits to .init.* sections").
Move SPECIAL_DATA_SECTIONS in Rules.mk before including
From: Anthony PERARD
Collect all the clean targets as we are going to modify it shortly.
Also, this is inspired by Linux's Kbuild.
"Kbuild.include" isn't included by "Makefile", but the "_clean" target
is only used by Rules.mk which include Kbuild.include.
Signed-off-by: Anthony PERARD
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.build-system-xen-v3
v3:
- new patches that do some cleanup or fix issues
- have rework most patches, to have better commit message or change the coding
style, or fix issues that I've
That comment was introduce by 3943db776371 ("[XEN] Can be built
-std=gnu99 (except for .S files).") to explain why CFLAGS was removed
from the command line. The comment is already written where the
-std=gnu flags gets remove from AFLAGS, no need to repeat it.
Signed-off-by: Anthony PERARD
---
This is part of upgrading our build system and import more of Linux's
one.
In Linux, subdir-y in Makefiles is only used to descend into
subdirectory when there are no object to build, Xen doesn't have that
and all subdir have object to be included in the final binary.
To allow the new syntax,
Hi Paul,
On 25/02/2020 09:53, Paul Durrant wrote:
There's no particular reason shared_info need use a xenheap page.
AFAICT, a side-effect of this change is the shared_info is now going to
be part of the migration stream. One issue with this is on the restore
side, they will be accounted in
From: Anthony PERARD
Most of the code executed by Rules.mk isn't necessary for the clean
target, especially not the CFLAGS. This patch makes running make clean
much faster.
The patch extract the clean target into a different Makefile,
Makefile.clean.
Since Makefile.clean, doesn't want to
The clang test for "asm()-s support .include." needs to be modified
because the symbolic link asm -> asm-x86 may not exist when the test
is runned. Since it's an x86 test, we don't need the link.
This will be an issue with the following patch "xen/build: have the
root Makefile generates the
On 26/02/2020 10:39, Jan Beulich wrote:
> On 26.02.2020 11:09, Roger Pau Monné wrote:
>> On Wed, Feb 26, 2020 at 10:19:19AM +0100, Jan Beulich wrote:
>>> Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
>>> be consulted first.
>>>
>>> Reported-by: Farrah Chen
>>>
On Wed, Feb 26, 2020 at 11:45:40AM +0100, Jan Beulich wrote:
> On 26.02.2020 11:18, Roger Pau Monné wrote:
> > On Wed, Feb 26, 2020 at 11:07:44AM +0100, Jan Beulich wrote:
> >> On 24.02.2020 11:46, Roger Pau Monne wrote:
> >>> Using scratch_cpumask in send_IPI_mask is not safe because it can be
>
On 26.02.2020 11:18, Roger Pau Monné wrote:
> On Wed, Feb 26, 2020 at 11:07:44AM +0100, Jan Beulich wrote:
>> On 24.02.2020 11:46, Roger Pau Monne wrote:
>>> Using scratch_cpumask in send_IPI_mask is not safe because it can be
>>> called from interrupt context, and hence Xen would have to make
On 26.02.2020 10:58, Andrew Cooper wrote:
> On 26/02/2020 09:32, Jan Beulich wrote:
>> On 25.02.2020 18:31, Andrew Cooper wrote:
>>> Policy objects aren't tiny, and the derivation logic isn't trivial. We are
>>> about to increase the number of policy objects, so take this opportunity to
>>> drop
On 26.02.2020 11:09, Roger Pau Monné wrote:
> On Wed, Feb 26, 2020 at 10:19:19AM +0100, Jan Beulich wrote:
>> Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
>> be consulted first.
>>
>> Reported-by: Farrah Chen
>> Signed-off-by: Jan Beulich
>>
>> ---
On 24.02.2020 11:46, Roger Pau Monne wrote:
> Current usage of the per-CPU scratch cpumask is dangerous since
> there's no way to figure out if the mask is already being used except
> for manual code inspection of all the callers and possible call paths.
>
> This is unsafe and not reliable, so
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-qemuu-nested-intel
testid debian-hvm-install/l1/l2
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf
This email only tracks big items for xen.git tree. Please reply for items
you would like to see in 4.14 so that people have an idea what
is going on and prioritise accordingly.
You're welcome to provide description and use cases of the feature you're
working on.
= Timeline =
We now adopt a
On Wed, Feb 26, 2020 at 11:07:44AM +0100, Jan Beulich wrote:
> On 24.02.2020 11:46, Roger Pau Monne wrote:
> > Using scratch_cpumask in send_IPI_mask is not safe because it can be
> > called from interrupt context, and hence Xen would have to make sure
> > all the users of the scratch cpumask
On 26/02/2020 09:19, Jan Beulich wrote:
> Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
> be consulted first.
>
> Reported-by: Farrah Chen
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
On Wed, Feb 26, 2020 at 10:19:19AM +0100, Jan Beulich wrote:
> Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
> be consulted first.
>
> Reported-by: Farrah Chen
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/cpu/vpmu_intel.c
> +++ b/xen/arch/x86/cpu/vpmu_intel.c
>
On 24.02.2020 11:46, Roger Pau Monne wrote:
> Using scratch_cpumask in send_IPI_mask is not safe because it can be
> called from interrupt context, and hence Xen would have to make sure
> all the users of the scratch cpumask disable interrupts while using
> it.
>
> Instead introduce a new cpumask
flight 147631 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147631/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen d90bcb5f10995c52d080274d66bfdc362b22598e
baseline version:
xen
On 26/02/2020 09:32, Jan Beulich wrote:
> On 25.02.2020 18:31, Andrew Cooper wrote:
>> Policy objects aren't tiny, and the derivation logic isn't trivial. We are
>> about to increase the number of policy objects, so take this opportunity to
>> drop logic and storage space based on
On 24.02.2020 11:06, Alexandru Stefan ISAILA wrote:
>
>
> On 21.02.2020 18:39, Jan Beulich wrote:
>> On 21.02.2020 09:30, Alexandru Stefan ISAILA wrote:
>>> @@ -4835,6 +4836,26 @@ static int do_altp2m_op(
>>>break;
>>>}
>>>
>>> +case HVMOP_altp2m_set_visibility:
>>>
On 25.02.2020 18:31, Andrew Cooper wrote:
> Policy objects aren't tiny, and the derivation logic isn't trivial. We are
> about to increase the number of policy objects, so take this opportunity to
> drop logic and storage space based on CONFIG_{PV,HVM}.
It doesn't look as if you were dropping
Just like VMX'es lbr_tsx_fixup_check() the respective CPUID bit should
be consulted first.
Reported-by: Farrah Chen
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/vpmu_intel.c
+++ b/xen/arch/x86/cpu/vpmu_intel.c
@@ -900,7 +900,6 @@ int vmx_vpmu_initialise(struct vcpu *v)
int __init
On Thu, 2020-02-20 at 14:39 +0100, Juergen Gross wrote:
> Currently the memory for each run-queue of the credit2 scheduler is
> allocated at the scheduler's init function: for each cpu in the
> system
> a struct csched2_runqueue_data is being allocated, even if the
> current scheduler only handles
On 26.02.2020 08:13, Julien Grall wrote:
> On 25/02/2020 12:34, Jan Beulich wrote:
>> Further, even if all current implementations obeyed by the more
>> strict rule, this still wouldn't mean callers are actually permitted
>> to assume such. The more strict rule would then also need to be
>>
flight 147536 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147536/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-thunderx 16 guest-start/debian.repeat fail REGR. vs. 147410
Hi,
On 25/02/2020 09:53, Paul Durrant wrote:
... and save the MFN.
This patch modifies the 'shared_info' field of struct domain to be
a structure comprising an MFN and a virtual address. Allocations are
still done from xenheap, so the virtual address still equates to
virt_to_mfn() called on
101 - 143 of 143 matches
Mail list logo
