On Mon, Nov 09, 2020 at 08:53:58AM +0100, Hannes Reinecke wrote:
>> index 376096bfc54a83..4e86c9aafd88a7 100644
>> --- a/drivers/nvme/host/core.c
>> +++ b/drivers/nvme/host/core.c
>> @@ -2053,7 +2053,7 @@ static void nvme_update_disk_info(struct gendisk *disk,
>> capacity = 0;
Hi Penny,
> -Original Message-
> From: Penny Zheng
> Sent: 2020年11月9日 16:21
> To: xen-devel@lists.xenproject.org; sstabell...@kernel.org; jul...@xen.org
> Cc: Andre Przywara ; Bertrand Marquis
> ; Wei Chen ; Penny Zheng
> ; Kaly Xin ; nd
> Subject: [PATCH] xen/arm: Add Cortex-A73 erratum
On 11/9/20 9:53 AM, Christoph Hellwig wrote:
On Mon, Nov 09, 2020 at 08:53:58AM +0100, Hannes Reinecke wrote:
index 376096bfc54a83..4e86c9aafd88a7 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2053,7 +2053,7 @@ static void nvme_update_disk_info(struct gendisk *disk,
Instead of using a softirq pci_serr_error() can use NMI continuation
for issuing an error message.
Signed-off-by: Juergen Gross
---
V4:
- rework to less generic approach
---
xen/arch/x86/traps.c | 21 +++--
xen/include/asm-x86/softirq.h | 5 ++---
2 files changed, 17 in
Actions in NMI context are rather limited as e.g. locking is rather
fragile.
Add a framework to continue processing in normal interrupt context
after leaving NMI processing.
This is done by a high priority interrupt vector triggered via a
self IPI from NMI context, which will then call the contin
Instead of calling send_guest_vcpu_virq() from NMI context use the
NMI continuation framework for that purpose. This avoids taking locks
in NMI mode.
Signed-off-by: Juergen Gross
---
V4:
- rework to less generic approach
---
xen/arch/x86/oprofile/nmi_int.c | 20 ++--
xen/arch/x86
Move sending of a virq event for oprofile to the local vcpu from NMI
to normal interrupt context.
This has been tested with a small test patch using the continuation
framework of patch 1 for all NMIs and doing a print to console in
the continuation handler.
Version 1 of this small series was sent
On Fri, Nov 06, 2020 at 08:03:35PM +0100, Christoph Hellwig wrote:
> revalidate_disk_size just updates the block device size from the disk
> size. Thus calling it from revalidate_disk_size doesn't actually do
> anything.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/block/virtio_blk.c |
Hi,
> On 9 Nov 2020, at 08:21, Penny Zheng wrote:
>
> CNTVCT_EL0 or CNTPCT_EL0 counter read in Cortex-A73 (all versions)
> might return a wrong value when the counter crosses a 32bit boundary.
>
> Until now, there is no case for Xen itself to access CNTVCT_EL0,
> and it also should be the Guest
Fixes a build failure with mediatek.
This change was supposed to be part of commit 49a3f51dfeee ("drm/gem:
Use struct dma_buf_map in GEM vmap ops and convert GEM backends"), but
mediatek was forgotten.
Signed-off-by: Thomas Zimmermann
Fixes: 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM
Fixes a build failure with msm.
This change was supposed to be part of commit 49a3f51dfeee ("drm/gem:
Use struct dma_buf_map in GEM vmap ops and convert GEM backends"), but
msm was forgotten.
Signed-off-by: Thomas Zimmermann
Fixes: 49a3f51dfeee ("drm/gem: Use struct dma_buf_map in GEM vmap ops a
On Wed, 4 Nov 2020 12:25:09 -0500
Eduardo Habkost wrote:
> All field property getters and setters must interpret the fourth
> argument as Property*. Change the function signature of field
> property getters and setters to indicate that.
>
> Signed-off-by: Eduardo Habkost
> ---
> Cc: Stefan Be
On Wed, 4 Nov 2020 12:25:11 -0500
Eduardo Habkost wrote:
> Introduce a FIELD_PTR macro that will ensure the size of the area
> we are accessing has the correct size, and will return a pointer
> of the correct type.
>
> Signed-off-by: Eduardo Habkost
> ---
> Cc: Stefan Berger
> Cc: Stefano Sta
At least the insn emulator test harness will continue to be buildable
(and ought to continue to be usable) also as a 32-bit binary. (Right now
the CPU policy test harness is, too, but there it may be less relevant
to keep it functional, just like e.g. we don't support fuzzing the insn
emulator in 3
Now that the IOMMU for guests can't be enabled "on demand" anymore,
there's also no reason to expose the related CPUID bit "just in case".
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -1050,7 +1050,8 @@ void cpuid_hypervisor_leaves(const struc
* I
On 09/11/2020 10:54, Jan Beulich wrote:
> Now that the IOMMU for guests can't be enabled "on demand" anymore,
> there's also no reason to expose the related CPUID bit "just in case".
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 09/11/2020 10:53, Jan Beulich wrote:
> At least the insn emulator test harness will continue to be buildable
> (and ought to continue to be usable) also as a 32-bit binary. (Right now
> the CPU policy test harness is, too, but there it may be less relevant
> to keep it functional, just like e.g.
On Fri, Nov 06, 2020 at 08:03:35PM +0100, Christoph Hellwig wrote:
> revalidate_disk_size just updates the block device size from the disk
> size. Thus calling it from revalidate_disk_size doesn't actually do
> anything.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Michael S. Tsirkin
> ---
flight 156575 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156575/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 14 guest-start fail REGR. vs. 152631
test-armhf-armhf-
On 09.11.2020 07:41, Juergen Gross wrote:
> Currently the lock for a single event channel needs to be taken with
> interrupts off, which causes deadlocks in some cases.
>
> Rework the per event channel lock to be non-blocking for the case of
> sending an event and removing the need for disabling i
On 09.11.2020 07:41, Juergen Gross wrote:
> The patches for XSA-343 produced some fallout, especially the event
> channel locking has shown to be problematic.
>
> Patch 1 is targeting fifo event channels for avoiding any races for the
> case that the fifo queue has been changed for a specific even
Hi,
On 09/11/2020 08:21, Penny Zheng wrote:
CNTVCT_EL0 or CNTPCT_EL0 counter read in Cortex-A73 (all versions)
might return a wrong value when the counter crosses a 32bit boundary.
Until now, there is no case for Xen itself to access CNTVCT_EL0,
and it also should be the Guest OS's responsibili
From: Oleksandr Andrushchenko
Hello, all!
This is an RFC and an attempt to understand the best way to progress with ARM
PCI passthrough configuration. This includes, but not limited to, configuration
of assignable PCI devices, (legacy IRQs, MSI/MSI-X are not yet supported), MMIO
etc.
This is ba
From: Oleksandr Andrushchenko
The original code depends on pciback to manage assignable device list.
The functionality which is implemented by the pciback and the toolstack
and which is relevant/missing/needed for ARM:
1. pciback is used as a database for assignable PCI devices, e.g. xl
pci-a
From: Oleksandr Andrushchenko
According to https://wiki.xenproject.org/wiki/Linux_PVH:
Items not supported by PVH
- PCI pass through (as of Xen 4.10)
Allow running PCI remove code on ARM and do not assert for PVH domains.
Signed-off-by: Oleksandr Andrushchenko
---
tools/libxl/Makefile|
From: Oleksandr Andrushchenko
In order vPCI to work it needs all access to PCI configuration space
access to be synchronized among all entities, e.g. hardware domain and
guests. For that implement PCI host bridge specific callbacks to
propelry setup those ranges depending on host bridge implement
From: Oleksandr Andrushchenko
As vPCI now takes care of the proper p2m mappings for PCI devices there
is no more need to hardcode anything.
Signed-off-by: Oleksandr Andrushchenko
---
xen/include/public/arch-arm.h | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/xen/i
From: Oleksandr Andrushchenko
Update hardware domain's BAR header as R-Car Gen3 is a non-ECAM host
controller, so vPCI MMIO handlers do not work for it in hwdom.
Signed-off-by: Oleksandr Andrushchenko
---
xen/arch/arm/pci/pci-host-rcar-gen3.c | 69 +++
1 file changed, 6
From: Oleksandr Andrushchenko
At the moment there is an identity mapping between how a guest sees its
BARs and how they are programmed into guest domain's p2m. This is not
going to work as guest domains have their own view on the BARs.
Extend existing vPCI BAR handling to allow every domain to ha
From: Oleksandr Andrushchenko
vPCI may map and unmap PCI device memory (BARs) being passed through which
may take a lot of time. For this those operations may be deferred to be
performed later, so that they can be safely preempted.
Run the corresponding vPCI code while switching a vCPU.
Signed-o
From: Oleksandr Andrushchenko
Host bridge controller's ECAM space is mapped into Domain-0's p2m,
thus it is not possible to trap the same for vPCI via MMIO handlers.
For this to work we need to unmap those mappings in p2m.
TODO (Julien): It would be best if we avoid the map/unmap operation.
So,
From: Oleksandr Andrushchenko
Non-ECAM host bridges in hwdom go directly to PCI config space,
not through vpci (they use their specific method for accessing PCI
configuration, e.g. dedicated registers etc.). Thus hwdom's vpci BARs are
never updated via vPCI MMIO handlers, so implement a dedicated
From: Oleksandr Andrushchenko
Signed-off-by: Oleksandr Andrushchenko
---
xen/drivers/vpci/header.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
index 1f326c894d16..d5738ecca93d 100644
--- a/xen/driver
On 09.11.20 13:00, Jan Beulich wrote:
On 09.11.2020 07:41, Juergen Gross wrote:
The patches for XSA-343 produced some fallout, especially the event
channel locking has shown to be problematic.
Patch 1 is targeting fifo event channels for avoiding any races for the
case that the fifo queue has b
From: Jiri Slaby
commit ffedeeb780dc554eff3d3b16e6a462a26a41d7ec upstream.
Introduce new C macros for annotations of functions and data in
assembly. There is a long-standing mess in macros like ENTRY, END,
ENDPROC and similar. They are used in different manners and sometimes
incorrectly.
So int
On 09.11.20 12:58, Jan Beulich wrote:
On 09.11.2020 07:41, Juergen Gross wrote:
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some cases.
Rework the per event channel lock to be non-blocking for the case of
sending an event and re
Ping?
On Thu, Oct 15, 2020 at 03:34:12PM +0200, Roger Pau Monné wrote:
> On Wed, Oct 07, 2020 at 06:41:17PM +0200, Roger Pau Monné wrote:
> > On Wed, Oct 07, 2020 at 01:06:08PM +0100, Andrew Cooper wrote:
> > > On 06/10/2020 17:23, Roger Pau Monne wrote:
> > > > Currently a PV hardware domain can
On Fri, Nov 6, 2020 at 8:04 PM Christoph Hellwig wrote:
>
> Use set_capacity_and_notify to set the size of both the disk and block
> device. This also gets the uevent notifications for the resize for free.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/block/rbd.c | 3 +--
> 1 file change
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-libvirt-xsm
testid guest-start
Tree: libvirt git://xenbits.xen.org/libvirt.git
Tree: libvirt_keycodemapdb https://gitlab.com/keycodemap/keycodemapdb.git
Tree: linux git://xenbits.xen.org/linux-pvops.git
Tree: linuxfirmware git://xenbit
Hi,
I have seen several occasions with "dead" xentop processes consuming 100% CPU
time, and tracked this down
to the following problem:
When the QEMU process the qmp_read function is communicating with terminates,
qmp_read may enter an
infinite loop: poll signals EOF (POLLIN and POLLHUP set),
flight 156577 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156577/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 14 guest-start fail REGR. vs. 156443
test-amd64-amd64-x
On 09.11.2020 14:16, Jürgen Groß wrote:
> On 09.11.20 12:58, Jan Beulich wrote:
>> On 09.11.2020 07:41, Juergen Gross wrote:
>>> --- a/xen/arch/x86/pv/shim.c
>>> +++ b/xen/arch/x86/pv/shim.c
>>> @@ -660,11 +660,12 @@ void pv_shim_inject_evtchn(unsigned int port)
>>> if ( port_is_valid(guest,
Just like is done for basic and extended major leaves.
Signed-off-by: Jan Beulich
--- a/xen/lib/x86/policy.c
+++ b/xen/lib/x86/policy.c
@@ -18,6 +18,9 @@ int x86_cpu_policies_are_compatible(cons
if ( guest->cpuid->basic.max_leaf > host->cpuid->basic.max_leaf )
FAIL_CPUID(0, NA);
On 09/11/2020 15:21, Jan Beulich wrote:
> Just like is done for basic and extended major leaves.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some cases.
Rework the per event channel lock to be non-blocking for the case of
sending an event and removing the need for disabling interrupts for
taking the lock.
The lock is needed f
With the event channel lock no longer disabling interrupts commit
52e1fc47abc3a0123 ("evtchn/Flask: pre-allocate node on send path") can
be reverted again.
Signed-off-by: Juergen Gross
---
xen/common/event_channel.c | 6 ---
xen/include/xsm/xsm.h | 1 -
xen/xsm/flask/avc.c | 78
The patches for XSA-343 produced some fallout, especially the event
channel locking has shown to be problematic.
Patch 1 is targeting fifo event channels for avoiding any races for the
case that the fifo queue has been changed for a specific event channel.
The second patch is modifying the per ev
The queue for a fifo event is depending on the vcpu_id and the
priority of the event. When sending an event it might happen the
event needs to change queues and the old queue needs to be kept for
keeping the links between queue elements intact. For this purpose
the event channel contains last_prior
On 09.11.2020 17:38, Juergen Gross wrote:
> With the event channel lock no longer disabling interrupts commit
> 52e1fc47abc3a0123 ("evtchn/Flask: pre-allocate node on send path") can
> be reverted again.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
On 09.11.2020 17:38, Juergen Gross wrote:
> Currently the lock for a single event channel needs to be taken with
> interrupts off, which causes deadlocks in some cases.
>
> Rework the per event channel lock to be non-blocking for the case of
> sending an event and removing the need for disabling i
From: Roger Pau Monné
Currently a PV hardware domain can also be given control over the CPU
frequency, and such guest is allowed to write to MSR_IA32_PERF_CTL.
However since commit 322ec7c89f6 the default behavior has been changed
to reject accesses to not explicitly handled MSRs, preventing PV
g
Hi Juergen,
On 09/11/2020 16:38, Juergen Gross wrote:
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some cases.
Rework the per event channel lock to be non-blocking for the case of
sending an event and removing the need for disabl
Hi,
On 09/11/2020 16:48, Jan Beulich wrote:
On 09.11.2020 17:38, Juergen Gross wrote:
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some cases.
Rework the per event channel lock to be non-blocking for the case of
sending an event
flight 156582 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156582/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332
test-amd64-i386-xl-
Elliott Mitchell writes ("Re: Tools backport request for Xen 4.14"):
> On Fri, Oct 09, 2020 at 06:47:22PM +0100, Julien Grall wrote:
> > Would it be possible to consider backporting to 4.14 the following tools
> > commit:
> >
> > d25cc3ec93eb "libxl: workaround gcc 10.2 maybe-uninitialized warnin
On Mon, Nov 09, 2020 at 05:38:19PM +, Andrew Cooper wrote:
> From: Roger Pau Monné
>
> Currently a PV hardware domain can also be given control over the CPU
> frequency, and such guest is allowed to write to MSR_IA32_PERF_CTL.
> However since commit 322ec7c89f6 the default behavior has been c
On Mon, Nov 09, Ian Jackson wrote:
> I have now backported all of the GCC10 fixes to all the supported Xen
> branches (ie back to 4.12).
Please consider also these commits:
55ab292c42 stubdom/vtpm: include stdio.h for declaration of printf
c3999835df libxl: Offer API versions 0x040700 and 0x0408
flight 156585 qemu-mainline real [real]
flight 156602 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/156585/
http://logs.test-lab.xenproject.org/osstest/logs/156602/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 11/9/20 12:34 AM, Jürgen Groß wrote:
> On 07.11.20 02:11, Brian Masney wrote:
>> When booting a hyperthreaded system with the kernel parameter
>> 'mitigations=auto,nosmt', the following warning occurs:
>>
>> WARNING: CPU: 0 PID: 1 at drivers/xen/events/events_base.c:1112
>> unbind_from_i
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-xsm
testid guest-start
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 git://xenbits.xen.o
flight 156588 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/156588/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm 14 guest-start fail REGR. vs. 156443
test-amd64-amd64-x
Ira,
On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> From: Ira Weiny
>
> To correctly support the semantics of kmap() with Kernel protection keys
> (PKS), kmap() may be required to set the protections on multiple
> processors (globally). Enabling PKS globally can be very expensive
> depending o
On Tue, Nov 10, 2020 at 02:13:56AM +0100, Thomas Gleixner wrote:
> Ira,
>
> On Fri, Oct 09 2020 at 12:49, ira weiny wrote:
> > From: Ira Weiny
> >
> > To correctly support the semantics of kmap() with Kernel protection keys
> > (PKS), kmap() may be required to set the protections on multiple
> >
[ .. ]
Originally nvme multipath would update/change the size of the multipath
device according to the underlying path devices.
With this patch the size of the multipath device will _not_ change if
there
is a change on the underlying devices.
Yes, it will. Take a close look at nvme_update
On 11/6/20 2:03 PM, Christoph Hellwig wrote:
Hi Jens,
this series builds on top of the work that went into the last merge window,
and make sure we have a single coherent interfac for updating the size of a
block device.
You can add
Reviewed-by: Josef Bacik
for the nbd bits, thanks,
Josef
On 09.11.20 18:46, Julien Grall wrote:
Hi,
On 09/11/2020 16:48, Jan Beulich wrote:
On 09.11.2020 17:38, Juergen Gross wrote:
Currently the lock for a single event channel needs to be taken with
interrupts off, which causes deadlocks in some cases.
Rework the per event channel lock to be non-b
On 11/10/20 12:28 AM, Sagi Grimberg wrote:
[ .. ]
Originally nvme multipath would update/change the size of the multipath
device according to the underlying path devices.
With this patch the size of the multipath device will _not_ change
if there
is a change on the underlying devices.
Yes,
Hi Jonathan,
Em Sun, 8 Nov 2020 16:56:21 +
Jonathan Cameron escreveu:
> > PS.: the IIO subsystem is the one that currently has more duplicated
> > ABI entries:
> > $ ./scripts/get_abi.pl validate 2>&1|grep iio
> > Warning: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias is defined 2
On 09.11.2020 18:46, Julien Grall wrote:
> Hi,
>
> On 09/11/2020 16:48, Jan Beulich wrote:
>> On 09.11.2020 17:38, Juergen Gross wrote:
>>> Currently the lock for a single event channel needs to be taken with
>>> interrupts off, which causes deadlocks in some cases.
>>>
>>> Rework the per event ch
On 09.11.2020 19:03, Ian Jackson wrote:
> Elliott Mitchell writes ("Re: Tools backport request for Xen 4.14"):
>> On Fri, Oct 09, 2020 at 06:47:22PM +0100, Julien Grall wrote:
>>> Would it be possible to consider backporting to 4.14 the following tools
>>> commit:
>>>
>>> d25cc3ec93eb "libxl: work
70 matches
Mail list logo
