[xen-4.14-testing test] 160127: tolerable FAIL - PUSHED

flight 160127 xen-4.14-testing real [real] flight 160136 xen-4.14-testing real-retest [real] http://logs.test-lab.xenproject.org/osstest/logs/160127/ http://logs.test-lab.xenproject.org/osstest/logs/160136/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): t

[qemu-mainline test] 160125: regressions - FAIL

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

Re: [PATCH] xen/arm: introduce XENFEAT_direct_mapped and XENFEAT_not_direct_mapped

On Wed, 17 Mar 2021, Boris Ostrovsky wrote: > On 2/25/21 6:51 PM, Stefano Stabellini wrote: > > Newer Xen versions expose two Xen feature flags to tell us if the domain > > is directly mapped or not. Only when a domain is directly mapped it > > makes sense to enable swiotlb-xen on ARM. > > > > Intr

[PATCH for-4.15] x86/mem_sharing: copy parent VM's hostp2m's max_mapped_pfn during forking

When creating a VM fork copy the parent VM's hostp2m max_mapped_pfn value. Some toolstack relies on the XENMEM_maximum_gpfn value to establish the maximum addressable physical memory in the VM and for forks that have not yet been unpaused that value is not going to reflect the correct max gpfn that

[linux-linus test] 160121: regressions - FAIL

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

Re: [ANNOUNCE] Xen 4.15 release update - still in feature freeze

[Adding George, since it's scheduling] On Mon, 2021-03-15 at 12:18 +, Ian Jackson wrote: > > OPEN ISSUES AND BLOCKERS > > > [...] > > SCHEDULER ISSUES NOT MAKING PROCESS ? > - > Yeah... let's try. > BUG: credit=sched2 machine ha

Re: [PATCH 1/2] docs/designs/launch: hyperlaunch design document

Just took a quick look at it. On Mon, Mar 15, 2021 at 11:18:13PM -0400, Daniel P. Smith wrote: > + > +---+---++---+-+-+ > + | **Xen Dom0** | **Linux** | **Late** | **Jail** | **Xen** | **Xen > Hyperlaunch** | > + | *

[PATCH 3/3] swiotlb: remove swiotlb_nr_tbl

All callers just use it to check if swiotlb is active at all, for which they can just use is_swiotlb_active. In the longer run drivers need to stop using is_swiotlb_active as well, but let's do the simple step first. Signed-off-by: Christoph Hellwig --- drivers/gpu/drm/i915/gem/i915_gem_interna

[xen-unstable-smoke test] 160126: tolerable all pass - PUSHED

flight 160126 xen-unstable-smoke real [real] http://logs.test-lab.xenproject.org/osstest/logs/160126/ Failures :-/ but no regressions. Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 1

[PATCH 2/3] swiotlb: dynamically allocate io_tlb_default_mem

Instead of allocating ->list and ->orig_addr separately just do one dynamic allocation for the actual io_tlb_mem structure. This simplifies a lot of the initialization code, and also allows to just check io_tlb_default_mem to see if swiotlb is in use. Signed-off-by: Christoph Hellwig --- driver

[PATCH 1/3] swiotlb: move global variables into a new io_tlb_mem structure

From: Claire Chang Added a new struct, io_tlb_mem, as the IO TLB memory pool descriptor and moved relevant global variables into that struct. This will be useful later to allow for restricted DMA pool. Signed-off-by: Claire Chang [hch: rebased] Signed-off-by: Christoph Hellwig --- drivers/xen

[xen-unstable test] 160120: tolerable FAIL

flight 160120 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/160120/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-examine4 memdisk-try-append fail in 160109 pass in 160120 test-amd64-amd64-xl-qemut-debian

swiotlb cleanups v3

Hi Konrad, this series contains a bunch of swiotlb cleanups, mostly to reduce the amount of internals exposed to code outside of swiotlb.c, which should helper to prepare for supporting multiple different bounce buffer pools. Changes since v2: - fix a bisetion hazard that did not allocate the al

Re: Working Group Meeting for hyperlaunch

On 3/16/21 12:09 AM, Daniel P. Smith wrote: > All, > > We have posted[1][2] the design documents for hyperlaunch and would > invite attendance at a working group call to discuss two agenda items. > The first item is a review of the documents and the second is a > discussion about bringing producti

[ovmf test] 160123: all pass - PUSHED

flight 160123 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/160123/ Perfect :-) All tests in this flight passed as required version targeted for testing: ovmf 9fd7e88c23f6fb056d25fbc3f8e2e7c1a53859d1 baseline version: ovmf 030ba3097a6e7d08b99f8

