lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 14 Apr 2016 08:45:19 -0400 From: Boris Ostrovsky <boris.ostrovsky@...cle.com> To: Stefano Stabellini <sstabellini@...nel.org> Cc: Vitaly Kuznetsov <vkuznets@...hat.com>, x86@...nel.org, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>, Jiang Liu <jiang.liu@...ux.intel.com>, "K. Y. Srinivasan" <kys@...rosoft.com>, linux-kernel@...r.kernel.org, konrad.wilk@...cle.com, david.vrabel@...rix.com, jgross@...e.com, "Luis R. Rodriguez" <mcgrof@...nel.org> Subject: Re: Xen regression, Was: [PATCH] x86/irq: Probe for PIC presence before allocating descs for legacy IRQs On 04/13/2016 06:38 PM, Stefano Stabellini wrote: > > On Wed, 13 Apr 2016, Boris Ostrovsky wrote: > >> On 04/13/2016 01:36 PM, Boris Ostrovsky wrote: >>> On 04/12/2016 09:27 PM, Boris Ostrovsky wrote: >>>> On 04/12/2016 07:15 PM, Stefano Stabellini wrote: >>>>> On Tue, 12 Apr 2016, Boris Ostrovsky wrote: >>>>>> On 04/12/2016 05:56 PM, Stefano Stabellini wrote: >>>>>>> I am not sure, maybe you didn't have CONFIG_SPARSE_IRQ? >>>>>>> But I am certain that 4.6-rc2, with the attached config, fails as >>>>>>> Dom0 >>>>>>> on QEMU with the following sequence of calls: >>>>>> I did have CONFIG_SPARSE_IRQ and I just rebuilt 4.5.0 with your config >>>>>> (4.6-rc3 doesn't build for me for some reason) and that booted dom0 as >>>>>> well. >>>>>> >>>>>> BTW, what do you mean by "dom0 on QEMU"? >>>>> I am running Xen and Linux inside a QEMU x86_64 emulated machine >>>>> (nested >>>>> virt). >>>> This I, of course, never tried. >>>> >>>> But given that things work in a single-level virt, doesn't this imply that >>>> perhaps there is something in the emulation that's not quite right? >>> OK, so this *is* broken on single level virt as well. It's just that we >>> always end up using AHCI so lack of irq 14 (and 15) does not affect the >>> system. And I guess in QEMU case it's IDE only, right? >>> >>> You patch does fix this but I wonder if we could change something in >>> probe_8259A() so that we can continue using nr_legacy_irqs(). Using >>> nr_legacy_irqs() and NR_IRQS_LEGACY at the same time is inconsistent and may >>> cause us headaches in the future. >>> >> I think we could use paravirt_has() feature that was added for similar reason >> when we had a problem with RTC (commit >> d8c98a1d1488747625ad6044d423406e17e99b7a). So we add paravirt_has(PIC) which >> will only be set by dom0 and then probe_8259A() will not set legacy_pic to >> null_legacy_pic when this flag is set. > Maybe we could introduce a legacy_pic_xen in arch/x86/kernel/i8259.c or > arch/x86/xen/enlighten.c? We could set legacy_pic = legacy_pic_xen from > start_kernel, so that we can skip probe_8259A completely. Something like legacy_pic_xen = null_legacy_pic; legacy_pic_xen.nr_legacy_irqs = NR_IRQS_LEGACY; legacy_pic = legacy_pic_xen; ? > > >> Note that paravirt_has() is being removed by >> http://lists.xenproject.org/archives/html/xen-devel/2016-04/msg01415.html so >> presumably we'd use new struct x86_legacy_features instead (copying Luis so >> that if this is acceptable he could add it to his next spin). > I would prefer to come up with a fix that is backportable to 4.3, 4.4 > and 4.5. I think once the series above makes it to mainline x86_legacy_features would be the way to go --- that's what it is created for. Given that we are almost at rc4 I assume that would be 4.7. Using paravirt_has() now will create merge headaches so it's probably not a good idea. We can either use your original patch or do what you suggested with legacy_pic_xen (both of which are backportable) and then switch to x86_legacy_features once it shows up in the tree. -boris
Powered by blists - more mailing lists