From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752267AbdBBRFv (ORCPT <rfc822;w@1wt.eu>);
        Thu, 2 Feb 2017 12:05:51 -0500
Received: from smtp.eu.citrix.com ([185.25.65.24]:4321 "EHLO
        SMTP.EU.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752238AbdBBRFt (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 2 Feb 2017 12:05:49 -0500
X-IronPort-AV: E=Sophos;i="5.33,325,1477958400"; 
   d="scan'208";a="40005485"
Date: Thu, 2 Feb 2017 16:40:55 +0000
From: Roger Pau =?iso-8859-1?Q?Monn=E9?= <roger.pau@citrix.com>
To: Boris Ostrovsky <boris.ostrovsky@oracle.com>
CC: <JGross@suse.com>, <xen-devel@lists.xenproject.org>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 5/9] xen/pvh: Prevent PVH guests from using PIC, RTC
 and IOAPIC
Message-ID: <20170202164055.2nx7ypqw7esu3pzt@dhcp-3-221.uk.xensource.com>
References: <1485459692-23961-1-git-send-email-boris.ostrovsky@oracle.com>
 <1485459692-23961-6-git-send-email-boris.ostrovsky@oracle.com>
 <20170202153515.a3hznbofx4u4b3az@dhcp-3-221.uk.xensource.com>
 <bcfdb3bc-e7df-9b1d-2066-1ff89b5e4620@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <bcfdb3bc-e7df-9b1d-2066-1ff89b5e4620@oracle.com>
User-Agent: NeoMutt/20170128 (1.7.2)
X-ClientProxiedBy: AMSPEX02CAS01.citrite.net (10.69.22.112) To
 AMSPEX02CL02.citrite.net (10.69.22.126)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Feb 02, 2017 at 11:30:19AM -0500, Boris Ostrovsky wrote:
> On 02/02/2017 10:35 AM, Roger Pau Monné wrote:
> > On Thu, Jan 26, 2017 at 02:41:28PM -0500, Boris Ostrovsky wrote:
> >> Make sure they don't use these devices since they are not emulated
> >> for unprivileged PVH guest.
> > This description seems weird for what it's actually done. AFAICT you are not
> > really preventing the guest from using the PIC or the IO APIC, because this is
> > fetched from the MADT table (or should be fetched from there in any case).
> 
> This was meant to say that we don't want to use ACPI_IRQ_MODEL_[IOA]PIC
> since we don't support SCI (which is expected on x86 to be one of the two).

Hm, right. At some point (ie: when PCI-passthrough is implemented) we will be
providing an IO APIC and a SCI through it. Or would we rather always use the
event channel SCI?

Roger.