| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: [GIT PULL] pv/pcifront-2.6.32
On 03/02/2010 01:54 PM, Konrad Rzeszutek Wilk wrote:
On Tue, Mar 02, 2010 at 12:12:23PM -0800, Jeremy Fitzhardinge wrote:
On 03/01/2010 07:12 PM, Konrad Rzeszutek Wilk wrote:
Hey Jeremy,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git pv/pcifront-2.6.32
It is a back-port of the Xen PCI front driver (not the SR-IOV one, just
old plain one). It has been tested with a bare 2.6.32 tree
(pv/master.2.6.32) and with xen/next
The merge of this is a bit hairy, so I did my own which is available in
the pv/xen.next.merge (which is basically xen/next + pv/pcifront-2.6.32
+ pv/fbfbront + xen: Allow unprivileged Xen domains to create iomap
pages).
I did a separate merge of the fbfront branch. Can you do another merge
with just the pcifront stuff?
Done: pv/merge.xen.next
(BTW, do you use git rerere? It remembers the results of previous merge
resolutions and will apply them again if you re-merge.)
Oooh goodies. Will start using it.
To make the PCI front driver work, another patch has to be put added in
the xen/next (or better yet in the swiotlb - but it really does not seem
to fit there), which is the "xen: Allow unprivileged Xen domains to
create iomap pages" (5a7357bdb10b40414d97d7582f5467e4a709bd07)
Do we really need that patch any more? The comment doesn't seem to bear
any relationship to its contents any more; it talks about disallowing
ISA mappings, but all it does it mask write-through/uncachable from PTEs
for non-privileged domains, and I'm not sure that's even desirable. I
think Xen will mask those flags from the PTE if the domain isn't allowed
to touch the device, and we want to be able to let passthrough mappings
to be uncached or writethrough.
Do things break without it?
I needed it for v2.6.32 + jeremy/xen/dom0/konrad-swiotlb-2.6.32 +
konrad/pv/pcifront-2.6.32. Otherwise I would get this:
OK, so I guess Xen does complain if you try to set UC/WT ptes but are
non-privileged. But still, with that patch in place, it means that even
a passthrough hardware mapping may lack UC/WT. Perhaps that doesn't
matter? I bet it will when we get around to fixing up PAT.
_But_, with xen/next + pv/pcifront there was no need for it.
That change is already present.
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home