From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934196AbcJZQFJ convert rfc822-to-8bit (ORCPT ); Wed, 26 Oct 2016 12:05:09 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:19086 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933666AbcJZQFD (ORCPT ); Wed, 26 Oct 2016 12:05:03 -0400 Subject: Re: [PATCH 5/8] xen/pvh: Prevent PVH guests from using PIC, RTC and IOAPIC To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= References: <1476468318-24422-1-git-send-email-boris.ostrovsky@oracle.com> <1476468318-24422-6-git-send-email-boris.ostrovsky@oracle.com> <20161026104205.vjemyddm6bus3kem@mac> <16d3a435-25c2-33b6-27a8-713dd9e54b7e@oracle.com> <20161026151825.zqt4fpirqurllsii@mac> Cc: david.vrabel@citrix.com, JGross@suse.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org From: Boris Ostrovsky Message-ID: <6ab88e87-0c3e-32c7-d3f3-d6c859cc477c@oracle.com> Date: Wed, 26 Oct 2016 12:06:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161026151825.zqt4fpirqurllsii@mac> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8BIT X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/26/2016 11:18 AM, Roger Pau Monné wrote: > On Wed, Oct 26, 2016 at 10:50:21AM -0400, Boris Ostrovsky wrote: >> On 10/26/2016 06:42 AM, Roger Pau Monné wrote: >>> On Fri, Oct 14, 2016 at 02:05:15PM -0400, Boris Ostrovsky wrote: >>>> Make sure they don't use these devices since they are not emulated >>>> for unprivileged PVH guest. >>>> >>>> Also don't initialize hypercall page for them in init_hvm_pv_info() >>>> since this has already been done. >>>> >>>> Signed-off-by: Boris Ostrovsky >>>> --- >>>> arch/x86/xen/enlighten.c | 24 +++++++++++++++++------- >>>> 1 file changed, 17 insertions(+), 7 deletions(-) >>>> >>>> diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c >>>> index d38d568..6c1a330 100644 >>>> --- a/arch/x86/xen/enlighten.c >>>> +++ b/arch/x86/xen/enlighten.c >>>> @@ -1803,10 +1803,21 @@ static void __init init_hvm_pv_info(void) >>>> minor = eax & 0xffff; >>>> printk(KERN_INFO "Xen version %d.%d.\n", major, minor); >>>> >>>> - cpuid(base + 2, &pages, &msr, &ecx, &edx); >>>> + xen_domain_type = XEN_HVM_DOMAIN; >>>> >>>> - pfn = __pa(hypercall_page); >>>> - wrmsr_safe(msr, (u32)pfn, (u32)(pfn >> 32)); >>>> + /* PVH set up hypercall page earlier in xen_prepare_pvh() */ >>>> + if (xen_pvh_domain()) { >>>> + pv_info.name = "Xen PVH"; >>>> +#ifdef CONFIG_ACPI >>>> + /* No PIC or IOAPIC */ >>> Shouldn't this be fetched from the MADT ACPI table if ACPI is available >>> (rsdp_paddr != 0 in start_info)? >> >> At this point we haven't parsed ACPI yet (with or without rsdp_paddr, >> which we don't set anyway for domU) so we don't know whether we have PIC >> or IOAPIC. > I guess I'm missing something, but if we are providing ACPI tables to a PVH > DomU rsdp_paddr should be set, or else we are failing to comply with our own > start info specification. acpi_find_root_pointer() searches low MB of memory for the RSDP signature. This is standard ACPICA's method of finding it, I'd think that FreeBSD does the same thing. And that's how a non-UEFI system is expected to find it as required by the ACPI spec ("Root System Description Pointer (RSDP)" section) RSDP structure is placed at RSDP_ADDRESS (which is just under 1MB at 0xfffc0) by libxl__dom_load_acpi(). > >> Having said that, I will probably remove this ("acpi_irq_model = >> ACPI_IRQ_MODEL_PLATFORM", together with the comment) since I am working >> on adding SCI support via an event channel and ACPI_IRQ_MODEL_PIC model, >> which is default, seems to work OK. > Hm, right, that might be an option. I'd actually prefer not to use ACPI_IRQ_MODEL_PIC since it implies that we have a PIC (which we don't). It just so happens that using it in Linux works for PVH as well. > Do you know how hardware-reduced ACPI > implementations (which IIRC also don't have a SCI interrupt) deliver events > to the OS? Or it's simply not possible in that case? I believe you need _AEI object for that. At least that's what section "4.1.1.1 GPIO-Signaled Events" suggests. -boris