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
next prev parent 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).