flight 159027 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159027/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Commit 91d4eca7add broke gnttab_need_iommu_mapping on ARM.
The offending chunk is:
#define gnttab_need_iommu_mapping(d)\
-(is_domain_direct_mapped(d) && need_iommu(d))
+(is_domain_direct_mapped(d) && need_iommu_pt_sync(d))
On ARM we need gnttab_need_iommu_mapping to b
flight 159023 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159023/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl 14 guest-start fail REGR. vs. 158387
test-arm64-arm64-xl-s
flight 159054 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159054/
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
flight 159031 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159031/
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
To prevent leaking HVM params via L1TF and similar issues on a
hyperthread pair, let's load values of domains as late as possible.
Furthermore, speculative barriers are re-arranged to make sure we do not
allow guests running on co-located VCPUs to leak hvm parameter values of
other domains.
This
Hi Daniel,
The time works for me. I am looking forward to it.
Cheers,
Stefano
On Fri, 5 Feb 2021, Daniel P. Smith wrote:
> Greetings,
>
> Per the community call on Feb. 4 I would like to get the working group
> started that will be reviewing the major design decisions for the DomB
> implemen
Greetings,
Per the community call on Feb. 4 I would like to get the working group
started that will be reviewing the major design decisions for the DomB
implementation. A summary of the discussion around the two primary
decisions we are seeking to get resolved are as follows,
Topic: DomB: Adopti
On 05/02/2021 18:46, Ian Jackson wrote:
> Igor Druzhinin writes ("[PATCH v2 2/2] tools/libxl: only set viridian flags
> on new domains"):
>> Domains migrating or restoring should have viridian HVM param key in
>> the migration stream already and setting that twice results in Xen
>> returing -EEXIS
Igor Druzhinin writes ("[PATCH v2 2/2] tools/libxl: only set viridian flags on
new domains"):
> Domains migrating or restoring should have viridian HVM param key in
> the migration stream already and setting that twice results in Xen
> returing -EEXIST on the second attempt later (during migration
Igor Druzhinin writes ("[PATCH v2 1/2] tools/libxl: pass
libxl__domain_build_state to libxl__arch_domain_create"):
> No functional change.
>
> Signed-off-by: Igor Druzhinin
Reviewed-by: Ian Jackson
Release-Acked-by: Ian Jackson
flight 159046 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159046/
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
flight 159017 xen-4.12-testing real [real]
flight 159048 xen-4.12-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159017/
http://logs.test-lab.xenproject.org/osstest/logs/159048/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On 05.02.2021 17:18, Roger Pau Monné wrote:
> On Fri, Feb 05, 2021 at 05:13:22PM +0100, Jan Beulich wrote:
>> On 05.02.2021 16:43, Roger Pau Monné wrote:
>>> On Thu, Jan 14, 2021 at 04:04:11PM +0100, Jan Beulich wrote:
The "guest" variants are intended to work with (potentially) fully guest
>>
On Fri, Feb 05, 2021 at 05:13:22PM +0100, Jan Beulich wrote:
> On 05.02.2021 16:43, Roger Pau Monné wrote:
> > On Thu, Jan 14, 2021 at 04:04:11PM +0100, Jan Beulich wrote:
> >> The "guest" variants are intended to work with (potentially) fully guest
> >> controlled addresses, while the "unsafe" var
On Mon, Feb 01, 2021 at 01:43:04PM +0100, Jan Beulich wrote:
> The (stime,tsc) tuple is the basis for extrapolation by get_s_time().
> Therefore the two better get taken as close to one another as possible.
> This means two things: First, reading platform time is too early when
> done on the first
On 05.02.2021 16:43, Roger Pau Monné wrote:
> On Thu, Jan 14, 2021 at 04:04:11PM +0100, Jan Beulich wrote:
>> The "guest" variants are intended to work with (potentially) fully guest
>> controlled addresses, while the "unsafe" variants are not.
>
> Just to clarify, both work against user addresses
On Mon, Feb 01, 2021 at 01:42:35PM +0100, Jan Beulich wrote:
> Setting the timer a second (EPOCH) into the future at a random point
> during boot (prior to bringing up APs and prior to launching Dom0) does
> not yield predictable results: The timer may expire while we're still
> bringing up APs (to
On Thu, Jan 14, 2021 at 04:04:11PM +0100, Jan Beulich wrote:
> The "guest" variants are intended to work with (potentially) fully guest
> controlled addresses, while the "unsafe" variants are not.
Just to clarify, both work against user addresses, but guest variants
need to be more careful because
Roger Pau Monne writes ("[PATCH for-4.15] tools/configure: add bison as
mandatory"):
> Bison is now mandatory when the pvshim build is enabled in order to
> generate the Kconfig.
>
> Signed-off-by: Roger Pau Monné
> ---
> Please re-run autogen.sh after applying.
>
> Fallout from this patch can
Roger Pau Monne writes ("[PATCH for-4.15] tools/tests: fix resource test build
on FreeBSD"):
> error.h is not a standard header, and none of the functions declared
> there are actually used by the code. This fixes the build on FreeBSD
> that doesn't have error.h
>
> Signed-off-by: Roger Pau Monné
Thanks, Andy, for those writeups. I still have substantial misgivings
I don't feel confident. However, I don't think continuing attempts to
try to understand and/or mitigate this risk will be helpful. I need
to make a decision now.
I think there are significant downsides to either choice here.
On 04.02.2021 13:12, Ian Jackson wrote:
> Although there are a few things outstanding, we are now firmly into
> the bugfixing phase of the Xen 4.15 release.
>
> I searched my email (and my memory) and found four open blockers which
> I have listed below, and one closed blocker.
>
> I feel there a
flight 159044 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159044/
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
From: Paolo Bonzini
This property can be useful for distros to set up known-good ROM sizes for
migration purposes. The VM will fail to start if the ROM is too large,
and migration compatibility will not be broken if the ROM is too small.
Note that even though romsize is a uint32_t, it has to be
On 05.02.2021 14:50, Andrew Cooper wrote:
> On 05/02/2021 13:39, Roger Pau Monné wrote:
>> On Fri, Feb 05, 2021 at 01:34:20PM +, Andrew Cooper wrote:
>>> On 05/02/2021 11:53, Roger Pau Monne wrote:
Bison is now mandatory when the pvshim build is enabled in order to
generate the Kconfi
On Fri, Feb 05, 2021 at 01:50:27PM +, Andrew Cooper wrote:
> On 05/02/2021 13:39, Roger Pau Monné wrote:
> > On Fri, Feb 05, 2021 at 01:34:20PM +, Andrew Cooper wrote:
> >> On 05/02/2021 11:53, Roger Pau Monne wrote:
> >>> Bison is now mandatory when the pvshim build is enabled in order to
On 04.02.2021 15:10, Andrew Cooper wrote:
> On 29/01/2021 11:45, Jan Beulich wrote:
>> +{
>> +u32 general1_intercepts = vmcb_get_general1_intercepts(vmcb);
>> +
>> +if ( v->arch.hvm.guest_cr[4] & X86_CR4_UMIP )
>> +{
>> +value &= ~X86_CR4_
On Thu, Feb 4, 2021 at 9:51 PM Elliott Mitchell wrote:
>
> On Thu, Feb 04, 2021 at 03:52:26PM -0600, Rob Herring wrote:
> > On Thu, Feb 4, 2021 at 3:33 PM Stefano Stabellini
> > wrote:
> > >
> > > On Thu, 4 Feb 2021, Rob Herring wrote:
> > > > On Thu, Feb 4, 2021 at 2:36 PM Stefano Stabellini
> >
On 05/02/2021 13:39, Roger Pau Monné wrote:
> On Fri, Feb 05, 2021 at 01:34:20PM +, Andrew Cooper wrote:
>> On 05/02/2021 11:53, Roger Pau Monne wrote:
>>> Bison is now mandatory when the pvshim build is enabled in order to
>>> generate the Kconfig.
>>>
>>> Signed-off-by: Roger Pau Monné
>>> -
On 04.02.2021 15:10, Andrew Cooper wrote:
> On 29/01/2021 11:45, Jan Beulich wrote:
>> There are three noteworthy drawbacks:
>> 1) The intercepts we need to enable here are CPL-independent, i.e. we
>>now have to emulate certain instructions for ring 0.
>> 2) On VMX there's no intercept for SMSW
On Fri, Feb 05, 2021 at 01:34:20PM +, Andrew Cooper wrote:
> On 05/02/2021 11:53, Roger Pau Monne wrote:
> > Bison is now mandatory when the pvshim build is enabled in order to
> > generate the Kconfig.
> >
> > Signed-off-by: Roger Pau Monné
> > ---
> > Please re-run autogen.sh after applying.
On 05/02/2021 11:53, Roger Pau Monne wrote:
> Bison is now mandatory when the pvshim build is enabled in order to
> generate the Kconfig.
>
> Signed-off-by: Roger Pau Monné
> ---
> Please re-run autogen.sh after applying.
>
> Fallout from this patch can lead to broken configure script being
> gene
On 05.02.21 14:00, Jan Beulich wrote:
On 05.02.2021 11:56, Jürgen Groß wrote:
As we need to consider backports of processor bug mitigations
in old guests, too, I think we need to have a "catch-all"
fallback.
Not being able to run an old updated guest until we add handling
for a new MSR isn't a
On 05.02.2021 12:32, Andrew Cooper wrote:
> On 05/02/2021 10:56, Jürgen Groß wrote:
>> On 05.02.21 11:14, Jan Beulich wrote:
>>> On 04.11.2020 11:50, Jan Beulich wrote:
On 03.11.2020 18:31, Andrew Cooper wrote:
> We should have the impacted MSRs handled explicitly, with a note
> statin
On 05.02.2021 11:56, Jürgen Groß wrote:
> As we need to consider backports of processor bug mitigations
> in old guests, too, I think we need to have a "catch-all"
> fallback.
>
> Not being able to run an old updated guest until we add handling
> for a new MSR isn't a viable option IMO.
I'm not s
On 05/02/2021 12:19, Roger Pau Monne wrote:
> error.h is not a standard header, and none of the functions declared
> there are actually used by the code. This fixes the build on FreeBSD
> that doesn't have error.h
>
> Signed-off-by: Roger Pau Monné
Urgh sorry. Acked-by: Andrew Cooper
error.h is not a standard header, and none of the functions declared
there are actually used by the code. This fixes the build on FreeBSD
that doesn't have error.h
Signed-off-by: Roger Pau Monné
---
Build tested on both Linux and FreeBSD. The risk would be breaking the
build, but it's already bro
flight 159016 xen-4.11-testing real [real]
flight 159039 xen-4.11-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/159016/
http://logs.test-lab.xenproject.org/osstest/logs/159039/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
On Fri, Feb 05, 2021 at 11:32:07AM +, Andrew Cooper wrote:
> On 05/02/2021 10:56, Jürgen Groß wrote:
> > On 05.02.21 11:14, Jan Beulich wrote:
> >> (simply re-sending what was sent over 2 months ago)
> >>
> >> On 04.11.2020 11:50, Jan Beulich wrote:
> >>> On 03.11.2020 18:31, Andrew Cooper wrot
On 05.02.21 12:32, Andrew Cooper wrote:
On 05/02/2021 10:56, Jürgen Groß wrote:
On 05.02.21 11:14, Jan Beulich wrote:
(simply re-sending what was sent over 2 months ago)
On 04.11.2020 11:50, Jan Beulich wrote:
On 03.11.2020 18:31, Andrew Cooper wrote:
On 03/11/2020 17:06, Jan Beulich wrote:
Bison is now mandatory when the pvshim build is enabled in order to
generate the Kconfig.
Signed-off-by: Roger Pau Monné
---
Please re-run autogen.sh after applying.
Fallout from this patch can lead to broken configure script being
generated or bison not detected correctly, but those will be cac
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-qemut-rhel6hvm-amd
testid redhat-install
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/o
On 05/02/2021 10:56, Jürgen Groß wrote:
> On 05.02.21 11:14, Jan Beulich wrote:
>> (simply re-sending what was sent over 2 months ago)
>>
>> On 04.11.2020 11:50, Jan Beulich wrote:
>>> On 03.11.2020 18:31, Andrew Cooper wrote:
On 03/11/2020 17:06, Jan Beulich wrote:
> Prior to 4.15 Linux,
On 05.02.2021 11:41, Andrew Cooper wrote:
> On 10/11/2020 13:26, Jan Beulich wrote:
>> The SDM specifically allows for earlier writes to fully overlapping
>> ranges to be dropped. If a guest did so, hvmemul_phys_mmio_access()
>> would crash it if varying data was written to the same address. Detect
On 05.02.2021 11:33, Andrew Cooper wrote:
> On 05/02/2021 08:11, Jan Beulich wrote:
>> On 04.02.2021 14:38, Jan Beulich wrote:
>>> Our linker capability check fails with the recent binutils release's ld:
>>>
>>> .../check.o:(.debug_aranges+0x6): relocation truncated to fit: R_X86_64_32
>>> against
flight 159019 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159019/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1b6c3a94eca7f12f6a3b65a3e8619d2e2e7c1eb6
baseline version:
ovmf f6ec1dd34fb6b9757b5ea
On 05.02.21 11:14, Jan Beulich wrote:
(simply re-sending what was sent over 2 months ago)
On 04.11.2020 11:50, Jan Beulich wrote:
On 03.11.2020 18:31, Andrew Cooper wrote:
On 03/11/2020 17:06, Jan Beulich wrote:
Prior to 4.15 Linux, when running in PV mode, did not install a #GP
handler early
On 10/11/2020 13:26, Jan Beulich wrote:
> The SDM specifically allows for earlier writes to fully overlapping
> ranges to be dropped. If a guest did so, hvmemul_phys_mmio_access()
> would crash it if varying data was written to the same address. Detect
> overlaps early, as doing so in hvmemul_{line
On 05/02/2021 08:11, Jan Beulich wrote:
> On 04.02.2021 14:38, Jan Beulich wrote:
>> Our linker capability check fails with the recent binutils release's ld:
>>
>> .../check.o:(.debug_aranges+0x6): relocation truncated to fit: R_X86_64_32
>> against `.debug_info'
>> .../check.o:(.debug_info+0x6):
(simply re-sending what was sent over 2 months ago)
On 04.11.2020 11:50, Jan Beulich wrote:
> On 03.11.2020 18:31, Andrew Cooper wrote:
>> On 03/11/2020 17:06, Jan Beulich wrote:
>>> Prior to 4.15 Linux, when running in PV mode, did not install a #GP
>>> handler early enough to cover for example t
On 10.11.2020 14:26, Jan Beulich wrote:
> The SDM specifically allows for earlier writes to fully overlapping
> ranges to be dropped. If a guest did so, hvmemul_phys_mmio_access()
> would crash it if varying data was written to the same address. Detect
> overlaps early, as doing so in hvmemul_{line
flight 159013 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159013/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 158977
test-amd64-amd64-xl-qemuu-ws16-amd64
On 04.02.2021 14:38, Jan Beulich wrote:
> Our linker capability check fails with the recent binutils release's ld:
>
> .../check.o:(.debug_aranges+0x6): relocation truncated to fit: R_X86_64_32
> against `.debug_info'
> .../check.o:(.debug_info+0x6): relocation truncated to fit: R_X86_64_32
> ag
54 matches
Mail list logo
