When adding locking to tools/libs/evtchn/minios.c a semaphore was
used. This can result in deadlocks, as the lock is taken inside the
event handler, which can interrupt an already locked region.
The fix is rather simple, as Mini-OS is supporting a single vcpu
only. So instead of the semaphore it i
flight 184087 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184087/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bb13a4adabcf0e5a1608583c386472773dca5726
baseline version:
ovmf 85a5141a320980e147934
On Tue, 5 Dec 2023 02:49:50 -0800
Xin Li wrote:
> WRMSRNS is an instruction that behaves exactly like WRMSR, with
> the only difference being that it is not a serializing instruction
> by default. Under certain conditions, WRMSRNS may replace WRMSR to
> improve performance.
>
> Add its CPU feat
flight 184078 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184078/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-pvops 6 kernel-build fail REGR. vs. 183973
Tests which did not
flight 184076 xen-unstable real [real]
flight 184084 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184076/
http://logs.test-lab.xenproject.org/osstest/logs/184084/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
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
In PVH dom0, it uses the linux local interrupt mechanism,
when it allocs irq for a gsi, it is dynamic, and follow
the principle of applying first, distributing first. And
the irq number is alloced from small to large, but the
applying gsi number is not, may gsi 38 comes before gsi
28, that causes t
Hi All,
v2->v3 changes:
* du to changes in the implementation of the second patch on kernel side(that
adds a new sysfs for gsi instead of a new syscall), so read gsi number from the
sysfs of gsi.
v3 patch on kernel side:
https://lore.kernel.org/lkml/20231210161519.1550860-1-jiqian.c...@amd.com/
In PVH dom0, it uses the linux local interrupt mechanism,
when it allocs irq for a gsi, it is dynamic, and follow
the principle of applying first, distributing first. And
the irq number is alloced from small to large, but the
applying gsi number is not, may gsi 38 comes before gsi
28, that causes t
If run Xen with PVH dom0 and hvm domU, hvm will map a pirq for
a passthrough device by using gsi, see
xen_pt_realize->xc_physdev_map_pirq and
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 allowed because currd is
Hi All,
This is v3 series to support passthrough when dom0 is PVH
v2->v3 changes:
* patch#1: move the content out of pci_reset_device_state and delete
pci_reset_device_state; add xsm_resource_setup_pci check for
PHYSDEVOP_pci_device_state_reset; add description for
PHYSDEVOP_pci_device_state_res
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
There is a need for some scenarios to use gsi sysfs.
For example, when xen passthrough a device to dumU, it will
use gsi to map pirq, but currently userspace can't get gsi
number.
So, add gsi sysfs for that and for other potential scenarios.
Co-developed-by: Huang Rui
Signed-off-by: Jiqian Chen
When dom0 is PVH, the gsi isn't be unmasked, that causes two
problems.
First, in PVH dom0, the gsis don't get registered, but the gsi of
a passthrough device must be configured for it to be able to be
mapped into a domU.
When assign a device to passthrough, proactively setup the gsi
of the device
When device on dom0 side has been reset, the vpci on Xen side
won't get notification, so that the cached state in vpci is
all out of date with the real device state.
To solve that problem, add a new function to clear all vpci
device state when device is reset on dom0 side.
And call that function i
Hi All,
This is v3 series to support passthrough on Xen when dom0 is PVH.
v2->v3 changes:
* patch#1: add condition to limit do xen_reset_device_state for no-pv domain in
pcistub_init_device.
* patch#2: Abandoning previous implementations that call unmask_irq. To setup
gsi and map pirq for passth
flight 184069 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184069/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184033
test-armhf-armhf-libvirt-qcow2 15 saveres
Pipeline #1101778169 has passed!
Project: xen ( https://gitlab.com/xen-project/xen )
Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
Commit: bc4fe94a (
https://gitlab.com/xen-project/xen/-/commit/bc4fe94a69d4dab103c37045d97e589ef75f8647
)
Commit Message: tools/libs/ev
flight 184068 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184068/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-dom0pvh-xl-amd 22 guest-start/debian.repeat fail REGR. vs.
183973
build-i386-pvo
flight 184064 xen-unstable real [real]
flight 184074 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184064/
http://logs.test-lab.xenproject.org/osstest/logs/184074/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be r
20 matches
Mail list logo
