Re: [BUG] Unable to boot Xen 4.11 (shipped with Ubuntu) on Intel 10i3 CPU

Thanks for explanation! I'll stick with older HW until this is out. On Tue, 29 Dec 2020 at 03:49, Andrew Cooper wrote: > On 28/12/2020 18:08, Ondrej Balaz wrote: > > Hi, > > I recently updated my home server running Ubuntu 20.04 (Focal) with > > Xen hypervisor 4.11 (installed using Ubuntu packag

[linux-linus test] 157945: regressions - FAIL

flight 157945 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/157945/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd

[qemu-mainline test] 157943: regressions - FAIL

flight 157943 qemu-mainline real [real] flight 157948 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/157943/ http://logs.test-lab.xenproject.org/osstest/logs/157948/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

[linux-linus test] 157937: regressions - FAIL

flight 157937 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/157937/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd

Re: [BUG] Unable to boot Xen 4.11 (shipped with Ubuntu) on Intel 10i3 CPU

On 28/12/2020 18:08, Ondrej Balaz wrote: > Hi, > I recently updated my home server running Ubuntu 20.04 (Focal) with > Xen hypervisor 4.11 (installed using Ubuntu packages). Before the > upgrade all was running fine and both dom0 and all domUs were booting > fine. Upgrade was literally taking hardd

Re: [PATCH 1/5] x86/vPCI: tolerate (un)masking a disabled MSI-X entry

On Mon, Dec 07, 2020 at 11:36:38AM +0100, Jan Beulich wrote: > None of the four reasons causing vpci_msix_arch_mask_entry() to get > called (there's just a single call site) are impossible or illegal prior > to an entry actually having got set up: > - the entry may remain masked (in this case, howe

PVH mode PCI passthrough status

Hi, As of Xen 4.10, PCI passthrough support was not available in PVH mode. I was wondering if the PCI passthrough support was added in a later version. It would be great to know the latest status of the PCI passthrough support for the Xen PVM mode. Please let me know if you have any updates on

[BUG] Unable to boot Xen 4.11 (shipped with Ubuntu) on Intel 10i3 CPU

Hi, I recently updated my home server running Ubuntu 20.04 (Focal) with Xen hypervisor 4.11 (installed using Ubuntu packages). Before the upgrade all was running fine and both dom0 and all domUs were booting fine. Upgrade was literally taking harddrive from 6th gen Intel CPU system to 10th gen Inte

Re: [PATCH 5/5] vPCI/MSI-X: tidy init_msix()

On Mon, Dec 07, 2020 at 11:38:42AM +0100, Jan Beulich wrote: > First of all introduce a local variable for the to be allocated struct. > The compiler can't CSE all the occurrences (I'm observing 80 bytes of > code saved with gcc 10). Additionally, while the caller can cope and > there was no memory

Re: [PATCH 4/5] vPCI/MSI-X: make use of xzalloc_flex_struct()

On Mon, Dec 07, 2020 at 11:38:21AM +0100, Jan Beulich wrote: > ... instead of effectively open-coding it in a type-unsafe way. > > Signed-off-by: Jan Beulich Reviewed-by: Roger Pau Monné Thanks.

Re: [PATCH 3/5] vPCI/MSI-X: fold clearing of entry->updated

On Mon, Dec 07, 2020 at 11:37:51AM +0100, Jan Beulich wrote: > Both call sites clear the flag after a successfull call to > update_entry(). This can be simplified by moving the clearing into the > function, onto its success path. The point of returning a value was to set the updated field, as ther

Re: [PATCH 2/5] x86/vPCI: check address in vpci_msi_update()

On Mon, Dec 07, 2020 at 11:37:22AM +0100, Jan Beulich wrote: > If the upper address bits don't match the interrupt delivery address > space window, entirely different behavior would need to be implemented. > Refuse such requests for the time being. > > Replace adjacent hard tabs while introducing

[qemu-mainline test] 157936: regressions - FAIL

flight 157936 qemu-mainline real [real] flight 157942 qemu-mainline real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/157936/ http://logs.test-lab.xenproject.org/osstest/logs/157942/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be

Re: [PATCH 5/5] x86: don't build unused entry code when !PV32

On Wed, Nov 25, 2020 at 09:51:33AM +0100, Jan Beulich wrote: > Except for the initial part of cstar_enter compat/entry.S is all dead > code in this case. Further, along the lines of the PV conditionals we > already have in entry.S, make code PV32-conditional there too (to a > fair part because this

Re: [PATCH 4/5] x86: hypercall vector is unused when !PV32

On Wed, Nov 25, 2020 at 09:50:51AM +0100, Jan Beulich wrote: > This vector can be used as an ordinary interrupt handling one in this > case. To be sure no references are left, make the #define itself > conditional. > > Signed-off-by: Jan Beulich Acked-by: Roger Pau Monné Thanks, Roger.

Re: [PATCH 3/5] x86/build: restrict contents of asm-offsets.h when !HVM / !PV

On Wed, Nov 25, 2020 at 09:49:54AM +0100, Jan Beulich wrote: > This file has a long dependencies list (through asm-offsets.[cs]) and a > long list of dependents. IOW if any of the former changes, all of the > latter will be rebuilt, even if there's no actual change to the > generated file. Therefor

Re: [PATCH 2/5] x86/build: limit #include-ing by asm-offsets.c

On Wed, Nov 25, 2020 at 09:49:21AM +0100, Jan Beulich wrote: > This file has a long dependencies list and asm-offsets.h, generated from > it, has a long list of dependents. IOW if any of the former changes, all > of the latter will be rebuilt, even if there's no actual change to the > generated fil

[libvirt test] 157933: regressions - FAIL

flight 157933 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/157933/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt

Re: [PATCH 1/5] x86/build: limit rebuilding of asm-offsets.h

On Wed, Nov 25, 2020 at 09:45:56AM +0100, Jan Beulich wrote: > This file has a long dependencies list (through asm-offsets.s) and a > long list of dependents. IOW if any of the former changes, all of the > latter will be rebuilt, even if there's no actual change to the > generated file. This is the

[xen-unstable test] 157931: tolerable FAIL

flight 157931 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/157931/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 157918 test-amd64-amd64-xl-qemuu-win7-amd64

Re: [PATCH] x86/CPUID: suppress IOMMU related hypervisor leaf data

On Mon, Nov 09, 2020 at 11:54:09AM +0100, 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 I'm not sure this is helpful from a guest PoV. How does the

[linux-linus test] 157930: regressions - FAIL

flight 157930 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/157930/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd