From: Julian Pidancet <julian.pidancet@gmail.com>
To: Tim Deegan <tim@xen.org>
Cc: Keir Fraser <keir.xen@gmail.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Ross Philipson <Ross.Philipson@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH 00/07] HVM firmware passthrough
Date: Tue, 01 May 2012 20:47:20 +0100 [thread overview]
Message-ID: <4FA03DC8.6040204@gmail.com> (raw)
In-Reply-To: <20120322112612.GG37468@ocelot.phlegethon.org>
On 03/22/12 11:26, Tim Deegan wrote:
> Hi,
>
> At 09:24 +0000 on 20 Mar (1332235452), Tim Deegan wrote:
>> My impression from the earlier discussions is that we're pasing largish
>> blobs of binary BIOS goop around, which aren't suitable to go into
>> xenstore. Dropping them in memory where HVMloader can pick them up
>> seems reasonable.
>>
>> All the control-path stuff - what the blobs are, where they are &c,
>> should go through Xenstore, though.
>
> So having looked at the code, I think the module system is really
> overkill - AIUI all the things you're talking about passing through are
> ACPI tables, which have their own length fields internally. So all
> you'd need to do is have a type code and an address in xenstore
> somewhere, the same way we pass a type code and a string for the other
> BIOS customizations.
>
> Cheers,
>
> Tim.
Hi,
I don't think ACPI and SMBIOS firmware passthrough are the only use
cases here.
The module architecture could also be used to pass the BIOS and Option
ROMs to hvmloader. The toolstack could load them from dom0's filesystem
dynamically and pass them to hvmloader, instead of having them
compiled-in statically in hvmloader.
Would we still be able to do that with the simplifications you're
suggesting here ?
--
Julian
next prev parent reply other threads:[~2012-05-01 19:47 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-19 22:04 [PATCH 00/07] HVM firmware passthrough Ross Philipson
2012-03-19 23:44 ` Keir Fraser
2012-03-19 23:58 ` Ross Philipson
2012-03-20 9:24 ` Tim Deegan
2012-03-22 11:26 ` Tim Deegan
2012-03-22 14:03 ` Ross Philipson
2012-04-04 9:30 ` Ian Campbell
2012-04-04 19:25 ` Ross Philipson
2012-04-05 10:08 ` Ian Campbell
2012-04-05 20:06 ` Ross Philipson
2012-04-10 14:21 ` Ian Campbell
2012-04-10 15:28 ` Ross Philipson
2012-04-10 15:39 ` Ian Campbell
2012-04-10 19:04 ` Ross Philipson
2012-04-11 8:44 ` Ian Campbell
2012-04-11 16:29 ` Ross Philipson
2012-04-13 9:38 ` Ian Campbell
2012-04-25 18:47 ` Ross Philipson
2012-04-25 20:47 ` Tim Deegan
2012-04-25 21:05 ` Ross Philipson
2012-04-26 7:46 ` Ian Campbell
2012-05-01 19:47 ` Julian Pidancet [this message]
2012-05-01 22:17 ` Tim Deegan
2012-05-01 22:59 ` Julian Pidancet
2012-05-01 23:21 ` Tim Deegan
2012-05-02 9:51 ` Ian Campbell
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=4FA03DC8.6040204@gmail.com \
--to=julian.pidancet@gmail.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ross.Philipson@citrix.com \
--cc=keir.xen@gmail.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xensource.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.