flight 180172 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180172/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180159
test-amd64-amd64-xl-qemuu-win7-amd64
flight 180168 qemu-mainline real [real]
flight 180174 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180168/
http://logs.test-lab.xenproject.org/osstest/logs/180174/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 04/04/2023 3:55 pm, Jan Beulich wrote:
> These are "compound" instructions to issue a series of RDMSR / WRMSR
> respectively. In the emulator we can therefore implement them by using
> the existing msr_{read,write}() hooks. The memory accesses utilize that
> the HVM ->read() / ->write() hooks
On 04/04/2023 3:54 pm, Jan Beulich wrote:
> Matching what was done earlier, explicit tests are added only for
> irregular insn / memory access patterns.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper , with two minor
requests.
> --- a/tools/misc/xen-cpuid.c
> +++
On Wed, 5 Apr 2023, Julien Grall wrote:
> On 03/04/2023 00:15, Stefano Stabellini wrote:
> > On Fri, 31 Mar 2023, Julien Grall wrote:
> > > Hi Oleksii,
> > >
> > > I was going to ack the patch but then I spotted something that would want
> > > some
> > > clarification.
> > >
> > > On 29/03/2023
On 04/04/2023 3:54 pm, Jan Beulich wrote:
> These are close relatives of the AVX-VNNI ISA extension. Since the insns
> here and in particular their memory access patterns follow the usual
> scheme (and especially the byte variants of AVX-VNNI), I didn't think it
> was necessary to add a contrived
flight 180171 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180171/
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 04/04/2023 3:53 pm, Jan Beulich wrote:
> As in a few cases before (in particular: AVX512_IFMA), since the insns
> here and in particular their memory access patterns follow the usual
> scheme, I didn't think it was necessary to add a contrived test
> specifically for them.
>
> Signed-off-by:
On 04/04/2023 3:53 pm, Jan Beulich wrote:
> This can now also be used to reduce the number of parameters
> x86emul_fpu() needs to take.
>
> Signed-off-by: Jan Beulich
As said in the previous patch, I think this patch wants reordering
forwards and picking up the addition into state.
"Because
flight 180163 xen-unstable real [real]
flight 180170 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180163/
http://logs.test-lab.xenproject.org/osstest/logs/180170/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 04/04/2023 3:52 pm, Jan Beulich wrote:
> Unconditionally wire this through the ->rmw() hook. Since x86_emul_rmw()
> now wants to construct and invoke a stub, make stub_exn available to it
> via a new field in the emulator state structure.
IMO, patch 5 should be re-ordered with this, because it
flight 180169 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180169/
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 06.04.2023 17:33, Andrew Cooper wrote:
> On 06/04/2023 3:15 pm, Jan Beulich wrote:
>> The assertion at the end of x86_emulate_wrapper() as well as the ones
>> in x86_emul_{hw_exception,pagefault}() can trigger if we ignore
>> X86EMUL_EXCEPTION coming back from certain hook functions.
>
>
On 04/04/2023 3:51 pm, Jan Beulich wrote:
> For an unclear reason 0552a8cfda43 ("x86emul: track only rIP in emulator
> state") converted the original struct cpu_user_regs instance to a
> pointer, rather than dropping the field altogether: The pointer merely
> aliases the one in the context
On 06/04/2023 3:15 pm, Jan Beulich wrote:
> The assertion at the end of x86_emulate_wrapper() as well as the ones
> in x86_emul_{hw_exception,pagefault}() can trigger if we ignore
> X86EMUL_EXCEPTION coming back from certain hook functions.
Looking at the comment I wrote back then, I don't think
On Tue, 7 Mar 2023 at 18:28, David Woodhouse wrote:
>
> From: David Woodhouse
>
> There's no need for this to be in the Xen accel code, and as we want to
> use the Xen console support with KVM-emulated Xen we'll want to have a
> platform-agnostic version of it. Make it use GString to build up
On 04/04/2023 17:28, Anthony PERARD wrote:
On Wed, Mar 22, 2023 at 01:58:00PM +, Peter Hoyes wrote:
From: Peter Hoyes
Saving, restoring and migrating domains are not currently supported on
arm and arm64 platforms, so xendomains prints the warning:
An error occurred while saving
On 06/04/2023 3:28 pm, Jan Beulich wrote:
> On 06.04.2023 15:27, Andrew Cooper wrote:
>> Exceptions and NPT intercepts almost have the same layout, but NPT has bits
>> above 31 in the error code, and the name for exitinfo2 really does want
>> distinguishing between cr2 and gpa.
>>
>> In
On 06.04.2023 15:27, Andrew Cooper wrote:
> Exceptions and NPT intercepts almost have the same layout, but NPT has bits
> above 31 in the error code, and the name for exitinfo2 really does want
> distinguishing between cr2 and gpa.
>
> In nsvm_vcpu_vmexit_inject() rearrange VMEXIT_NPF to fall
The assertion at the end of x86_emulate_wrapper() as well as the ones
in x86_emul_{hw_exception,pagefault}() can trigger if we ignore
X86EMUL_EXCEPTION coming back from certain hook functions. Squash
exceptions when merely probing MSRs, plus on SWAPGS'es "best effort"
error handling path.
In
Exceptions and NPT intercepts almost have the same layout, but NPT has bits
above 31 in the error code, and the name for exitinfo2 really does want
distinguishing between cr2 and gpa.
In nsvm_vcpu_vmexit_inject() rearrange VMEXIT_NPF to fall through instead of
repeating the exitinfo1 write. Use
On 06/04/2023 1:50 pm, Jan Beulich wrote:
> On 06.04.2023 14:17, Andrew Cooper wrote:
>> ... rather than having separate definitions locally. EXC_HAS_EC in
>> particular
>> is missing #CP, #VC and #SX vs X86_EXC_HAVE_EC.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper
> Acked-by:
On 06.04.2023 14:17, Andrew Cooper wrote:
> ... rather than having separate definitions locally. EXC_HAS_EC in particular
> is missing #CP, #VC and #SX vs X86_EXC_HAVE_EC.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
Yet more re-basing for me to do ...
... rather than having separate definitions locally. EXC_HAS_EC in particular
is missing #CP, #VC and #SX vs X86_EXC_HAVE_EC.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Wei Liu
---
xen/arch/x86/x86_emulate/x86_emulate.c | 608
On 06/04/2023 12:41 pm, Roger Pau Monne wrote:
> It's a GNU libc specific header which prevents building on musl for
> example. Instead use errx() in ERROR() and DIFF_FATAL() macros.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
flight 180159 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180159/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 180145
test-amd64-amd64-xl-qemuu-win7-amd64
It's a GNU libc specific header which prevents building on musl for
example. Instead use errx() in ERROR() and DIFF_FATAL() macros.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
Cc: Ross Lagerwall
---
Changes since v1:
- Use errx().
---
common.h | 9 ++---
From: Juergen Gross
[ Upstream commit 2eca98e5b24d01c02b46c67be05a5f98cc9789b1 ]
Issue the same error message in case an illegal page boundary crossing
has been detected in both cases where this is tested.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Link:
From: Juergen Gross
[ Upstream commit 2eca98e5b24d01c02b46c67be05a5f98cc9789b1 ]
Issue the same error message in case an illegal page boundary crossing
has been detected in both cases where this is tested.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Link:
From: Juergen Gross
[ Upstream commit 2eca98e5b24d01c02b46c67be05a5f98cc9789b1 ]
Issue the same error message in case an illegal page boundary crossing
has been detected in both cases where this is tested.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Link:
From: Juergen Gross
[ Upstream commit 2eca98e5b24d01c02b46c67be05a5f98cc9789b1 ]
Issue the same error message in case an illegal page boundary crossing
has been detected in both cases where this is tested.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Link:
From: Juergen Gross
[ Upstream commit 2eca98e5b24d01c02b46c67be05a5f98cc9789b1 ]
Issue the same error message in case an illegal page boundary crossing
has been detected in both cases where this is tested.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Link:
From: Juergen Gross
[ Upstream commit 2eca98e5b24d01c02b46c67be05a5f98cc9789b1 ]
Issue the same error message in case an illegal page boundary crossing
has been detected in both cases where this is tested.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Link:
From: Juergen Gross
[ Upstream commit 2eca98e5b24d01c02b46c67be05a5f98cc9789b1 ]
Issue the same error message in case an illegal page boundary crossing
has been detected in both cases where this is tested.
Suggested-by: Jan Beulich
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
Link:
On 06/04/2023 10:59 am, Jan Beulich wrote:
> On 06.04.2023 11:52, Andrew Cooper wrote:
>> On 06/04/2023 10:31 am, Jan Beulich wrote:
>>> On 05.04.2023 22:44, Andrew Cooper wrote:
--- a/xen/arch/x86/include/asm/hvm/svm/vmcb.h
+++ b/xen/arch/x86/include/asm/hvm/svm/vmcb.h
@@ -450,6
On 06/04/2023 11:54 am, Roger Pau Monné wrote:
> On Thu, Apr 06, 2023 at 10:36:37AM +0100, Andrew Cooper wrote:
>> On 06/04/2023 10:18 am, Roger Pau Monne wrote:
>>> It's a GNU libc specific header which prevents building on musl for
>>> example. Instead open code an equivalent replacement for
On Thu, Apr 06, 2023 at 10:36:37AM +0100, Andrew Cooper wrote:
> On 06/04/2023 10:18 am, Roger Pau Monne wrote:
> > It's a GNU libc specific header which prevents building on musl for
> > example. Instead open code an equivalent replacement for the usage
> > of ERROR() and DIFF_FATAL() macros.
>
On 05/04/2023 12:17, Michal Orzel wrote:
In both vpl011_read_data() and vpl011_read_data_xen(), there is a comment
stating that the guest is expected to read the DR register only if the
TXFE bit of FR register is not set. This is obviously logically wrong and
it should be RXFE (i.e. RX FIFO
flight 180153 qemu-mainline real [real]
flight 180167 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180153/
http://logs.test-lab.xenproject.org/osstest/logs/180167/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On Wed, Apr 05, 2023 at 03:18:32PM -0500, Bjorn Helgaas wrote:
> On Wed, Apr 05, 2023 at 11:28:27AM +0300, Andy Shevchenko wrote:
> > On Tue, Apr 04, 2023 at 11:11:01AM -0500, Bjorn Helgaas wrote:
> > > On Thu, Mar 30, 2023 at 07:24:27PM +0300, Andy Shevchenko wrote:
...
> > > I omitted
> > >
>
On 06.04.2023 11:52, Andrew Cooper wrote:
> On 06/04/2023 10:31 am, Jan Beulich wrote:
>> On 05.04.2023 22:44, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/include/asm/hvm/svm/vmcb.h
>>> +++ b/xen/arch/x86/include/asm/hvm/svm/vmcb.h
>>> @@ -450,6 +450,11 @@ struct vmcb_struct {
>>>
>>>
On 06/04/2023 10:31 am, Jan Beulich wrote:
> On 05.04.2023 22:44, Andrew Cooper wrote:
>> This removes raw number manipulation, and makes the logic easier to follow.
>>
>> No functional change.
>>
>> Signed-off-by: Andrew Cooper
> Reviewed-by: Jan Beulich
Thanks.
>
> One remark though:
>
>>
On 06/04/2023 10:18 am, Roger Pau Monne wrote:
> It's a GNU libc specific header which prevents building on musl for
> example. Instead open code an equivalent replacement for the usage
> of ERROR() and DIFF_FATAL() macros.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Konrad Rzeszutek Wilk
>
On 05.04.2023 22:44, Andrew Cooper wrote:
> This removes raw number manipulation, and makes the logic easier to follow.
>
> No functional change.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Jan Beulich
One remark though:
> --- a/xen/arch/x86/include/asm/hvm/svm/vmcb.h
> +++
It's a GNU libc specific header which prevents building on musl for
example. Instead open code an equivalent replacement for the usage
of ERROR() and DIFF_FATAL() macros.
Signed-off-by: Roger Pau Monné
---
Cc: Konrad Rzeszutek Wilk
Cc: Ross Lagerwall
---
common.h | 10 ++
flight 180166 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/180166/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3e3be2cbc286e773ed5bd3afd5942440546888de
baseline version:
ovmf
For generic virtio devices, where we don't need to add compatible or
other special DT properties, the type field is set to "virtio,device".
But this misses the case where the user sets the type with a valid
virtio device id as well, like "virtio,device1a" for file system device.
The complete list
The strings won't be an exact match, as we are only looking to match the
prefix here, i.e. "virtio,device". This is already done properly in
libxl_virtio.c file, lets do the same here too.
Fixes: 43ba5202e2ee ("libxl: add support for generic virtio device")
Signed-off-by: Viresh Kumar
Hi,
On 06/04/2023 07:35, Jan Beulich wrote:
On 05.04.2023 18:39, Julien Grall wrote:
To reduce the amount of patch to resend, I was actually thinking to
merge patch #1-3 and #5 (so leave this patch alone) and modify the
default in a follow-up. Any thoughts?
Well, yes, that's what I did a
flight 180149 linux-5.4 real [real]
flight 180165 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/180149/
http://logs.test-lab.xenproject.org/osstest/logs/180165/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 05.04.2023 23:52, Andrew Cooper wrote:
> At the time of XSA-170, the x86 instruction emulator was genuinely broken. It
> would load arbitrary values into %rip and putting a check here probably was
> the best stopgap security fix. It should have been reverted following c/s
> 81d3a0b26c1
On 06.04.2023 01:02, Andrew Cooper wrote:
> On 05/04/2023 9:56 am, Jan Beulich wrote:
>> On 04.04.2023 18:06, Sergey Dyasli wrote:
>>> --- a/tools/libs/ctrl/xc_misc.c
>>> +++ b/tools/libs/ctrl/xc_misc.c
>>> @@ -243,6 +243,24 @@ int xc_get_cpu_version(xc_interface *xch, struct
>>>
On 05.04.2023 23:29, Andrew Cooper wrote:
> On 04/04/2023 3:50 pm, Jan Beulich wrote:
>> This insn differs from WRMSR solely in the lack of serialization. Hence
>> the code used there can simply be used here as well, plus a feature
>> check of course.
>
> I have a feeling this is a bit stale now
On 05.04.2023 18:39, Julien Grall wrote:
> To reduce the amount of patch to resend, I was actually thinking to
> merge patch #1-3 and #5 (so leave this patch alone) and modify the
> default in a follow-up. Any thoughts?
Well, yes, that's what I did a couple of days ago already.
Jan
On 06.04.23 05:57, Marek Marczykowski-Górecki wrote:
Add xendevicemodel_get_ioreq_server_info_ext() which additionally
returns output flags that XEN_DMOP_get_ioreq_server_info can now return.
Do not change signature of existing
xendevicemodel_get_ioreq_server_info() so existing users will not
55 matches
Mail list logo