Xen Security Advisory 368 v3 (CVE-2021-28687) - HVM soft-reset crashes toolstack

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory CVE-2021-28687 / XSA-368 version 3 HVM soft-reset crashes toolstack UPDATES IN VERSION 3 CVE assigned. ISSUE DESCRIPTION = li

[qemu-mainline test] 160119: regressions - FAIL

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

Xen Security Advisory 368 v2 - HVM soft-reset crashes toolstack

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Xen Security Advisory XSA-368 version 2 HVM soft-reset crashes toolstack UPDATES IN VERSION 2 Public release. ISSUE DESCRIPTION = libxl req

Re: [PATCH] xen/arm: Prevent Dom0 to be loaded when using dom0less

Hi Julien, I will create a new serie with all the improvements we have discussed. Thank you for your time. Cheers, Luca > On 18 Mar 2021, at 11:13, Julien Grall wrote: > > > > On 17/03/2021 17:04, Luca Fancellu wrote: >> Hi, > > Hi Luca, > >> I’ve checked the common code and the arm part

Re: [PATCH v7] arm: Add Kconfig entry to select CONFIG_DTB_FILE

On 18.03.2021 10:20, Jan Beulich wrote: > On 18.03.2021 08:21, Michal Orzel wrote: >> Hi Julien, >> >> On 16.03.2021 15:54, Julien Grall wrote: >>> Hi Michal, >>> >>> On 15/03/2021 09:23, Michal Orzel wrote: Currently in order to link existing DTB into Xen image we need to either speci

Re: [PATCH] xen/arm: Prevent Dom0 to be loaded when using dom0less

On 17/03/2021 17:04, Luca Fancellu wrote: Hi, Hi Luca, I’ve checked the common code and the arm part, I can confirm that the domid 0 is never allocated even if the domain 0 is not present, here the only places where domain_create(…) is called using a variable value: Thanks for checking

[PATCH 4/4][4.15?] VT-d: restore flush hooks when disabling qinval

Leaving the hooks untouched is at best a latent risk: There may well be cases where some flush is needed, which then needs carrying out the "register" way. Switch from u to uint_t while needing to touch the function headers anyway. Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/vtd/ex

Re: [PATCH v7] arm: Add Kconfig entry to select CONFIG_DTB_FILE

On 18/03/2021 07:21, Michal Orzel wrote: Hi Julien, On 16.03.2021 15:54, Julien Grall wrote: Hi Michal, On 15/03/2021 09:23, Michal Orzel wrote: Currently in order to link existing DTB into Xen image we need to either specify option CONFIG_DTB_FILE on the command line or manually add it in

[PATCH 3/4][4.15?] VT-d: re-order register restoring in vtd_resume()

For one FECTL must be written last - the interrupt shouldn't be unmasked without first having written the data and address needed to actually deliver it. In the common case (when dma_msi_set_affinity() doesn't end up bailing early) this happens from init_vtd_hw(), but for this to actually have the

[PATCH 2/4][4.15?] VT-d: leave FECTL write to vtd_resume()

