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. Since
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
test-amd64-i386-xl-
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 n
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 o
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 ea
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: Support
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 o
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 r
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 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 b
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 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 = v->d
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 and
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 wo
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 insertions
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
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
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
F
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'
f
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. Howev
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 wi
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
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.
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 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
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, w
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 'ioservid_t'
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
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, ...) __
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: Entering
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 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 (p
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 PRINTF_ATTRIBU
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 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 libxendevi
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 exte
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
test-amd64-amd64-xl-qemut-win7-amd64
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'
>>
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:
>>>
>>> include/xendevicemodel.h:52:5
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 buil
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 inne
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 i
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 thi
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 paramete
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
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ß w
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
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 of
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 1
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
> l
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 tend
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.
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 bits
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 al
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. Therefor
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 ef91b07388e1c0a50c604
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
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
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
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 (inv
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
>
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
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 t
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) was
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 virtualize
-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
-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
=
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
test-armhf-armhf-
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
test-amd64-i386-xl-
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 20
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 +00
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
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
test-amd64-i386-xl-qemuu-win7-am
74 matches
Mail list logo
