On 26.02.2020 21:22, Andrew Cooper wrote:
> For now, write the same content for both. Update the users of the
> initialisers to use the new name, and extend xen-cpuid to dump both default
> and max featuresets.
>
> Signed-off-by: Andrew Cooper
Hypervisor and libxc parts
Reviewed-by: Jan Beulich
On 26.02.2020 21:22, Andrew Cooper wrote:
> @@ -76,16 +77,27 @@ void __init init_guest_msr_policy(void)
> {
> calculate_raw_policy();
> calculate_host_policy();
> -calculate_hvm_max_policy();
> -calculate_pv_max_policy();
> +
> +if ( IS_ENABLED(CONFIG_PV) )
> +calcula
On 26.02.2020 21:22, Andrew Cooper wrote:
> For now, the default and max policies remain identical, but this will change
> in the future.
>
> Update XEN_SYSCTL_get_cpu_policy and init_domain_msr_policy() to use the
> default policies.
>
> Take the opportunity sort PV ahead of HVM, as is the preva
On 26.02.2020 21:22, Andrew Cooper wrote:
> CPUID Policy objects are large (1860 bytes at the time of writing), so
> compiling them out based on CONFIG_{PV,HVM} makes a lot of sense.
>
> This involves a bit of complexity in init_domain_cpuid_policy() and
> recalculate_cpuid_policy() as is_pv_domai
On 26.02.2020 21:22, Andrew Cooper wrote:
> For now, the default and max policies remain identical, but this will change
> in the future. Write calculate_{pv,hvm}_def_policy() in a way which will cope
> with simple feature differences for now.
>
> Update XEN_SYSCTL_get_cpu_policy and init_domain_
On 26.02.2020 21:22, Andrew Cooper wrote:
> Allow lowercase a/s/h to be used to annotate a non-default feature.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproje
On 26.02.2020 21:22, Andrew Cooper wrote:
> Memory Protection eXtension support has been dropped from GCC and Linux, and
> will be dropped from future Intel CPUs.
>
> With all other default/max pieces in place, move MPX from default to max.
> This means that VMs won't be offered it by default, but
On Wed, Feb 26, 2020 at 11:33:37AM +, Anthony PERARD wrote:
> 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 t
On 27.02.2020 10:05, Roger Pau Monné wrote:
> On Wed, Feb 26, 2020 at 11:33:37AM +, Anthony PERARD wrote:
>> 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
On Wed, Feb 26, 2020 at 11:33:39AM +, Anthony PERARD wrote:
> 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 h
On 26.02.20 22:26, Gustavo A. R. Silva wrote:
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
On 27/02/2020 07:38, Jan Beulich wrote:
> On 26.02.2020 21:22, Andrew Cooper wrote:
>> Just as with c/s 96dc77b4b1 for XEN_SYSCTL_get_cpu_policy,
>> XEN_SYSCTL_get_cpu_featureset needs to become conditional.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
>
> Albeit I'd say "want",
On 26.02.2020 12:33, Anthony PERARD wrote:
> 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").
Obviously
On 27.02.2020 10:33, Andrew Cooper wrote:
> On 27/02/2020 07:38, Jan Beulich wrote:
>> On 26.02.2020 21:22, Andrew Cooper wrote:
>>> Just as with c/s 96dc77b4b1 for XEN_SYSCTL_get_cpu_policy,
>>> XEN_SYSCTL_get_cpu_featureset needs to become conditional.
>>>
>>> Signed-off-by: Andrew Cooper
>> Rev
On 26.02.2020 12:33, Anthony PERARD wrote:
> --- a/xen/Rules.mk
> +++ b/xen/Rules.mk
> @@ -111,17 +111,14 @@ define gendep
> endef
> $(foreach o,$(filter-out %/,$(obj-y) $(obj-bin-y) $(extra-y)),$(eval $(call
> gendep,$(o
>
> -# Ensure each subdirectory has exactly one trailing slash.
> -s
On 27/02/2020 07:47, Jan Beulich wrote:
> On 26.02.2020 21:22, Andrew Cooper wrote:
>> Drop XC_FEATUREMASK_DEEP_FEATURES. It isn't used by any callers, and unlike
>> the other static masks, won't be of interest to anyone without other pieces
>> of
>> cpuid-autogen.h
>>
>> In xc_get_static_cpu_fea
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-xl-arndale
testid xen-boot
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 git://xenbits.xen.org/osstest/ovmf.git
Tree:
On 27/02/2020 07:57, Jan Beulich wrote:
> On 26.02.2020 21:22, Andrew Cooper wrote:
>> Better split the logic between parse/calculate/write. Collect the feature
>> comment by their comment character, and perform the accumulation operations
>> in
>> crunch_numbers().
> Would you mind saying "chara
On Wed, Feb 26, 2020 at 11:33:46AM +, Anthony PERARD wrote:
> 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.
On 27/02/2020 08:02, Jan Beulich wrote:
> On 26.02.2020 21:22, Andrew Cooper wrote:
>> For now, write the same content for both. Update the users of the
>> initialisers to use the new name, and extend xen-cpuid to dump both default
>> and max featuresets.
>>
>> Signed-off-by: Andrew Cooper
> Hype
On 27.02.2020 11:29, Andrew Cooper wrote:
> On 27/02/2020 08:02, Jan Beulich wrote:
>> On 26.02.2020 21:22, Andrew Cooper wrote:
>>> For now, write the same content for both. Update the users of the
>>> initialisers to use the new name, and extend xen-cpuid to dump both default
>>> and max feature
flight 147600 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147600/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 147298
test-amd64-amd64-qemuu-nested-intel
On 27/02/2020 08:07, Jan Beulich wrote:
> On 26.02.2020 21:22, Andrew Cooper wrote:
>> @@ -76,16 +77,27 @@ void __init init_guest_msr_policy(void)
>> {
>> calculate_raw_policy();
>> calculate_host_policy();
>> -calculate_hvm_max_policy();
>> -calculate_pv_max_policy();
>> +
>> +
From: Wei Liu
The function will map and unmap pages on demand.
Since we now map and unmap Xen PTE pages, we would like to track the
lifetime of mappings so that 1) we do not dereference memory through a
variable after it is unmapped, 2) we do not unmap more than once.
Therefore, we introduce the
On 27/02/2020 08:19, Jan Beulich wrote:
> On 26.02.2020 21:22, Andrew Cooper wrote:
>> For now, the default and max policies remain identical, but this will change
>> in the future. Write calculate_{pv,hvm}_def_policy() in a way which will
>> cope
>> with simple feature differences for now.
>>
On Wed, Feb 26, 2020 at 11:33:47AM +, Anthony PERARD wrote:
> 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
First of all in commit d6573bc6e6b7 ("VT-d: check all of an RMRR for
being E820-reserved") along with changing the function used, the enum-
like value passed should have been changed too (to E820_*). Do so now.
(Luckily the actual values of RAM_TYPE_RESERVED and E820_RESERVED
match, so the breakage
On 27.02.2020 11:37, Andrew Cooper wrote:
> On 27/02/2020 08:07, Jan Beulich wrote:
>> On 26.02.2020 21:22, Andrew Cooper wrote:
>>> @@ -76,16 +77,27 @@ void __init init_guest_msr_policy(void)
>>> {
>>> calculate_raw_policy();
>>> calculate_host_policy();
>>> -calculate_hvm_max_polic
On 27.02.2020 11:55, Andrew Cooper wrote:
> On 27/02/2020 08:19, Jan Beulich wrote:
>> On 26.02.2020 21:22, Andrew Cooper wrote:
>>> For now, the default and max policies remain identical, but this will change
>>> in the future. Write calculate_{pv,hvm}_def_policy() in a way which will
>>> cope
>
On Thu, Feb 27, 2020 at 10:27:39AM +, Hongyan Xia wrote:
> From: Wei Liu
>
> The function will map and unmap pages on demand.
>
> Since we now map and unmap Xen PTE pages, we would like to track the
> lifetime of mappings so that 1) we do not dereference memory through a
> variable after it
Hi Hongyan,
On 27/02/2020 10:27, Hongyan Xia wrote:
From: Wei Liu
The function will map and unmap pages on demand.
Since we now map and unmap Xen PTE pages, we would like to track the
lifetime of mappings so that 1) we do not dereference memory through a
variable after it is unmapped, 2) we d
Hi Hongyan,
On 27/02/2020 11:59, Xia, Hongyan wrote:
On Thu, 2020-02-27 at 11:51 +, Julien Grall wrote:
Hi Hongyan,
On 27/02/2020 10:27, Hongyan Xia wrote:
...
diff --git a/xen/include/xen/domain_page.h
b/xen/include/xen/domain_page.h
index 32669a3339..bfc3bf6aeb 100644
--- a/xen/include/
On Thu, 2020-02-27 at 11:51 +, Julien Grall wrote:
> Hi Hongyan,
>
> On 27/02/2020 10:27, Hongyan Xia wrote:
> > ...
> > diff --git a/xen/include/xen/domain_page.h
> > b/xen/include/xen/domain_page.h
> > index 32669a3339..bfc3bf6aeb 100644
> > --- a/xen/include/xen/domain_page.h
> > +++ b/xen/
It is possible that a ramblock doesn't have memory that QEMU can
access, this is the case with the Xen hypervisor.
In order to avoid to trigger an assert, only call ramblock_ptr() when
needed in qemu_ram_writeback(). This should fix migration of Xen
guests that was broken with bd108a44bc29 ("migra
.git
tags/pull-xen-20200227
for you to fetch changes up to 5d4c954931ba62661c6a1bc16ce604a012a10007:
Memory: Only call ramblock_ptr when needed in qemu_ram_writeback (2020-02-27
11:50:30 +)
Xen queue 2020-02-27
* fix for
From: Paul Durrant
It is not safe to close an event channel from the QEMU main thread when
that channel's poller is running in IOThread context.
This patch adds a new xen_device_set_event_channel_context() function
to explicitly assign the channel AioContext, and modifies
xen_device_bind_event_c
From: Philippe Mathieu-Daudé
xen_pt_load_rom.c does not use any of these includes, remove them.
Signed-off-by: Philippe Mathieu-Daudé
Reviewed-by: Paul Durrant
Message-Id: <20191014142246.4538-9-phi...@redhat.com>
Signed-off-by: Anthony PERARD
---
hw/xen/xen_pt_load_rom.c | 4
1 file ch
On Mon, Oct 14, 2019 at 03:29:42PM +0100, Paul Durrant wrote:
> On Mon, 14 Oct 2019 at 15:27, Philippe Mathieu-Daudé
> wrote:
> >
> > xen_pt_load_rom.c does not use any of these includes, remove them.
> >
> > Signed-off-by: Philippe Mathieu-Daudé
>
> Reviewed-by: Paul Durrant
Hi,
I've added
flight 147612 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147612/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
test-amd64-i386-xl-qemu
flight 147609 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147609/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 142932
test-amd64-amd64-qem
On Wed, Feb 26, 2020 at 11:33:49AM +, Anthony PERARD wrote:
> This patch start to use if_changed introduced in a previous commit.
>
> Whenever if_changed is called, the target must have FORCE as
> dependency so that if_changed can check if the command line to be
> run as changed, so the macro
On Wed, Feb 26, 2020 at 11:33:52AM +, Anthony PERARD wrote:
> 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.
>
On Wed, Feb 26, 2020 at 11:33:53AM +, Anthony PERARD wrote:
> 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
On 26/10/19 15:32, Laurent Vivier wrote:
> Le 26/10/2019 à 14:20, Philippe Mathieu-Daudé a écrit :
>> Hi,
>>
>> On 10/14/19 4:22 PM, Philippe Mathieu-Daudé wrote:
>>> This is a follow-up of Markus's cleanup series:
>>> Tame a few "touch this, recompile the world"
>>> https://www.mail-archive.com/qe
We should neither cause IOMMU initialization as a whole to fail in this
case (we should still be able to bring up the system in non-x2APIC or
x2APIC physical mode), nor should the remainder of the function be
skipped (as the main part of it won't get entered a 2nd time) in such an
event. It is mere
On Thu, Feb 27, 2020 at 03:34:48PM +0100, Jan Beulich wrote:
> We should neither cause IOMMU initialization as a whole to fail in this
> case (we should still be able to bring up the system in non-x2APIC or
> x2APIC physical mode), nor should the remainder of the function be
> skipped (as the main
On 23/02/2020 14:14, Jürgen Groß wrote:
> On 22.02.20 17:42, Igor Druzhinin wrote:
>> (XEN) [ 120.891143] *** Dumping CPU0 host state: ***
>> (XEN) [ 120.895909] [ Xen-4.13.0 x86_64 debug=y Not tainted ]
>> (XEN) [ 120.902487] CPU: 0
>> (XEN) [ 120.905269] RIP: e008:[]
>> smp
On 27.02.20 16:16, Igor Druzhinin wrote:
On 23/02/2020 14:14, Jürgen Groß wrote:
On 22.02.20 17:42, Igor Druzhinin wrote:
(XEN) [ 120.891143] *** Dumping CPU0 host state: ***
(XEN) [ 120.895909] [ Xen-4.13.0 x86_64 debug=y Not tainted ]
(XEN) [ 120.902487] CPU: 0
(XEN) [ 120.
On 27/02/2020 14:34, Jan Beulich wrote:
> --- a/xen/drivers/passthrough/amd/iommu_init.c
> +++ b/xen/drivers/passthrough/amd/iommu_init.c
> @@ -1364,6 +1364,7 @@ static int __init amd_iommu_prepare_one(
> int __init amd_iommu_prepare(bool xt)
> {
> struct amd_iommu *iommu;
> +bool no_xt
On 25/02/2020 12:46, Igor Druzhinin wrote:
> On 25/02/2020 12:40, Jan Beulich wrote:
>> On 25.02.2020 13:37, Igor Druzhinin wrote:
>>> On 25/02/2020 12:22, Jan Beulich wrote:
On 21.02.2020 20:26, Igor Druzhinin wrote:
> On 21/02/2020 16:29, Jan Beulich wrote:
>> On 19.02.2020 18:25, Ig
On 27/02/2020 09:40, Jan Beulich wrote:
> On 27.02.2020 10:33, Andrew Cooper wrote:
>> On 27/02/2020 07:38, Jan Beulich wrote:
>>> On 26.02.2020 21:22, Andrew Cooper wrote:
Just as with c/s 96dc77b4b1 for XEN_SYSCTL_get_cpu_policy,
XEN_SYSCTL_get_cpu_featureset needs to become conditional
On 27/02/2020 09:55, Andrew Cooper wrote:
>>> +BUILD_BUG_ON(ARRAY_SIZE(masks[0]) != FEATURESET_NR_ENTRIES);
>> Isn't this quite pointless with the now changed definition of
>> the array?
> I'd need to double check
Double check says it isn't necessary. I'll drop.
~Andrew
On Wed, Feb 26, 2020 at 11:36:52AM +0100, Jan Beulich wrote:
> 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
I also did a full review of all callers, and only the xen driver
forgot to call drm_dev_put in the failure path. Fix that up too.
v2: I noticed that xen has a drm_driver.release hook, and uses
drm_dev_alloc(). We need to remove the kfree from
xen_drm_drv_release().
bochs also has a release hook,
flight 147629 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147629/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-examine 8 reboot fail REGR. vs. 147480
test-armhf-armhf-xl-
flight 147692 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147692/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
Each function takes an unsigned count, and loops based on a signed i. This
causes problems when between 2 and 4 billion operations are requested.
In practice, signed-ness issues aren't possible because count exceeding
INT_MAX is excluded earlier in do_grant_op(), but the code reads as if it is
bu
flight 147649 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147649/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 146182
build-i386-libvirt
On Wednesday, February 26, 2020 6:34 AM, Anthony PERARD wrote:
>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
Hi Juergen,
On 26/02/2020 14:17, Jürgen Groß wrote:
On 24.02.20 23:25, Julien Grall wrote:
Hi Juergen,
On 11/02/2020 09:31, Juergen Gross wrote:
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 6f9bec22d3..30c4c1830b 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@
flight 147640 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147640/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-shadow12 guest-start fail REGR. vs. 133580
test-amd64-amd64-xl
Hi,
On 26/02/2020 16:08, Paul Durrant wrote:
The purpose and semantics of the node are explained in
xenstore-paths.pandoc [1]. It was originally introduced in xend by commit
17636f47a474 "Teach xc_save to use event-channel-based domain suspend if
available.". Note that, because, the top-level fr
flight 147641 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147641/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 11 guest-startfail REGR. vs. 144861
test-amd64-i386-f
flight 147702 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147702/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 147654 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147654/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-examine 8 reboot fail REGR. vs. 142849
test-armhf-armhf-xl-
Hi!
I'm really excited about all the xenfs patches, but I'm wondering
if there's a branch that tracks that work I can play with?
Thanks,
Roman.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-
flight 147711 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147711/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 147655 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147655/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
142947
test-amd64-i3
On 28.02.20 04:05, Roman Shaposhnik wrote:
Hi!
I'm really excited about all the xenfs patches, but I'm wondering
if there's a branch that tracks that work I can play with?
Just pushed it to:
github.com/jgross1/xen.git hypfs
Juergen
___
Xen-devel
On 27.02.20 16:16, Igor Druzhinin wrote:
On 23/02/2020 14:14, Jürgen Groß wrote:
On 22.02.20 17:42, Igor Druzhinin wrote:
(XEN) [ 120.891143] *** Dumping CPU0 host state: ***
(XEN) [ 120.895909] [ Xen-4.13.0 x86_64 debug=y Not tainted ]
(XEN) [ 120.902487] CPU: 0
(XEN) [ 120.
With core scheduling active it is mandatory for stop_machine_run() to
be called in idle context only (so either during boot or in a tasklet),
as otherwise a scheduling deadlock would occur: stop_machine_run()
does a cpu rendezvous by activating a tasklet on all other cpus. In
case stop_machine_run(
flight 147662 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147662/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
139698
test-amd64-i3
72 matches
Mail list logo
