[qemu-mainline test] 156111: regressions - FAIL

flight 156111 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/156111/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm 6 xen-buildfail REGR. vs. 152631 build-amd64

Re: BUG: credit=sched2 machine hang when using DRAKVUF

On 23.10.20 00:59, Michał Leszczyński wrote: Hello, when using DRAKVUF against a Windows 7 x64 DomU, the whole machine hangs after a few minutes. The chance for a hang seems to be correlated with number of PCPUs, in this case we have 14 PCPUs and hang is very easily reproducible, while on oth

urgent

I want to know a few things like how have you implemented the repeated migration of VM checkpoints from primary to backup, whenever backup receives the checkpoint, it sends an acknowledgement, the primary receives this acknowledgement and send a output release signal, Can you shed some light on how

RE: [PATCH] x86/vmx: Revert "x86/VMX: sanitize rIP before re-entering guest"

> From: Jan Beulich > Sent: Tuesday, October 20, 2020 4:10 PM > > On 19.10.2020 18:12, Andrew Cooper wrote: > > On 19/10/2020 10:09, Jan Beulich wrote: > >> On 16.10.2020 17:38, Andrew Cooper wrote: > >>> On 15/10/2020 09:01, Jan Beulich wrote: > On 14.10.2020 15:57, Andrew Cooper wrote: > >

Re: [PATCH] xen/acpi: Don't fail if SPCR table is absent

On 22.10.2020 19:13, Elliott Mitchell wrote: > On Thu, Oct 22, 2020 at 09:42:17AM +0200, Jan Beulich wrote: >> On 22.10.2020 00:12, Elliott Mitchell wrote: >>> --- a/xen/arch/arm/acpi/domain_build.c >>> +++ b/xen/arch/arm/acpi/domain_build.c >>> @@ -42,17 +42,18 @@ static int __init acpi_iomem_deny

RE: [PATCH] IOMMU: avoid double flushing in shared page table case

> From: Jan Beulich > Sent: Tuesday, October 20, 2020 9:53 PM > > While the flush coalescing optimization has been helping the non-shared > case, it has actually lead to double flushes in the shared case (which > ought to be the more common one nowadays at least): Once from > *_set_entry() and a

[PATCH for-5.10] swiotlb: remove the tbl_dma_addr argument to swiotlb_tbl_map_single

The tbl_dma_addr argument is used to check the DMA boundary for the allocations, and thus needs to be a dma_addr_t. swiotlb-xen instead passed a physical address, which could lead to incorrect results for strange offsets. Fix this by removing the parameter entirely and hard code the DMA address f

<    1   2