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 anchor
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.
So
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 term)
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
enlarge the
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 the rest of
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 it. So you'd
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 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, if
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 to
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 smbios
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 0 welcome,
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 system
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 my preference
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/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
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 (recently
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.
Oh, OK.
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 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,
via fw_cfg.
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 it is 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
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 an
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
-
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 expect
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 SeaBIOS
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
should
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
Type 0 (BIOS
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 following bits
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 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, the maximum
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 patch
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 aware of
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-time blobs
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 (not
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,
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 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 very
37 matches
Mail list logo
