All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Durrant, Paul" <pdurrant@amazon.co.uk>
To: "Roger Pau Monné" <roger.pau@citrix.com>,
	"Jason Andryuk" <jandryuk@gmail.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	"marmarek@invisiblethingslab.com"
	<marmarek@invisiblethingslab.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Simon Gaiser <simon@invisiblethingslab.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: RE: [Xen-devel] [PATCH 6/6] xen-pt: Round pci regions sizes to XEN_PAGE_SIZE
Date: Wed, 15 Jan 2020 08:33:02 +0000	[thread overview]
Message-ID: <ed1ca41d72bd49c59e5e25044a0a85e0@EX13D32EUC003.ant.amazon.com> (raw)
In-Reply-To: <20200114180457.GG11756@Air-de-Roger>

> -----Original Message-----
> 
> > Linux PCI subsytem has an option resource_alignment that can be
> > applied to either a single device or all devices.  Booting with
> > pci=resource_aligment=4096 will align each device to a page.  Do you
> > think pciback should force resource_alignment=4096 for dom0?
>

That sounds like a good idea.
 
> Ideally Xen should keep track of the BARs position and size and refuse
> to passthrough devices that have BARs sharing a page with other
> devices BARs.
> 
> > Are
> > there other MMIO ranges to be concerned about adjacent to BARs?
> 
> IIRC you can have two BARs of different devices in the same 4K page,
> BARs are only aligned to it's size, so BARs smaller than 4K are not
> required to be page aligned.

If we had a notion of assignment groups for this, as well as devices sharing requester id, then Xen would not need to refuse pass-through, it would just require that all devices sharing the page were passed through as a unit.

  Paul


WARNING: multiple messages have this Message-ID (diff)
From: "Durrant, Paul" <pdurrant@amazon.co.uk>
To: "Roger Pau Monné" <roger.pau@citrix.com>,
	"Jason Andryuk" <jandryuk@gmail.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	"marmarek@invisiblethingslab.com"
	<marmarek@invisiblethingslab.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Simon Gaiser <simon@invisiblethingslab.com>,
	Anthony Perard <anthony.perard@citrix.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: [Xen-devel] [PATCH 6/6] xen-pt: Round pci regions sizes to XEN_PAGE_SIZE
Date: Wed, 15 Jan 2020 08:33:02 +0000	[thread overview]
Message-ID: <ed1ca41d72bd49c59e5e25044a0a85e0@EX13D32EUC003.ant.amazon.com> (raw)
In-Reply-To: <20200114180457.GG11756@Air-de-Roger>

> -----Original Message-----
> 
> > Linux PCI subsytem has an option resource_alignment that can be
> > applied to either a single device or all devices.  Booting with
> > pci=resource_aligment=4096 will align each device to a page.  Do you
> > think pciback should force resource_alignment=4096 for dom0?
>

That sounds like a good idea.
 
> Ideally Xen should keep track of the BARs position and size and refuse
> to passthrough devices that have BARs sharing a page with other
> devices BARs.
> 
> > Are
> > there other MMIO ranges to be concerned about adjacent to BARs?
> 
> IIRC you can have two BARs of different devices in the same 4K page,
> BARs are only aligned to it's size, so BARs smaller than 4K are not
> required to be page aligned.

If we had a notion of assignment groups for this, as well as devices sharing requester id, then Xen would not need to refuse pass-through, it would just require that all devices sharing the page were passed through as a unit.

  Paul

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2020-01-15 13:24 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-11 18:02 [Qemu-devel] [PATCH 0/6] Xen stubdom support Jason Andryuk
2019-03-11 18:02 ` Jason Andryuk
2019-03-11 18:02 ` [Qemu-devel] [PATCH 1/6] xen: Introduce -xen-stubdom option Jason Andryuk
2019-03-11 18:02   ` Jason Andryuk
2019-03-11 18:06   ` [Qemu-devel] " Paolo Bonzini
2019-03-11 18:06     ` Paolo Bonzini
2019-03-11 19:46     ` [Qemu-devel] " Jason Andryuk
2019-03-11 19:46       ` Jason Andryuk
2019-03-11 18:02 ` [Qemu-devel] [PATCH 2/6] xen: Move xenstore initialization to common location Jason Andryuk
2019-03-11 18:02   ` Jason Andryuk
2019-03-13 15:01   ` Paul Durrant
2019-03-13 18:11     ` Jason Andryuk
2019-03-14 14:00       ` Paul Durrant
2019-03-11 18:02 ` [Qemu-devel] [PATCH 3/6] xen: Skip backend initialization for stubdom Jason Andryuk
2019-03-11 18:02   ` Jason Andryuk
2019-03-13 15:04   ` Paul Durrant
2019-03-11 18:02 ` [Qemu-devel] [PATCH 4/6] xen: Set HVM_PARAM_DM_DOMAIN for stubdom on older Xen Jason Andryuk
2019-03-11 18:02   ` Jason Andryuk
2019-03-11 18:02 ` [Qemu-devel] [PATCH 5/6] xen-pt: Hide MSI-X from xen stubdoms Jason Andryuk
2019-03-11 18:02   ` Jason Andryuk
2019-03-12 12:04   ` Roger Pau Monné
2019-03-12 12:38     ` Marek Marczykowski-Górecki
2019-03-12 13:58       ` Jason Andryuk
2019-03-12 14:13         ` Roger Pau Monné
2019-03-12 15:15           ` Jason Andryuk
2019-03-13  2:15             ` Jason Andryuk
2019-03-12 14:29         ` Marek Marczykowski-Górecki
2019-03-11 18:02 ` [Qemu-devel] [PATCH 6/6] xen-pt: Round pci regions sizes to XEN_PAGE_SIZE Jason Andryuk
2019-03-11 18:02   ` Jason Andryuk
2019-03-13 15:09   ` Paul Durrant
2019-03-14 18:15     ` Jason Andryuk
2019-03-14 19:22       ` Simon Gaiser
2019-03-14 19:37         ` Andrew Cooper
2019-03-15  9:12           ` Paul Durrant
2019-03-14 20:45       ` Simon Gaiser
2019-03-15  9:17       ` Paul Durrant
2019-03-15 16:28         ` Andrew Cooper
2019-03-20 17:28           ` Jason Andryuk
2019-03-22  3:09             ` Roger Pau Monné
2019-03-22 19:43               ` Jason Andryuk
2020-01-13 19:01                 ` [Xen-devel] " Jason Andryuk
2020-01-13 19:01                   ` Jason Andryuk
2020-01-14 10:04                   ` Roger Pau Monné
2020-01-14 10:04                     ` Roger Pau Monné
2020-01-14 14:41                     ` Jason Andryuk
2020-01-14 14:41                       ` Jason Andryuk
2020-01-14 18:04                       ` Roger Pau Monné
2020-01-14 18:04                         ` Roger Pau Monné
2020-01-15  8:33                         ` Durrant, Paul [this message]
2020-01-15  8:33                           ` Durrant, Paul

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=ed1ca41d72bd49c59e5e25044a0a85e0@EX13D32EUC003.ant.amazon.com \
    --to=pdurrant@amazon.co.uk \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=jandryuk@gmail.com \
    --cc=marmarek@invisiblethingslab.com \
    --cc=qemu-devel@nongnu.org \
    --cc=roger.pau@citrix.com \
    --cc=simon@invisiblethingslab.com \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.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.