[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Patch][2/2][BIOS] Support BCV table


  • To: Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Fri, 27 Mar 2009 09:00:18 +0000
  • Cc:
  • Delivery-date: Fri, 27 Mar 2009 02:01:39 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcmudcrB6wBrpi9SRPKQTFD4d/nrdAARKik+
  • Thread-topic: [Xen-devel] [Patch][2/2][BIOS] Support BCV table

On 27/03/2009 00:48, "Akio Takebe" <takebe_akio@xxxxxxxxxxxxxx> wrote:

>> You want qemu mucking about with the hvm_info_table? I don't think so.
>> You'll have to consider an approach which doesn't touch qemu - you have some
>> time anyway since this is not going in for 3.4.
> I didn't want to modify qemu, but virtual slot is decided in qemu.
> Most of my patch modify hw/pass-through.c
> Because hw/pass-though.c is used by only xen,
> I though it was accectable to modify it.
> So I modified qemu involuntarily. I'm sorry.
> If we don't modify qemu, we need to see xenstore and so on
> from hvmloader. Do you have any idea?

I may be missing some of the motivation and higher-level design, which you
may have to describe. I'm not really sure what the whole patchset was
actually for and why we'd want it.

But, for example, why not specify the vendor:dev identifier via
hvm_info_table, rather than specifying the vslot?

Or, if you feel you must do this via qemu, hack extra info into the PCI
config space of each device, or expose via the xen-platform device I/O
ports? Something which qemu already controls (unlike hvm_info_table).

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.