On 05.10.22 18:48, Marek Marczykowski-Górecki wrote:
On Wed, Oct 05, 2022 at 05:45:56PM +0200, Juergen Gross wrote:
On 05.10.22 17:35, Marek Marczykowski-Górecki wrote:
On Wed, Oct 05, 2022 at 05:04:29PM +0200, Juergen Gross wrote:
On 05.10.22 15:51, Marek Marczykowski-Górecki wrote:
On Wed,
flight 173437 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173437/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 710f83b79d6eab641401c054b2f40f6c630f8cd5
baseline version:
ovmf 1bd2ff18664b9564a5802
On 29.08.22 17:15, Jason Andryuk wrote:
An HVM guest with linux stubdom and 2 PCI devices failed to start as
libxl timed out waiting for the PCI devices to be added. It happens
intermittently but with some regularity. libxl wrote the two xenstore
entries for the devices, but then timed out wait
On 05.10.22 19:48, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
As find_xen_grant_dma_data() is called from both interrupt and process
contexts, the access to xen_grant_dma_devices XArray must be protected
by xa_lock_irqsave to avoid deadlock scenario.
As XArray API doesn't provide xa
flight 173433 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173433/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 173353
test-armhf-armhf-xl-c
On 05.10.22 19:48, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshchenko
Take page offset into the account when calculating the number of pages
to be granted.
Signed-off-by: Oleksandr Tyshchenko
Fixes: d6aca3504c7d ("xen/grant-dma-ops: Add option to restrict memory access under
Xen")
Revi
On Wed, Oct 05, 2022 at 11:28:29PM +0200, Ard Biesheuvel wrote:
> On Wed, 5 Oct 2022 at 20:11, Demi Marie Obenour
> wrote:
> >
> > On Wed, Oct 05, 2022 at 08:15:07AM +0200, Jan Beulich wrote:
> > > On 04.10.2022 17:46, Demi Marie Obenour wrote:
> > > > Linux has a function called efi_mem_reserve()
flight 173431 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173431/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-shadow broken
test-amd64-amd64-xl
On Wed, 5 Oct 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> As find_xen_grant_dma_data() is called from both interrupt and process
> contexts, the access to xen_grant_dma_devices XArray must be protected
> by xa_lock_irqsave to avoid deadlock scenario.
> As XArray API doesn't
On Wed, 5 Oct 2022, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Take page offset into the account when calculating the number of pages
> to be granted.
>
> Signed-off-by: Oleksandr Tyshchenko
> Fixes: d6aca3504c7d ("xen/grant-dma-ops: Add option to restrict memory access
> und
flight 173430 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173430/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 173422
test-amd64-i386-xl-qemuu-win7-amd64
On Wed, 5 Oct 2022 at 20:11, Demi Marie Obenour
wrote:
>
> On Wed, Oct 05, 2022 at 08:15:07AM +0200, Jan Beulich wrote:
> > On 04.10.2022 17:46, Demi Marie Obenour wrote:
> > > Linux has a function called efi_mem_reserve() that is used to reserve
> > > EfiBootServicesData memory that contains e.g.
On Wed, Oct 05, 2022 at 08:15:07AM +0200, Jan Beulich wrote:
> On 04.10.2022 17:46, Demi Marie Obenour wrote:
> > Linux has a function called efi_mem_reserve() that is used to reserve
> > EfiBootServicesData memory that contains e.g. EFI configuration tables.
> > This function does not work under X
Hi Jan,
On 05/10/2022 12:55, Jan Beulich wrote:
On 05.10.2022 12:44, Julien Grall wrote:
On 04/10/2022 16:58, Jan Beulich wrote:
On 30.09.2022 14:51, Bertrand Marquis wrote:
On 30 Sep 2022, at 09:50, Jan Beulich wrote:
efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
From: Oleksandr Tyshchenko
As find_xen_grant_dma_data() is called from both interrupt and process
contexts, the access to xen_grant_dma_devices XArray must be protected
by xa_lock_irqsave to avoid deadlock scenario.
As XArray API doesn't provide xa_store_irqsave helper, call lockless
__xa_store d
From: Oleksandr Tyshchenko
Hello all.
These are several fixes I collected when playing with virtio-net device
using Xen grant mappings.
Tested with both virtio-blk and virtio-net devices.
Oleksandr Tyshchenko (2):
xen/virtio: Fix n_pages calculation in xen_grant_dma_map(unmap)_page()
xen/v
From: Oleksandr Tyshchenko
Take page offset into the account when calculating the number of pages
to be granted.
Signed-off-by: Oleksandr Tyshchenko
Fixes: d6aca3504c7d ("xen/grant-dma-ops: Add option to restrict memory access
under Xen")
---
drivers/xen/grant-dma-ops.c | 5 +++--
1 file chan
flight 173427 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173427/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 5 host-install broken REGR. vs. 173353
test-amd64-i386-qemut
flight 173426 linux-linus real [real]
flight 173432 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173426/
http://logs.test-lab.xenproject.org/osstest/logs/173432/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-
On Wed, Oct 05, 2022 at 05:45:56PM +0200, Juergen Gross wrote:
> On 05.10.22 17:35, Marek Marczykowski-Górecki wrote:
> > On Wed, Oct 05, 2022 at 05:04:29PM +0200, Juergen Gross wrote:
> > > On 05.10.22 15:51, Marek Marczykowski-Górecki wrote:
> > > > On Wed, Oct 05, 2022 at 03:34:56PM +0200, Juerg
On 05.10.22 17:35, Marek Marczykowski-Górecki wrote:
On Wed, Oct 05, 2022 at 05:04:29PM +0200, Juergen Gross wrote:
On 05.10.22 15:51, Marek Marczykowski-Górecki wrote:
On Wed, Oct 05, 2022 at 03:34:56PM +0200, Juergen Gross wrote:
On 05.10.22 15:25, Marek Marczykowski-Górecki wrote:
On Wed,
On 05.10.2022 16:12, Roger Pau Monné wrote:
> Hm, I have the following diff attached below which is more limited,
> and not so bad I think. Initially I wanted to introduce an
> efi_all_mapped() helper, but that would require exposing EFI_MEMORY_TYPE
> which is quite intrusive.
>
> Let me know if
On Wed, Oct 05, 2022 at 05:04:29PM +0200, Juergen Gross wrote:
> On 05.10.22 15:51, Marek Marczykowski-Górecki wrote:
> > On Wed, Oct 05, 2022 at 03:34:56PM +0200, Juergen Gross wrote:
> > > On 05.10.22 15:25, Marek Marczykowski-Górecki wrote:
> > > > On Wed, Oct 05, 2022 at 02:57:01PM +0200, Juerg
On 05.10.22 15:51, Marek Marczykowski-Górecki wrote:
On Wed, Oct 05, 2022 at 03:34:56PM +0200, Juergen Gross wrote:
On 05.10.22 15:25, Marek Marczykowski-Górecki wrote:
On Wed, Oct 05, 2022 at 02:57:01PM +0200, Juergen Gross wrote:
On 05.10.22 14:41, Marek Marczykowski-Górecki wrote:
Hi,
Whe
On Wed, Oct 05, 2022 at 10:53:38AM +0200, Jan Beulich wrote:
> On 05.10.2022 10:37, Roger Pau Monné wrote:
> > On Tue, Oct 04, 2022 at 06:11:50PM +0200, Jan Beulich wrote:
> >> On 04.10.2022 17:36, Roger Pau Monne wrote:
> >>> The EFI memory map contains two memory types (EfiMemoryMappedIO and
> >>
On Wed, Oct 05, 2022 at 01:34:06PM +, Andrew Cooper wrote:
> On 05/10/2022 10:55, Roger Pau Monné wrote:
> > On Tue, Oct 04, 2022 at 05:08:09PM +0100, Andrew Cooper wrote:
> >> A future change will want a cpuid-like identifier which doesn't have a
> >> mapping
> >> to a feature bit.
> > Why we
On Wed, Oct 05, 2022 at 03:34:56PM +0200, Juergen Gross wrote:
> On 05.10.22 15:25, Marek Marczykowski-Górecki wrote:
> > On Wed, Oct 05, 2022 at 02:57:01PM +0200, Juergen Gross wrote:
> > > On 05.10.22 14:41, Marek Marczykowski-Górecki wrote:
> > > > Hi,
> > > >
> > > > When booting Xen with Linu
On 05/10/2022 14:11, Jan Beulich wrote:
> On 05.10.2022 14:58, Andrew Cooper wrote:
>> On 05/10/2022 07:59, Jan Beulich wrote:
>>> On 04.10.2022 18:08, Andrew Cooper wrote:
A future change will want a cpuid-like identifier which doesn't have a
mapping
to a feature bit.
*
On 05.10.22 15:25, Marek Marczykowski-Górecki wrote:
On Wed, Oct 05, 2022 at 02:57:01PM +0200, Juergen Gross wrote:
On 05.10.22 14:41, Marek Marczykowski-Górecki wrote:
Hi,
When booting Xen with Linux dom0 nested under KVM,
CONFIG_XEN_VIRTIO_FORCE_GRANT=y makes it unable to use virtio devices
On 05/10/2022 10:55, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 05:08:09PM +0100, Andrew Cooper wrote:
>> A future change will want a cpuid-like identifier which doesn't have a
>> mapping
>> to a feature bit.
> Why we prefer this logic over just giving such pseudo features a
> synthetic bit
On 05/10/2022 13:09, Jan Beulich wrote:
> On 05.10.2022 12:20, Roger Pau Monné wrote:
>> On Tue, Oct 04, 2022 at 05:08:10PM +0100, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/cpu/common.c
>>> +++ b/xen/arch/x86/cpu/common.c
>>> @@ -209,6 +209,34 @@ void ctxt_switch_levelling(const struct vcpu *next
On Wed, Oct 05, 2022 at 02:57:01PM +0200, Juergen Gross wrote:
> On 05.10.22 14:41, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > When booting Xen with Linux dom0 nested under KVM,
> > CONFIG_XEN_VIRTIO_FORCE_GRANT=y makes it unable to use virtio devices
> > provided by L0 hypervisor (KVM with
flight 173428 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173428/
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.10.2022 14:58, Andrew Cooper wrote:
> On 05/10/2022 07:59, Jan Beulich wrote:
>> On 04.10.2022 18:08, Andrew Cooper wrote:
>>> A future change will want a cpuid-like identifier which doesn't have a
>>> mapping
>>> to a feature bit.
>>>
>>> * Pass the feature name into the parse callback.
>>
On 05.10.22 14:41, Marek Marczykowski-Górecki wrote:
Hi,
When booting Xen with Linux dom0 nested under KVM,
CONFIG_XEN_VIRTIO_FORCE_GRANT=y makes it unable to use virtio devices
provided by L0 hypervisor (KVM with qemu). With PV dom0, grants are
required for virtio even if just CONFIG_XEN_VIRTIO
On 05/10/2022 07:59, Jan Beulich wrote:
> On 04.10.2022 18:08, Andrew Cooper wrote:
>> A future change will want a cpuid-like identifier which doesn't have a
>> mapping
>> to a feature bit.
>>
>> * Pass the feature name into the parse callback.
>> * Exclude a feature value of ~0u from falling in
Hi,
When booting Xen with Linux dom0 nested under KVM,
CONFIG_XEN_VIRTIO_FORCE_GRANT=y makes it unable to use virtio devices
provided by L0 hypervisor (KVM with qemu). With PV dom0, grants are
required for virtio even if just CONFIG_XEN_VIRTIO is enabled.
This is probably uncommon corner case, bu
On 05.10.2022 12:20, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 05:08:10PM +0100, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpu/common.c
>> +++ b/xen/arch/x86/cpu/common.c
>> @@ -209,6 +209,34 @@ void ctxt_switch_levelling(const struct vcpu *next)
>> alternative_vcall(ctxt_switc
On 05.10.2022 13:03, Juergen Gross wrote:
> The CPU vendor checks for pmu emulation are rather limited today, as
> the assumption seems to be that only Intel and AMD are existing and/or
> supported vendors.
>
> Fix that by handling Centaur and Zhaoxin CPUs the same way as Intel,
> and Hygon the sa
On 05.10.2022 13:02, Juergen Gross wrote:
> Today pmu_msr_read() and pmu_msr_write() fall back to the safe variants
> of read/write MSR in case the MSR access isn't emulated via Xen. Allow
> the caller to select that faults should not be recovered from by passing
> NULL for the error pointer.
>
>
On 05.10.2022 12:44, Julien Grall wrote:
> On 04/10/2022 16:58, Jan Beulich wrote:
>> On 30.09.2022 14:51, Bertrand Marquis wrote:
On 30 Sep 2022, at 09:50, Jan Beulich wrote:
efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
higher priority than the type
Instead of always doing the safe variants for reading and writing MSRs
in Xen PV guests, make the behavior controllable via Kconfig option
and a boot parameter.
The default will be the current behavior, which is to always use the
safe variant.
Signed-off-by: Juergen Gross
---
.../admin-guide/ke
Refactor and rename xen_read_msr_safe() and xen_write_msr_safe() to
support both cases of MSR accesses, safe ones and potentially GP-fault
generating ones.
This will prepare to no longer swallow GPs silently in xen_read_msr()
and xen_write_msr().
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beu
The CPU vendor checks for pmu emulation are rather limited today, as
the assumption seems to be that only Intel and AMD are existing and/or
supported vendors.
Fix that by handling Centaur and Zhaoxin CPUs the same way as Intel,
and Hygon the same way as AMD.
While at it fix the return type of is_
Historically when running as Xen PV guest all MSR accesses have been
silently swallowing any GP faults, even when the kernel was using not
the *msr_safe() access functions.
Change that by making the behavior controllable via kernel config and
via a boot parameter.
This will help finding paths whe
Today pmu_msr_read() and pmu_msr_write() fall back to the safe variants
of read/write MSR in case the MSR access isn't emulated via Xen. Allow
the caller to select that faults should not be recovered from by passing
NULL for the error pointer.
Restructure the code to make it more readable.
Signed
flight 173423 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173423/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-qcow2 15 saverestore-support-check fail like 173413
test-armhf-armhf-libvirt 16 saveresto
Hi Jan,
On 04/10/2022 16:58, Jan Beulich wrote:
On 30.09.2022 14:51, Bertrand Marquis wrote:
On 30 Sep 2022, at 09:50, Jan Beulich wrote:
efi_init_memory() in both relevant places is treating EFI_MEMORY_RUNTIME
higher priority than the type of the range. To avoid accessing memory at
runtime w
On Tue, Oct 04, 2022 at 05:08:10PM +0100, Andrew Cooper wrote:
> Intel IceLake and later CPUs have microarchitectural behaviours which cause
> data-dependent timing behaviour. This is not an issue for 99% of software,
> but it is a problem for cryptography routines. On these CPUs, a new
> archite
On Tue, Oct 04, 2022 at 05:08:09PM +0100, Andrew Cooper wrote:
> A future change will want a cpuid-like identifier which doesn't have a mapping
> to a feature bit.
Why we prefer this logic over just giving such pseudo features a
synthetic bit or akin?
Could we have a bit more of a description abo
flight 173422 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173422/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-libvirt-xsm 7 xen-installfail pass in 173416
Tests which did not succeed, but
Currently balloon drivers (Virtio,XEN, HyperV, VMWare, ...)
inflate and deflate the guest memory size but there is no
way to know how much the memory size is changed by them.
A common use of the ballooning is to emulate [1]
hot plug and hot unplug - due to the complexity of the later.
Hotplug has
On 05.10.2022 10:37, Roger Pau Monné wrote:
> On Tue, Oct 04, 2022 at 06:11:50PM +0200, Jan Beulich wrote:
>> On 04.10.2022 17:36, Roger Pau Monne wrote:
>>> The EFI memory map contains two memory types (EfiMemoryMappedIO and
>>> EfiMemoryMappedIOPortSpace) used to describe IO memory areas used by
On Tue, Oct 04, 2022 at 06:11:50PM +0200, Jan Beulich wrote:
> On 04.10.2022 17:36, Roger Pau Monne wrote:
> > The EFI memory map contains two memory types (EfiMemoryMappedIO and
> > EfiMemoryMappedIOPortSpace) used to describe IO memory areas used by
> > EFI firmware.
> >
> > The current parsing
flight 173421 linux-linus real [real]
flight 173425 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/173421/
http://logs.test-lab.xenproject.org/osstest/logs/173425/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
flight 173424 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/173424/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1bd2ff18664b9564a5802d0ac153b5023f2fa41e
baseline version:
ovmf f931506815548cee5a392
On 04.10.2022 18:08, Andrew Cooper wrote:
> A future change will want a cpuid-like identifier which doesn't have a mapping
> to a feature bit.
>
> * Pass the feature name into the parse callback.
> * Exclude a feature value of ~0u from falling into the general set/clear bit
>paths.
> * In g
57 matches
Mail list logo
