diff mbox

[RFC,2/4] x86/dom0: prevent PVH Dom0 from mapping read-only the IO APIC area

Message ID 20170424115201.96963-3-roger.pau@citrix.com (mailing list archive)
State New, archived
Headers show

Commit Message

Roger Pau Monné April 24, 2017, 11:51 a.m. UTC
This is emulated by Xen and must not be mapped into PVH Dom0 p2m.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
---
 xen/arch/x86/dom0_build.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Jan Beulich June 30, 2017, 11:31 a.m. UTC | #1
>>> Roger Pau Monne <roger.pau@citrix.com> 04/24/17 1:52 PM >>>
>This is emulated by Xen and must not be mapped into PVH Dom0 p2m.

Yes, but this reminds of of the reason we permit the r/o mapping in PV
Dom0, and I wonder how well the emulated variant is going to work with
ACPI methods accessing the IO-APICs. Let's hope there's not going to
be any problems.

Jan
Roger Pau Monné June 30, 2017, 3:34 p.m. UTC | #2
On Fri, Jun 30, 2017 at 05:31:36AM -0600, Jan Beulich wrote:
> >>> Roger Pau Monne <roger.pau@citrix.com> 04/24/17 1:52 PM >>>
> >This is emulated by Xen and must not be mapped into PVH Dom0 p2m.
> 
> Yes, but this reminds of of the reason we permit the r/o mapping in PV
> Dom0, and I wonder how well the emulated variant is going to work with
> ACPI methods accessing the IO-APICs. Let's hope there's not going to
> be any problems.

Won't ACPI be satisfied by accessing the emulated vIO APIC? That's
available, and should reflect the real IO APIC state in most cases
(except for GSIs in use by Xen).

Roger.
Jan Beulich July 3, 2017, 7:07 a.m. UTC | #3
>>> On 30.06.17 at 17:34, <roger.pau@citrix.com> wrote:
> On Fri, Jun 30, 2017 at 05:31:36AM -0600, Jan Beulich wrote:
>> >>> Roger Pau Monne <roger.pau@citrix.com> 04/24/17 1:52 PM >>>
>> >This is emulated by Xen and must not be mapped into PVH Dom0 p2m.
>> 
>> Yes, but this reminds of of the reason we permit the r/o mapping in PV
>> Dom0, and I wonder how well the emulated variant is going to work with
>> ACPI methods accessing the IO-APICs. Let's hope there's not going to
>> be any problems.
> 
> Won't ACPI be satisfied by accessing the emulated vIO APIC? That's
> available, and should reflect the real IO APIC state in most cases
> (except for GSIs in use by Xen).

This "most cases" is what I'm not sufficiently happy with; hence the
"let's hope ...".

Jan
diff mbox

Patch

diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 481a899afe..be3ba33a16 100644
--- a/xen/arch/x86/dom0_build.c
+++ b/xen/arch/x86/dom0_build.c
@@ -416,7 +416,7 @@  int __init dom0_setup_permissions(struct domain *d)
     for ( i = 0; i < nr_ioapics; i++ )
     {
         mfn = paddr_to_pfn(mp_ioapics[i].mpc_apicaddr);
-        if ( !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
+        if ( dom0_pvh || !rangeset_contains_singleton(mmio_ro_ranges, mfn) )
             rc |= iomem_deny_access(d, mfn, mfn);
     }
     /* MSI range. */