xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
To: Eric Shelton <eshelton@pobox.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	Jan Beulich <JBeulich@suse.com>
Subject: Re: PCI passthrough to QEMU traditional stubdom not working when option ROM present
Date: Fri, 21 Oct 2016 15:23:22 +0200	[thread overview]
Message-ID: <20161021132322.GN2829@var.bordeaux.inria.fr> (raw)
In-Reply-To: <CAPQw5r=FUtV8QZ0OtF5Uchnic6VG1yMK8+BqasTaQUiKRTM2jw@mail.gmail.com>

Hello,

Eric Shelton, on Fri 21 Oct 2016 09:01:43 -0400, wrote:
> ERROR: PCI region size must be pow2 type=0x8, size=0xdf080000

>           u32 u = pci_read_long(d, reg);
>           if (u != 0xffffffff)
> -           d->rom_base_addr = u;
> +            {
> +              d->rom_base_addr = u;
> +              if (flags & PCI_FILL_SIZES)
> +                {
> +                  u32 size;
> +                  pci_write_long(d, reg, ~0);
> +                  d->rom_size = pci_read_long(d, reg);
> +                  pci_write_long(d, reg, u);
> +                }
> +            }
> = = = =
> 
> It looks like there are a few issues going on with this:

Indeed :) I have to say that 8 years have made me forget about the code
:)

> (1) The expansion ROM BAR at 0x30 appears to be read only, so the
> write of ~0 to determine its size is not working.  As a result,
> d->rom_size is getting set to the base address for the expansion ROM.
> I assume 0x30 being read only is a pciback issue, but I don't know if
> changes after 4.4.14 have affected this - I see there have been
> changes to rom_write() and rom_init() in conf_space_header.c

I don't know about this. Probably an issue in pciback indeed.

> (2) Even if that write issue wasn't happening, the above patch does
> not look like the right way to determine the size of the expansion ROM
> anyway.  For example, with the example device above having a 256K
> expansion ROM, I believe a write of 0xffffffff to 0x30 would result in
> a value of 0xfffc0001 (the lowest bit is an address decode
> enable/disable), which we would not want to store in d->rom_size.
> Instead, something like:
>   d->rom_size = pci_size(u, pci_read_long(d, reg), PCI_ROM_ADDRESS_MASK);
> probably should be done instead, in the same way the other BARs are being sized.

Completely agree. I guess the rom_base_addr field should also have a
& PCI_ROM_ADDRESS_MASK like the other base_addr fields in the patch.

Also, that part is not specific to mini-os. It'd be good to submit it
upstream :)

> (3) (minor) When QEMU errors out, it takes a while for xl to time out
> on it.  Perhaps it would make sense for QEMU to set something in
> xenstore on its way out to let xl know it has errored out.

Mmm, I guess the stubdom itself crashes? I'd say xl should be watching
for the stubdom being alive, and perhaps abort the domain if the stubdom
crashed?

Samuel

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

  reply	other threads:[~2016-10-21 13:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-21 13:01 PCI passthrough to QEMU traditional stubdom not working when option ROM present Eric Shelton
2016-10-21 13:23 ` Samuel Thibault [this message]
2016-10-24 10:19   ` Jan Beulich
2016-10-24 12:30     ` Eric Shelton
2016-10-24 12:47       ` Jan Beulich
2016-10-24 13:01         ` Eric Shelton
2016-10-24 13:12           ` Jan Beulich
2016-10-24 13:16             ` Samuel Thibault
2016-10-24 13:56             ` Eric Shelton
2016-10-24 14:02               ` Jan Beulich

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=20161021132322.GN2829@var.bordeaux.inria.fr \
    --to=samuel.thibault@ens-lyon.org \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=JBeulich@suse.com \
    --cc=eshelton@pobox.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).