From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: Re: [GIT PULL] pv/pcifront-2.6.32 Date: Tue, 02 Mar 2010 14:47:09 -0800 Message-ID: <4B8D956D.9030406@goop.org> References: <20100302031217.GB881@phenom.dumpdata.com> <4B8D7127.5070907@goop.org> <20100302215432.GA29262@phenom.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20100302215432.GA29262@phenom.dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.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