From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
Christoph Egger <christoph.egger@amd.com>,
"Keir (Xen.org)" <keir@xen.org>,
Eddie Dong <eddie.dong@intel.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Wei Wang <wei.wang2@amd.com>,
"xiantao.zhang@intel.com" <xiantao.zhang@intel.com>
Subject: Re: Other PCI devices to mark mark as read-only for dom0
Date: Fri, 22 Jun 2012 13:27:23 +0100 [thread overview]
Message-ID: <4FE464AB.2070402@citrix.com> (raw)
In-Reply-To: <4FE47368020000780008B60F@nat28.tlf.novell.com>
On 22/06/12 12:30, Jan Beulich wrote:
>> It is certainly not an easy problem, and perhaps I am needlessly
>> complicating the issue.
>>
>> It occurs that we have 3 possible directions to fix this issue.
>>
>> 1) Continue the current method of fixing things up after they break,
>> which can cause a hassle for a user encountering the issue.
>> 2) Mark as RO and provide an explicit hypercall interface to remap
>> BARs. I don't know how well this would go with upstream Linux.
> And what would the hypercall do? You don't expect it to fix up
> all the uses of the old address(es) to now use the new one(s),
> do you? Leaving aside the difficulty in getting this right, in some
> cases this might not even be possible in a seamless manner.
>
>> 3) Extend current infrastructure to be able to tell when a write is
>> affecting the BARs and permit them. This seems like the best option
>> going forward, but might be quite hard to implement.
> Doing the mechanical trap-and-emulate part of this shouldn't
> be that hard, namely on top of that other patch I'm about to
> commit.
>
> But the thing is that this has the same problems as the hypercall
> one above.
Currently my understanding is that dom0 has fairly free reign on the PCI
devices, meaning that if it decides to remap BARs and ends up with
conflicts, we already have a problem, especially if its a PCI device
that Xen is trying to use.
As Xen avoids using PCI devices as much as possible, it should be easier
(but doubtfully 'easy') to make Xen aware that PCI devices it is using
may move from under its feet. ( I am just throwing ideas out here - it
might be that this is a stupid idea. )
>
>> I guess the real question is whether we should continue reactively
>> fixing problems, or start protectively fixing the root cause.
> I agree with this position from a theoretical standpoint.
>
>> My gut
>> feeling is that we are going to start seeing more and more devices on
>> the PCI bus which Xen should be using, rather than dom0.
> That would be bad - surfacing arbitrary devices on the PCI bus
> is - in my opinion - rather questionable a design (which is also
> why I consider this aspect of the AMD IOMMUs badly designed).
>
> Jan
Agreed, but we now have a problem and need a solution.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
--
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com
prev parent reply other threads:[~2012-06-22 12:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-22 9:04 Other PCI devices to mark mark as read-only for dom0 Andrew Cooper
2012-06-22 9:24 ` Sander Eikelenboom
2012-06-22 10:11 ` Andrew Cooper
2012-06-22 9:43 ` Jan Beulich
2012-06-22 10:08 ` Andrew Cooper
2012-06-22 11:23 ` Jan Beulich
2012-06-22 12:06 ` Andrew Cooper
2012-06-22 12:20 ` Jan Beulich
2012-06-22 12:30 ` Andrew Cooper
2012-06-22 11:30 ` Jan Beulich
2012-06-22 12:27 ` Andrew Cooper [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FE464AB.2070402@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=andre.przywara@amd.com \
--cc=christoph.egger@amd.com \
--cc=eddie.dong@intel.com \
--cc=keir@xen.org \
--cc=wei.wang2@amd.com \
--cc=xen-devel@lists.xen.org \
--cc=xiantao.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.