All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: [GIT PULL] pv/pcifront-2.6.32
Date: Tue, 02 Mar 2010 12:12:23 -0800	[thread overview]
Message-ID: <4B8D7127.5070907@goop.org> (raw)
In-Reply-To: <20100302031217.GB881@phenom.dumpdata.com>

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?

(BTW, do you use git rerere?  It remembers the results of previous merge 
resolutions and will apply them again if you re-merge.)

> 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?

(BTW, it looks like its change 979e121cb348add17ed8171bf447b27a3a9d1be3 
in your tree; I don't have 5a7357bdb10b40414d97d7582f5467e4a709bd07 in 
my repo at all).

Thanks,
     J

  parent reply	other threads:[~2010-03-02 20:12 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-02  3:12 [GIT PULL] pv/pcifront-2.6.32 Konrad Rzeszutek Wilk
2010-03-02  9:21 ` Ian Campbell
2010-03-02 13:55   ` Konrad Rzeszutek Wilk
2010-03-02 14:45     ` Ian Campbell
2010-03-02 14:15 ` Konrad Rzeszutek Wilk
2010-03-02 20:12 ` Jeremy Fitzhardinge [this message]
2010-03-02 21:54   ` Konrad Rzeszutek Wilk
2010-03-02 22:20     ` Konrad Rzeszutek Wilk
2010-03-02 23:13       ` Jeremy Fitzhardinge
2010-03-02 22:47     ` Jeremy Fitzhardinge
2010-03-03 14:22       ` Konrad Rzeszutek Wilk

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=4B8D7127.5070907@goop.org \
    --to=jeremy@goop.org \
    --cc=konrad.wilk@oracle.com \
    --cc=xen-devel@lists.xensource.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.