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: CONFIG_DTB_FILE >> to be able to provide the path to DTB we want to embed >> into Xen image. If no path provided - the dtb will not >> be embedded. >> >> Remove the line: AFLAGS-y += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\" >> as it is not needed since Kconfig will define it in a header >> with all the other config options. >> >> Make a change in the linker script from: >> _sdtb = .; >> to: >> PROVIDE(_sdtb = .); >> to avoid creation of _sdtb if there is no reference to it. > > This means that if someone is using #ifdef CONFIG_DTB_FILE rather than > .ifnes, _sdtb will get defined. Do we really want to overengineer something that simple? Why would someone use #ifdef CONFIG_DTB_FILE? In my opinion the rule of thumb is that you don't use #ifdef on configs of string type. Using #ifdef CONFIG_DTB_FILE means that someone modifying the code did not even spend 1 minute checking the Kconfig. If you do not agree, I can modify the code so _sdtb will be created in dtb.S. In that case I would like Jan Beulich to give his opinion before I will send v8. > > The difference between two is quite subttle and can be easily missed during > review. > > How about defining _sdtb in dtb.S? With that approach, we would get a > compiler error if someone protect _sdtb with #ifdef rather than .ifnes. > > Cheers, > Cheers, Michal
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 is the call stack: [ 17.817018] [ cut here ] [ 17.817021] kernel BUG at drivers/xen/events/events_fifo.c:258! [ 18.817079] Internal error: Oops - BUG: 0 [#1] PREEMPT_RT SMP [ 18.817081] Modules linked in: bridge stp llc ipv6 [ 18.817086] CPU: 3 PID: 558 Comm: xenstored Not tainted 5.10.16-rt25-yocto-preempt-rt #1 [ 18.817089] Hardware name: Arm Neoverse N1 System Development Platform (DT) [ 18.817090] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 18.817092] pc : evtchn_fifo_unmask+0xd4/0xe0 [ 18.817099] lr : xen_irq_lateeoi_locked+0xec/0x200 [ 18.817102] sp : 8000123f3cc0 [ 18.817102] x29: 8000123f3cc0 x28: 427b1d80 [ 18.817104] x27: x26: [ 18.817106] x25: 0001 x24: 0001 [ 18.817107] x23: 412fc900 x22: 0004 [ 18.817109] x21: x20: 42e06990 [ 18.817110] x19: 427b1d80 x18: 0010 [ 18.817112] x17: x16: [ 18.817113] x15: 0002 x14: 0001 [ 18.817114] x13: 0001a7e8 x12: 0040 [ 18.817116] x11: 40400248 x10: 4040024a [ 18.817117] x9 : 800011be5200 x8 : 40400270 [ 18.817119] x7 : x6 : 0003 [ 18.817120] x5 : x4 : 40400308 [ 18.817121] x3 : 408a400c x2 : [ 18.817122] x1 : x0 : 408a4000 [ 18.817124] Call trace: [ 18.817125] evtchn_fifo_unmask+0xd4/0xe0 [ 18.817127] xen_irq_lateeoi_locked+0xec/0x200 [ 18.817129] xen_irq_lateeoi+0x48/0x64 [ 18.817131] evtchn_write+0x124/0x15c [ 18.817134] vfs_write+0xf0/0x2cc [ 18.817137] ksys_write+0xe0/0x100 [ 18.817139] __arm64_sys_write+0x20/0x30 [ 18.817142] el0_svc_common.constprop.0+0x78/0x1a0 [ 18.817145] do_el0_svc+0x24/0x90 [ 18.817147] el0_svc+0x14/0x20 [ 18.817151] el0_sync_handler+0x1a4/0x1b0 [ 18.817153] el0_sync+0x174/0x180 [ 18.817156] Code: 52800120 b90023e6 97e6d104 17f0 (d421) [ 18.817158] ---[ end trace 0002 ]--- Our last tested kernel was the 5.4 and our analysis pointed out that the introduction of the lateeoi framework (xen/events: add a new "late EOI" evtchn framework) in conjunction with the preempt_rt patches (irqs kept enabled between spinlock_t/rwlock_t _irqsave///_irqrestore operations) is the root cause. Given that many modifications were made to the mask/unmask operations, a big one from Juergen Gross (xen/events: don't unmask an event channel when an eoi is pending), is the BUG_ON(...) still needed? With the mentioned commit every call to a mask/unmask operation is protected by a spinlock, so I would like to have some feedbacks from who has more experience than me on this part of the code. I think this BUG_ON() can be removed. Are you planning to send a patch? Juergen OpenPGP_0xB0DE9DD628BF132F.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
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 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 is the call stack: >> [ 17.817018] [ cut here ] >> [ 17.817021] kernel BUG at drivers/xen/events/events_fifo.c:258! >> [ 18.817079] Internal error: Oops - BUG: 0 [#1] PREEMPT_RT SMP >> [ 18.817081] Modules linked in: bridge stp llc ipv6 >> [ 18.817086] CPU: 3 PID: 558 Comm: xenstored Not tainted >> 5.10.16-rt25-yocto-preempt-rt #1 >> [ 18.817089] Hardware name: Arm Neoverse N1 System Development Platform >> (DT) >> [ 18.817090] pstate: 6045 (nZCv daif +PAN -UAO -TCO BTYPE=--) >> [ 18.817092] pc : evtchn_fifo_unmask+0xd4/0xe0 >> [ 18.817099] lr : xen_irq_lateeoi_locked+0xec/0x200 >> [ 18.817102] sp : 8000123f3cc0 >> [ 18.817102] x29: 8000123f3cc0 x28: 427b1d80 >> [ 18.817104] x27: x26: >> [ 18.817106] x25: 0001 x24: 0001 >> [ 18.817107] x23: 412fc900 x22: 0004 >> [ 18.817109] x21: x20: 42e06990 >> [ 18.817110] x19: 427b1d80 x18: 0010 >> [ 18.817112] x17: x16: >> [ 18.817113] x15: 0002 x14: 0001 >> [ 18.817114] x13: 0001a7e8 x12: 0040 >> [ 18.817116] x11: 40400248 x10: 4040024a >> [ 18.817117] x9 : 800011be5200 x8 : 40400270 >> [ 18.817119] x7 : x6 : 0003 >> [ 18.817120] x5 : x4 : 40400308 >> [ 18.817121] x3 : 408a400c x2 : >> [ 18.817122] x1 : x0 : 408a4000 >> [ 18.817124] Call trace: >> [ 18.817125] evtchn_fifo_unmask+0xd4/0xe0 >> [ 18.817127] xen_irq_lateeoi_locked+0xec/0x200 >> [ 18.817129] xen_irq_lateeoi+0x48/0x64 >> [ 18.817131] evtchn_write+0x124/0x15c >> [ 18.817134] vfs_write+0xf0/0x2cc >> [ 18.817137] ksys_write+0xe0/0x100 >> [ 18.817139] __arm64_sys_write+0x20/0x30 >> [ 18.817142] el0_svc_common.constprop.0+0x78/0x1a0 >> [ 18.817145] do_el0_svc+0x24/0x90 >> [ 18.817147] el0_svc+0x14/0x20 >> [ 18.817151] el0_sync_handler+0x1a4/0x1b0 >> [ 18.817153] el0_sync+0x174/0x180 >> [ 18.817156] Code: 52800120 b90023e6 97e6d104 17f0 (d421) >> [ 18.817158] ---[ end trace 0002 ]--- >> Our last tested kernel was the 5.4 and our analysis pointed out that the >> introduction of the lateeoi framework (xen/events: add a new "late EOI" >> evtchn framework) in conjunction with the preempt_rt patches (irqs kept >> enabled between spinlock_t/rwlock_t _irqsave///_irqrestore operations) is >> the root cause. >> Given that many modifications were made to the mask/unmask operations, a big >> one from Juergen Gross (xen/events: don't unmask an event channel when an >> eoi is pending), is the BUG_ON(...) still needed? >> With the mentioned commit every call to a mask/unmask operation is protected >> by a spinlock, so I would like to have some feedbacks from who has more >> experience than me on this part of the code. > > I think this BUG_ON() can be removed. > > Are you planning to send a patch? > > > Juergen >
[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 6 libvirt-buildfail REGR. vs. 151777 build-i386-libvirt6 libvirt-buildfail REGR. vs. 151777 build-arm64-libvirt 6 libvirt-buildfail REGR. vs. 151777 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a version targeted for testing: libvirt f07ae0fcbd84f52da6660a7ad0b19c99f6a6f9d6 baseline version: libvirt 2c846fa6bcc11929c9fb857a22430fb9945654ad Last test of basis 151777 2020-07-10 04:19:19 Z 251 days Failing since151818 2020-07-11 04:18:52 Z 250 days 243 attempts Testing same since 160122 2021-03-18 04:20:00 Z0 days1 attempts People who touched revisions under test: Adolfo Jayme Barrientos Aleksandr Alekseev Aleksei Zakharov Andika Triwidada Andrea Bolognani Balázs Meskó Barrett Schonefeld Bastien Orivel BiaoXiang Ye Bihong Yu Binfeng Wu Boris Fiuczynski Brian Turek Bruno Haible Chris Mayo Christian Ehrhardt Christian Schoenebeck Cole Robinson Collin Walling Cornelia Huck Cédric Bosdonnat Côme Borsoi Daniel Henrique Barboza Daniel Letai Daniel P. Berrange Daniel P. Berrangé Dmytro Linkin Eiichi Tsukata Erik Skultety Fabian Affolter Fabian Freyer Fangge Jin Farhan Ali Fedora Weblate Translation gongwei Guoyi Tu Göran Uddeborg Halil Pasic Han Han Hao Wang Hela Basa Helmut Grohne Ian Wienand Jakob Meng Jamie Strandboge Jamie Strandboge Jan Kuparinen Jean-Baptiste Holcroft Jianan Gao Jim Fehlig Jin Yan Jiri Denemark John Ferlan Jonathan Watt Jonathon Jongsma Julio Faracco Ján Tomko Kashyap Chamarthy Kevin Locke Kristina Hanicova Laine Stump Laszlo Ersek Liao Pingfang Lin Ma Lin Ma Lin Ma Marc Hartmayer Marc-André Lureau Marek Marczykowski-Górecki Markus Schade Martin Kletzander Masayoshi Mizuma Matt Coleman Matt Coleman Mauro Matteo Cascella Meina Li Michal Privoznik Michał Smyk Milo Casagrande Moshe Levi Muha Aliss Neal Gompa Nick Shyrokovskiy Nickys Music Group Nico Pache Nikolay Shirokovskiy Olaf Hering Olesya Gerasimenko Orion Poplawski Pany Patrick Magauran Paulo de Rezende Pinatti Pavel Hrdina Peng Liang Peter Krempa Pino Toscano Pino Toscano Piotr Drąg Prathamesh Chavan Ricky Tigg Roman Bogorodskiy Roman Bolshakov Ryan Gahagan Ryan Schmidt Sam Hartman Scott Shambarger Sebastian Mitterle Shalini Chellathurai Saroja Shaojun Yang Shi Lei simmon Simon Gaiser Stefan Bader Stefan Berger Stefan Berger Szymon Scholz Thomas Huth Tim Wiederhake Tomáš Golembiovský Tomáš Janoušek Tuguoyi Ville Skyttä Wang Xin Weblate Yalei Li <274268...@qq.com> Yalei Li Yang Hang Yanqiu Zhang Yi Li Yi Wang Yuri Chornoivan Zheng Chuan zhenwei pi Zhenyu Zheng jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 pass build-armhf pass build-i386 pass build-amd64-libvirt fail
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 drives things through Reconfiguring state.
>> I'm not sure this would be an appropriate (and backwards compatible)
>> thing to do when initially populating xenstore.
>
> Ah. Tbanks, that is precisely the answer to my question.
>
> I think that means, therefore, populating the whole lot in one
> transaction.
>
> (From what you say it doesn't sound like it's possible to write only a
> subset, perhaps with state "not ready yet" and then set them all go
> "go" at the end.)
Indeed, that's my understanding and a consequence of pciback's watch
covering the entire backend subtree, rather than e.g. just the
num_devs node.
Jan
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 manually add it into .config. >>> Add Kconfig entry: CONFIG_DTB_FILE >>> to be able to provide the path to DTB we want to embed >>> into Xen image. If no path provided - the dtb will not >>> be embedded. >>> >>> Remove the line: AFLAGS-y += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\" >>> as it is not needed since Kconfig will define it in a header >>> with all the other config options. >>> >>> Make a change in the linker script from: >>> _sdtb = .; >>> to: >>> PROVIDE(_sdtb = .); >>> to avoid creation of _sdtb if there is no reference to it. >> >> This means that if someone is using #ifdef CONFIG_DTB_FILE rather than >> .ifnes, _sdtb will get defined. > > Do we really want to overengineer something that simple? > Why would someone use #ifdef CONFIG_DTB_FILE? > In my opinion the rule of thumb is that you don't use #ifdef on configs of > string type. > Using #ifdef CONFIG_DTB_FILE means that someone modifying the code did not > even spend 1 minute checking the Kconfig. > > If you do not agree, I can modify the code so _sdtb will be created in dtb.S. > In that case I would like Jan Beulich to give his opinion before I will send > v8. TBH I'd find it more natural in any event if the symbol came from dtb.S. So far I was assuming there was some (hidden) reason why this wouldn't work. 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 starting "I find all of this confusing". Jan, > can you please tell me in words of one syllable what the implication > of that message is ? In particular is any of what you say a reason > for me to withhold my release-ack ? Answering the last question first - I don't think so. Something may indeed want doing here beyond what we already have, and it may well be precisely what Andrew is proposing, possibly just with extended descriptions and/or comments. My confusion about patch 3 is that it (a) claims behavior in turbostat that I can't locate and (b) implies (describes) behavior of code that I find entirely unexpected (as in: not making sense to me). And I'm sorry: Not all of the words are of one syllable. Jan
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
[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 restoring in vtd_resume() 4: restore flush hooks when disabling qinval Jan
[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 correcting even the most obvious things (scope of MAX_IOMMUS and
nr_iommus) for a later patch.
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1168,10 +1168,10 @@ int __init iommu_alloc(struct acpi_drhd_
unsigned long sagaw, nr_dom;
int agaw;
-if ( nr_iommus > MAX_IOMMUS )
+if ( nr_iommus >= MAX_IOMMUS )
{
dprintk(XENLOG_ERR VTDPREFIX,
- "IOMMU: nr_iommus %d > MAX_IOMMUS\n", nr_iommus);
+"IOMMU: nr_iommus %d > MAX_IOMMUS\n", nr_iommus + 1);
return -ENOMEM;
}
[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(adjust_vtd_irq_affinities);
-static int __must_check init_vtd_hw(void)
+static int __must_check init_vtd_hw(bool resume)
{
struct acpi_drhd_unit *drhd;
struct vtd_iommu *iommu;
@@ -2121,6 +2121,10 @@ static int __must_check init_vtd_hw(void
disable_qinval(iommu);
}
+if ( resume )
+/* FECTL write done by vtd_resume(). */
+continue;
+
spin_lock_irqsave(&iommu->register_lock, flags);
sts = dmar_readl(iommu->reg, DMAR_FECTL_REG);
sts &= ~DMA_FECTL_IM;
@@ -2320,7 +2324,7 @@ static int __init vtd_setup(void)
P(iommu_hap_pt_share, "Shared EPT tables");
#undef P
-ret = init_vtd_hw();
+ret = init_vtd_hw(false);
if ( ret )
goto error;
@@ -2590,7 +2594,7 @@ static void vtd_resume(void)
if ( !iommu_enabled )
return;
-if ( init_vtd_hw() != 0 && force_iommu )
+if ( init_vtd_hw(true) != 0 && force_iommu )
panic("IOMMU setup failed, crash Xen for security purpose\n");
for_each_drhd_unit ( drhd )
[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 intended effect we shouldn't subsequently overwrite
what was written there - this is only benign when old and new settings
match. Instead we should restore the registers ahead of calling
init_vtd_hw(), just for the unlikely case of dma_msi_set_affinity()
bailing early.
In the moved code drop some stray casts as well.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2594,6 +2594,21 @@ static void vtd_resume(void)
if ( !iommu_enabled )
return;
+for_each_drhd_unit ( drhd )
+{
+iommu = drhd->iommu;
+i = iommu->index;
+
+spin_lock_irqsave(&iommu->register_lock, flags);
+dmar_writel(iommu->reg, DMAR_FEDATA_REG,
+iommu_state[i][DMAR_FEDATA_REG]);
+dmar_writel(iommu->reg, DMAR_FEADDR_REG,
+iommu_state[i][DMAR_FEADDR_REG]);
+dmar_writel(iommu->reg, DMAR_FEUADDR_REG,
+iommu_state[i][DMAR_FEUADDR_REG]);
+spin_unlock_irqrestore(&iommu->register_lock, flags);
+}
+
if ( init_vtd_hw(true) != 0 && force_iommu )
panic("IOMMU setup failed, crash Xen for security purpose\n");
@@ -2605,12 +2620,6 @@ static void vtd_resume(void)
spin_lock_irqsave(&iommu->register_lock, flags);
dmar_writel(iommu->reg, DMAR_FECTL_REG,
(u32) iommu_state[i][DMAR_FECTL_REG]);
-dmar_writel(iommu->reg, DMAR_FEDATA_REG,
-(u32) iommu_state[i][DMAR_FEDATA_REG]);
-dmar_writel(iommu->reg, DMAR_FEADDR_REG,
-(u32) iommu_state[i][DMAR_FEADDR_REG]);
-dmar_writel(iommu->reg, DMAR_FEUADDR_REG,
-(u32) iommu_state[i][DMAR_FEUADDR_REG]);
spin_unlock_irqrestore(&iommu->register_lock, flags);
iommu_enable_translation(drhd);
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 into .config. Add Kconfig entry: CONFIG_DTB_FILE to be able to provide the path to DTB we want to embed into Xen image. If no path provided - the dtb will not be embedded. Remove the line: AFLAGS-y += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\" as it is not needed since Kconfig will define it in a header with all the other config options. Make a change in the linker script from: _sdtb = .; to: PROVIDE(_sdtb = .); to avoid creation of _sdtb if there is no reference to it. This means that if someone is using #ifdef CONFIG_DTB_FILE rather than .ifnes, _sdtb will get defined. Do we really want to overengineer something that simple? Interesting, I would argue that using PROVIDE is over-engineered (and error-prone) when you likely can define _sdtb in .S. Why would someone use #ifdef CONFIG_DTB_FILE? In my opinion the rule of thumb is that you don't use #ifdef on configs of string type. Using #ifdef CONFIG_DTB_FILE means that someone modifying the code did not even spend 1 minute checking the Kconfig. I'd like to point out that your first approach didn't replace #ifdef. This was fully reviewed and nearly committed. When I pointed out the issue, I had to argue that this was broken. This is not quite the same as adding #ifdef but it shows that such mistake can be easily slipped in master. Cheers, -- Julien Grall
[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/extern.h
+++ b/xen/drivers/passthrough/vtd/extern.h
@@ -49,6 +49,16 @@ int iommu_flush_iec_global(struct vtd_io
int iommu_flush_iec_index(struct vtd_iommu *iommu, u8 im, u16 iidx);
void clear_fault_bits(struct vtd_iommu *iommu);
+int __must_check vtd_flush_context_reg(struct vtd_iommu *iommu, uint16_t did,
+ uint16_t source_id,
+ uint8_t function_mask, uint64_t type,
+ bool flush_non_present_entry);
+int __must_check vtd_flush_iotlb_reg(struct vtd_iommu *iommu, uint16_t did,
+ uint64_t addr, unsigned int size_order,
+ uint64_t type,
+ bool flush_non_present_entry,
+ bool flush_dev_iotlb);
+
struct vtd_iommu *ioapic_to_iommu(unsigned int apic_id);
struct vtd_iommu *hpet_to_iommu(unsigned int hpet_id);
struct acpi_drhd_unit *ioapic_to_drhd(unsigned int apic_id);
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -380,10 +380,9 @@ static void iommu_flush_write_buffer(str
}
/* return value determine if we need a write buffer flush */
-static int __must_check flush_context_reg(struct vtd_iommu *iommu, u16 did,
- u16 source_id, u8 function_mask,
- u64 type,
- bool flush_non_present_entry)
+int vtd_flush_context_reg(struct vtd_iommu *iommu, uint16_t did,
+ uint16_t source_id, uint8_t function_mask,
+ uint64_t type, bool flush_non_present_entry)
{
u64 val = 0;
unsigned long flags;
@@ -449,11 +448,9 @@ static int __must_check iommu_flush_cont
}
/* return value determine if we need a write buffer flush */
-static int __must_check flush_iotlb_reg(struct vtd_iommu *iommu, u16 did,
-u64 addr,
-unsigned int size_order, u64 type,
-bool flush_non_present_entry,
-bool flush_dev_iotlb)
+int vtd_flush_iotlb_reg(struct vtd_iommu *iommu, uint16_t did, uint64_t addr,
+unsigned int size_order, uint64_t type,
+bool flush_non_present_entry, bool flush_dev_iotlb)
{
int tlb_offset = ecap_iotlb_offset(iommu->ecap);
u64 val = 0;
@@ -2144,8 +2141,8 @@ static int __must_check init_vtd_hw(bool
*/
if ( enable_qinval(iommu) != 0 )
{
-iommu->flush.context = flush_context_reg;
-iommu->flush.iotlb = flush_iotlb_reg;
+iommu->flush.context = vtd_flush_context_reg;
+iommu->flush.iotlb = vtd_flush_iotlb_reg;
}
}
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -462,4 +462,7 @@ void disable_qinval(struct vtd_iommu *io
!(sts & DMA_GSTS_QIES), sts);
out:
spin_unlock_irqrestore(&iommu->register_lock, flags);
+
+iommu->flush.context = vtd_flush_context_reg;
+iommu->flush.iotlb = vtd_flush_iotlb_reg;
}
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 it! 1) xen/arch/arm/domain_build.c d = domain_create(++max_init_domid, &d_cfg, false); Where max_init_domid has value 0 and it is defined in setup.c We might want to add a comment on top of this code to explain why the '++a' rather than 'a++'. 2) xen/common/domctl.c d = domain_create(dom, &op->u.createdomain, false); For me seems that the dom variable won’t take the 0 value, if someone could give another feedback it would be great. On every other part where domain_create(…) is used, it is called with a constant value different from 0. I agree with the analysis. However, I feel this is fragile because we rely on the caller to never pass 0. But it looks like domain_create() doesn't check if the ID is already used. So it would already be possible to overwrite hardware_domain. Therefore, this can probably be deffered. For the hardware_domain being NULL and not handled in some situation, it seems that it’s not directly related to this patch, but I can handle it on a next serie, from a quick look it seems that many cases can be handled by checking if the domain is NULL in is_hardware_domain(…). Before this series, it is not possible to have hardware_domain == NULL at runtime because dom0 is always created. Cheers, -- Julien Grall
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 specify option CONFIG_DTB_FILE on the command line or manually add it into .config. Add Kconfig entry: CONFIG_DTB_FILE to be able to provide the path to DTB we want to embed into Xen image. If no path provided - the dtb will not be embedded. Remove the line: AFLAGS-y += -DCONFIG_DTB_FILE=\"$(CONFIG_DTB_FILE)\" as it is not needed since Kconfig will define it in a header with all the other config options. Make a change in the linker script from: _sdtb = .; to: PROVIDE(_sdtb = .); to avoid creation of _sdtb if there is no reference to it. >>> >>> This means that if someone is using #ifdef CONFIG_DTB_FILE rather than >>> .ifnes, _sdtb will get defined. >> >> Do we really want to overengineer something that simple? >> Why would someone use #ifdef CONFIG_DTB_FILE? >> In my opinion the rule of thumb is that you don't use #ifdef on configs of >> string type. >> Using #ifdef CONFIG_DTB_FILE means that someone modifying the code did not >> even spend 1 minute checking the Kconfig. >> >> If you do not agree, I can modify the code so _sdtb will be created in dtb.S. >> In that case I would like Jan Beulich to give his opinion before I will send >> v8. > > TBH I'd find it more natural in any event if the symbol came from > dtb.S. So far I was assuming there was some (hidden) reason why > this wouldn't work. > > Jan > Then if both of you agree that _sdtb should be defined in dtb.S, I will make it in v8 Michal
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, 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 it! > > >> 1) xen/arch/arm/domain_build.c >> d = domain_create(++max_init_domid, &d_cfg, false); >> Where max_init_domid has value 0 and it is defined in setup.c > > We might want to add a comment on top of this code to explain why the '++a' > rather than 'a++'. > >> 2) xen/common/domctl.c >> d = domain_create(dom, &op->u.createdomain, false); >> For me seems that the dom variable won’t take the 0 value, if someone could >> give another feedback it would be great. >> On every other part where domain_create(…) is used, it is called with a >> constant value different from 0. > > I agree with the analysis. However, I feel this is fragile because we rely on > the caller to never pass 0. But it looks like domain_create() doesn't check > if the ID is already used. So it would already be possible to overwrite > hardware_domain. > > Therefore, this can probably be deffered. > >> For the hardware_domain being NULL and not handled in some situation, it >> seems that it’s not directly related to this patch, but I can handle it on a >> next serie, from a quick look it seems that many cases can be handled by >> checking if the domain is NULL in is_hardware_domain(…). > > Before this series, it is not possible to have hardware_domain == NULL at > runtime because dom0 is always created. > > Cheers, > > -- > Julien Grall
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 requires all data structures passed across its public interface to be initialized before use and disposed of afterwards by calling a specific set of functions. Many internal data structures also require this initialize / dispose discipline, but not all of them. When the "soft reset" feature was implemented, the libxl__domain_suspend_state structure didn't require any initialization or disposal. At some point later, an initialization function was introduced for the structure; but the "soft reset" path wasn't refactored to call the initialization function. When a guest nwo initiates a "soft reboot", uninitialized data structure leads to an assert() when later code finds the structure in an unexpected state. The effect of this is to crash the process monitoring the guest. How this affects the system depends on the structure of the toolstack. For xl, this will have no security-relevant effect: every VM has its own independent monitoring process, which contains no state. The domain in question will hang in a crashed state, but can be destroyed by `xl destroy` just like any other non-cooperating domain. For daemon-based toolstacks linked against libxl, such as libvirt, this will crash the toolstack, losing the state of any in-progress operations (localized DoS), and preventing further administrator operations unless the daemon is configured to restart automatically (system-wide DoS). If crashes "leak" resources, then repeated crashes could use up resources, also causing a system-wide DoS. IMPACT == A malicious guest can crash the management daemon, leading to at least a localized, possibly system-wide denial-of-service. VULNERABLE SYSTEMS == Only Xen versions 4.12 through 4.14 are affected. Earlier versions are not affected. The issue affects only systems with a guest monitoring process, which is linked against libxl, and which is important other than simply for the functioning of one particular guest. libvirt is one common toolstack affected. Systems using the `xl` command-line tool should generally suffer no security-relevant effects. The xapi toolstack does not currently link against libxl, and so is not affected. MITIGATION == Ensuring that any management daemons are restarted automatically after a crash will partially mitigate the issue. CREDITS === This issue was discovered by Olaf Hering. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa368.patch xen-unstable xsa368-4.14.patch Xen 4.14.x xsa368-4.13.patch Xen 4.13.x - Xen 4.12.x $ sha256sum xsa368* e80f33c3ce45372fef7bd91ec71b2b66e557176b79f9771872ce111bfff34150 xsa368.meta b82f2b110514cdf47a2688913ad5af68b01050751d56705a15ddf9a970b6fa0d xsa368.patch 636df70ae5eaf00b50ef0b5ac219a2aeda771c66833fae88e7ee43b18ae889f4 xsa368-4.13.patch 55bbe59c75b69f493e364dfcf6cdbc7db4acd32dbf0b4d2466815b7c1f1823ce xsa368-4.14.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmBTQEMMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZDAIH/ibVSFJRukaH4TKAtm0Qy7Qb0jSF6u5lHdUH4lfa EXTAS4/vAJI70bMt2yePGoaa+QPSJ340MwlKcW8GerAEWeW0hTxOp23GGavEwbtu I+OFdls2YGrxGM2FMQR0ZEftV4jsyVAcCNF6oq6nqzTDe1OZC0bQSDUL69CWnIKn hC9Br/hV3AuijwwQdOGQoe+rj8aZK134UaNjr0AI9e1l2jEsJ3NxC3IxeHy4/J3E meoHKtTRZXFdG2VMu709jqrnhpOQcZDT+meiNhoOdUvXyPBa2MzVj3XY32yWuJxa Fi7qrpXIAZ8qNbCbLIbNYMGlgB+7sLsKQULycgai8Sk7QpU= =ea+C -END PGP SIGNATURE- xsa368.meta Description: Binary d
[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 run: test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631 test-amd64-amd64-xl-qcow2 21 guest-start/debian.repeat fail REGR. vs. 152631 test-armhf-armhf-xl-vhd 17 guest-start/debian.repeat fail REGR. vs. 152631 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152631 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152631 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152631 test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: qemuu571d413b5da6bc6f1c2aaca8484717642255ddb0 baseline version: qemuu1d806cef0e38b5db8347a8e12f214d543204a314 Last test of basis 152631 2020-08-20 09:07:46 Z 210 days Failing since152659 2020-08-21 14:07:39 Z 208 days 405 attempts Testing same since 160119 2021-03-18 00:08:21 Z0 days1 attempts 456 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-arm64-xsm
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 = libxl requires all data structures passed across its public interface to be initialized before use and disposed of afterwards by calling a specific set of functions. Many internal data structures also require this initialize / dispose discipline, but not all of them. When the "soft reset" feature was implemented, the libxl__domain_suspend_state structure didn't require any initialization or disposal. At some point later, an initialization function was introduced for the structure; but the "soft reset" path wasn't refactored to call the initialization function. When a guest nwo initiates a "soft reboot", uninitialized data structure leads to an assert() when later code finds the structure in an unexpected state. The effect of this is to crash the process monitoring the guest. How this affects the system depends on the structure of the toolstack. For xl, this will have no security-relevant effect: every VM has its own independent monitoring process, which contains no state. The domain in question will hang in a crashed state, but can be destroyed by `xl destroy` just like any other non-cooperating domain. For daemon-based toolstacks linked against libxl, such as libvirt, this will crash the toolstack, losing the state of any in-progress operations (localized DoS), and preventing further administrator operations unless the daemon is configured to restart automatically (system-wide DoS). If crashes "leak" resources, then repeated crashes could use up resources, also causing a system-wide DoS. IMPACT == A malicious guest can crash the management daemon, leading to at least a localized, possibly system-wide denial-of-service. VULNERABLE SYSTEMS == Only Xen versions 4.12 through 4.14 are affected. Earlier versions are not affected. The issue affects only systems with a guest monitoring process, which is linked against libxl, and which is important other than simply for the functioning of one particular guest. libvirt is one common toolstack affected. Systems using the `xl` command-line tool should generally suffer no security-relevant effects. The xapi toolstack does not currently link against libxl, and so is not affected. MITIGATION == Ensuring that any management daemons are restarted automatically after a crash will partially mitigate the issue. CREDITS === This issue was discovered by Olaf Hering. RESOLUTION == Applying the appropriate attached patch resolves this issue. Note that patches for released versions are generally prepared to apply to the stable branches, and may not apply cleanly to the most recent release tarball. Downstreams are encouraged to update to the tip of the stable branch before applying these patches. xsa368.patch xen-unstable xsa368-4.14.patch Xen 4.14.x xsa368-4.13.patch Xen 4.13.x - Xen 4.12.x $ sha256sum xsa368* e80f33c3ce45372fef7bd91ec71b2b66e557176b79f9771872ce111bfff34150 xsa368.meta b82f2b110514cdf47a2688913ad5af68b01050751d56705a15ddf9a970b6fa0d xsa368.patch 636df70ae5eaf00b50ef0b5ac219a2aeda771c66833fae88e7ee43b18ae889f4 xsa368-4.13.patch 55bbe59c75b69f493e364dfcf6cdbc7db4acd32dbf0b4d2466815b7c1f1823ce xsa368-4.14.patch $ DEPLOYMENT DURING EMBARGO = Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -BEGIN PGP SIGNATURE- iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmBTXAAMHHBncEB4ZW4u b3JnAAoJEIP+FMlX6CvZdgcH/RTW41tLPh8KHJ+82qefaI2EUBK3nmNnR5hnye3c 9GPP/QB7QdHp+JSIRTAZxOayBQeFEcYSX/5VxDypIiqT02wHS9hDr3jcpOfGLcdt MiN9kB3vYqe353Lask0mN7AX3J5v3wvrYzBRx9ccaYcX/Jcubrx6Jy5laQSYpTUu 4GCeLZQ2tHI8N3ZHiKI7YUyxmn9vKgvFil1gyuk8L5x6npnW4ixdWF0MRyHe7wbS dbZbug0g6bbJbs4CFZbm1CbQjGGOwznfT8z9ppmgPdi+33X+Cimz3wlbpXeJKpZk /nJObobdPGk7ClChvUjntv0oaZ+2zFoUoe3Yc08aa+B29e8= =Dehk -END PGP SIGNATURE- xsa368.meta Description: B
[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 030ba3097a6e7d08b99f8a9d19a322f61409c1f6 Last test of basis 160117 2021-03-17 20:41:58 Z0 days Testing same since 160123 2021-03-18 04:45:10 Z0 days1 attempts People who touched revisions under test: Jiaxin Wu Mars CC Lin Pierre Gondois Ray Ni jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/osstest/ovmf.git 030ba3097a..9fd7e88c23 9fd7e88c23f6fb056d25fbc3f8e2e7c1a53859d1 -> xen-tested-master
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 production-ready revisions of our previous > prototype in as patches to provide a near-term implementation of the > design. If possible please join us this Thursday 3/18 at > 1700CET/1600GMT/1200EDT/0900PDT. Below are the call details. > > [1] > https://lists.xenproject.org/archives/html/xen-devel/2021-03/msg00939.html > [2] > https://lists.xenproject.org/archives/html/xen-devel/2021-03/pdfCV4LaWCrTN.pdf Agenda link, https://cryptpad.fr/pad/#/2/pad/edit/+MJgJ0EkalH81-YVOlsp1bEo/ > Call Details: > > Daniel Smith's Meeting > > > Please join my meeting from your computer, tablet or smartphone. > > https://www.gotomeet.me/apertussolutions > > You can also dial in using your phone. > (For supported devices, tap a one-touch number below to join instantly.) > > United States (Toll Free): 1 877 568 4106 > - One-touch: tel:+18775684106,,691818141# > > Access Code: 691-818-141 >
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 alloc_size array - dropped all patches already merged Changes since v1: - rebased to v5.12-rc1 - a few more cleanups - merge and forward port the patch from Claire to move all the global variables into a struct to prepare for multiple instances
[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-debianhvm-i386-xsm 12 debian-hvm-install fail pass in 160109 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 160109 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 160109 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 160109 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 160109 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 160109 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 160109 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 160109 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 160109 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 160109 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 160109 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 160109 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass version targeted for testing: xen 21657ad4f01a634beac570c64c0691e51b9cf366 baseline version: xen 21657ad4f01a634beac570c64c0691e51b9cf366 Last test of basis 160120 2021-03-18 01:52:30 Z0 days Testing same since (not found) 0 attempts jobs: build-amd64-xsm pass build-arm64-xsm pass build-i386-xsm
[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/swiotlb-xen.c | 2 +-
include/linux/swiotlb.h | 43 -
kernel/dma/swiotlb.c | 354 ++
3 files changed, 206 insertions(+), 193 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 4ecfce2c6f7263..5329ad54a5f34e 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -548,7 +548,7 @@ xen_swiotlb_sync_sg_for_device(struct device *dev, struct
scatterlist *sgl,
static int
xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
{
- return xen_phys_to_dma(hwdev, io_tlb_end - 1) <= mask;
+ return xen_phys_to_dma(hwdev, io_tlb_default_mem.end - 1) <= mask;
}
const struct dma_map_ops xen_swiotlb_dma_ops = {
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 0696bdc8072e97..5ec5378b17c333 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
struct device;
struct page;
@@ -61,11 +62,49 @@ dma_addr_t swiotlb_map(struct device *dev, phys_addr_t phys,
#ifdef CONFIG_SWIOTLB
extern enum swiotlb_force swiotlb_force;
-extern phys_addr_t io_tlb_start, io_tlb_end;
+
+/**
+ * struct io_tlb_mem - IO TLB Memory Pool Descriptor
+ *
+ * @start: The start address of the swiotlb memory pool. Used to do a quick
+ * range check to see if the memory was in fact allocated by this
+ * API.
+ * @end: The end address of the swiotlb memory pool. Used to do a quick
+ * range check to see if the memory was in fact allocated by this
+ * API.
+ * @nslabs:The number of IO TLB blocks (in groups of 64) between @start and
+ * @end. This is command line adjustable via setup_io_tlb_npages.
+ * @used: The number of used IO TLB block.
+ * @list: The free list describing the number of free entries available
+ * from each index.
+ * @index: The index to start searching in the next round.
+ * @orig_addr: The original address corresponding to a mapped entry.
+ * @alloc_size:Size of the allocated buffer.
+ * @lock: The lock to protect the above data structures in the map and
+ * unmap calls.
+ * @debugfs: The dentry to debugfs.
+ * @late_alloc:%true if allocated using the page allocator
+ */
+struct io_tlb_mem {
+ phys_addr_t start;
+ phys_addr_t end;
+ unsigned long nslabs;
+ unsigned long used;
+ unsigned int *list;
+ unsigned int index;
+ phys_addr_t *orig_addr;
+ size_t *alloc_size;
+ spinlock_t lock;
+ struct dentry *debugfs;
+ bool late_alloc;
+};
+extern struct io_tlb_mem io_tlb_default_mem;
static inline bool is_swiotlb_buffer(phys_addr_t paddr)
{
- return paddr >= io_tlb_start && paddr < io_tlb_end;
+ struct io_tlb_mem *mem = &io_tlb_default_mem;
+
+ return paddr >= mem->start && paddr < mem->end;
}
void __init swiotlb_exit(void);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 35e24f0ff8b207..d9c097f0f78cec 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -59,32 +59,11 @@
*/
#define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
-enum swiotlb_force swiotlb_force;
-
-/*
- * Used to do a quick range check in swiotlb_tbl_unmap_single and
- * swiotlb_tbl_sync_single_*, to see if the memory was in fact allocated by
this
- * API.
- */
-phys_addr_t io_tlb_start, io_tlb_end;
-
-/*
- * The number of IO TLB blocks (in groups of 64) between io_tlb_start and
- * io_tlb_end. This is command line adjustable via setup_io_tlb_npages.
- */
-static unsigned long io_tlb_nslabs;
+#define INVALID_PHYS_ADDR (~(phys_addr_t)0)
-/*
- * The number of used IO TLB block
- */
-static unsigned long io_tlb_used;
+enum swiotlb_force swiotlb_force;
-/*
- * This is a free list describing the number of free entries available from
- * each index
- */
-static unsigned int *io_tlb_list;
-static unsigned int io_tlb_index;
+struct io_tlb_mem io_tlb_default_mem;
/*
* Max segment that we can provide which (if pages are contingous) will
@@ -92,32 +71,15 @@ static unsigned int io_tlb_index;
*/
static unsigned int max_segment;
-/*
- * We need to save away the original address corresponding to a mapped entry
- * for the sync operations.
- */
-#define INVALID_PHYS_ADDR (~(phys_addr_t)0)
-static phys_addr_t *io_tlb_orig_addr;
-
-/*
- * The mapped buffer's size should be validated during a sync operation.
- */
-static size_t *io_tlb_alloc_size;
-
-/*
- * Protect the above data structures in the map and unmap calls
- */
-static DEFINE_SPINLOCK(io_tlb_lock);
-
-static int late_alloc;
-
static int __init
setup_io_tl
[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
---
drivers/xen/swiotlb-xen.c | 22 +--
include/linux/swiotlb.h | 18 ++-
kernel/dma/swiotlb.c | 306 --
3 files changed, 117 insertions(+), 229 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 5329ad54a5f34e..4c89afc0df6289 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -158,17 +158,14 @@ static const char *xen_swiotlb_error(enum xen_swiotlb_err
err)
int __ref xen_swiotlb_init(void)
{
enum xen_swiotlb_err m_ret = XEN_SWIOTLB_UNKNOWN;
- unsigned long nslabs, bytes, order;
- unsigned int repeat = 3;
+ unsigned long bytes = swiotlb_size_or_default();
+ unsigned long nslabs = bytes >> IO_TLB_SHIFT;
+ unsigned int order, repeat = 3;
int rc = -ENOMEM;
char *start;
- nslabs = swiotlb_nr_tbl();
- if (!nslabs)
- nslabs = DEFAULT_NSLABS;
retry:
m_ret = XEN_SWIOTLB_ENOMEM;
- bytes = nslabs << IO_TLB_SHIFT;
order = get_order(bytes);
/*
@@ -221,19 +218,16 @@ int __ref xen_swiotlb_init(void)
#ifdef CONFIG_X86
void __init xen_swiotlb_init_early(void)
{
- unsigned long nslabs, bytes;
+ unsigned long bytes = swiotlb_size_or_default();
+ unsigned long nslabs = bytes >> IO_TLB_SHIFT;
unsigned int repeat = 3;
char *start;
int rc;
- nslabs = swiotlb_nr_tbl();
- if (!nslabs)
- nslabs = DEFAULT_NSLABS;
retry:
/*
* Get IO TLB memory from any location.
*/
- bytes = nslabs << IO_TLB_SHIFT;
start = memblock_alloc(PAGE_ALIGN(bytes), PAGE_SIZE);
if (!start)
panic("%s: Failed to allocate %lu bytes align=0x%lx\n",
@@ -248,8 +242,8 @@ void __init xen_swiotlb_init_early(void)
if (repeat--) {
/* Min is 2MB */
nslabs = max(1024UL, (nslabs >> 1));
- pr_info("Lowering to %luMB\n",
- (nslabs << IO_TLB_SHIFT) >> 20);
+ bytes = nslabs << IO_TLB_SHIFT;
+ pr_info("Lowering to %luMB\n", bytes >> 20);
goto retry;
}
panic("%s (rc:%d)", xen_swiotlb_error(XEN_SWIOTLB_EFIXUP), rc);
@@ -548,7 +542,7 @@ xen_swiotlb_sync_sg_for_device(struct device *dev, struct
scatterlist *sgl,
static int
xen_swiotlb_dma_supported(struct device *hwdev, u64 mask)
{
- return xen_phys_to_dma(hwdev, io_tlb_default_mem.end - 1) <= mask;
+ return xen_phys_to_dma(hwdev, io_tlb_default_mem->end - 1) <= mask;
}
const struct dma_map_ops xen_swiotlb_dma_ops = {
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 5ec5378b17c333..63f7a63f61d098 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -90,28 +90,30 @@ struct io_tlb_mem {
phys_addr_t end;
unsigned long nslabs;
unsigned long used;
- unsigned int *list;
unsigned int index;
- phys_addr_t *orig_addr;
- size_t *alloc_size;
spinlock_t lock;
struct dentry *debugfs;
bool late_alloc;
+ struct io_tlb_slot {
+ phys_addr_t orig_addr;
+ size_t alloc_size;
+ unsigned int list;
+ } slots[];
};
-extern struct io_tlb_mem io_tlb_default_mem;
+extern struct io_tlb_mem *io_tlb_default_mem;
static inline bool is_swiotlb_buffer(phys_addr_t paddr)
{
- struct io_tlb_mem *mem = &io_tlb_default_mem;
+ struct io_tlb_mem *mem = io_tlb_default_mem;
- return paddr >= mem->start && paddr < mem->end;
+ return mem && paddr >= mem->start && paddr < mem->end;
}
void __init swiotlb_exit(void);
unsigned int swiotlb_max_segment(void);
size_t swiotlb_max_mapping_size(struct device *dev);
bool is_swiotlb_active(void);
-void __init swiotlb_adjust_size(unsigned long new_size);
+void __init swiotlb_adjust_size(unsigned long size);
#else
#define swiotlb_force SWIOTLB_NO_FORCE
static inline bool is_swiotlb_buffer(phys_addr_t paddr)
@@ -135,7 +137,7 @@ static inline bool is_swiotlb_active(void)
return false;
}
-static inline void swiotlb_adjust_size(unsigned long new_size)
+static inline void swiotlb_adjust_size(unsigned long size)
{
}
#endif /* CONFIG_SWIOTLB */
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index d9c097f0f78cec..13de669a9b4681 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -63,7 +63,7 @@
enum swiotlb_force swiotlb_force;
-struct io_tlb_mem io_tlb_default_mem;
+struct io_tlb_mem *io_tlb_default_mem;
/*
* Max segment that we can
[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 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass version targeted for testing: xen dae3c3e8b257cd27d6b35a467a34bf79a6650340 baseline version: xen 21657ad4f01a634beac570c64c0691e51b9cf366 Last test of basis 160099 2021-03-16 15:00:26 Z2 days Testing same since 160126 2021-03-18 14:01:29 Z0 days1 attempts People who touched revisions under test: Anthony PERARD Olaf Hering jobs: build-arm64-xsm pass build-amd64 pass build-armhf pass build-amd64-libvirt pass test-armhf-armhf-xl pass test-arm64-arm64-xl-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-amd64-libvirt pass sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary Pushing revision : To xenbits.xen.org:/home/xen/git/xen.git 21657ad4f0..dae3c3e8b2 dae3c3e8b257cd27d6b35a467a34bf79a6650340 -> smoke
[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_internal.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +-
drivers/pci/xen-pcifront.c | 2 +-
include/linux/swiotlb.h | 1 -
kernel/dma/swiotlb.c | 7 +--
5 files changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index ad22f42541bda6..a9d65fc8aa0eab 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -42,7 +42,7 @@ static int i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
max_order = MAX_ORDER;
#ifdef CONFIG_SWIOTLB
- if (swiotlb_nr_tbl()) {
+ if (is_swiotlb_active()) {
unsigned int max_segment;
max_segment = swiotlb_max_segment();
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index a37bc3d7b38b3b..9662522aa0664a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -321,7 +321,7 @@ nouveau_ttm_init(struct nouveau_drm *drm)
}
#if IS_ENABLED(CONFIG_SWIOTLB) && IS_ENABLED(CONFIG_X86)
- need_swiotlb = !!swiotlb_nr_tbl();
+ need_swiotlb = is_swiotlb_active();
#endif
ret = ttm_bo_device_init(&drm->ttm.bdev, &nouveau_bo_driver,
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 2d75026482197d..b7a8f3a1921f83 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -693,7 +693,7 @@ static int pcifront_connect_and_init_dma(struct
pcifront_device *pdev)
spin_unlock(&pcifront_dev_lock);
- if (!err && !swiotlb_nr_tbl()) {
+ if (!err && !is_swiotlb_active()) {
err = pci_xen_swiotlb_init_late();
if (err)
dev_err(&pdev->xdev->dev, "Could not setup SWIOTLB!\n");
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 63f7a63f61d098..216854a5e5134b 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -37,7 +37,6 @@ enum swiotlb_force {
extern void swiotlb_init(int verbose);
int swiotlb_init_with_tbl(char *tlb, unsigned long nslabs, int verbose);
-extern unsigned long swiotlb_nr_tbl(void);
unsigned long swiotlb_size_or_default(void);
extern int swiotlb_late_init_with_tbl(char *tlb, unsigned long nslabs);
extern int swiotlb_late_init_with_default_size(size_t default_size);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 13de669a9b4681..539c76beb52e07 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -94,12 +94,6 @@ setup_io_tlb_npages(char *str)
}
early_param("swiotlb", setup_io_tlb_npages);
-unsigned long swiotlb_nr_tbl(void)
-{
- return io_tlb_default_mem ? io_tlb_default_mem->nslabs : 0;
-}
-EXPORT_SYMBOL_GPL(swiotlb_nr_tbl);
-
unsigned int swiotlb_max_segment(void)
{
return io_tlb_default_mem ? max_segment : 0;
@@ -652,6 +646,7 @@ bool is_swiotlb_active(void)
{
return io_tlb_default_mem != NULL;
}
+EXPORT_SYMBOL_GPL(is_swiotlb_active);
#ifdef CONFIG_DEBUG_FS
--
2.30.1
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** | > + | **(Classic)** | **KVM** | **HW Dom** | **house** | > **dom0less**+-+---+ > + | | || | | Static > | Dynamic | > + > +===+===++===+=+=+===+ > + | Hypervisor able to launch multiple VMs during host boot > | > + > +---+---++---+-+-+---+ > + | | || Y | Y |Y > | Y | > + > +---+---++---+-+-+---+ > + | Hypervisor supports Static Partitioning > | > + > +---+---++---+-+-+---+ > + | | || Y | Y |Y > | | > + > +---+---++---+-+-+---+ > + | Able to launch VMs dynamically after host boot > | > + > +---+---++---+-+-+---+ > + | Y | Y | Y*| Y | Y*| > | Y | > + > +---+---++---+-+-+---+ > + | Supports strong isolation between all VMs started at host boot > | > + > +---+---++---+-+-+---+ > + | | || Y | Y |Y > | Y | > + > +---+---++---+-+-+---+ > + | Enables flexible sequencing of VM start during host boot > | > + > +---+---++---+-+-+---+ > + | | || | |Y > | Y | > + > +---+---++---+-+-+---+ > + | Prevent all-powerful static root domain being launched at boot > | > + > +---+---++---+-+-+---+ > + | | || | Y*|Y > | Y | > + > +---+---++---+-+-+---+ > + | Operates without a Highly-privileged management VM (eg. Dom0) > | > + > +---+---++---+-+-+---+ > + | | | Y*| | Y*|Y > | Y | > + > +---+---++---+-+-+---+ > + | Operates without a privileged toolstack VM (Control Domain) > | > + > +---+---++---+-+-+---+ > + | | || | Y*|Y > | | > + > +---+---++---+-+-+---+ > + | Extensible VM configuration applied before launch of VMs at host boot > | > + > +---+---++---+-+-+---+ > + | | || | |Y > | Y | > + > +---+---++---+-+-+---+ > + | Flexible granular assignment of permissions and functions to VMs > | > + > +---+---++---+-+-+---+ > + | | || | |Y > | Y | > + > +---+---++---+-+-+---+ > + | Supports extensible VM measurement architecture for DRTM and attestation > | > + > +---+---++---+-+-+---+ > + | | || | |Y > | Y | > + > +---+---++---+-+-+---+ > + | PCI passthrough configured at host boot > | > +
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 hang when using DRAKVUF
>
> Information from
> Dario Faggioli
> References
> https://lists.xen.org/archives/html/xen-devel/2020-05/msg01985.html
>
> https://lists.xenproject.org/archives/html/xen-devel/2020-10/msg01561.html
> https://bugzilla.opensuse.org/show_bug.cgi?id=1179246
>
So, this is mostly about the third issue, the one described in the
openSUSE bug, which was however also reported here, by different
people.
As I've just wrote there (on the bug), I've been working on trying to
reproduce the problem on a variety of different machines. Seems AMD
seemed to be the most impacted, I've lately focused on hardware from
such vendor.
I have been, however, unable to re-create a situation where the
symptoms described in the reports occur. I specifically looked for
hardware that was the same, or similar enough, and I replayed the dom0
vcpu pinning configuration and the creation of domUs, both PV and HVM,
but the problem did not show up for me. The only difference between
what I've done so far and what is described, e.g., in the bug is that
I've not been able to check Windows guests yet. (I'll try that as soon
as I can, but if this would really be a scheduling issue, which OS runs
in the guest should not really matter much, I think).
Code inspection for something that comes from and/or affects the
scheduler and is both:
- CPU-vendor specific, and
- guest-type specific
also led me pretty much nowhere.
I produced a debug patch (I attach two versions of it, one for staging
and one for v4.13.2) that should help me tell whether or not the
scheduler is being invoked every time it should be and whether or not
there are vcpus that manages to run for longer than how the scheduler
would want them to.
But as you can imagine, a debug patch is not really helpful if it can't
be used within the scenario it is meant to debug, i.e., without a
reproducer.
I did manage to find an actual bug in Credit2, but that's totally
unrelated to the problem at hand (and that will hence be discussed in
another email).
So, that's the status. I definitely was hoping for things to be better
at this point of the release cycle. Sorry they're not. And of course
I'll keep digging, but unless I find a way to reproduce, I don't expect
big breakthrough. :-/
> G. Null scheduler and vwfi native problem
>
> Information from
> Dario Faggioli
>
> References
>
> https://lists.xenproject.org/archives/html/xen-devel/2021-01/msg01634.html
>
> Quoting Dario:
> > RCU issues, but manifests due to scheduler behavior (especially
> > NULL scheduler, especially on ARM).
> >
> > Patches that should solve the issue for ARM posted already. They
> > will need to be slightly adjusted to cover x86 as well.
>
> As of last update from Dario 29.1.21:
> waiting for test report from submitter.
>
For this, I made progress toward making an actual patch that works for
both ARM and x86, but I've been sidetracked by a number of things, and
have not finished it.
The ARM-only fix has been tested successfully and would be ready
already. The full solution may not be ready in time for 4.15.
So, I'd say we can either merge the ARM part (ARM is where the issue
manifests most of the times and more severely) or wait for a full
solution during 4.16 development, which we will then backport.
Thanks and Regards
--
Dario Faggioli, Ph.D
http://about.me/dario.faggioli
Virtualization Software Engineer
SUSE Labs, SUSE https://www.suse.com/
---
<> (Raistlin Majere)
commit 278305aff03edd326382374d7757822a20d96c86
Author: Dario Faggioli
Date: Tue Mar 2 19:03:05 2021 +
Debug patch for suspect scheduler issues.
Signed-off-by: Dario Faggioli
diff --git a/tools/xentrace/xenalyze.c b/tools/xentrace/xenalyze.c
index b7f4e2bea8..8ce705bd48 100644
--- a/tools/xentrace/xenalyze.c
+++ b/tools/xentrace/xenalyze.c
@@ -7440,6 +7440,17 @@ void sched_process(struct pcpu_info *p)
/* TRC_SCHED_VERBOSE */
switch(ri->event)
{
+case TRC_SCHED_MAX_INTRV:
+if(opt.dump_all) {
+struct {
+unsigned int domid, vcpuid;
+unsigned int interv, time, last;
+} *r = (typeof(r))ri->d;
+
+printf(" %s sched_max_interv %u usecs, at %u usecs with d%uv%u (last: %u usecs)\n",
+ ri->dump_header, r->interv, r->time, r->domid, r->vcpuid, r->last);
+}
+break;
case TRC_SCHED_DOM_ADD:
if(opt.dump_all) {
struct {
@@ -7904,6 +7915,18 @@ void sched_process(struct pcpu_info *p)
ri->dump_header, r
[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-i386-xl-qemuu-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-intel 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-xsm7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt 7 xen-install fail REGR. vs. 152332 test-amd64-i386-examine 6 xen-install fail REGR. vs. 152332 test-amd64-coresched-i386-xl 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemut-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-xl-qemut-ws16-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-qemuu-rhel6hvm-amd 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-raw7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-pvshim 7 xen-install fail REGR. vs. 152332 test-amd64-i386-freebsd10-i386 7 xen-installfail REGR. vs. 152332 test-amd64-i386-xl-shadow 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-debianhvm-i386-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-ovmf-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-install fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 10 xen-install/src_host fail REGR. vs. 152332 test-amd64-i386-libvirt-pair 11 xen-install/dst_host fail REGR. vs. 152332 test-amd64-i386-xl-qemuu-win7-amd64 7 xen-install fail REGR. vs. 152332 test-amd64-amd64-amd64-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-i386-pvgrub 20 guest-stop fail REGR. vs. 152332 test-amd64-amd64-qemuu-freebsd11-amd64 21 guest-start/freebsd.repeat fail REGR. vs. 152332 test-arm64-arm64-examine 8 reboot fail REGR. vs. 152332 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 152332 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152332 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152332 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152332 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152332 test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-chec
[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's possible to populate into the p2m. This patch fixes the issue. Signed-off-by: Tamas K Lengyel --- xen/arch/x86/mm/mem_sharing.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/x86/mm/mem_sharing.c b/xen/arch/x86/mm/mem_sharing.c index 00ada05c10..98b14f7b0a 100644 --- a/xen/arch/x86/mm/mem_sharing.c +++ b/xen/arch/x86/mm/mem_sharing.c @@ -1761,6 +1761,7 @@ static int copy_settings(struct domain *cd, struct domain *d) return rc; copy_tsc(cd, d); +p2m_get_hostp2m(cd)->max_mapped_pfn = p2m_get_hostp2m(d)->max_mapped_pfn; return rc; } -- 2.25.1
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.
> >
> > Introduce a function on ARM to check the new Xen feature flags and also
> > to deal with the legacy case. Call the function xen_swiotlb_detect.
> >
> > Also rename the existing pci_xen_swiotlb_detect on x86 to
> > xen_swiotlb_detect so that we can share a common function declaration.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> >
> > This is the corresponding Xen patch under review:
> > https://marc.info/?l=xen-devel&m=161421618217686
> >
> > We don't *have to* make the x86 function and the ARM function exactly
> > the same, but I thought it would be much nicer if we did. However, we
> > can't really call it pci_* on ARM as there is no PCI necessarily.
>
>
> I would prefer to keep existing names for consistency on x86 side (but making
> that inconsistent with ARM, as you point out). But if you feel strongly
> about making the change you would have to have x86 maintainers agree to this
> (arch/x86/kernel/pci-swiotlb.c).
OK. And from an x86 point of view, it makes sense for it to be called
pci_xen_swiotlb_detect given that it is passed to IOMMU_INIT_FINISH in
arch/x86/kernel/pci-swiotlb.c.
So, I'll follow you suggestion, keep the x86 side named as it is today,
and provide a tiny wrapper so that we can still have an arch-neutral
xen_swiotlb_detect function (on x86 just calls pci_xen_swiotlb_detect.)
See below.
>From 5f6c91990df1e834c78501799905b04916105836 Mon Sep 17 00:00:00 2001
From: Stefano Stabellini
Date: Thu, 18 Mar 2021 16:17:21 -0700
Subject: [PATCH] xen/arm: introduce XENFEAT_direct_mapped and
XENFEAT_not_direct_mapped
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.
Introduce a function on ARM to check the new Xen feature flags and also
to deal with the legacy case. Call the function xen_swiotlb_detect.
Also implement xen_swiotlb_detect on x88 using the existing
pci_xen_swiotlb_detect() so that we can share a common function
declaration.
Signed-off-by: Stefano Stabellini
---
arch/arm/xen/mm.c | 14 +-
arch/arm64/mm/dma-mapping.c| 2 +-
arch/x86/include/asm/xen/swiotlb-xen.h | 4 ++--
arch/x86/xen/pci-swiotlb-xen.c | 7 ++-
include/xen/interface/features.h | 14 ++
include/xen/swiotlb-xen.h | 6 ++
6 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 467fa225c3d0..e1b12b242a32 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -135,10 +135,22 @@ void xen_destroy_contiguous_region(phys_addr_t pstart,
unsigned int order)
return;
}
+int xen_swiotlb_detect(void)
+{
+ if (!xen_domain())
+ return 0;
+ if (xen_feature(XENFEAT_direct_mapped))
+ return 1;
+ /* legacy case */
+ if (!xen_feature(XENFEAT_not_direct_mapped) && xen_initial_domain())
+ return 1;
+ return 0;
+}
+
static int __init xen_mm_init(void)
{
struct gnttab_cache_flush cflush;
- if (!xen_initial_domain())
+ if (!xen_swiotlb_detect())
return 0;
xen_swiotlb_init(1, false);
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 93e87b287556..4bf1dd3eb041 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -53,7 +53,7 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, u64
size,
iommu_setup_dma_ops(dev, dma_base, size);
#ifdef CONFIG_XEN
- if (xen_initial_domain())
+ if (xen_swiotlb_detect())
dev->dma_ops = &xen_swiotlb_dma_ops;
#endif
}
diff --git a/arch/x86/include/asm/xen/swiotlb-xen.h
b/arch/x86/include/asm/xen/swiotlb-xen.h
index 6b56d0d45d15..66d576486509 100644
--- a/arch/x86/include/asm/xen/swiotlb-xen.h
+++ b/arch/x86/include/asm/xen/swiotlb-xen.h
@@ -4,12 +4,12 @@
#ifdef CONFIG_SWIOTLB_XEN
extern int xen_swiotlb;
-extern int __init pci_xen_swiotlb_detect(void);
+extern int pci_xen_swiotlb_detect(void);
extern void __init pci_xen_swiotlb_init(void);
extern int pci_xen_swiotlb_init_late(void);
#else
#define xen_swiotlb (0)
-static inline int __init pci_xen_swiotlb_detect(void) { return 0; }
+static inline int pci_xen_swiotlb_detect(void) { return 0; }
static inline void __init pci_xen_swiotlb_init(void) { }
static inline int pci_xen_swiotlb_init_late(void) { return -ENXIO; }
#endif
diff --git a/arch/x86/xen/pci-swiotlb-xen.c b/arch/x86/xen/pci-swiotlb-xen.c
index 19ae3e4fe4e9..0555f68a773f 100644
--- a/arch/x86/xen/pci-swiotlb-xen.c
+++ b/arch/x86/xen/pci-swiotlb-xen.c
@@ -26,7 +26,7 @@ in
[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 run: test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail REGR. vs. 152631 test-amd64-amd64-xl-qcow2 21 guest-start/debian.repeat fail REGR. vs. 152631 test-armhf-armhf-xl-vhd 17 guest-start/debian.repeat fail REGR. vs. 152631 Tests which are failing intermittently (not blocking): test-arm64-arm64-xl-thunderx 12 debian-install fail pass in 160133-retest Tests which did not succeed, but are not blocking: test-arm64-arm64-xl-thunderx 15 migrate-support-check fail in 160133 never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-check fail in 160133 never pass test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 152631 test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 152631 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 152631 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 152631 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 152631 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 152631 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 152631 test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: qemuub12498fc575f2ad30f09fe78badc7fef526e2d76 baseline version: qemuu1d806cef0e38b5db8347a8e12f214d543204a314 Last test of basis 152631 2020-08-20 09:07:46 Z 210 days Failing since152659 2020-08-21 14:07:39 Z 209 days 406 attempts Testing same since 160125 2021-03-18 12:43:06 Z0 days1 attempts 457 people touched rev
[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): test-amd64-amd64-libvirt-vhd 19 guest-start/debian.repeat fail pass in 160136-retest Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 159840 test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 159840 test-armhf-armhf-libvirt-raw 15 saverestore-support-checkfail like 159840 test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 159840 test-amd64-amd64-qemuu-nested-amd 20 debian-hvm-install/l1/l2 fail like 159840 test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 159840 test-amd64-amd64-xl-qemut-ws16-amd64 19 guest-stopfail like 159840 test-amd64-i386-xl-qemut-win7-amd64 19 guest-stop fail like 159840 test-amd64-i386-xl-qemut-ws16-amd64 19 guest-stop fail like 159840 test-amd64-i386-xl-qemuu-ws16-amd64 19 guest-stop fail like 159840 test-amd64-amd64-xl-qemuu-ws16-amd64 19 guest-stopfail like 159840 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-i386-xl-pvshim14 guest-start fail never pass test-arm64-arm64-xl-seattle 15 migrate-support-checkfail never pass test-arm64-arm64-xl-seattle 16 saverestore-support-checkfail never pass test-amd64-i386-libvirt 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 15 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 15 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl 15 migrate-support-checkfail never pass test-arm64-arm64-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit1 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit1 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit1 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 15 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-xl-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-thunderx 15 migrate-support-checkfail never pass test-arm64-arm64-xl-thunderx 16 saverestore-support-checkfail never pass test-arm64-arm64-libvirt-xsm 15 migrate-support-checkfail never pass test-arm64-arm64-libvirt-xsm 16 saverestore-support-checkfail never pass test-arm64-arm64-xl-credit2 15 migrate-support-checkfail never pass test-arm64-arm64-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 15 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 16 saverestore-support-checkfail never pass test-armhf-armhf-libvirt-raw 14 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 15 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 15 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 16 saverestore-support-checkfail never pass test-armhf-armhf-xl 15 migrate-support-checkfail never pass test-armhf-armhf-xl 16 saverestore-support-checkfail never pass test-armhf-armhf-xl-vhd 14 migrate-support-checkfail never pass test-armhf-armhf-xl-vhd 15 saverestore-support-checkfail never pass version targeted for testing: xen b0d7739f10dc93d9565220b4e79ebc6675548c02 baseline version: xen a1dab05393ec5654e2a88be296cc973595ffb1d0 Last test of basis 159840 2021-03-05 15:07:16 Z 13 days Testing same since 160127 2021-03-18 14:06:28 Z0 days1 attempts People who touched revisions under test: Andrew Cooper Anthony PERARD Dari
