From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: kvm@vger.kernel.org, ddutile@redhat.com, chrisw@redhat.com
Subject: Re: [PATCH 2/2] device-assignment: Allow PCI to manage the option ROM
Date: Fri, 8 Oct 2010 00:45:23 +0200 [thread overview]
Message-ID: <20101007224523.GB20504@redhat.com> (raw)
In-Reply-To: <1286472841.3020.56.camel@x201>
On Thu, Oct 07, 2010 at 11:34:01AM -0600, Alex Williamson wrote:
> On Thu, 2010-10-07 at 19:18 +0200, Michael S. Tsirkin wrote:
> > On Mon, Oct 04, 2010 at 03:26:30PM -0600, Alex Williamson wrote:
> > > --- a/hw/device-assignment.c
> > > +++ b/hw/device-assignment.c
> ...
> > > @@ -1644,58 +1621,64 @@ void add_assigned_devices(PCIBus *bus, const char **devices, int n_devices)
> > > */
> > > static void assigned_dev_load_option_rom(AssignedDevice *dev)
> > > {
> > > - int size, len, ret;
> > > - void *buf;
> > > + char name[32], rom_file[64];
> > > FILE *fp;
> > > - uint8_t i = 1;
> > > - char rom_file[64];
> > > + uint8_t val;
> > > + struct stat st;
> > > + void *ptr;
> > > +
> > > + /* If loading ROM from file, pci handles it */
> > > + if (dev->dev.romfile || !dev->dev.rom_bar)
> > > + return;
> > >
> > > snprintf(rom_file, sizeof(rom_file),
> > > "/sys/bus/pci/devices/%04x:%02x:%02x.%01x/rom",
> > > dev->host.seg, dev->host.bus, dev->host.dev, dev->host.func);
> > >
> > > - if (access(rom_file, F_OK))
> > > + if (stat(rom_file, &st)) {
> > > return;
> > > + }
> > >
> >
> > Just a note that stat on the ROM sysfs file returns window size,
> > not the ROM size. So this allocates more ram than really necessary for
> > ROM. Real size is returned by fread.
> >
> > Do we care?
>
> That was my intention with using stat. I thought that by default the
> ROM BAR should match physical hardware, so even if the contents could be
> rounded down to a smaller size, we maintain the size of the physical
> device. To use the minimum size, the contents could be extracted using
> pci-sysfs and passed with the romfile option, or the ROM could be
> disabled altogether with the rombar=0 option. Sound reasonable?
> Thanks,
>
> Alex
For BAR size yes, but we do not need the buffer full of 0xff as it is
never accessed: let's have buffer size match real ROM, avoid wasting
memory: this can come up to megabytes easily.
Makes sense?
next prev parent reply other threads:[~2010-10-07 22:51 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-04 21:26 [PATCH 0/2] device-assignment: Re-work PCI option ROM support Alex Williamson
2010-10-04 21:26 ` [PATCH 1/2] PCI: Export pci_map_option_rom() Alex Williamson
2010-10-05 16:03 ` Chris Wright
2010-10-04 21:26 ` [PATCH 2/2] device-assignment: Allow PCI to manage the option ROM Alex Williamson
2010-10-07 17:18 ` Michael S. Tsirkin
2010-10-07 17:34 ` Alex Williamson
2010-10-07 22:45 ` Michael S. Tsirkin [this message]
2010-10-08 4:02 ` Alex Williamson
2010-10-08 8:40 ` Michael S. Tsirkin
2010-10-08 15:12 ` Alex Williamson
2010-10-09 21:44 ` Michael S. Tsirkin
2010-10-11 15:15 ` Alex Williamson
2010-10-11 15:21 ` Michael S. Tsirkin
2010-10-11 15:43 ` Alex Williamson
2010-10-06 20:43 ` [PATCH 0/2] device-assignment: Re-work PCI option ROM support Marcelo Tosatti
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=20101007224523.GB20504@redhat.com \
--to=mst@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=chrisw@redhat.com \
--cc=ddutile@redhat.com \
--cc=kvm@vger.kernel.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