flight 159840 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159840/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 159450
flight 159841 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159841/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-ovmf-amd64 3 hosts-allocate starved n/a
version targeted for testing:
ovmf
On Tue, 2 Mar 2021, Stefano Stabellini wrote:
> On Tue, 2 Mar 2021, Jan Beulich wrote:
> > On 02.03.2021 10:36, Roger Pau Monné wrote:
> > > On Tue, Mar 02, 2021 at 09:53:41AM +0100, Jan Beulich wrote:
> > >> On 02.03.2021 09:14, Roger Pau Monné wrote:
> > >>> On Mon, Mar 01, 2021 at 06:01:36PM
flight 159838 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159838/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 159831
test-amd64-amd64-qemuu-nested-amd
flight 159835 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159835/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
flight 159834 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159834/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qcow2 21 guest-start/debian.repeat fail REGR. vs. 152631
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-28039 / XSA-369
version 2
Linux: special config may crash when trying to map foreign pages
UPDATES IN VERSION 2
CVE assigned.
ISSUE DESCRIPTION
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-28038 / XSA-367
version 2
Linux: netback fails to honor grant mapping errors
UPDATES IN VERSION 2
CVE assigned.
ISSUE DESCRIPTION
Andrew Cooper writes ("Re: [PATCH 1/2][4.15?] x86/shadow: suppress "fast fault
path" optimization when running virtualized"):
> On 05/03/2021 16:40, Ian Jackson wrote:
> > Andrew Cooper writes ("Re: [PATCH 1/2][4.15?] x86/shadow: suppress "fast
> > fault path" optimization when running
On 05/03/2021 16:28, Jan Beulich wrote:
> Just like all other object files - wherever *.o is mentioned, *.opic
> also needs mentioning to yield consistent behavior. Otherwise make may
> decide to (re)build the object before recursion into $(ACPI_PATH)/ (to
> update $(DSDT_FILES-y) and ssdt_*.h)
On 05/03/2021 16:40, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH 1/2][4.15?] x86/shadow: suppress "fast
> fault path" optimization when running virtualized"):
>> This wants backporting to stable releases, so I would recommend for 4.15
>> even at this point.
> Can someone explain to me
Andrew Cooper writes ("Re: [PATCH 1/2][4.15?] x86/shadow: suppress "fast fault
path" optimization when running virtualized"):
> This wants backporting to stable releases, so I would recommend for 4.15
> even at this point.
Can someone explain to me the implications of not taking these patch,
and
Jan Beulich writes ("[PATCH][4.15?] libxl/ACPI: add missing build dependency"):
> Just like all other object files - wherever *.o is mentioned, *.opic
> also needs mentioning to yield consistent behavior. Otherwise make may
> decide to (re)build the object before recursion into $(ACPI_PATH)/ (to
>
On 05/03/2021 15:37, Jan Beulich wrote:
> Since we don't need to encode all of the PTE flags, we have enough bits
> in the shadow entry to store the full GFN. Don't use literal numbers -
> instead derive the involved values. Or, where derivation would become
> too ugly, sanity-check the result
On 05.03.2021 16:47, Andrew Cooper wrote:
> On 05/03/2021 15:37, Jan Beulich wrote:
>> We can't make correctness of our own behavior dependent upon a
>> hypervisor underneath us correctly telling us the true physical address
>> with hardware uses. Without knowing this, we can't be certain reserved
Just like all other object files - wherever *.o is mentioned, *.opic
also needs mentioning to yield consistent behavior. Otherwise make may
decide to (re)build the object before recursion into $(ACPI_PATH)/ (to
update $(DSDT_FILES-y) and ssdt_*.h) was actually finished.
Signed-off-by: Jan Beulich
Cc'ing Xen list
On 3/5/21 3:59 PM, Claudio Fontana wrote:
> There might be more than just KVM and TCG in the future,
> so where appropriate, replace broad "else" statements
> with the appropriate if (accel_enabled()) check.
>
> Also invert some checks for !kvm_enabled() or !tcg_enabled()
> where
flight 159836 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159836/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c5740f360636479fb91681093b1dee1cc366075c
baseline version:
ovmf
On 05/03/2021 15:37, Jan Beulich wrote:
> We can't make correctness of our own behavior dependent upon a
> hypervisor underneath us correctly telling us the true physical address
> with hardware uses. Without knowing this, we can't be certain reserved
> bit faults can actually be observed.
Since we don't need to encode all of the PTE flags, we have enough bits
in the shadow entry to store the full GFN. Don't use literal numbers -
instead derive the involved values. Or, where derivation would become
too ugly, sanity-check the result (invoking #error to identify failure).
This then
We can't make correctness of our own behavior dependent upon a
hypervisor underneath us correctly telling us the true physical address
with hardware uses. Without knowing this, we can't be certain reserved
bit faults can actually be observed. Therefore, besides evaluating the
number of address
Andrew points out that 'x86/shadow: suppress "fast fault path"
optimization without reserved bits' assumes firm knowledge of the
physical machine's address width. When we run virtualized
ourselves, we can't reasonably assume that we do, the more that
the property may change as we may get migrated.
Andrew Cooper writes ("Re: [PATCH 2/3] xen/dmop: Strip __XEN_TOOLS__ header
guard from public API"):
> The use in the dom0 kernel wasn't kept secret in the slightest. It was
> discussed on at the time, and at dev summits.
No-one is accusing anyone of keeping anything secret.
> But upstream
On 05/03/2021 14:21, Jan Beulich wrote:
> On 05.03.2021 15:18, Jan Beulich wrote:
>> On 05.03.2021 15:12, Andrew Cooper wrote:
>>> On 05/03/2021 13:53, Jan Beulich wrote:
On 05.03.2021 13:49, Andrew Cooper wrote:
> Exactly as with c/s f40e1c52e4, this is inappropriate for a stable
>
flight 159837 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159837/
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
On 05.03.21 15:46, Ian Jackson wrote:
Jürgen Groß writes ("Re: [PATCH for-4.15] tools/xenstored: liveupdate: Increase the
maximum number of parameters"):
On 05.03.21 15:37, Ian Jackson wrote:
Jürgen Groß writes ("Re: [PATCH for-4.15] tools/xenstored: liveupdate: Increase the
maximum number
On 05.03.21 15:49, Ian Jackson wrote:
Ian Jackson writes ("Re: [PATCH for-4.15] tools/xenstored: liveupdate: Increase the
maximum number of parameters"):
Jürgen Groß writes ("Re: [PATCH for-4.15] tools/xenstored: liveupdate: Increase the
maximum number of parameters"):
On 05.03.21 15:37, Ian
Ian Jackson writes ("Re: [PATCH for-4.15] tools/xenstored: liveupdate: Increase
the maximum number of parameters"):
> Jürgen Groß writes ("Re: [PATCH for-4.15] tools/xenstored: liveupdate:
> Increase the maximum number of parameters"):
> > On 05.03.21 15:37, Ian Jackson wrote:
> > > Jürgen Groß
Jürgen Groß writes ("Re: [PATCH for-4.15] tools/xenstored: liveupdate: Increase
the maximum number of parameters"):
> On 05.03.21 15:37, Ian Jackson wrote:
> > Jürgen Groß writes ("Re: [PATCH for-4.15] tools/xenstored: liveupdate:
> > Increase the maximum number of parameters"):
> >> This is the
On 05.03.21 15:37, Ian Jackson wrote:
Jürgen Groß writes ("Re: [PATCH for-4.15] tools/xenstored: liveupdate: Increase the
maximum number of parameters"):
This is the max number of 0 delimited string parameters. Especially the
stubdom case needs a binary blob (with length, of course) as
Jürgen Groß writes ("Re: [PATCH for-4.15] tools/xenstored: liveupdate: Increase
the maximum number of parameters"):
> This is the max number of 0 delimited string parameters. Especially the
> stubdom case needs a binary blob (with length, of course) as parameter,
> and the number of 0 bytes in
On 05.03.21 14:22, Ian Jackson wrote:
Julien Grall writes ("[PATCH for-4.15] tools/xenstored: liveupdate: Increase the
maximum number of parameters"):
From: Julien Grall
The longest possible command line for LiveUpdate is:
liveupdate -s -t -F
This is 5 parameters. However, the maximum
Jan Beulich writes ("Re: [PATCH 2/3] xen/dmop: Strip __XEN_TOOLS__ header guard
from public API"):
> This is news to me - so far it had been my understanding that it
> was introduced to have a way for the kernel to audit and hand on
> requests to the hypervisor without needing to know all the
On 05.03.2021 15:18, Jan Beulich wrote:
> On 05.03.2021 15:12, Andrew Cooper wrote:
>> On 05/03/2021 13:53, Jan Beulich wrote:
>>> On 05.03.2021 13:49, Andrew Cooper wrote:
Exactly as with c/s f40e1c52e4, this is inappropriate for a stable library.
That change actually broke the
On 05.03.2021 15:12, Andrew Cooper wrote:
> On 05/03/2021 13:53, Jan Beulich wrote:
>> On 05.03.2021 13:49, Andrew Cooper wrote:
>>> Exactly as with c/s f40e1c52e4, this is inappropriate for a stable library.
>>>
>>> That change actually broke the build with:
>>>
>>>
On 05/03/2021 13:53, Jan Beulich wrote:
> On 05.03.2021 13:49, Andrew Cooper wrote:
>> Exactly as with c/s f40e1c52e4, this is inappropriate for a stable library.
>>
>> That change actually broke the build with:
>>
>> include/xendevicemodel.h:52:5: error: unknown type name 'ioservid_t'
>>
flight 159831 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159831/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-rtds 18 guest-start/debian.repeatfail like 159820
Julien Grall writes ("Re: [PATCH for-4.15 2/2] tools/xenstore: Check the format
printf for xprintf() and barf{,_perror}()"):
> Urgh, you are right. Actually, the extern was added recently by Anthony:
>
> dacdbf7088d6a3705a9831e73991c2b14c519a65 ("tools/xenstore: mark variable
> in header as
On 05.03.2021 13:49, Andrew Cooper wrote:
> Exactly as with c/s f40e1c52e4, this is inappropriate for a stable library.
>
> That change actually broke the build with:
>
> include/xendevicemodel.h:52:5: error: unknown type name 'ioservid_t'
>ioservid_t *id);
>^
>
> as
On 05/03/2021 13:45, Jan Beulich wrote:
> On 05.03.2021 14:01, Jürgen Groß wrote:
>> On 05.03.21 13:40, Julien Grall wrote:
>>> From: Julien Grall
>>> --- a/tools/xenstore/utils.h
>>> +++ b/tools/xenstore/utils.h
>>> @@ -29,10 +29,12 @@ const char *dump_state_align(FILE *fp);
>>>
>>> #define
Hi Jan,
On 05/03/2021 13:45, Jan Beulich wrote:
On 05.03.2021 14:01, Jürgen Groß wrote:
On 05.03.21 13:40, Julien Grall wrote:
From: Julien Grall
--- a/tools/xenstore/utils.h
+++ b/tools/xenstore/utils.h
@@ -29,10 +29,12 @@ const char *dump_state_align(FILE *fp);
#define
On 05.03.2021 14:01, Jürgen Groß wrote:
> On 05.03.21 13:40, Julien Grall wrote:
>> From: Julien Grall
>> --- a/tools/xenstore/utils.h
>> +++ b/tools/xenstore/utils.h
>> @@ -29,10 +29,12 @@ const char *dump_state_align(FILE *fp);
>>
>> #define PRINTF_ATTRIBUTE(a1, a2) __attribute__((format
Andrew Cooper writes ("Re: [PATCH 3/3] tools/libs: Fix headers.chk logic"):
> On 05/03/2021 12:49, Andrew Cooper wrote:
> > c/s 4664034cd dropped the $(LIBHEADERSGLOB) dependency for the headers.chk
> > rule, without replacing it.
> >
> > As headers.chk uses $^, a typical build looks like:
> >
> >
On 05/03/2021 12:49, Andrew Cooper wrote:
> c/s 4664034cd dropped the $(LIBHEADERSGLOB) dependency for the headers.chk
> rule, without replacing it.
>
> As headers.chk uses $^, a typical build looks like:
>
> andrewcoop@andrewcoop:/local/xen.git$ make -C tools/libs/devicemodel/
> make:
Hi Ian,
On 05/03/2021 13:27, Ian Jackson wrote:
Jürgen Groß writes ("Re: [PATCH for-4.15 2/2] tools/xenstore: Check the format
printf for xprintf() and barf{,_perror}()"):
On 05.03.21 13:40, Julien Grall wrote:
-extern void (*xprintf)(const char *fmt, ...);
+void barf(const char *fmt, ...)
Jürgen Groß writes ("Re: [PATCH for-4.15 2/2] tools/xenstore: Check the format
printf for xprintf() and barf{,_perror}()"):
> On 05.03.21 13:40, Julien Grall wrote:
> > -extern void (*xprintf)(const char *fmt, ...);
> > +void barf(const char *fmt, ...) __noreturn PRINTF_ATTRIBUTE(1, 2);
> > +void
Andrew Cooper writes ("[PATCH 2/3] xen/dmop: Strip __XEN_TOOLS__ header guard
from public API"):
> Exactly as with c/s f40e1c52e4, this is inappropriate for a stable library.
>
> That change actually broke the build with:
>
> include/xendevicemodel.h:52:5: error: unknown type name
Andrew Cooper writes ("[PATCH 1/3] tools/libxentoolcore: Fill in LIBHEADERS"):
> c/s 4664034cd replaced a glob over include/*.h with an expectation that
> LIBHEADER was suitably set for libraries which didn't have a single,
> consistently named, header file.
>
> This wasn't true for xentoolcore,
Julien Grall writes ("[PATCH for-4.15 2/2] tools/xenstore: Check the format
printf for xprintf() and barf{,_perror}()"):
> From: Julien Grall
>
> Allow GCC to analyze the format printf for xprintf() and
> barf{,_perror}().
>
> Take the opportunity to define __noreturn to make the prototype for
Julien Grall writes ("[PATCH for-4.15 1/2] tools/xenstore: Consolidate
PRINTF_ATTRIBUTE() in utils.h"):
> From: Julien Grall
>
> At the moment PRINTF_ATTRIBUTE() is defined in two places:
> - tdb.h: Defined as a NOP
> - talloc.h: Defined as a NOP for GCC older than 3.0 otherwise will
>
Julien Grall writes ("[PATCH for-4.15] tools/xenstored: liveupdate: Increase
the maximum number of parameters"):
> From: Julien Grall
>
> The longest possible command line for LiveUpdate is:
>
> liveupdate -s -t -F
>
> This is 5 parameters. However, the maximum is currently specified to 4.
On 05.03.21 13:40, Julien Grall wrote:
From: Julien Grall
Allow GCC to analyze the format printf for xprintf() and
barf{,_perror}().
Take the opportunity to define __noreturn to make the prototype for
barf{,_perror})() easier to read.
Signed-off-by: Julien Grall
Reviewed-by: Juergen Gross
On 05.03.21 13:40, Julien Grall wrote:
From: Julien Grall
At the moment PRINTF_ATTRIBUTE() is defined in two places:
- tdb.h: Defined as a NOP
- talloc.h: Defined as a NOP for GCC older than 3.0 otherwise will
add the attribute to check the printf format
Xen requires to build
Exactly as with c/s f40e1c52e4, this is inappropriate for a stable library.
That change actually broke the build with:
include/xendevicemodel.h:52:5: error: unknown type name 'ioservid_t'
ioservid_t *id);
^
as libxendevicemodel.h now uses a type it can't see a typedef for.
c/s 4664034cd dropped the $(LIBHEADERSGLOB) dependency for the headers.chk
rule, without replacing it.
As headers.chk uses $^, a typical build looks like:
andrewcoop@andrewcoop:/local/xen.git$ make -C tools/libs/devicemodel/
make: Entering directory '/local/xen.git/tools/libs/devicemodel'
c/s 4664034cd replaced a glob over include/*.h with an expectation that
LIBHEADER was suitably set for libraries which didn't have a single,
consistently named, header file.
This wasn't true for xentoolcore, which lost xentoolcore_internal.h as a
consequence, and failed an API/ABI check vs 4.14
This can of worms is festering. See patch 1 for yet more issues.
Andrew Cooper (3):
tools/libxentoolcore: Fill in LIBHEADERS
xen/dmop: Strip __XEN_TOOLS__ header guard from public API
tools/libs: Fix headers.chk logic
tools/libs/devicemodel/private.h | 2 --
tools/libs/libs.mk
On 05.03.21 13:10, Julien Grall wrote:
From: Julien Grall
The longest possible command line for LiveUpdate is:
liveupdate -s -t -F
This is 5 parameters. However, the maximum is currently specified to 4.
This means the some of the parameters will get ignored.
Update the field max_pars to
From: Julien Grall
This patch is a follow-up to Norbert's series [1].
The first patch will define PRINTF_ATTRIBUTE the same way everywhere.
The second patch will check the format printf on a few more calls.
Both patches are candidate for 4.15. They only affects the build system
and therefore
From: Julien Grall
At the moment PRINTF_ATTRIBUTE() is defined in two places:
- tdb.h: Defined as a NOP
- talloc.h: Defined as a NOP for GCC older than 3.0 otherwise will
add the attribute to check the printf format
Xen requires to build with minimum GCC 4.1 and we want to check the
From: Julien Grall
Allow GCC to analyze the format printf for xprintf() and
barf{,_perror}().
Take the opportunity to define __noreturn to make the prototype for
barf{,_perror})() easier to read.
Signed-off-by: Julien Grall
---
tools/xenstore/utils.h | 8 +---
1 file changed, 5
From: Julien Grall
The longest possible command line for LiveUpdate is:
liveupdate -s -t -F
This is 5 parameters. However, the maximum is currently specified to 4.
This means the some of the parameters will get ignored.
Update the field max_pars to 5 so and admin can specify the timeout
On 05.03.2021 11:56, Jan Beulich wrote:
> On 04.03.2021 15:47, Roger Pau Monne wrote:
>> --- a/xen/arch/x86/hvm/svm/svm.c
>> +++ b/xen/arch/x86/hvm/svm/svm.c
>> @@ -1795,6 +1795,7 @@ static int svm_msr_read_intercept(unsigned int msr,
>> uint64_t *msr_content)
>> const struct domain *d =
On 04.03.2021 15:47, Roger Pau Monne wrote:
> Introduce an option to allow selecting a less strict behaviour for
> rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
> commit 84e848fd7a162f669 accesses to MSRs not explicitly handled by
> Xen result in the injection of a #GP to the
On 23.02.21 10:26, Ross Lagerwall wrote:
On 2021-02-19 15:40, Juergen Gross wrote:
An event channel should be kept masked when an eoi is pending for it.
When being migrated to another cpu it might be unmasked, though.
In order to avoid this keep three different flags for each event channel
to
On 05.03.2021 10:15, Roger Pau Monné wrote:
> On Fri, Mar 05, 2021 at 12:06:19AM +, Andrew Cooper wrote:
>> On 04/03/2021 14:47, Roger Pau Monne wrote:
>>> From a release PoV the biggest risk would be breaking some of the
>>> existing MSR functionality. I think that's a necessary risk in order
On 04.03.2021 18:43, Roger Pau Monné wrote:
> One option we could go for is making this behavior depend on Kconfig:
> enable strict MSR policy for debug builds and fallback to the
> 'relaxed' one for non-debug builds. That might get us some more data,
> but again I fear most people out there will
Linux has been warning ("firmware bug") about this bit being clear for a
long time. While writable in older hardware it has been readonly on more
than just most recent hardware. For simplicitly report it always set (if
anything we may want to log the issue ourselves if it turns out to be
clear on
Prior to 4.15 Linux, when running in PV mode, did not install a #GP
handler early enough to cover for example the rdmsrl_safe() of
MSR_K8_TSEG_ADDR in bsp_init_amd() (not to speak of the unguarded read
of MSR_K7_HWCR later in the same function). The respective change
(42b3a4cb5609 "x86/xen:
The first patch was stripped of its WRMSR adjustments, albeit I'm
not convinced we'll get away with this - see there. v2 there also
addresses further comments. The 2nd patch is new here, but the
need for something like this was mentioned in v1 already.
1: PV: conditionally avoid raising #GP for
Hi,
Volodymyr Babchuk writes:
> Hi Andrew,
>
> Andrew Cooper writes:
>
>> On 24/02/2021 23:58, Volodymyr Babchuk wrote:
>>> And I am not mentioning x86 support there...
>>
>> x86 uses per-pCPU stacks, not per-vCPU stacks.
>>
>> Transcribing from an old thread which happened in private as part
On Fri, Mar 05, 2021 at 12:06:19AM +, Andrew Cooper wrote:
> On 04/03/2021 14:47, Roger Pau Monne wrote:
> > Introduce an option to allow selecting a less strict behaviour for
> > rdmsr accesses targeting a MSR not explicitly handled by Xen. Since
> > commit 84e848fd7a162f669 accesses to MSRs
flight 159830 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/159830/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332
On Thu, Mar 04, 2021 at 11:28:16PM +, Andrew Cooper wrote:
> On 04/03/2021 23:09, Boris Ostrovsky wrote:
> > On 3/4/21 9:47 AM, Roger Pau Monne wrote:
> >> Introduce an option to allow selecting a less strict behaviour for
> >> rdmsr accesses targeting a MSR not explicitly handled by Xen.
74 matches
Mail list logo