We shouldn't blindly unmask the interrupt when resuming. vtd_resume() will restore the intended state. Signed-off-by: Jan Beulich --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -2092,7 +2092,7 @@ static int adjust_vtd_irq_affinities(voi } __initcall(adju

[PATCH 1/4][4.15?] VT-d: correct off-by-1 in number-of-IOMMUs check

Otherwise, if we really run on a system with this many IOMMUs, entering/leaving S3 would overrun iommu_state[]. Signed-off-by: Jan Beulich --- There are more anomalies here, but since we were asked to not make any cosmetic changes for patches to have a chance to go into 4.15, I've put off correct

[PATCH 0/4][4.15?] VT-d: mostly S3 related corrections

None of these are regressions afaict, so considering how late we are in the 4.15 process, I can see reasons to not take any of these. All of them are backporting candidates though, imo. 1: correct off-by-1 in number-of-IOMMUs check 2: leave FECTL write to vtd_resume() 3: re-order register restorin

Re: [PATCH 1/3] Revert "x86/msr: drop compatibility #GP handling in guest_{rd,wr}msr()"

On 17.03.2021 15:46, Ian Jackson wrote: > Jan, what is your summary opinion about patch 3 ? Just to answer this question explicitly: I can't form one yet without further information provided to me. Jan

Re: [PATCH 1/3] Revert "x86/msr: drop compatibility #GP handling in guest_{rd,wr}msr()"

On 17.03.2021 14:37, Ian Jackson wrote: > I have read this thread and with my release manager hat on I feel > confused and/or ignorant. > > Patch 3/ has a good explanation of what the problem is it is > addressing and why this is important for 4.15. But then there is > Jan's most recent reply sta

Re: [PATCH v7] arm: Add Kconfig entry to select CONFIG_DTB_FILE

On 18.03.2021 08:21, Michal Orzel wrote: > Hi Julien, > > On 16.03.2021 15:54, Julien Grall wrote: >> Hi Michal, >> >> On 15/03/2021 09:23, Michal Orzel wrote: >>> Currently in order to link existing DTB into Xen image >>> we need to either specify option CONFIG_DTB_FILE on the >>> command line or

Re: libxl / xen-pciback interaction [and 1 more messages]

On 17.03.2021 16:55, Ian Jackson wrote: > Jan Beulich writes ("Re: libxl / xen-pciback interaction [and 1 more > messages]"): >> On 17.03.2021 16:12, Ian Jackson wrote: >>> How does what libxl is doing differ from a setup, immediately followed >>> by a hot-add ? >> >> In the hot-add case libxl dri

[libvirt test] 160122: regressions - FAIL

flight 160122 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/160122/ 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-armhf-libvirt

Re: xen/evtchn: Dom0 boot hangs using preempt_rt kernel 5.10

Hi Juergen, If you are willing to do the patch I think it will be faster to being accepted, what about the BUG_ON(…) in evtchn_2l_unmask from events_2l.c file? Cheers, Luca > On 18 Mar 2021, at 07:54, Jürgen Groß wrote: > > On 17.03.21 15:32, Luca Fancellu wrote: >> Hi all, >> we've been enc

Re: xen/evtchn: Dom0 boot hangs using preempt_rt kernel 5.10

On 17.03.21 15:32, Luca Fancellu wrote: Hi all, we've been encountering an issue when using the kernel 5.10 with preempt_rt support for Dom0, the problem is that during the boot of Dom0, it hits a BUG_ON(!irqs_disabled()) from the function evtchn_fifo_unmask defined in events_fifo.c. This

Re: [PATCH v7] arm: Add Kconfig entry to select CONFIG_DTB_FILE

Hi Julien, On 16.03.2021 15:54, Julien Grall wrote: > Hi Michal, > > On 15/03/2021 09:23, Michal Orzel wrote: >> Currently in order to link existing DTB into Xen image >> we need to either specify option CONFIG_DTB_FILE on the >> command line or manually add it into .config. >> Add Kconfig entry: