flight 186608 linux-linus real [real]
flight 186614 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186608/
http://logs.test-lab.xenproject.org/osstest/logs/186614/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
On Mon, 1 Jul 2024 06:36:15 +0200
"h...@lst.de" wrote:
> On Sun, Jun 30, 2024 at 02:02:52PM +, Michael Kelley wrote:
> > 1) Rename is_swiotlb_buffer() to swiotlb_find_pool(), since it
> > now returns a pool. A NULL return value indicates that the
> > paddr is not an swiotlb buffer.
> >
> >
On Sun, Jun 30, 2024 at 02:02:52PM +, Michael Kelley wrote:
> 1) Rename is_swiotlb_buffer() to swiotlb_find_pool(), since it
> now returns a pool. A NULL return value indicates that the
> paddr is not an swiotlb buffer.
>
> 2) Similarly, rename is_xen_swiotlb_buffer() to
> xen_swiotlb_find_po
flight 186612 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186612/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 8c09d862bfb034e00b6b3bc37fe37243c866dd3a
baseline version:
ovmf 3b2025969e6e8a2f65429
flight 186600 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186600/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 8 xen-bootfail REGR. vs. 186562
Tests which are fai
flight 186594 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186594/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-multivcpu 8 xen-bootfail REGR. vs. 186562
Tests which are fai
From: h...@lst.de Sent: Saturday, June 29, 2024 10:56 PM
>
> On Sat, Jun 29, 2024 at 03:55:58PM +, Michael Kelley wrote:
> > Unless there is further discussion on this point, I'll just keep the
> > original
> > "is_swiotlb_buffer()" in v2.
>
> That is the wrong name for something that retur
Hi All,
I am trying to enable vhost user input with xen hypervisor on i.MX95, using qemu
vhost-user-input. But meet " Invalid vring_addr message ". My xen domu cfg:
'-chardev', 'socket,path=/tmp/input.sock,id=mouse0',
'-device', 'vhost-user-input-pci,chardev=mouse0',
Anyone knows what missing?
Hypercall PHYSDEVOP_map_pirq support to map a gsi into a specific
pirq or a free pirq, it depends on the parameter pirq(>0 or <0).
But in current xc_physdev_map_pirq, it set *pirq=index when
parameter pirq is <0, it causes to force all cases to be mapped
to a specific pirq. That has some problems,
When dom0 is PVH, and passthrough a device to dumU, xl will
use the gsi number of device to do a pirq mapping, see
pci_add_dm_done->xc_physdev_map_pirq, but the gsi number is
got from file /sys/bus/pci/devices//irq, that confuses
irq and gsi, they are in different space and are not equal,
so it wil
Hi All,
This is v11 series to support passthrough when dom0 is PVH
v10->v11 changes:
* patch#1: Move the curly braces of "case PHYSDEVOP_pci_device_state_reset" to
the next line.
Delete unnecessary local variables "struct physdev_pci_device *dev".
Downgrade printk to dprintk.
The gsi of a passthrough device must be configured for it to be
able to be mapped into a hvm domU.
But When dom0 is PVH, the gsis don't get registered, it causes
the info of apic, pin and irq not be added into irq_2_pin list,
and the handler of irq_desc is not set, then when passthrough a
device, s
If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
a passthrough device by using gsi, see qemu code
xen_pt_realize->xc_physdev_map_pirq and libxl code
pci_add_dm_done->xc_physdev_map_pirq. Then xc_physdev_map_pirq
will call into Xen, but in hvm_physdev_op, PHYSDEVOP_map_pirq
is not allo
When passthrough a device to domU, QEMU and xl tools use its gsi
number to do pirq mapping, see QEMU code
xen_pt_realize->xc_physdev_map_pirq, and xl code
pci_add_dm_done->xc_physdev_map_pirq, but the gsi number is got
from file /sys/bus/pci/devices//irq, that is wrong, because
irq is not equal wit
Some type of domain don't have PIRQs, like PVH, it doesn't do
PHYSDEVOP_map_pirq for each gsi. When passthrough a device
to guest base on PVH dom0, callstack
pci_add_dm_done->XEN_DOMCTL_irq_permission will fail at function
domain_pirq_to_irq, because PVH has no mapping of gsi, pirq and
irq on Xen s
allocate_pirq is to allocate a pirq for a irq, and it supports to
allocate a free pirq(pirq parameter is <0) or a specific pirq (pirq
parameter is > 0).
For current code, it has four usecases.
First, pirq>0 and current_pirq>0, (current_pirq means if irq already
has a mapped pirq), if pirq==curren
When a device has been reset on dom0 side, the vpci on Xen
side won't get notification, so the cached state in vpci is
all out of date compare with the real device state.
To solve that problem, add a new hypercall to clear all vpci
device state. When the state of device is reset on dom0 side,
dom0
flight 186588 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/186588/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 186568
test-amd64-amd64-xl-qemuu-ws16-amd64
flight 186586 linux-linus real [real]
flight 186592 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/186586/
http://logs.test-lab.xenproject.org/osstest/logs/186592/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run
19 matches
Mail list logo
