flight 151465 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151465/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 00217f1919270007d7a911f89b32e39b9dcaa907
baseline version:
ovmf
Hi Roger,
thanks for your time, your remark that you cannot see how it has to do with the
shared_info got me to step-by-step revert all changes I have done. Turns out a
few weeks ago when implementing a sysctl I must have accidentally deleted the
architecture specific syctl in the default case
On 30.06.20 09:09, Oleksandr Andrushchenko wrote:
On 6/30/20 10:03 AM, Jürgen Groß wrote:
On 30.06.20 08:13, Oleksandr Andrushchenko wrote:
On 6/29/20 10:02 AM, Jürgen Groß wrote:
On 20.05.20 11:04, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Change protocol version
On 30.06.20 08:13, Oleksandr Andrushchenko wrote:
On 6/29/20 10:02 AM, Jürgen Groß wrote:
On 20.05.20 11:04, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Change protocol version from string to integer
Version string, which is in fact an integer, is hard to handle in the
On 6/30/20 10:03 AM, Jürgen Groß wrote:
On 30.06.20 08:13, Oleksandr Andrushchenko wrote:
On 6/29/20 10:02 AM, Jürgen Groß wrote:
On 20.05.20 11:04, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
1. Change protocol version from string to integer
Version string, which is in
On 6/29/20 10:02 AM, Jürgen Groß wrote:
> On 20.05.20 11:04, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> 1. Change protocol version from string to integer
>>
>> Version string, which is in fact an integer, is hard to handle in the
>> code that supports different protocol
On Mon, Jun 29, 2020 at 07:20:35PM +, Anchal Agarwal wrote:
> On Fri, Jun 26, 2020 at 11:12:39AM +0200, Roger Pau Monné wrote:
> > So the frontend should do:
> >
> > - Switch to Closed state (and cleanup everything required).
> > - Wait for backend to switch to Closed state (must be done
> >
Ian, Wei, would you mind looking at the below please?
Thank you in advance,
Oleksandr
On 5/20/20 12:04 PM, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add version 2 of the dma-buf ioctls which adds data_ofs parameter.
>
> dma-buf is backed by a scatter-gather table and
Rename 'vai' to 'via'.
Signed-off-by: Olaf Hering
---
xen/arch/x86/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/Kconfig b/xen/arch/x86/Kconfig
index 4a2ec87ff5..a636a4bb1e 100644
--- a/xen/arch/x86/Kconfig
+++ b/xen/arch/x86/Kconfig
@@ -113,7 +113,7
> -Original Message-
> From: Xen-devel On Behalf Of Olaf
> Hering
> Sent: 30 June 2020 11:21
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Olaf Hering ;
> Wei Liu ; Jan
> Beulich ; Roger Pau Monné
> Subject: [PATCH v1] kconfig: fix typo in XEN_SHSTK description
>
> Rename
On 30.06.2020 11:52, Roger Pau Monné wrote:
> On Mon, Jun 29, 2020 at 05:50:59PM +0200, Jan Beulich wrote:
>> As was pointed out by "mm: fix public declaration of struct
>> xen_mem_acquire_resource", we're not currently handling structs
>> correctly that has uint64_aligned_t fields. #pragma
flight 151469 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151469/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151417
test-armhf-armhf-libvirt-raw 13
I'm not familiar with compat header generation, sorry if the comments
below are obvious or plain wrong.
On Mon, Jun 29, 2020 at 05:50:59PM +0200, Jan Beulich wrote:
> As was pointed out by "mm: fix public declaration of struct
> xen_mem_acquire_resource", we're not currently handling structs
>
On 6/30/20 10:30 AM, Jürgen Groß wrote:
> On 30.06.20 09:09, Oleksandr Andrushchenko wrote:
>> On 6/30/20 10:03 AM, Jürgen Groß wrote:
>>> On 30.06.20 08:13, Oleksandr Andrushchenko wrote:
On 6/29/20 10:02 AM, Jürgen Groß wrote:
> On 20.05.20 11:04, Oleksandr Andrushchenko wrote:
>>
On 30.06.20 09:39, Oleksandr Andrushchenko wrote:
On 6/30/20 10:30 AM, Jürgen Groß wrote:
On 30.06.20 09:09, Oleksandr Andrushchenko wrote:
On 6/30/20 10:03 AM, Jürgen Groß wrote:
On 30.06.20 08:13, Oleksandr Andrushchenko wrote:
On 6/29/20 10:02 AM, Jürgen Groß wrote:
On 20.05.20 11:04,
On 26.06.2020 17:57, Roger Pau Monne wrote:
> Commit e9aca9470ed86 introduced a regression when avoiding sending
> IPIs for certain flush operations. Xen page fault handler
> (spurious_page_fault) relies on blocking interrupts in order to
> prevent handling TLB flush IPIs and thus preventing other
Hi all,
Xen 4.14 RC4 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.14.0-rc4
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.14.0-rc4/xen-4.14.0-rc4.tar.gz
And the signature is at:
flight 151461 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151461/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 151448
From: Michal Leszczynski
Add an demonstration tool that uses xc_vmtrace_* calls in order
to manage external IPT monitoring for DomU.
Signed-off-by: Michal Leszczynski
---
tools/proctrace/COPYING | 339
tools/proctrace/Makefile| 48 +
> -Original Message-
> From: Anthony PERARD
> Sent: 30 June 2020 16:09
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; qemu-de...@nongnu.org; Eduardo Habkost
> ;
> Michael S. Tsirkin ; Paul Durrant ;
> Jason Andryuk
> ; Paolo Bonzini ; Richard Henderson
>
> Subject: Re:
From: Michal Leszczynski
Allow to specify the size of per-vCPU trace buffer upon
domain creation. This is zero by default (meaning: not enabled).
Signed-off-by: Michal Leszczynski
---
docs/man/xl.cfg.5.pod.in | 10 ++
tools/golang/xenlight/helpers.gen.go | 2 ++
From: Michal Leszczynski
Add functions in libxc that use the new XEN_DOMCTL_vmtrace interface.
Signed-off-by: Michal Leszczynski
---
tools/libxc/Makefile | 1 +
tools/libxc/include/xenctrl.h | 39 +++
tools/libxc/xc_vmtrace.c | 73
From: Michal Leszczynski
Allocate processor trace buffer for each vCPU when the domain
is created, deallocate trace buffers on domain destruction.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/domain.c| 11 +++
xen/common/domain.c | 32
From: Michal Leszczynski
Allow to map processor trace buffer using
acquire_resource().
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/mm.c | 25 +
xen/include/public/memory.h | 1 +
2 files changed, 26 insertions(+)
diff --git a/xen/arch/x86/mm.c
From: Michal Leszczynski
Implement domctl to manage the runtime state of
processor trace feature.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/domctl.c | 48 +
xen/include/public/domctl.h | 26
2 files changed, 74
On Tue, Jun 30, 2020 at 02:13:36PM +0200, Jan Beulich wrote:
> On 26.06.2020 17:57, Roger Pau Monne wrote:
> > Commit e9aca9470ed86 introduced a regression when avoiding sending
> > IPIs for certain flush operations. Xen page fault handler
> > (spurious_page_fault) relies on blocking interrupts in
flight 151467 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151467/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
Tests which did
On Wed, Jun 24, 2020 at 01:18:41PM +0100, Paul Durrant wrote:
> From: Paul Durrant
>
> The generic pc_machine_initfn() calls pc_system_flash_create() which creates
> 'system.flash0' and 'system.flash1' devices. These devices are then realized
> by pc_system_flash_map() which is called from
On 6/24/20 2:18 PM, Paul Durrant wrote:
> From: Paul Durrant
>
> 'xen-sysdev' plugs into the 'System' bus type, not 'xen-sysbus. That bus type
> is what 'xen-backend' plugs into.
> 'xen-sysdev' is drived form 'sys-bus-device' so the bus type need not be
> overridden. 'xen-backend' is derived
From: Michal Leszczynski
Use Intel Processor Trace feature in order to
provision vmtrace_pt_* features.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/hvm/vmx/vmx.c | 89 ++
xen/include/asm-x86/hvm/hvm.h | 38 +
From: Michal Leszczynski
Define constants related to Intel Processor Trace features.
Signed-off-by: Michal Leszczynski
---
xen/include/asm-x86/msr-index.h | 37 +
1 file changed, 37 insertions(+)
diff --git a/xen/include/asm-x86/msr-index.h
From: Michal Leszczynski
Intel Processor Trace is an architectural extension available in modern Intel
family CPUs. It allows recording the detailed trace of activity while the
processor executes the code. One might use the recorded trace to reconstruct
the code flow. It means, to find out
From: Michal Leszczynski
Check if Intel Processor Trace feature is supported by current
processor. Define vmtrace_supported global variable.
Signed-off-by: Michal Leszczynski
---
xen/arch/x86/hvm/vmx/vmcs.c | 7 ++-
xen/common/domain.c | 2 ++
From: Michal Leszczynski
Allow to acquire large resources by allowing acquire_resource()
to process items in batches, using hypercall continuation.
Signed-off-by: Michal Leszczynski
---
xen/common/memory.c | 32 +---
1 file changed, 29 insertions(+), 3 deletions(-)
Hi Roger,
On 26/06/2020 16:57, Roger Pau Monne wrote:
Commit e9aca9470ed86 introduced a regression when avoiding sending
IPIs for certain flush operations. Xen page fault handler
(spurious_page_fault) relies on blocking interrupts in order to
prevent handling TLB flush IPIs and thus preventing
On 6/30/20 2:33 PM, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Intel Processor Trace is an architectural extension available in modern Intel
> family CPUs. It allows recording the detailed trace of activity while the
> processor executes the code. One might use the recorded trace
On 6/24/20 2:18 PM, Paul Durrant wrote:
> From: Paul Durrant
>
> The generic pc_machine_initfn() calls pc_system_flash_create() which creates
> 'system.flash0' and 'system.flash1' devices. These devices are then realized
> by pc_system_flash_map() which is called from pc_system_firmware_init()
> -Original Message-
> From: Julien Grall
> Sent: 30 June 2020 13:48
> To: Roger Pau Monne ; xen-devel@lists.xenproject.org
> Cc: p...@xen.org; Stefano Stabellini ; Volodymyr
> Babchuk
> ; Andrew Cooper ;
> George Dunlap
> ; Ian Jackson ; Jan
> Beulich ;
> Wei Liu
> Subject: Re:
flight 151476 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151476/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On Wed, Jun 24, 2020 at 08:52:44AM -0400, Jason Andryuk wrote:
> On Wed, Jun 24, 2020 at 8:30 AM Paul Durrant wrote:
> >
> > > -Original Message-
> > > From: Jason Andryuk
> > > Sent: 24 June 2020 13:20
> > > To: Stefano Stabellini ; Anthony Perard
> > > ; Paul
> > > Durrant ;
On 30.06.2020 14:33, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Define constants related to Intel Processor Trace features.
>
> Signed-off-by: Michal Leszczynski
This needs re-basing onto current staging, now that Andrew's patch
to add the MSR numbers has gone in. Apart from
On Tue, Jun 30, 2020 at 11:39 AM Andrew Cooper
wrote:
>
> On 30/06/2020 13:33, Michał Leszczyński wrote:
> > diff --git a/xen/include/asm-x86/msr-index.h
> > b/xen/include/asm-x86/msr-index.h
> > index b328a47ed8..0203029be9 100644
> > --- a/xen/include/asm-x86/msr-index.h
> > +++
flight 151471 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151471/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs.
- 30 cze 2020 o 20:03, Tamas K Lengyel tamas.k.leng...@gmail.com napisał(a):
> On Tue, Jun 30, 2020 at 11:39 AM Andrew Cooper
> wrote:
>>
>> On 30/06/2020 13:33, Michał Leszczyński wrote:
>> > diff --git a/xen/include/asm-x86/msr-index.h
>> > b/xen/include/asm-x86/msr-index.h
>> > index
In order to get the CNT value from QEMU, we were supposed to read a
word, according to the implementation in QEMU. But it has been lax and
allowed to read a single byte. This has changed with commit
5d971f9e6725 ("memory: Revert "memory: accept mismatching sizes in
memory_region_access_valid"")
On 6/30/20 5:44 PM, Paul Durrant wrote:
>> -Original Message-
>> From: Philippe Mathieu-Daudé
>> Sent: 30 June 2020 16:26
>> To: Paul Durrant ; xen-devel@lists.xenproject.org;
>> qemu-de...@nongnu.org
>> Cc: Eduardo Habkost ; Michael S. Tsirkin
>> ; Paul Durrant
>> ; Jason Andryuk ;
On 30/06/2020 13:33, Michał Leszczyński wrote:
> diff --git a/xen/include/asm-x86/msr-index.h b/xen/include/asm-x86/msr-index.h
> index b328a47ed8..0203029be9 100644
> --- a/xen/include/asm-x86/msr-index.h
> +++ b/xen/include/asm-x86/msr-index.h
> @@ -69,6 +69,43 @@
> #define MSR_MCU_OPT_CTRL
> -Original Message-
> From: Philippe Mathieu-Daudé
> Sent: 30 June 2020 16:26
> To: Paul Durrant ; xen-devel@lists.xenproject.org;
> qemu-de...@nongnu.org
> Cc: Eduardo Habkost ; Michael S. Tsirkin
> ; Paul Durrant
> ; Jason Andryuk ; Paolo Bonzini
> ;
> Richard Henderson
> Subject:
On 19/06/2020 15:19, Hubert Jasudowicz wrote:
> On 6/18/20 6:51 PM, Andrew Cooper wrote:
>> On 18/06/2020 17:22, Hubert Jasudowicz wrote:
>>> When running under KVM (or presumably other hypervisors) we enable
>>> the CPUID.1.EDX.HTT flag, thus indicating validity of CPUID.1.EBX[23:16]
>>> -
[+cc Juergen, Boris]
On Thu, Apr 09, 2020 at 12:41:18PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The variable irq is being initialized with a value that is never read
> and it is being updated later with a new value. The initialization is
> redundant and can be removed.
>
>
I get the following errors when trying to build xen-4.14.0-rc4
kdd.c: In function 'kdd_tx':
kdd.c:754:15: error: array subscript 16 is above array bounds of 'uint8_t[16]'
{aka 'unsigned char[16]'} [-Werror=array-bounds]
754 | s->txb[len++] = 0xaa;
| ~~^~~
flight 151473 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151473/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm 10 debian-hvm-install fail REGR.
vs. 151461
Philippe Mathieu-Daudé writes:
> On 6/30/20 5:44 PM, Paul Durrant wrote:
>>> -Original Message-
>>> From: Philippe Mathieu-Daudé
>>> Sent: 30 June 2020 16:26
>>> To: Paul Durrant ; xen-devel@lists.xenproject.org;
>>> qemu-de...@nongnu.org
>>> Cc: Eduardo Habkost ; Michael S. Tsirkin
Anthony PERARD writes:
> On Wed, Jun 24, 2020 at 01:18:41PM +0100, Paul Durrant wrote:
>> From: Paul Durrant
>>
>> The generic pc_machine_initfn() calls pc_system_flash_create() which creates
>> 'system.flash0' and 'system.flash1' devices. These devices are then realized
>> by
flight 151480 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151480/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
Tests which did
55 matches
Mail list logo
