Am Fri, 11 Jun 2021 07:01:31 +0200
schrieb Juergen Gross :
> Why? You realize that above is a comment just documenting the default?
That depends on the context. See
https://bugzilla.opensuse.org/show_bug.cgi?id=1185682 for a reason why it
should become an empty variable. But yes, we can patch
flight 162600 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162600/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 8 xen-boot fail REGR. vs. 162533
On 08.06.21 18:39, Olaf Hering wrote:
Am Tue, 8 Jun 2021 07:58:39 +0200
schrieb Juergen Gross :
+#XENSTORED_MAX_N_DOMAINS=32768
This will break fillup.
Why? You realize that above is a comment just documenting the default?
Provide an empty variable like it is done for a few others in
flight 162626 xen-unstable-smoke real [real]
flight 162628 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162626/
http://logs.test-lab.xenproject.org/osstest/logs/162628/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
branch xen-unstable
xenbranch xen-unstable
job test-xtf-amd64-amd64-4
testid xtf/test-pv32pae-selftest
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu
On Thu, 10 Jun 2021, Bertrand Marquis wrote:
> Hi Jan,
>
> > On 10 Jun 2021, at 12:32, Jan Beulich wrote:
> >
> > On 10.06.2021 12:50, osstest service owner wrote:
> >> flight 162597 xen-unstable-smoke real [real]
> >> flight 162602 xen-unstable-smoke real-retest [real]
> >>
flight 162618 xen-unstable-smoke real [real]
flight 162621 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162618/
http://logs.test-lab.xenproject.org/osstest/logs/162621/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
flight 162591 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162591/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-freebsd11-amd64 16 guest-saverestore fail REGR. vs.
152631
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
flight 162607 xen-unstable-smoke real [real]
flight 162612 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162607/
http://logs.test-lab.xenproject.org/osstest/logs/162612/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
flight 162576 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162576/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 162361
test-amd64-amd64-qemuu-nested-amd 20
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemuu-debianhvm-amd64
testid guest-saverestore
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf git://xenbits.xen.org/osstest/ovmf.git
Tree: qemu
flight 162598 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162598/
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
flight 162561 xen-4.15-testing real [real]
flight 162608 xen-4.15-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162561/
http://logs.test-lab.xenproject.org/osstest/logs/162608/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
Hi Jan,
> On 10 Jun 2021, at 12:32, Jan Beulich wrote:
>
> On 10.06.2021 12:50, osstest service owner wrote:
>> flight 162597 xen-unstable-smoke real [real]
>> flight 162602 xen-unstable-smoke real-retest [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/162597/
>>
flight 162583 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162583/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 12 debian-hvm-install fail REGR. vs. 162359
On 10.06.21 17:10, Roger Pau Monné wrote:
> On Thu, Jun 10, 2021 at 10:01:16AM +, Oleksandr Andrushchenko wrote:
>> Hello, Roger!
>>
>> On 10.06.21 10:54, Roger Pau Monné wrote:
>>> On Fri, Jun 04, 2021 at 06:37:27AM +, Oleksandr Andrushchenko wrote:
Hi, all!
While working
On 6/7/2021 10:56 PM, Tianyu Lan wrote:
On 6/7/2021 2:43 PM, Christoph Hellwig wrote:
On Sun, May 30, 2021 at 11:06:25AM -0400, Tianyu Lan wrote:
From: Tianyu Lan
For Hyper-V isolation VM with AMD SEV SNP, the bounce buffer(shared
memory)
needs to be accessed via extra address
Hi Vitaly:
Thanks for your review.
On 6/10/2021 5:47 PM, Vitaly Kuznetsov wrote:
diff --git a/arch/x86/include/asm/hyperv-tlfs.h
b/arch/x86/include/asm/hyperv-tlfs.h
index 606f5cc579b2..632281b91b44 100644
--- a/arch/x86/include/asm/hyperv-tlfs.h
+++
flight 162603 xen-unstable-smoke real [real]
flight 162606 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162603/
http://logs.test-lab.xenproject.org/osstest/logs/162606/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
On 6/9/2021 8:46 PM, Joerg Roedel wrote:
On Sun, May 30, 2021 at 11:06:21AM -0400, Tianyu Lan wrote:
+void hv_ghcb_msr_write(u64 msr, u64 value)
+{
+ union hv_ghcb *hv_ghcb;
+ void **ghcb_base;
+ unsigned long flags;
+
+ if (!ms_hyperv.ghcb_base)
+
Hi Joerg：
Thanks for your review.
On 6/9/2021 8:38 PM, Joerg Roedel wrote:
On Sun, May 30, 2021 at 11:06:18AM -0400, Tianyu Lan wrote:
From: Tianyu Lan
Hyper-V exposes GHCB page via SEV ES GHCB MSR for SNP guest
to communicate with hypervisor. Map GHCB page for all
cpus to
On Thu, Jun 10, 2021 at 10:01:16AM +, Oleksandr Andrushchenko wrote:
> Hello, Roger!
>
> On 10.06.21 10:54, Roger Pau Monné wrote:
> > On Fri, Jun 04, 2021 at 06:37:27AM +, Oleksandr Andrushchenko wrote:
> >> Hi, all!
> >>
> >> While working on PCI SR-IOV support for ARM I started porting
On 10.06.2021 13:58, Jan Beulich wrote:
> On 09.06.2021 12:53, Andrew Cooper wrote:
>> On 09/06/2021 10:27, Jan Beulich wrote:
>>> It appears unhelpful to me for flush_command_buffer() to block all
>>> progress elsewhere for the given IOMMU by holding its lock while
>>> waiting for command
flight 162557 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162557/
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 10.06.21 15:02, Jan Beulich wrote:
> On 10.06.2021 13:45, Oleksandr Andrushchenko wrote:
>> Hi, Jan!
>>
>> On 10.06.21 13:48, Jan Beulich wrote:
>>> On 10.06.2021 12:01, Oleksandr Andrushchenko wrote:
On 10.06.21 10:54, Roger Pau Monné wrote:
> OTOH if we properly trap accesses to the
On 09.06.2021 12:36, Andrew Cooper wrote:
> On 09/06/2021 10:26, Jan Beulich wrote:
>> The present abuse of the completion interrupt does not only stand in the
>> way of, down the road, using it for its actual purpose, but also
>> requires holding the IOMMU lock while waiting for command
On 10.06.2021 13:45, Oleksandr Andrushchenko wrote:
> Hi, Jan!
>
> On 10.06.21 13:48, Jan Beulich wrote:
>> On 10.06.2021 12:01, Oleksandr Andrushchenko wrote:
>>> On 10.06.21 10:54, Roger Pau Monné wrote:
OTOH if we properly trap accesses to the SR-IOV capability (like it
was proposed
On 09.06.2021 12:53, Andrew Cooper wrote:
> On 09/06/2021 10:27, Jan Beulich wrote:
>> It appears unhelpful to me for flush_command_buffer() to block all
>> progress elsewhere for the given IOMMU by holding its lock while
>> waiting for command completion. Unless the lock is already held,
>>
Hi, Jan!
On 10.06.21 13:48, Jan Beulich wrote:
> On 10.06.2021 12:01, Oleksandr Andrushchenko wrote:
>> On 10.06.21 10:54, Roger Pau Monné wrote:
>>> OTOH if we properly trap accesses to the SR-IOV capability (like it
>>> was proposed in [1] from your references) we won't have to modify OSes
>>>
On 10.06.2021 12:50, osstest service owner wrote:
> flight 162597 xen-unstable-smoke real [real]
> flight 162602 xen-unstable-smoke real-retest [real]
> http://logs.test-lab.xenproject.org/osstest/logs/162597/
> http://logs.test-lab.xenproject.org/osstest/logs/162602/
>
> Regressions :-(
>
>
On 07.06.2021 04:43, Penny Zheng wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -1087,6 +1087,9 @@ static struct page_info *alloc_staticmem_pages(unsigned
> long nr_mfns,
> nr_mfns, mfn_x(smfn));
> return NULL;
> }
> +
> +
flight 162597 xen-unstable-smoke real [real]
flight 162602 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162597/
http://logs.test-lab.xenproject.org/osstest/logs/162602/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
On 10.06.2021 12:01, Oleksandr Andrushchenko wrote:
> On 10.06.21 10:54, Roger Pau Monné wrote:
>> OTOH if we properly trap accesses to the SR-IOV capability (like it
>> was proposed in [1] from your references) we won't have to modify OSes
>> that want to run as hardware domains in order to
On 07.06.2021 04:43, Penny Zheng wrote:
> alloc_staticmem_pages aims to allocate nr_mfns contiguous pages of
> static memory. And it is the equivalent of alloc_heap_pages for static
> memory. Here only covers allocating at specified starting address.
>
> For each page, it shall check if the page
Hello, Roger!
On 10.06.21 10:54, Roger Pau Monné wrote:
> On Fri, Jun 04, 2021 at 06:37:27AM +, Oleksandr Andrushchenko wrote:
>> Hi, all!
>>
>> While working on PCI SR-IOV support for ARM I started porting [1] on top
>> of current PCI on ARM support [2]. The question I have for this series
Tianyu Lan writes:
> From: Tianyu Lan
>
> In Isolation VM, all shared memory with host needs to mark visible
> to host via hvcall. vmbus_establish_gpadl() has already done it for
> netvsc rx/tx ring buffer. The page buffer used by vmbus_sendpacket_
> pagebuffer() still need to handle. Use DMA
On 07.06.2021 04:43, Penny Zheng wrote:
> Introduce new interface assign_pages_nr to deal with when page number is
> not in a power-of-two, which will save the trouble each time user needs
> to split the size in a power of 2 to use assign_pages.
First of all I still don't see why in this one
Tianyu Lan writes:
> From: Tianyu Lan
>
> Add new hvcall guest address host visibility support. Mark vmbus
> ring buffer visible to host when create gpadl buffer and mark back
> to not visible when tear down gpadl buffer.
>
> Co-developed-by: Sunil Muthuswamy
> Signed-off-by: Tianyu Lan
> ---
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-ovmf-amd64
testid debian-hvm-install
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: ovmf https://github.com/tianocore/edk2.git
Tree: qemu
flight 162556 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162556/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-ws16-amd64 8 xen-boot fail REGR. vs. 162533
On 07.06.2021 04:43, Penny Zheng wrote:
> --- a/xen/arch/arm/setup.c
> +++ b/xen/arch/arm/setup.c
> @@ -611,6 +611,30 @@ static void __init init_pdx(void)
> }
> }
>
> +/* Static memory initialization */
> +static void __init init_staticmem_pages(void)
> +{
> +int bank;
While I'm not a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2021-0089,CVE-2021-26313 / XSA-375
version 4
Speculative Code Store Bypass
UPDATES IN VERSION 4
Correct the link to the AMD bulletin.
ISSUE
flight 162563 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/162563/
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
On 10/06/2021 09:04, Sven Kieske wrote:
> On Mi, 2021-06-09 at 13:50 +, Xen.org security team wrote:
>> For more details, see:
> [..]
>> https://www.amd.com/en/corporate-product-security-bulletin-amd-sb-1003
> The above link turns into a "Page not found", at least for me, I believe the
>
On Mi, 2021-06-09 at 13:50 +, Xen.org security team wrote:
> For more details, see:
[..]
> https://www.amd.com/en/corporate-product-security-bulletin-amd-sb-1003
The above link turns into a "Page not found", at least for me, I believe the
correct link is:
On Fri, Jun 04, 2021 at 06:37:27AM +, Oleksandr Andrushchenko wrote:
> Hi, all!
>
> While working on PCI SR-IOV support for ARM I started porting [1] on top
> of current PCI on ARM support [2]. The question I have for this series
> is if we really need emulating SR-IOV code in Xen?
>
> I
On 09.06.2021 17:45, Andrew Cooper wrote:
> On 09/06/2021 14:14, Jan Beulich wrote:
>> Clang 10 reports
>>
>> domain.c:1328:10: error: variable 'cr3_mfn' is used uninitialized whenever
>> 'if' condition is false [-Werror,-Wsometimes-uninitialized]
>> if ( !compat )
>> ^~~
>>
flight 162590 xen-unstable-smoke real [real]
flight 162595 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/162590/
http://logs.test-lab.xenproject.org/osstest/logs/162595/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which
49 matches
Mail list logo
