[PATCH] pci-assign: Hide ioport regions on lacking sysfs support

[PATCH] pci-assign: Hide ioport regions on lacking sysfs support

[Jan Kiszka]

As suggested by Alex: Instead of failing if the kernel does not allow us
to speak to an ioport region, warn the user but, hide the region and
continue.

Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
---
 hw/device-assignment.c |    9 +++++----
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/hw/device-assignment.c b/hw/device-assignment.c
index 9ad5de5..e47a23c 100644
--- a/hw/device-assignment.c
+++ b/hw/device-assignment.c
@@ -429,11 +429,12 @@ static int assigned_dev_register_regions(PCIRegion *io_regions,
                 fprintf(stderr, "Unexpected return from I/O port read: %d\n",
                         ret);
                 abort();
-            } else if (errno != EINVAL) {
-                fprintf(stderr,
-                        "Kernel doesn't support ioport resource access.\n");
+            } else if (errno != EINVAL || 1) {
+                fprintf(stderr, "Kernel doesn't support ioport resource "
+                                "access, hiding this region.\n");
                 close(pci_dev->v_addrs[i].region->resource_fd);
-                return -1;
+                cur_region->valid = 0;
+                continue;
             }
 
             pci_dev->v_addrs[i].u.r_baseport = cur_region->base_addr;
-- 
1.7.3.4

Re: [PATCH] pci-assign: Hide ioport regions on lacking sysfs support

[Alex Williamson]

On Tue, 2012-05-29 at 19:04 +0200, Jan Kiszka wrote:
> As suggested by Alex: Instead of failing if the kernel does not allow us
> to speak to an ioport region, warn the user but, hide the region and
> continue.
> 
> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
> ---
>  hw/device-assignment.c |    9 +++++----
>  1 files changed, 5 insertions(+), 4 deletions(-)

Thanks!

Acked-by: Alex Williamson <alex.williamson@redhat.com>

> diff --git a/hw/device-assignment.c b/hw/device-assignment.c
> index 9ad5de5..e47a23c 100644
> --- a/hw/device-assignment.c
> +++ b/hw/device-assignment.c
> @@ -429,11 +429,12 @@ static int assigned_dev_register_regions(PCIRegion *io_regions,
>                  fprintf(stderr, "Unexpected return from I/O port read: %d\n",
>                          ret);
>                  abort();
> -            } else if (errno != EINVAL) {
> -                fprintf(stderr,
> -                        "Kernel doesn't support ioport resource access.\n");
> +            } else if (errno != EINVAL || 1) {
> +                fprintf(stderr, "Kernel doesn't support ioport resource "
> +                                "access, hiding this region.\n");
>                  close(pci_dev->v_addrs[i].region->resource_fd);
> -                return -1;
> +                cur_region->valid = 0;
> +                continue;
>              }
>  
>              pci_dev->v_addrs[i].u.r_baseport = cur_region->base_addr;

Re: [PATCH] pci-assign: Hide ioport regions on lacking sysfs support

[Avi Kivity]

On 05/29/2012 08:04 PM, Jan Kiszka wrote:
> As suggested by Alex: Instead of failing if the kernel does not allow us
> to speak to an ioport region, warn the user but, hide the region and
> continue.


Should we not, in addition, abort if the region is actually used?  A
guest malfunction is likely if we don't.


-- 
error compiling committee.c: too many arguments to function

Re: [PATCH] pci-assign: Hide ioport regions on lacking sysfs support

[Alex Williamson]

On Tue, 2012-05-29 at 20:13 +0300, Avi Kivity wrote:
> On 05/29/2012 08:04 PM, Jan Kiszka wrote:
> > As suggested by Alex: Instead of failing if the kernel does not allow us
> > to speak to an ioport region, warn the user but, hide the region and
> > continue.
> 
> 
> Should we not, in addition, abort if the region is actually used?  A
> guest malfunction is likely if we don't.

The only way we could know that it's used is if it's the device ends up
with no valid regions as a result of this.  Otherwise it's dependent on
both the device and the driver whether it can still function without the
i/o port regions.  Thanks,

Alex

Re: [PATCH] pci-assign: Hide ioport regions on lacking sysfs support

[Avi Kivity]

