flight 161554 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161554/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-i3
flight 161559 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161559/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1e6b0394d6c001802dc454ecff19076aaa80f51c
baseline version:
ovmf ab957f036f67118692832
flight 161551 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161551/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 161534
test-armhf-armhf-libvirt 16 save
flight 161549 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161549/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
flight 161556 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161556/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
On 4/30/21 9:45 PM, Tim Deegan wrote:
> At 14:36 +0300 on 30 Apr (1619793419), Costin Lupu wrote:
>> Hi Tim,
>>
>> On 4/29/21 10:58 PM, Tim Deegan wrote:
>>> Hi,
>>>
>>> At 15:05 +0300 on 27 Apr (1619535916), Costin Lupu wrote:
If PAGE_SIZE is already defined in the system (e.g. in
/usr/i
On 4/30/21, 3:15 AM, Jan Beulich wrote:
> So far you didn't tell us what the actual crash was. I guess it's not
> even clear to me whether it's Xen or qemu that did crash for you. But
> I have to also admit that until now it wasn't really clear to me that
> you ran Xen _under_ qemu - instead I was
flight 161545 xen-4.12-testing real [real]
flight 161557 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/161545/
http://logs.test-lab.xenproject.org/osstest/logs/161557/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
At 14:36 +0300 on 30 Apr (1619793419), Costin Lupu wrote:
> Hi Tim,
>
> On 4/29/21 10:58 PM, Tim Deegan wrote:
> > Hi,
> >
> > At 15:05 +0300 on 27 Apr (1619535916), Costin Lupu wrote:
> >> If PAGE_SIZE is already defined in the system (e.g. in
> >> /usr/include/limits.h header) then gcc will tri
From: Anthony PERARD
Because Coverity complains about it and this is one leak that Valgrind
reports.
Signed-off-by: Anthony PERARD
---
hw/i386/xen/xen-hvm.c | 9 ++---
include/hw/xen/xen_common.h | 6 ++
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/hw/i386/xen/
From: Anthony PERARD
... when a xen-block backend instance is created via xenstore.
Following 8d17adf34f50 ("block: remove support for using "file" driver
with block/char devices"), using the "file" blockdev driver for
everything doesn't work anymore, we need to use the "host_device"
driver when
flight 161540 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161540/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
test-amd64-i3
On 30.04.2021 16:37, Andrew Cooper wrote:
> On 30/04/2021 11:42, Jan Beulich wrote:
>> On 30.04.2021 12:21, Andrew Cooper wrote:
>>> If I do the rebase, are you happy for this patch to stay as it is (so
>>> the complicated change concerning context switching doesn't get more
>>> complicated), and s
Move the logic from xc_cpu_policy_apply_cpuid into libxl, now that the
xc_cpu_policy_* helpers allow modifying a cpu policy. By moving such
parsing into libxl directly we can get rid of xc_xend_cpuid, as libxl
will now implement it's own private type for storing CPUID
information, which currently m
With the addition of the xc_cpu_policy_* now libxl can have better
control over the cpu policy, this allows removing the
xc_cpuid_apply_policy function and instead coding the required bits by
libxl in libxl__cpuid_legacy directly.
Remove xc_cpuid_apply_policy.
Signed-off-by: Roger Pau Monné
---
Pull out the code from xc_cpuid_apply_policy that applies a featureset
to a cpu policy and place it on it's own standalone function that's
part of the public interface.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
tools/include/xenctrl.h | 5 ++
tools/libs/guest/xg
Rename xc_cpuid_xend_policy to xc_cpu_policy_apply_cpuid and make it
public. Modify the function internally to use the new xc_cpu_policy_*
set of functions. Also don't apply the passed policy to a domain
directly, and instead modify the provided xc_cpu_policy_t. The caller
will be responsible of ap
This logic is pulled out from xc_cpuid_apply_policy and placed into a
separate helper. Note the legacy part of the introduced function, as
long term Xen will require a proper topology setter function capable
of expressing a more diverse set of topologies.
No functional change intended.
Signed-off
Older Xen versions used to expose some CPUID bits which are no longer
exposed by default. In order to keep a compatible behavior with
guests migrated from versions of Xen that don't encode the CPUID data
on the migration stream introduce a function that sets the same bits
as older Xen versions.
Th
Introduce a helper to obtain a compatible cpu policy based on two
input cpu policies. Currently this is done by and'ing all CPUID
feature leaves and MSR entries, except for MSR_ARCH_CAPABILITIES which
has the RSBA bit or'ed.
The _AC macro is pulled from libxl_internal.h into xen-tools/libs.h
since
Such helpers is just a wrapper to the existing
x86_cpu_policies_are_compatible function. This requires building
policy.c from libx86 on user land also.
No user of the interface introduced.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- Initialize err.
- Explicitly name parameters as ho
Introduce a helper to update the MSR policy using an array of
xen_msr_entry_t entries. Note the MSRs present in the input
xen_msr_entry_t array will replace any existing entries on the
policy.
No user of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
Introduce a helper to update the CPUID policy using an array of
xen_cpuid_leaf_t entries. Note the leaves present in the input
xen_cpuid_leaf_t array will replace any existing leaves on the policy.
No user of the interface introduced on this patch.
Signed-off-by: Roger Pau Monné
---
Changes sinc
Introduce an interface that returns a specific MSR entry from a cpu
policy in xen_msr_entry_t format. Provide a helper to perform a binary
search against an array of MSR entries.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced on
Introduce an interface that returns a specific leaf/subleaf from a cpu
policy in xen_cpuid_leaf_t format.
This is useful to callers can peek data from the opaque
xc_cpu_policy_t type.
No caller of the interface introduced on this patch.
Note that callers of find_leaf need to be slightly adjusted
Also change libxl__cpuid_legacy to propagate the error from
xc_cpuid_apply_policy into callers.
Signed-off-by: Roger Pau Monné
Reviewed-by: Jan Beulich
---
Changes since v2:
- Use 'r' for xc_cpuid_apply_policy return value.
- Use LOGEVD to print error message.
Changes since v1:
- Return ERRO
Hello,
The following series introduces a new CPUID/MSR interface for the
xenguest library. Such interface handles both CPUID and MSRs using the
same opaque object, and provides some helpers for the user to peek or
modify such data without exposing the backing type. This is useful for
future develo
On 29/04/2021 10:07, Jan Beulich wrote:
> On 28.04.2021 19:54, Andrew Cooper wrote:
>> I know we're making up our "how to do complicated experimental features"
>> process as we go here, but nothing *in Xen* will malfunction if a user
>> opts into CET_SS/IBT. Therefore I think they're fine to go in
We shouldn't default to include any unsupported code in the shim. Mark
the setting as off, replacing the ARGO specification. This points out
anomalies with the scheduler configuration: Unsupported schedulers
better don't default to Y in release builds (like is already the case
for ARINC653). Withou
As of commit d155e4aef35c ("xen: Allow EXPERT mode to be selected from
the menuconfig directly") EXPERT is a regular config option.
Signed-off-by: Jan Beulich
--- a/tools/firmware/xen-dir/Makefile
+++ b/tools/firmware/xen-dir/Makefile
@@ -74,10 +74,10 @@ $(D): linkfarm.stamp
$(MAKE) -C $
Some intermediate files weren't considered at all at the time. Also
after its introduction, various changes to the build environment have
rendered the exclusion sets stale. For example, we now have some .*.cmd
files in the build tree. Combine all respective patterns into a single
.* one, seeing th
Originally I meant to finally get v2 of "firmware/shim: honor symlinks
during Xen tree setup" sorted. However, the suggestion to use find's
-L option, while a suitable equivalent of the -xtype primary, has the
same drawback: It doesn't distinguish between relative and absolute
symlinks (and we spec
On Fri, Apr 30, 2021 at 04:16:24PM +0200, Jan Beulich wrote:
> On 30.04.2021 11:55, Roger Pau Monné wrote:
> > On Mon, Apr 12, 2021 at 04:12:41PM +0200, Jan Beulich wrote:
> >> --- a/xen/arch/x86/x86_64/compat/mm.c
> >> +++ b/xen/arch/x86/x86_64/compat/mm.c
> >> @@ -155,8 +155,10 @@ int compat_arch
On 30/04/2021 11:42, Jan Beulich wrote:
> On 30.04.2021 12:21, Andrew Cooper wrote:
>> On 30/04/2021 10:08, Jan Beulich wrote:
>>> On 30.04.2021 00:12, Andrew Cooper wrote:
The sole user of read_pkru() is the emulated pagewalk, and guarded behind
guest_pku_enabled() which restricts the pa
On 30.04.2021 11:55, Roger Pau Monné wrote:
> On Mon, Apr 12, 2021 at 04:12:41PM +0200, Jan Beulich wrote:
>> --- a/xen/arch/x86/x86_64/compat/mm.c
>> +++ b/xen/arch/x86/x86_64/compat/mm.c
>> @@ -155,8 +155,10 @@ int compat_arch_memory_op(unsigned long
>> case XENMEM_get_sharing_shared_pages:
Dmitry Torokhov writes:
> I don't know why Xen keyboard exports that many keycodes ;) In general,
> my recommendation is to mirror the physical device when possible, and
> instantiate several devices so there is 1:1 relationship between virtual
> and physical devices.
I'm still trying to wrap m
On Fri, 30 Apr 2021 09:15:51 +0200
Paolo Bonzini wrote:
> > Nit, but in change logs, please avoid stating "next patch" as searching git
> > history (via git blame or whatever) there is no such thing as "next patch".
> >
>
> Interesting, I use next patch(es) relatively often, though you're rig
flight 161534 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161534/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-xtf-amd64-amd64-3 92 xtf/test-pv32pae-xsa-286 fail in 161512 pass in
161534
test-amd64-amd64-xl-qemuu-deb
Hi Tim,
On 4/29/21 10:58 PM, Tim Deegan wrote:
> Hi,
>
> At 15:05 +0300 on 27 Apr (1619535916), Costin Lupu wrote:
>> If PAGE_SIZE is already defined in the system (e.g. in
>> /usr/include/limits.h header) then gcc will trigger a redefinition error
>> because of -Werror. This commit also protects
@Christian: This version is slightly changed, it uses XC_PAGE_* macros
instead of PAGE_* macros and that's why I didn't add your ack.
Cheers,
Costin
On 4/30/21 2:28 PM, Costin Lupu wrote:
> If PAGE_SIZE is already defined in the system (e.g. in /usr/include/limits.h
> header) then gcc will trigge
If PAGE_SIZE is already defined in the system (e.g. in /usr/include/limits.h
header) then gcc will trigger a redefinition error because of -Werror. This
patch replaces usage of PAGE_* macros with XC_PAGE_* macros in order to avoid
confusion between control domain page granularity (PAGE_* definition
If PAGE_SIZE is already defined in the system (e.g. in /usr/include/limits.h
header) then gcc will trigger a redefinition error because of -Werror. This
patch replaces usage of PAGE_* macros with XC_PAGE_* macros in order to avoid
confusion between control domain page granularity (PAGE_* definition
If PAGE_SIZE is already defined in the system (e.g. in /usr/include/limits.h
header) then gcc will trigger a redefinition error because of -Werror. This
patch replaces usage of PAGE_* macros with XC_PAGE_* macros in order to avoid
confusion between control domain page granularity (PAGE_* definition
If PAGE_SIZE is already defined in the system (e.g. in /usr/include/limits.h
header) then gcc will trigger a redefinition error because of -Werror. This
patch replaces usage of PAGE_* macros with XC_PAGE_* macros in order to avoid
confusion between control domain page granularity (PAGE_* definition
For replication I used gcc 10.3 on an Alpine system. In order to replicate the
redefinition error for PAGE_SIZE one should install the 'fortify-headers'
package which will change the chain of included headers by indirectly including
/usr/include/limits.h where PAGE_SIZE and PATH_MAX are defined.
C
If PATH_MAX is already defined in the system (e.g. in /usr/include/limits.h
header) then gcc will trigger a redefinition error because of -Werror.
Signed-off-by: Costin Lupu
Reviewed-by: Julien Grall
---
tools/libfsimage/ext2fs/fsys_ext2fs.c | 2 ++
tools/libfsimage/reiserfs/fsys_reiserfs.c
On Mon, Apr 12, 2021 at 04:14:22PM +0200, Jan Beulich wrote:
> Combine two HVM-specific sections in two cases (i.e. going from four of
> them to just two). Make defer_nested_flush bool and HVM-only, moving it
> next to other nested stuff. Move default_access up into a padding hole.
>
> When moving
On Mon, Apr 12, 2021 at 04:13:19PM +0200, Jan Beulich wrote:
> With the hooks no longer needing setting, p2m_pt_init() degenerates to
> (about) nothing when !HVM. As a result, p2m-pt.c doesn't need building
> anymore in this case, as long as p2m_pt_init() has proper surrogates put
> in place.
>
>
On 30.04.2021 12:21, Andrew Cooper wrote:
> On 30/04/2021 10:08, Jan Beulich wrote:
>> On 30.04.2021 00:12, Andrew Cooper wrote:
>>> The sole user of read_pkru() is the emulated pagewalk, and guarded behind
>>> guest_pku_enabled() which restricts the path to HVM (hap, even) context
>>> only.
>>>
>
On 30/04/2021 10:08, Jan Beulich wrote:
> On 30.04.2021 00:12, Andrew Cooper wrote:
>> The sole user of read_pkru() is the emulated pagewalk, and guarded behind
>> guest_pku_enabled() which restricts the path to HVM (hap, even) context only.
>>
>> The commentary in read_pkru() concerning _PAGE_GNTT
On Mon, Apr 12, 2021 at 04:12:41PM +0200, Jan Beulich wrote:
> While doing so, make the option dependent upon HVM, which really is the
> main purpose of the change.
>
> Signed-off-by: Jan Beulich
> ---
> v2: New.
>
> --- a/xen/arch/x86/Kconfig
> +++ b/xen/arch/x86/Kconfig
> @@ -15,7 +15,6 @@ con
flight 161524 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161524/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
On Mon, Apr 12, 2021 at 04:09:18PM +0200, Jan Beulich wrote:
> Exclude functions involved in its use from !HVM builds, thus making it
> possible to exclude the hook as well.
>
> Signed-off-by: Jan Beulich
Acked-by: Roger Pau Monné
Thanks, Roger.
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-win7-amd64
testid guest-saverestore
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 git://xenb
On 30.04.2021 00:12, Andrew Cooper wrote:
> The sole user of read_pkru() is the emulated pagewalk, and guarded behind
> guest_pku_enabled() which restricts the path to HVM (hap, even) context only.
>
> The commentary in read_pkru() concerning _PAGE_GNTTAB overlapping with
> _PAGE_PKEY_BITS is only
On 30.04.2021 10:19, Julien Grall wrote:
> On 29/04/2021 14:10, Jan Beulich wrote:
>> With there being a way to disable v2 support, telling new guests to use
>> v2 exclusively is not a good suggestion.
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/include/public/grant_table.h
>> +++ b/xen/inclu
Hi Jan,
On 29/04/2021 14:10, Jan Beulich wrote:
With there being a way to disable v2 support, telling new guests to use
v2 exclusively is not a good suggestion.
Signed-off-by: Jan Beulich
--- a/xen/include/public/grant_table.h
+++ b/xen/include/public/grant_table.h
@@ -121,8 +121,10 @@ typede
Hi Jan,
On 29/04/2021 14:40, Jan Beulich wrote:
On 29.04.2021 15:15, Julien Grall wrote:
On 15/04/2021 10:41, Jan Beulich wrote:
This array can be large when many grant frames are permitted; avoid
allocating it when it's not going to be used anyway, by doing this only
in gnttab_populate_status
Hi all,
The proposed agenda is in
https://cryptpad.fr/pad/#/2/pad/edit/o-pGdfLGjXG8Bui-Cu+iJLsC/ and you can edit
to add items. Alternatively, you can reply to this mail directly.
Agenda items appreciated a few days before the call: please put your name
besides items if you edit the document.
> On 29 Apr 2021, at 14:10, Jan Beulich wrote:
>
> With there being a way to disable v2 support, telling new guests to use
> v2 exclusively is not a good suggestion.
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/include/public/grant_table.h
> +++ b/xen/include/public/grant_table.h
> @@ -121,
flight 161542 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/161542/
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
On 28/04/21 23:27, Steven Rostedt wrote:
On Tue, 27 Apr 2021 07:09:46 +0800
Lai Jiangshan wrote:
From: Lai Jiangshan
There is no any functionality change intended. Just rename it and
move it to arch/x86/kernel/nmi.c so that we can resue it later in
next patch for early NMI and kvm.
Nit, b
On 29.04.2021 23:04, Scott Davis wrote:
> On 4/28/21, 3:20 AM, Paul Durrant wrote:
>>> Following the extension to the command line option I'm putting in place
>>> in "IOMMU: make DMA containment of quarantined devices optional" (which
>>> I still need to get around to address review feedback for an
63 matches
Mail list logo
