Re: [PATCH v4] IOMMU: make DMA containment of quarantined devices optional

On 30.11.2020 07:13, Tian, Kevin wrote: >> From: Jan Beulich >> Sent: Saturday, November 28, 2020 12:46 AM >> >> @@ -1316,11 +1316,32 @@ boolean (e.g. `iommu=no`) can override t >> will prevent Xen from booting if IOMMUs aren't discovered and enabled >> successfully. >> >> -* The `quar

RE: [PATCH v4] IOMMU: make DMA containment of quarantined devices optional

> From: Jan Beulich > Sent: Saturday, November 28, 2020 12:46 AM > > Containing still in flight DMA was introduced to work around certain > devices / systems hanging hard upon hitting a "not-present" IOMMU fault. > Passing through (such) devices (on such systems) is inherently insecure > (as gues

RE: [PATCH v10 7/7] vtd: use a bit field for dma_pte

> From: Beulich > Sent: Saturday, November 28, 2020 12:02 AM > > On 20.11.2020 14:24, Paul Durrant wrote: > > @@ -709,20 +709,23 @@ static void dma_pte_clear_one(struct domain > *domain, uint64_t addr, > > page = (struct dma_pte *)map_vtd_domain_page(pg_maddr); > > pte = page + address_l

RE: [PATCH v10 6/7] vtd: use a bit field for context_entry

> From: Paul Durrant > Sent: Friday, November 20, 2020 9:25 PM > > From: Paul Durrant > > This removes the need for much shifting, masking and several magic > numbers. > On the whole it makes the code quite a bit more readable. > > Signed-off-by: Paul Durrant Reviewed-by: Kevin Tian > ---

RE: [PATCH v10 5/7] vtd: use a bit field for root_entry

> From: Paul Durrant > Sent: Friday, November 20, 2020 9:25 PM > > From: Paul Durrant > > This makes the code a little easier to read and also makes it more consistent > with iremap_entry. > > Also take the opportunity to tidy up the implementation of > device_in_domain(). > > Signed-off-by:

RE: [PATCH] xen/iommu: vtd: Fix undefined behavior pci_vtd_quirks()

> From: Julien Grall > Sent: Thursday, November 19, 2020 10:52 PM > > From: Julien Grall > > When booting Xen with CONFIG_USBAN=y on Sandy Bridge, UBSAN will > throw > the following splat: > > (XEN) > > > (XEN) U

RE: [PATCH v3 13/13] x86: replace open-coded occurrences of sizeof_field()...

> From: Paul Durrant > Sent: Wednesday, November 25, 2020 3:08 AM > > From: Paul Durrant > > ... with macro evaluations, now that it is available. > > A recent patch imported the sizeof_field() macro from Linux. This patch > makes > use of it in places where the construct is currently open-cod

[qemu-mainline test] 157097: regressions - FAIL

flight 157097 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/157097/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631 test-amd64-amd64

[linux-linus test] 157093: regressions - trouble: broken/fail/pass

flight 157093 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/157093/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-arm64-arm64-xl broken test-amd64-i386-xl-qemuu-ws16-amd64 7 xen

[qemu-mainline test] 157088: regressions - FAIL

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

Re: [PATCH 2/8] net: xen-netback: xenbus: Demote nonconformant kernel-doc headers

On Thu, Nov 26, 2020 at 01:38:47PM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member > 'dev' not described in 'frontend_changed' > drivers/net/xen-netback/xenbus.c:419: warning: Function par

HVM - 2nd bridge breaking DomU config

Hi all, got the recommendation from the freenode xen IRC channel to open a ticket here. Hoping that's ok. Problem: I want to provide a second bridge to a HVM Linux DomU. But as soon as I add this to the DomU config file the DomU doesn't start and the qemu log file does state *qemu-system-i386:

[linux-linus test] 157086: regressions - FAIL

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

[xen-unstable-coverity test] 157090: all pass - PUSHED

flight 157090 xen-unstable-coverity real [real] http://logs.test-lab.xenproject.org/osstest/logs/157090/ Perfect :-) All tests in this flight passed as required version targeted for testing: xen f7d7d53f6464cff94ead4c15d21e79ce4d9173f5 baseline version: xen 9b15

[xen-unstable test] 157082: tolerable FAIL

flight 157082 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/157082/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-rtds 20 guest-localmigrate/x10 fail in 157072 pass in 157082 test-amd64-amd64-xl-qemut-deb

Re: NetBSD dom0 PVH: hardware interrupts stalls

On Sat, Nov 28, 2020 at 06:14:30PM +0100, Manuel Bouyer wrote: > On Sat, Nov 28, 2020 at 03:53:11PM +0100, Roger Pau Monné wrote: > > > the trace is at > > > http://www-soc.lip6.fr/~bouyer/xen-log13.txt > > > > Thanks! I think I've found the issue and I'm attaching a possible fix > > (fix.patch) t