All of lore.kernel.org
 help / color / mirror / Atom feed
From: "H. Peter Anvin" <hpa@zytor.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: the arch/x86 maintainers <x86@kernel.org>,
	"Xen-devel@lists.xensource.com" <Xen-devel@lists.xensource.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Subject: Re: [PATCH] x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on VM_IO vmas
Date: Thu, 21 Oct 2010 17:45:44 -0700	[thread overview]
Message-ID: <4CC0DEB8.1060309@zytor.com> (raw)
In-Reply-To: <4CC0CA07.3000306@goop.org>

On 10/21/2010 04:17 PM, Jeremy Fitzhardinge wrote:
> 
> Xen PV guests are always responsible for constructing ptes with machine
> addresses in them (ie, doing their own pseudo-physical to machine
> address conversion), and Xen verifies that the pages they want to map
> either belong to them or have been granted to them.  The _PAGE_IOMAP
> flag is a kernel-internal one which allows us to distinguish between
> ptes intended to map memory vs machine hardware addresses; it is not
> part of the Xen ABI.
> 
> If you're passing a device through to a domain, the domain is given
> access to the device's address space so it can legally map those pages
> (and if an IOMMU is available, the device is constrained to only DMA
> that domain's memory).
> 

Okay, could you clarify this part a bit?  Why does the kernel need to
know the difference between "pseudo-physical" and "machine addresses" at
all?  If they overlap, there is a problem, and if they don't overlap, it
will be a 1:1 mapping anyway...

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.


  reply	other threads:[~2010-10-22  0:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-21 22:40 [PATCH] x86: define arch_vm_get_page_prot to set _PAGE_IOMAP on VM_IO vmas Jeremy Fitzhardinge
2010-10-21 22:47 ` H. Peter Anvin
2010-10-21 23:17   ` Jeremy Fitzhardinge
2010-10-22  0:45     ` H. Peter Anvin [this message]
2010-10-22 15:08       ` Konrad Rzeszutek Wilk
2010-10-22 16:44         ` H. Peter Anvin
2010-10-22 18:02           ` Konrad Rzeszutek Wilk
2010-10-22 18:05             ` Konrad Rzeszutek Wilk
2010-10-22 19:06             ` H. Peter Anvin
2010-10-22 19:11               ` [Xen-devel] " Konrad Rzeszutek Wilk
2010-10-22 19:06           ` Jeremy Fitzhardinge
2010-10-22 19:20             ` H. Peter Anvin
2010-10-22 19:36               ` Jeremy Fitzhardinge

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=4CC0DEB8.1060309@zytor.com \
    --to=hpa@zytor.com \
    --cc=Xen-devel@lists.xensource.com \
    --cc=jeremy@goop.org \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /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.