Re: Re: [GIT PULL] pv/pcifront-2.6.32

[Jeremy Fitzhardinge <jeremy@goop.org>]

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