Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 08/13] range: add Range structure
On Mon, May 13, 2013 at 09:20:08PM +0100, Peter Maydell wrote:
On 13 May 2013 21:01, Michael S. Tsirkin m...@redhat.com wrote:
Sometimes we need to pass ranges around, add a
handy structure for this purpose.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
include/qemu/range.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/include/qemu/range.h b/include/qemu/range.h
index 3502372..4bcd346 100644
--- a/include/qemu/range.h
+++ b/include/qemu/range.h
@@ -1,6 +1,28 @@
#ifndef QEMU_RANGE_H
#define QEMU_RANGE_H
+#include inttypes.h
+
+/*
+ * Operations on 64 address ranges.
missing bit ?
+ * Notes:
+ * - ranges must not wrap around 0, but can include the last byte ~0x0LL.
+ * - this can not represent a full 0 to ~0x0LL range.
+ */
+
+/* A structure representing a range of addresses. */
+struct Range {
+uint64_t begin; /* First byte of the range, or 0 if empty. */
+uint64_t end; /* 1 + the last byte. 0 if range empty or ends at
~0x0LL. */
+};
+typedef struct Range Range;
+
+/* verify that range is not empty and does not overlap */
Doesn't overlap what?
I meant wrap around there.
Why isn't an empty range valid?
The struct definition above says it's OK.
Yes it's a bad name. Should be range_non_empty or something.
+{
+return range-begin + 1 = range-end;
+}
I note that memory.c defines its own concept of an AddrRange.
thanks
-- PMM
Good point, maybe I'll reuse that or just use two 64 bit fields explicitly.
--
MST
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 10/13] i386: generate pc guest info
On Mon, May 13, 2013 at 09:23:54PM +0100, Peter Maydell wrote:
On 13 May 2013 21:01, Michael S. Tsirkin m...@redhat.com wrote:
This fills in guest info table with misc
information of interest to the guest.
Will be used by ACPI table generation code.
Bunch of coding style violations in this patch which will
need fixing at some point in the RFC-patch process.
thanks
-- PMM
I went over it again and found one:
+if (ram_size = 0x8000)
+guest_info-pci_info.w32.begin = 0x8000;
+else if (ram_size = 0xc000)
+guest_info-pci_info.w32.begin = 0xc000;
+else
+guest_info-pci_info.w32.begin = 0xe000;
should use {}.
One is not a bunch so I obviously missed some - it might be helpful if
you pointed them out.
Thanks,
--
MST
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Hi, Several future developments that this will enable: - make it easier to use alternative firmware: any firmware can just load the ACPI tables from QEMU. case in point OVMF. UEFI obviously can create ACPI tables already so I don't think this is a valid advantage. Yea, but it doesn't do all the patching seabios does, so some features simply don't work. Generating the tables in qemu instead will zap those differnces and will make it alot easier to bring all firmware images (seabios, ovmf, coreboot, ...) to feature parity without duplicating the code needed for that in all firmwares. You could use this argument to say that QEMU should implement int13 or int10 too... This is comparing apples and oranges. This has strong analogies to generating device trees Indeed, both acpi and device trees describe the hardware emulated by qemu. Comparing acpi + device trees makes alot more sense than comparing acpi with int10 ... and is also a good reason why exposing this information via a common interface (fw_cfg) would be a good idea. Huh? As far I know we generate device trees in qemu instead of expecting pseries firmware compile them from fw_cfg information. cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
On Tue, May 14, 2013 at 08:34:43AM -0500, Anthony Liguori wrote: Michael S. Tsirkin m...@redhat.com writes: On Mon, May 13, 2013 at 03:38:51PM -0500, Anthony Liguori wrote: I don't think it's a good idea to move BIOS functionality in QEMU. Just to clarify: generating ACPI tables is not BIOS functionality. It ended up in seabios for historical reasons. A normal scenario for ACPI tables is that they are written in ASL and compiled with IASL. I wouldn't call this the normal scenario. Some tables are static but more tables are dynamic than you'd think. If you're a firmware engineer and you have to support dozens of platforms, it's much easier to make the tables dynamic than attempt to maintain dozens of ASL descriptions. A lot of what you'd consider to be static is actually dynamic in a multi-node system. The tables are then stored in some ROM device - most of them, except FACP, can actually be mapped directly from ROM if necessary. You won't normally find real BIOS probing PCI slots for hotplug support and writing EJ0 methods dynamically - instead the assumption is that hardware (in this case QEMU) supplies its own static description in form of ACPI tables. Actually, this is a very good example. In more modern boxes like Flex, there's a PCI-Express backplane that all of the nodes are connected to with a common set of slots for all nodes. You can configure in firmware how the slots map to each node. So if you tell BIOS how to map slots to nodes it can generate SRAT. Fine but it still never needs to discover which hardware is there. I can share an acpi dump from one of these systems when after I head into the office this morning. This is what's nice about a switched PCI complex. You have tremendous amounts of flexibility in how you set things up. Regards, Anthony Liguori My patchset uses FW_CFG as such a ROM device. It would be easy to switch to something else instead of FW_CFG. Is this what you are suggesting? -- MST ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
Gerd Hoffmann kra...@redhat.com writes: Hi, and is also a good reason why exposing this information via a common interface (fw_cfg) would be a good idea. Huh? As far I know we generate device trees in qemu instead of expecting pseries firmware compile them from fw_cfg information. It depends on what firmware you are using. Of course. On archs which don't use device trees in the first place it doesn't make sense. We don't really generate device trees in general in QEMU. pseries does (thats why the hard libfdt dependency if you want pseries support). arm wants move into that direction too. pseries is a bad example because it's not a real hardware platform. It's emulating what PowerVM does. It's more akin to the xenpv machine than a real piece of hardware. As Peter mentioned, in an ideal world we'd generate them from the QOM graph. Sure. That should happen in the firmware and it could be enabled by adding just a couple fw_cfg commands to navigate the QOM graph (analogs to qom-list and qom-get in QMP). I don't think Peter intended to imply *that* ... Yes, this has been discussed dozens of times in the past. And as I've said in the past, generating device trees belongs in the firmware. It's a firmware/OS interface. It's not just an academic argument though. We want to expose hardware interfaces that are rich enough for firmware to do whatever it needs to do to initialize the system. There are a lot of things that are normally only visible to firmware that we don't emulate today. In exposing this information, we ought to attempt to do so in an architectural neutral way. ACPI is not architectural neutral. You could argue that that's okay because we only need to support two things: ACPI and device trees. But that's not quite right. Device trees very often have platform specific quirks so a generated device tree in common code is not going to have the right set of quirks for any given system. Having a good interface for firmware to generate ACPI tables and device trees solves this problem in a much nicer way. It enables firmware to display whatever type of tree it wants (ACPI or device tree) and also provides the flexibility to implement the necessary quirks for that platform. Regards, Anthony Liguori cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
On 14 May 2013 15:29, David Woodhouse dw...@infradead.org wrote: On Tue, 2013-05-14 at 10:38 +0100, Peter Maydell wrote: It depends. For ARM we insist that the user provides the device tree that corresponds to the kernel they're going to run, and then we just tweak it a bit. Um... device trees describe hardware, and should not be at all kernel-specific. Did you mean to say the device tree that corresponds to the machine they're going to emulate? No, I meant corresponding to the kernel. (Qualifier to the following rant: I'm talking specifically about ARM; I understand PPC is different.) In my experience if you try to use a device tree blob other than the one which you produce from the dts that is shipped with the exact revision of the kernel that you're booting, then it is likely to result in missing devices at best and quite likely random inexplicable crashes. ARM device trees are simply churning way too much at the moment (the usual failure behaviour is device which was driven by board data gets a DT binding, so using an old DT means the kernel doesn't think the device exists at all, but I've seen crashes too). Maybe in a decade we'll be able to claim that device trees are a description of the hardware, but right now the fact is that this is a kernel specific data structure and it's not guaranteed to work with anything other than the kernel it goes with. If somebody reports a this isn't booting kind of bug, are you using the right device tree blob for the kernel? is among the first questions I ask (and I have zero interest in debugging cases where there's a mismatch.) I make a very small exception for mach-virt, because it's entirely device tree driven and there's a very small set of things that appear in it. So we have a reasonable chance of holding kernel peoples' feet to the fire if they try to break existing device trees generated by QEMU or kvmtool. For anything else I am absolutely against having QEMU generate any ARM device tree blobs or do anything beyond the minimal modifications to them we absolutely must. thanks -- PMM ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [PATCH RFC 00/13] qemu: generate acpi tables for the guest
On Tue, 2013-05-14 at 10:38 +0100, Peter Maydell wrote: It depends. For ARM we insist that the user provides the device tree that corresponds to the kernel they're going to run, and then we just tweak it a bit. Um... device trees describe hardware, and should not be at all kernel-specific. Did you mean to say the device tree that corresponds to the machine they're going to emulate? And I suppose you do have a kernel that corresponds to the machine it's going to run on, so what you say isn't *entirely* bogus. But it's just written in a way which makes it scary :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