On 05/29/2012 08:28 PM, Alex Williamson wrote:
> On Tue, 2012-05-29 at 20:13 +0300, Avi Kivity wrote:
>> On 05/29/2012 08:04 PM, Jan Kiszka wrote:
>> > As suggested by Alex: Instead of failing if the kernel does not allow us
>> > to speak to an ioport region, warn the user but, hide the region and
>> > continue.
>> 
>> 
>> Should we not, in addition, abort if the region is actually used?  A
>> guest malfunction is likely if we don't.
> 
> The only way we could know that it's used is if it's the device ends up
> with no valid regions as a result of this.  Otherwise it's dependent on
> both the device and the driver whether it can still function without the
> i/o port regions.  Thanks,

If the I/O callback is called, we know it's used.


-- 
error compiling committee.c: too many arguments to function

Re: [PATCH] pci-assign: Hide ioport regions on lacking sysfs support

[Jan Kiszka]

On 2012-05-30 10:21, Avi Kivity wrote:
> On 05/29/2012 08:28 PM, Alex Williamson wrote:
>> On Tue, 2012-05-29 at 20:13 +0300, Avi Kivity wrote:
>>> On 05/29/2012 08:04 PM, Jan Kiszka wrote:
>>>> As suggested by Alex: Instead of failing if the kernel does not allow us
>>>> to speak to an ioport region, warn the user but, hide the region and
>>>> continue.
>>>
>>>
>>> Should we not, in addition, abort if the region is actually used?  A
>>> guest malfunction is likely if we don't.
>>
>> The only way we could know that it's used is if it's the device ends up
>> with no valid regions as a result of this.  Otherwise it's dependent on
>> both the device and the driver whether it can still function without the
>> i/o port regions.  Thanks,
> 
> If the I/O callback is called, we know it's used.

We neither expose the region to the guest (so the guest has no clue
where to write to unless it assumes a fixed address - of which we have
no clue) nor register any callback for it.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [PATCH] pci-assign: Hide ioport regions on lacking sysfs support

[Avi Kivity]

On 05/30/2012 11:47 AM, Jan Kiszka wrote:
> On 2012-05-30 10:21, Avi Kivity wrote:
>> On 05/29/2012 08:28 PM, Alex Williamson wrote:
>>> On Tue, 2012-05-29 at 20:13 +0300, Avi Kivity wrote:
>>>> On 05/29/2012 08:04 PM, Jan Kiszka wrote:
>>>>> As suggested by Alex: Instead of failing if the kernel does not allow us
>>>>> to speak to an ioport region, warn the user but, hide the region and
>>>>> continue.
>>>>
>>>>
>>>> Should we not, in addition, abort if the region is actually used?  A
>>>> guest malfunction is likely if we don't.
>>>
>>> The only way we could know that it's used is if it's the device ends up
>>> with no valid regions as a result of this.  Otherwise it's dependent on
>>> both the device and the driver whether it can still function without the
>>> i/o port regions.  Thanks,
>> 
>> If the I/O callback is called, we know it's used.
> 
> We neither expose the region to the guest (so the guest has no clue
> where to write to unless it assumes a fixed address - of which we have
> no clue) nor register any callback for it.

Ah, I thought you expose the BAR but don't back it with anything.  No
idea which approach is better, so we might as well try yours first.

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH] pci-assign: Hide ioport regions on lacking sysfs support

[Jan Kiszka]

On 2012-05-30 10:50, Avi Kivity wrote:
> On 05/30/2012 11:47 AM, Jan Kiszka wrote:
>> On 2012-05-30 10:21, Avi Kivity wrote:
>>> On 05/29/2012 08:28 PM, Alex Williamson wrote:
>>>> On Tue, 2012-05-29 at 20:13 +0300, Avi Kivity wrote:
>>>>> On 05/29/2012 08:04 PM, Jan Kiszka wrote:
>>>>>> As suggested by Alex: Instead of failing if the kernel does not allow us
>>>>>> to speak to an ioport region, warn the user but, hide the region and
>>>>>> continue.
>>>>>
>>>>>
>>>>> Should we not, in addition, abort if the region is actually used?  A
>>>>> guest malfunction is likely if we don't.
>>>>
>>>> The only way we could know that it's used is if it's the device ends up
>>>> with no valid regions as a result of this.  Otherwise it's dependent on
>>>> both the device and the driver whether it can still function without the
>>>> i/o port regions.  Thanks,
>>>
>>> If the I/O callback is called, we know it's used.
>>
>> We neither expose the region to the guest (so the guest has no clue
>> where to write to unless it assumes a fixed address - of which we have
>> no clue) nor register any callback for it.
> 
> Ah, I thought you expose the BAR but don't back it with anything.  No
> idea which approach is better, so we might as well try yours first.

Great. But don't apply this version, I just found some testing
left-over. Will send and update soon.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux