From: Alexander Duyck <alexander.duyck@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org, hjk@hansjkoch.de, gregkh@linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] uio: new driver to support PCI MSI-X
Date: Thu, 1 Oct 2015 19:33:13 -0700 [thread overview]
Message-ID: <560DECE9.8020408@gmail.com> (raw)
In-Reply-To: <20151001170452.0e6a90c2@urahara>
On 10/01/2015 05:04 PM, Stephen Hemminger wrote:
> On Thu, 1 Oct 2015 16:40:10 -0700
> Alexander Duyck <alexander.duyck@gmail.com> wrote:
>
>> Do you really need to map IORESOURCE bars? Most drivers I can think of
>> don't use IO BARs anymore. Maybe we could look at just dropping the
>> code and adding it back later if we have a use case that absolutely
>> needs it.
> Mapping is not strictly necessary, but for virtio it acts a way to communicate
> the regions.
I think I see what you are saying. I was hoping we could get away from
having to map any I/O ports but it looks like virtio is still using them
for BAR 0, or at least that is what I am seeing on my VM with
virtio_net. I was really hoping we could get away from that since a 16b
address space is far too restrictive anyway.
>> Also how many devices actually need resources beyond BAR 0? I'm just
>> curious as I know BAR 2 on many of the Intel devices is the register
>> space related to MSI-X so now we have both the PCIe subsystem and user
>> space with access to this region.
> VMXNet3 needs 2 bars. Most use only one.
So essentially we are needing to make exceptions for the virtual interfaces.
I guess there isn't much we can do then and we probably need to map any
and all base address registers we can find for the given device. I was
hoping for something a bit more surgical since we are opening a security
hole of sorts, but I guess it can't be helped if we want to support
multiple devices and they all have such radically different configurations.
- Alex
WARNING: multiple messages have this Message-ID (diff)
From: Alexander Duyck <alexander.duyck@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: hjk@hansjkoch.de, gregkh@linux-foundation.org, dev@dpdk.org,
linux-kernel@vger.kernel.org
Subject: Re: [dpdk-dev] [PATCH 2/2] uio: new driver to support PCI MSI-X
Date: Thu, 1 Oct 2015 19:33:13 -0700 [thread overview]
Message-ID: <560DECE9.8020408@gmail.com> (raw)
In-Reply-To: <20151001170452.0e6a90c2@urahara>
On 10/01/2015 05:04 PM, Stephen Hemminger wrote:
> On Thu, 1 Oct 2015 16:40:10 -0700
> Alexander Duyck <alexander.duyck@gmail.com> wrote:
>
>> Do you really need to map IORESOURCE bars? Most drivers I can think of
>> don't use IO BARs anymore. Maybe we could look at just dropping the
>> code and adding it back later if we have a use case that absolutely
>> needs it.
> Mapping is not strictly necessary, but for virtio it acts a way to communicate
> the regions.
I think I see what you are saying. I was hoping we could get away from
having to map any I/O ports but it looks like virtio is still using them
for BAR 0, or at least that is what I am seeing on my VM with
virtio_net. I was really hoping we could get away from that since a 16b
address space is far too restrictive anyway.
>> Also how many devices actually need resources beyond BAR 0? I'm just
>> curious as I know BAR 2 on many of the Intel devices is the register
>> space related to MSI-X so now we have both the PCIe subsystem and user
>> space with access to this region.
> VMXNet3 needs 2 bars. Most use only one.
So essentially we are needing to make exceptions for the virtual interfaces.
I guess there isn't much we can do then and we probably need to map any
and all base address registers we can find for the given device. I was
hoping for something a bit more surgical since we are opening a security
hole of sorts, but I guess it can't be helped if we want to support
multiple devices and they all have such radically different configurations.
- Alex
next prev parent reply other threads:[~2015-10-02 2:33 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 22:28 [PATCH 0/2] uio_msi: device driver Stephen Hemminger
2015-09-30 22:28 ` Stephen Hemminger
2015-09-30 22:28 ` [PATCH 1/2] uio: add support for ioctls Stephen Hemminger
2015-09-30 22:28 ` Stephen Hemminger
2015-09-30 22:28 ` [PATCH 2/2] uio: new driver to support PCI MSI-X Stephen Hemminger
2015-09-30 22:28 ` Stephen Hemminger
2015-10-01 8:33 ` Michael S. Tsirkin
2015-10-01 8:33 ` Michael S. Tsirkin
2015-10-01 10:37 ` Michael S. Tsirkin
2015-10-01 10:37 ` Michael S. Tsirkin
2015-10-01 16:06 ` Michael S. Tsirkin
2015-10-01 16:06 ` Michael S. Tsirkin
2015-10-01 14:50 ` Stephen Hemminger
2015-10-01 14:50 ` Stephen Hemminger
2015-10-01 15:22 ` Michael S. Tsirkin
2015-10-01 15:22 ` Michael S. Tsirkin
2015-10-01 16:31 ` Michael S. Tsirkin
2015-10-01 16:31 ` Michael S. Tsirkin
2015-10-01 17:26 ` Stephen Hemminger
2015-10-01 17:26 ` Stephen Hemminger
2015-10-01 18:25 ` Michael S. Tsirkin
2015-10-01 18:25 ` Michael S. Tsirkin
2015-10-05 21:54 ` Michael S. Tsirkin
2015-10-05 21:54 ` Michael S. Tsirkin
2015-10-05 22:09 ` Vladislav Zolotarov
2015-10-05 22:49 ` Michael S. Tsirkin
2015-10-05 22:49 ` [dpdk-dev] " Michael S. Tsirkin
2015-10-06 7:33 ` Stephen Hemminger
2015-10-06 7:33 ` [dpdk-dev] " Stephen Hemminger
2015-10-06 12:15 ` Avi Kivity
2015-10-06 12:15 ` [dpdk-dev] " Avi Kivity
2015-10-06 14:07 ` Michael S. Tsirkin
2015-10-06 15:41 ` Avi Kivity
2015-10-06 15:41 ` [dpdk-dev] " Avi Kivity
2015-10-16 17:11 ` Thomas Monjalon
2015-10-16 17:11 ` [dpdk-dev] " Thomas Monjalon
2015-10-16 17:20 ` Stephen Hemminger
2015-10-16 17:20 ` [dpdk-dev] " Stephen Hemminger
2015-10-06 13:42 ` Michael S. Tsirkin
2015-10-06 13:42 ` [dpdk-dev] " Michael S. Tsirkin
2015-10-06 8:23 ` Vlad Zolotarov
2015-10-06 8:23 ` [dpdk-dev] " Vlad Zolotarov
2015-10-06 13:58 ` Michael S. Tsirkin
2015-10-06 13:58 ` [dpdk-dev] " Michael S. Tsirkin
2015-10-06 14:49 ` Vlad Zolotarov
2015-10-06 15:00 ` Michael S. Tsirkin
2015-10-06 15:00 ` [dpdk-dev] " Michael S. Tsirkin
2015-10-06 16:40 ` Vlad Zolotarov
2015-10-06 16:40 ` [dpdk-dev] " Vlad Zolotarov
2015-10-01 23:40 ` Alexander Duyck
2015-10-01 23:40 ` [dpdk-dev] " Alexander Duyck
2015-10-02 0:01 ` Stephen Hemminger
2015-10-02 0:01 ` [dpdk-dev] " Stephen Hemminger
2015-10-02 1:21 ` Alexander Duyck
2015-10-02 1:21 ` [dpdk-dev] " Alexander Duyck
2015-10-02 0:04 ` Stephen Hemminger
2015-10-02 2:33 ` Alexander Duyck [this message]
2015-10-02 2:33 ` Alexander Duyck
2015-10-01 8:36 ` [PATCH 0/2] uio_msi: device driver Michael S. Tsirkin
2015-10-01 8:36 ` Michael S. Tsirkin
2015-10-01 10:59 ` Avi Kivity
2015-10-01 10:59 ` [dpdk-dev] " Avi Kivity
2015-10-01 14:57 ` Stephen Hemminger
2015-10-01 19:48 ` Alexander Duyck
2015-10-01 19:48 ` [dpdk-dev] " Alexander Duyck
2015-10-01 22:00 ` Stephen Hemminger
2015-10-01 22:00 ` [dpdk-dev] " Stephen Hemminger
2015-10-01 23:03 ` Alexander Duyck
2015-10-01 23:03 ` [dpdk-dev] " Alexander Duyck
2015-10-01 23:39 ` Stephen Hemminger
2015-10-01 23:39 ` [dpdk-dev] " Stephen Hemminger
2015-10-01 23:43 ` Alexander Duyck
2015-10-02 0:04 ` Stephen Hemminger
2015-10-02 0:04 ` [dpdk-dev] " Stephen Hemminger
2015-10-02 1:39 ` Alexander Duyck
2015-10-04 16:49 ` Vlad Zolotarov
2015-10-04 16:49 ` [dpdk-dev] " Vlad Zolotarov
2015-10-04 19:03 ` Greg KH
2015-10-04 20:49 ` Vlad Zolotarov
2015-10-04 20:49 ` [dpdk-dev] " Vlad Zolotarov
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=560DECE9.8020408@gmail.com \
--to=alexander.duyck@gmail.com \
--cc=dev@dpdk.org \
--cc=gregkh@linux-foundation.org \
--cc=hjk@hansjkoch.de \
--cc=linux-kernel@vger.kernel.org \
--cc=stephen@networkplumber.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.