On Mon, Apr 07, 2014 at 02:57:08PM -0400, Kevin O'Connor wrote:
> On Mon, Apr 07, 2014 at 02:05:21PM -0400, Gabriel L. Somlo wrote:
> > On Mon, Apr 07, 2014 at 11:23:44AM -0400, Kevin O'Connor wrote:
> > > So, I'm suggesting QEMU produce two new fw_cfg files: an anchor file
> > > with the valid anc
On Mon, Apr 07, 2014 at 02:05:21PM -0400, Gabriel L. Somlo wrote:
> On Mon, Apr 07, 2014 at 11:23:44AM -0400, Kevin O'Connor wrote:
> > So, I'm suggesting QEMU produce two new fw_cfg files: an anchor file
> > with the valid anchor table (the address pointer can be just set to
> > zero), and an smbi
On Mon, Apr 07, 2014 at 11:23:44AM -0400, Kevin O'Connor wrote:
> So, I'm suggesting QEMU produce two new fw_cfg files: an anchor file
> with the valid anchor table (the address pointer can be just set to
> zero), and an smbios table file with the complete set of smbios tables
> formatted according
On Mon, Apr 07, 2014 at 10:49:54AM -0400, Gabriel L. Somlo wrote:
> On Mon, Apr 07, 2014 at 10:14:36AM -0400, Kevin O'Connor wrote:
> > How about having QEMU produce the smbios table with a dummy type0
> > table and then both seabios and ovmf can replace the type0 table if
> > desired. After all,
On Mon, Apr 07, 2014 at 10:14:36AM -0400, Kevin O'Connor wrote:
> How about having QEMU produce the smbios table with a dummy type0
> table and then both seabios and ovmf can replace the type0 table if
> desired. After all, if OVMF is splitting the blob into tables, it can
> just as easily replace
On 04/07/14 16:14, Kevin O'Connor wrote:
> On Mon, Apr 07, 2014 at 09:09:56AM +0200, Gerd Hoffmann wrote:
The only fly in this ointment may be that type 0 doesn't have a fixed
length that could be edited in place, if you consider the various
strings that get tacked on to the end of i
On Mon, Apr 07, 2014 at 09:09:56AM +0200, Gerd Hoffmann wrote:
> > > The only fly in this ointment may be that type 0 doesn't have a fixed
> > > length that could be edited in place, if you consider the various
> > > strings that get tacked on to the end of it. So you'd still have to
> > > slide th
Hi,
> > The only fly in this ointment may be that type 0 doesn't have a fixed
> > length that could be edited in place, if you consider the various
> > strings that get tacked on to the end of it. So you'd still have to
> > slide the rest of the smbios payload left or right to shrink or
> > enla
On Do, 2014-04-03 at 09:32 -0400, Gabriel L. Somlo wrote:
> For that, ideally, I'd like to clone a git repo (and pull once
> every few days to stay on top of things). Looks like the top-level
> upstream one doesn't have your smbios code, so would there be a
> "mid-stream" (for the lack of a better
On Do, 2014-04-03 at 11:42 +0200, Laszlo Ersek wrote:
> (a) Gerd's packages:
>
> http://www.kraxel.org/repos/
> Under (a) you find some short instructions, and a set of RPMs that is
> automatically rebuilt twice a day (IIRC).
It polls the git repos once per hour and kicks a build on new commits.
On Wed, Apr 02, 2014 at 12:35:26AM +0200, Laszlo Ersek wrote:
> On 04/02/14 00:00, Kevin O'Connor wrote:
> > On Tue, Apr 01, 2014 at 11:44:12PM +0200, Laszlo Ersek wrote:
> >> Right now, OVMF can accept individual fields, or table-at-a-time blobs,
> >> via fw_cfg.
> >>
> >> The internal interface (
On Fri, Apr 04, 2014 at 09:15:14PM -0400, Gabriel L. Somlo wrote:
> On Fri, Apr 04, 2014 at 08:34:11PM -0400, Kevin O'Connor wrote:
> > >
> > > IMO 'dmidecode -t0' should show what firmware you are running
> > > (seabios/ovmf/coreboot/whatever), not something made up by qemu.
> >
> > Ultimately m
On Fri, Apr 04, 2014 at 08:34:11PM -0400, Kevin O'Connor wrote:
> >
> > IMO 'dmidecode -t0' should show what firmware you are running
> > (seabios/ovmf/coreboot/whatever), not something made up by qemu.
>
> Ultimately my preference would be to make a clean break from the
> existing smbios fw_cfg
On Wed, Apr 02, 2014 at 05:04:57PM +0200, Gerd Hoffmann wrote:
> > > - therefore, the maximum granularity of QEMU-generated
> > > elements should be full tables of a given type, and
> > > not the full SMBIOS blob at once (other mechanisms to
> > > allow the BIOS to insert its own type
On 04/03/14 15:32, Gabriel L. Somlo wrote:
> On Thu, Apr 03, 2014 at 11:42:31AM +0200, Laszlo Ersek wrote:
>> You don't see SMBIOS tables in the guest because you've built upstream
>> OVMF. As I said before, upstream OvmfPkg doesn't include my SMBIOS
>> patches. Both (a) and (b) do however.
>
> O
On Thu, Apr 03, 2014 at 11:42:31AM +0200, Laszlo Ersek wrote:
> Unless you want to do OVMF development yourself (ie. as long as you'd
> like to test only), you're best off with
>
> (a) Gerd's packages:
>
> http://www.kraxel.org/repos/
>
> (b) If you use a Fedora host, you can also try a (recentl
On 04/03/14 03:57, Gabriel L. Somlo wrote:
> On Wed, Apr 02, 2014 at 01:01:28PM -0400, Gabriel L. Somlo wrote:
>> Speaking of, I *thought* I had a vague idea of how all this stuff fits
>> together, but it turns out I don't... There's
>>
>> - OVMF
>>http://sourceforge.net/apps/mediawiki
On Wed, Apr 02, 2014 at 01:01:28PM -0400, Gabriel L. Somlo wrote:
> Speaking of, I *thought* I had a vague idea of how all this stuff fits
> together, but it turns out I don't... There's
>
> - OVMF
> http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF
>
> - Ti
On Wed, Apr 02, 2014 at 05:07:05PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> > If qemu gives OVMF a complete, concatenated dump of all tables, I'll
> > have to split that up into individual tables, and install those one by one.
>
> I feel like I should have a look at how coreboot handles this for a
Hi,
> If qemu gives OVMF a complete, concatenated dump of all tables, I'll
> have to split that up into individual tables, and install those one by one.
I feel like I should have a look at how coreboot handles this for an
additional data point ...
cheers,
Gerd
Hi,
> > From the conversation so far, it seems to me that:
> >
> > - type 0 is best left to the BIOS (user overrides via
> > command line at their own risk)
I think it was a bad idea to allow overriding type0 fields in the first
place. It also isn't used in practice. I don't think
On 04/02/14 14:38, Gabriel L. Somlo wrote:
> On Wed, Apr 02, 2014 at 12:35:26AM +0200, Laszlo Ersek wrote:
>> On 04/02/14 00:00, Kevin O'Connor wrote:
>>> On Tue, Apr 01, 2014 at 11:44:12PM +0200, Laszlo Ersek wrote:
Right now, OVMF can accept individual fields, or table-at-a-time blobs,
On Wed, Apr 02, 2014 at 12:35:26AM +0200, Laszlo Ersek wrote:
> On 04/02/14 00:00, Kevin O'Connor wrote:
> > On Tue, Apr 01, 2014 at 11:44:12PM +0200, Laszlo Ersek wrote:
> >> Right now, OVMF can accept individual fields, or table-at-a-time blobs,
> >> via fw_cfg.
> >>
> >> The internal interface (
On 04/02/14 00:00, Kevin O'Connor wrote:
> On Tue, Apr 01, 2014 at 11:44:12PM +0200, Laszlo Ersek wrote:
>> Right now, OVMF can accept individual fields, or table-at-a-time blobs,
>> via fw_cfg.
>>
>> The internal interface (EFI_SMBIOS_PROTOCOL) expects one table at a time
>> (for which table-at-a-
On Tue, Apr 01, 2014 at 11:44:12PM +0200, Laszlo Ersek wrote:
> Right now, OVMF can accept individual fields, or table-at-a-time blobs,
> via fw_cfg.
>
> The internal interface (EFI_SMBIOS_PROTOCOL) expects one table at a time
> (for which table-at-a-time blobs are a perfect match).
I wasn't awar
On Tue, Apr 01, 2014 at 05:28:10PM -0400, Gabriel L. Somlo wrote:
> Assuming all relevant QEMU maintainers are OK with the idea of
> creating a full SMBIOS blob (with e.g. type 0 defaulting to the
> relevant SeaBIOS values, override-able to fit some different bios,
> e.g. OVMF), would you take a pa
On 04/01/14 23:28, Gabriel L. Somlo wrote:
> On Tue, Apr 01, 2014 at 04:28:32PM -0400, Kevin O'Connor wrote:
>>> From the conversation so far, it seems to me that:
>>>
>>> - type 0 is best left to the BIOS (user overrides via
>>> command line at their own risk)
>>>
>>> - therefore, th
On Tue, Apr 01, 2014 at 04:28:32PM -0400, Kevin O'Connor wrote:
> > From the conversation so far, it seems to me that:
> >
> > - type 0 is best left to the BIOS (user overrides via
> > command line at their own risk)
> >
> > - therefore, the maximum granularity of QEMU-generated
> >
On Tue, Apr 01, 2014 at 02:47:27PM -0400, Gabriel L. Somlo wrote:
> On Tue, Apr 01, 2014 at 05:47:09PM +0200, Laszlo Ersek wrote:
> > bit 2 of the BIOS Characteristics Extension Byte 2 (7.1.2.2) is set, for
> > "Enable Targeted Content Distribution".
> >
> > In OVMF, the same byte has the followin
On Tue, Apr 01, 2014 at 05:47:09PM +0200, Laszlo Ersek wrote:
> On 04/01/14 16:39, Kevin O'Connor wrote:
> > On Tue, Apr 01, 2014 at 10:40:00AM +0200, Laszlo Ersek wrote:
> >> On 03/31/14 22:18, Gabriel L. Somlo wrote:
> >>> The only sticking point remaining would be who gets to generate the
> >>>
On 04/01/14 16:39, Kevin O'Connor wrote:
> On Tue, Apr 01, 2014 at 10:40:00AM +0200, Laszlo Ersek wrote:
>> On 03/31/14 22:18, Gabriel L. Somlo wrote:
>>> The only sticking point remaining would be who gets to generate the
>>> Type 0 (BIOS Information) table and when, which is something QEMU
>>> sh
On Tue, Apr 01, 2014 at 10:40:00AM +0200, Laszlo Ersek wrote:
> On 03/31/14 22:18, Gabriel L. Somlo wrote:
> > The only sticking point remaining would be who gets to generate the
> > Type 0 (BIOS Information) table and when, which is something QEMU
> > should arguably NOT be doing on behalf of SeaB
On 03/31/14 22:18, Gabriel L. Somlo wrote:
> On Wed, Mar 26, 2014 at 06:36:10PM -0400, Kevin O'Connor wrote:
>> On Wed, Mar 26, 2014 at 03:58:50PM -0400, Gabriel L. Somlo wrote:
>>> - SeaBIOS is still in charge of providing the smbios_entry_point
>>> structure, and it's unlikely we can reasonably
On Wed, Mar 26, 2014 at 06:36:10PM -0400, Kevin O'Connor wrote:
> On Wed, Mar 26, 2014 at 03:58:50PM -0400, Gabriel L. Somlo wrote:
> > - SeaBIOS is still in charge of providing the smbios_entry_point
> > structure, and it's unlikely we can reasonably expect it to
> > bump the version to 2.5 (n
On Wed, Mar 26, 2014 at 03:58:50PM -0400, Gabriel L. Somlo wrote:
> On Tue, Mar 18, 2014 at 07:23:17PM -0400, Gabriel L. Somlo wrote:
> > At this point, can anyone with access to a real, physical, NUMA
> > system dump the smbios tables with dmidecode and post them here?
> > I think that would be ve
On Wed, Mar 26, 2014 at 03:58:50PM -0400, Gabriel L. Somlo wrote:
> - SeaBIOS is still in charge of providing the smbios_entry_point
> structure, and it's unlikely we can reasonably expect it to
> bump the version to 2.5 (not that it seems to matter, if my
> tests are to be believed)
This is
On Tue, Mar 18, 2014 at 07:23:17PM -0400, Gabriel L. Somlo wrote:
> At this point, can anyone with access to a real, physical, NUMA
> system dump the smbios tables with dmidecode and post them here?
> I think that would be very informative.
So I thrashed around a bit trying to find a real NUMA box
37 matches
Mail list logo
