From mboxrd@z Thu Jan  1 00:00:00 1970
From: George Dunlap <George.Dunlap@eu.citrix.com>
Subject: Re: [v7][PATCH 06/16] hvmloader/pci: skip reserved
	ranges
Date: Wed, 15 Jul 2015 14:56:16 +0100
Message-ID: <CAFLBxZZ_-AOgkijz7rA7wWvO8b1nmdfZxwqmTj_8XwftSz5uwg@mail.gmail.com>
References: <1436420047-25356-1-git-send-email-tiejun.chen@intel.com>
	<1436420047-25356-7-git-send-email-tiejun.chen@intel.com>
	<55A3D5600200007800090330@mail.emea.novell.com>
	<55A4AE88.2000200@intel.com>
	<55A4F2270200007800090834@mail.emea.novell.com>
	<55A4EA54.60708@intel.com>
	<55A5138F0200007800090A71@mail.emea.novell.com>
	<55A5AF6F.1050305@intel.com> <55A5E122.7030203@intel.com>
	<55A6374E02000078000911EC@mail.emea.novell.com>
	<55A6210E.8080406@intel.com>
	<55A64386020000780009132E@mail.emea.novell.com>
	<55A6374F.6030901@intel.com>
	<55A65F620200007800091472@mail.emea.novell.com>
	<55A6454D.2000201@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <55A6454D.2000201@intel.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: "Chen, Tiejun" <tiejun.chen@intel.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Ian Campbell <ian.campbell@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Ian Jackson <ian.jackson@eu.citrix.com>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>, Keir Fraser <keir@xen.org>
List-Id: xen-devel@lists.xenproject.org

On Wed, Jul 15, 2015 at 12:34 PM, Chen, Tiejun <tiejun.chen@intel.com> wrote:
>>> Maybe I  can move this chunk of codes downward those actual allocation
>>> to check if RDM conflicts with the final allocation, and then just
>>> disable those associated devices by writing PCI_COMMAND without BUG()
>>> like this draft code,
>>
>>
>> And what would keep the guest from re-enabling the device?
>>
>
> We can't but IMO,
>
> #1. We're already posting that warning messages.
>
> #2. Actually this is like this sort of case like, as you known, even in the
> native platform, some broken devices are also disabled by BIOS, right? So I
> think this is OS's responsibility or risk to force enabling such a broken
> device.
>
> #3. Its really rare possibility in real world.

Well the real question is if the guest re-enabling the device would
cause a security problem; I think the answer to that must be "no" (or
at least, "it's not any worse than it was before").

The guest OS has the device disabled, and the RMRRs in the e820 map;
if it re-enables the device over the "BIOS" (which hvmloader sort of
acts as), then it should know what it's doing.

Would it be possible, on a collision, to have one last "stab" at
allocating the BAR somewhere else, without relocating memory (or
relocating any other BARs)?  At very least then an administrator could
work around this kind of thing by setting the mmio_hole larger in the
domain config.

 -George