On Vi, 2018-06-08 at 08:42 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 08.06.18 at 14:46, wrote:
> > > From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
> > > Sent: 08 June 2018 09:51
> > > On Vi, 2018-06-08 at 08:33 +, Paul Durrant wrote:
> > > >
> > > > There's a typo
This run is configured for baseline tests only.
flight 74888 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74888/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 11d0cd23dd1bc15a6e6a1598250ea2e0c4c36e9a
baseline v
flight 124430 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124430/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 988d66cb78c35c620c2a0eb01bac842e4e99bf0e
baseline version:
xen e23d
flight 124389 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124389/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-libvirt 13 migrate-support-checkfail never pass
test-amd64-i386-xl-pvshim12 guest-
The call to freeze_domains() in enter_state() guarentees that we are
running in idle context for the duration of S3/S4.
In restore_rest_processor_state(), the stts() is problematic as it
unilaterally sets %cr0.ts even in fully_eager FPU context. It also fails to
account for the non-lazy xsave sta
This run is configured for baseline tests only.
flight 74887 xen-4.10-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74887/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 16 gue
On 20/06/18 12:12, Andrew Cooper wrote:
> The call to freeze_domains() in enter_state() guarentees that we are
> running in idle context for the duration of S3/S4.
>
> In restore_rest_processor_state(), the stts() is problematic as it
> unilaterally sets %cr0.ts even in fully_eager FPU context. I
flight 124400 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124400/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 124361
version targeted for testi
On 06/20/2018 02:17 AM, Juergen Gross wrote:
> On 20/06/18 05:31, Boris Ostrovsky wrote:
>>
>> On 06/19/2018 05:30 PM, Brian Woods wrote:
>>> I'm currently seeing an issue where when booting from a recent Linux
>>> kernel without nospec_store_bypass_disable. There's a NULL pointer
>>> having to do
In order to unmap the BARs
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
xen/drivers/vpci/header.c | 30 +++--
Tear down functions are not mandatory. Note that this patch just
implements the framework, but doesn't implement any tear down function
yet.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
This new helper will merge two rangesets.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
xen/common/rangeset.c | 12
This is required in order to allow run-time removal of MSI-X regions.
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
So that pci_{add/remove}_device work correctly with vpci. Note that
this requires moving vpci_add_handlers out of the init section.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano S
So that interrupts are properly freed.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
xen/drivers/vpci/msi.c | 23
To the outside of the vpci struct. This way the lock can be used to
check whether vpci is present, and removal can be performed while
holding the lock, in order to make sure there are no accesses to the
contents of the vpci struct. Previously removal could race with
vpci_read for example, since the
Hello,
The following series enables the usage of the SR-IOV capability by a PVH
Dom0. This allows Dom0 to enable virtual functions and access them as it
would do on bare metal.
No changes are needed in the Dom0 kernel in order to manage the PCIe
SR-IOV capability.
The first 9 patches are prepara
So that interrupts are properly freed.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
xen/drivers/vpci/msix.c | 43 +++
To be queued in vpci_vcpu. This will be required for SR-IOV support,
which uses a single control register bit to toggle memory decoding for
all the virtual functions.
No functional change expected.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan
So that a PCI device that supports SR-IOV (PF) can enable the capability
and use the virtual functions.
This code is expected to only be used by privileged domains,
unprivileged domains should not get access to the SR-IOV capability.
The current code detects enabling of the virtual functions feat
flight 124373 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124373/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-rtds broken
test-armhf-armhf-xl-cubietruck
On 06/20/2018 10:27 AM, Boris Ostrovsky wrote:
> On 06/20/2018 02:17 AM, Juergen Gross wrote:
>> On 20/06/18 05:31, Boris Ostrovsky wrote:
>>> On 06/19/2018 05:30 PM, Brian Woods wrote:
I'm currently seeing an issue where when booting from a recent Linux
kernel without nospec_store_bypass
branch xen-unstable
xenbranch xen-unstable
job test-armhf-armhf-libvirt
testid xen-boot
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_gnulib https://git.savannah.gnu.org/git/gnulib.git/
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://git.
flight 124398 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124398/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 124232
Tests which did n
On Wed, Jun 20, 2018 at 08:34:13AM +0200, Juergen Gross wrote:
> Brian, would you please give the attached patch a try?
>
>
> Juergen
Juergen,
It works for Dom0. You see a lot of messages that are like:
(XEN) emul-priv-op.c:1166:d0v1 Domain attempted WRMSR c0011020 from
0x02068000 to
On 21/06/18 01:20, Brian Woods wrote:
> On Wed, Jun 20, 2018 at 08:34:13AM +0200, Juergen Gross wrote:
>> Brian, would you please give the attached patch a try?
>>
>>
>> Juergen
> Juergen,
>
> It works for Dom0. You see a lot of messages that are like:
> (XEN) emul-priv-op.c:1166:d0v1 Domain attem
flight 124381 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124381/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
build-i386-libvirt6 libvirt-bui
flight 124428 seabios real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124428/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 122202
build-amd64-xsm
On Wed, Jun 20, 2018 at 12:20:21PM -0500, Brian Woods wrote:
> On Wed, Jun 20, 2018 at 08:34:13AM +0200, Juergen Gross wrote:
> Juergen,
>
> It works for Dom0. You see a lot of messages that are like:
> (XEN) emul-priv-op.c:1166:d0v1 Domain attempted WRMSR c0011020 from
> 0x02068000 to 0
flight 124411 linux-4.9 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124411/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-xsm broken in 124365
test-amd64-amd64-xl-qemuu-debianh
This run is configured for baseline tests only.
flight 74889 xen-4.8-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74889/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 21
flight 124438 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124438/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 123814
build-amd64-libvirt
> The patch "xen-netfront: Fix race between device setup and open" seems
> to have introduced a regression preventing setting MTU's larger than
> 1500. We experienced this downstream with Container Linux and
> confirmed with Fedora 28 as well.
>
> It's commit f599c64fdf7d9c108e8717fb04bc41c680120da
flight 74890 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/74890/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-i386-squeeze-netboot-pygrub 10 debian-di-install fail like
74864
test-amd64-i386-i386
On Thu, Jun 21, 2018 at 01:55:54AM +0800, Andrew Cooper wrote:
> That is Linux trying to enable the SSBD via the native mechanism (on
> Fam17h hardware I'm guessing, give the bit position).
>
> Like many of the other mitigations, a PV guest knows it is virtualised
> and shouldn’t be playing with t
flight 124440 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124440/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 124361
version targeted for testi
flight 124393 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124393/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 broken
test-armhf-armhf-
flight 124416 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124416/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-pvhv2-intel 7 xen-boot fail REGR. vs. 124090
test-amd64-amd64-x
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-qemuu-win10-i386
testid xen-boot
Tree: linux
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-trad
From: Jan Beulich
There are two issues. First, the nonlazy xstates were never restored
after returning from the runtime call.
Secondly, with the fully_eager_fpu mitigation for XSA-267 / LazyFPU, the
unilateral stts() is no longer correct, and hits an assertion later when
a lazy state restore tr
On 21/06/18 10:10, dougt...@icloud.com wrote:
> From: Doug Goldstein
>
> Import the following files and directories from the Linux v4.17 tag
> (commit id 29dcea88779c856c7dc92040a0c01233263101d4):
> - scripts/kconfig/ -> xen/tools/kconfig/
> - scripts/Makefile.host -> xen/tools/kconfig/Makefile.ho
On 21/06/18 04:14, Andrew Cooper wrote:
> From: Jan Beulich
>
> There are two issues. First, the nonlazy xstates were never restored
> after returning from the runtime call.
>
> Secondly, with the fully_eager_fpu mitigation for XSA-267 / LazyFPU, the
> unilateral stts() is no longer correct, an
flight 124449 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/124449/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-libvirt6 libvirt-buildfail REGR. vs. 124232
test-amd64-amd64-
>>> On 18.06.18 at 10:45, wrote:
> On 17/06/18 16:56, Jan Beulich wrote:
>> --- a/xen/arch/x86/acpi/suspend.c
>> +++ b/xen/arch/x86/acpi/suspend.c
>> @@ -92,8 +92,11 @@ void restore_rest_processor_state(void)
>> write_debugreg(7, curr->arch.debugreg[7]);
>> }
>>
>> -/* Reload F
44 matches
Mail list logo
