Re: [SeaBIOS] [PATCH v2 0/2] Add IPMI SMBIOS/ACPI support
On Mon, Aug 13, 2012 at 07:07:06PM -0500, Corey Minyard wrote: On 08/13/2012 05:49 PM, Kevin O'Connor wrote: How different are they. Can you give human readable example? Here are the examples from the IPMI spec. I lied a little bit, there are actually four standard interfaces (one can be on an SMBus), but it's a different thing to manage, I think. Does your patch produce all of the four variants you've identified? What fields (if any) are dynamic within the variants? My patch does not do the SMBus variant, as that would need to go into an SMBus device, and I haven't worked at all on an IPMI device to do this. So, the patch supports two variants - IPMI_SMIC and IPMI_BT? The fields that are dynamic are: _STR - A string identifying the interface type (optional, but recommended) But this isn't dynamic within a variant, correct? (That is, if you're using an IPMI_SMIC type device then the _STR will always be IPMI_SMIC?) _CRS - This can be a I/O or a memory address, and an interrupt may or may not be here. I have not done the work to add the memory bus, as my qemu patch does not support that yet. Will the irq and ioports be different within a given variant? _IFT - An integer that identifies the interface type. Again, static within a variant, right? _SRV - Identifies the IPMI spec version the interface complies to. It's generally best to use the actual version; if you used a newer version then an old driver may not work with it. Again, static within a variant, right? If more than one interface is added, then the _UID field becomes important, but there's no support for that at the moment. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v2 0/2] Add IPMI SMBIOS/ACPI support
On 08/13/2012 07:25 PM, Kevin O'Connor wrote: On Mon, Aug 13, 2012 at 07:07:06PM -0500, Corey Minyard wrote: On 08/13/2012 05:49 PM, Kevin O'Connor wrote: How different are they. Can you give human readable example? Here are the examples from the IPMI spec. I lied a little bit, there are actually four standard interfaces (one can be on an SMBus), but it's a different thing to manage, I think. Does your patch produce all of the four variants you've identified? What fields (if any) are dynamic within the variants? My patch does not do the SMBus variant, as that would need to go into an SMBus device, and I haven't worked at all on an IPMI device to do this. So, the patch supports two variants - IPMI_SMIC and IPMI_BT? IPMI_SMIC, IPMI_BT, and IPMI_KCS. So three variants. The fields that are dynamic are: _STR - A string identifying the interface type (optional, but recommended) But this isn't dynamic within a variant, correct? (That is, if you're using an IPMI_SMIC type device then the _STR will always be IPMI_SMIC?) Yes, that is correct. _CRS - This can be a I/O or a memory address, and an interrupt may or may not be here. I have not done the work to add the memory bus, as my qemu patch does not support that yet. Will the irq and ioports be different within a given variant? The I/O ports are somewhat standard. There are spec-recommended places for all of them, and most (but not all) systems use those. Most systems do not support interrupts, but there is no standard for the ones that do. System with the device in memory are all over the place. _IFT - An integer that identifies the interface type. Again, static within a variant, right? Yes, this is what defines the variant, I guess. _SRV - Identifies the IPMI spec version the interface complies to. It's generally best to use the actual version; if you used a newer version then an old driver may not work with it. Again, static within a variant, right? Yes. -corey If more than one interface is added, then the _UID field becomes important, but there's no support for that at the moment. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v2 0/2] Add IPMI SMBIOS/ACPI support
On 08/13/2012 05:49 PM, Kevin O'Connor wrote: On How different are they. Can you give human readable example? Here are the examples from the IPMI spec. I lied a little bit, there are actually four standard interfaces (one can be on an SMBus), but it's a different thing to manage, I think. Does your patch produce all of the four variants you've identified? What fields (if any) are dynamic within the variants? -Kevin My patch does not do the SMBus variant, as that would need to go into an SMBus device, and I haven't worked at all on an IPMI device to do this. The fields that are dynamic are: _STR - A string identifying the interface type (optional, but recommended) _CRS - This can be a I/O or a memory address, and an interrupt may or may not be here. I have not done the work to add the memory bus, as my qemu patch does not support that yet. _IFT - An integer that identifies the interface type. _SRV - Identifies the IPMI spec version the interface complies to. It's generally best to use the actual version; if you used a newer version then an old driver may not work with it. If more than one interface is added, then the _UID field becomes important, but there's no support for that at the moment. -corey ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v2 0/2] Add IPMI SMBIOS/ACPI support
On Sun, Aug 12, 2012 at 08:22:12PM -0500, Corey Minyard wrote: Patch 2 is complex and I don't fully understand what it is doing. A quick scan leads me to believe it is constructing a dynamic SSDT - though it's not clear why a dynamic SSDT is needed and why the existing mechanism (see build_ssdt()) for generating dynamic SSDTs is not used. It is constructing an addition to the DSDT table that is tacked on to the end of that table if IPMI is present. It is complex, but building ACPI namespace data is complex, and the data is not fixed length. You do not need to construct IPMI device dynamically in DSDT. Write it in AML and have _STA method that tells OSPM if device is present or not. -- Gleb. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v2 0/2] Add IPMI SMBIOS/ACPI support
On Mon, Aug 13, 2012 at 09:47:50AM -0500, Corey Minyard wrote: On 08/13/2012 01:25 AM, Gleb Natapov wrote: On Sun, Aug 12, 2012 at 08:22:12PM -0500, Corey Minyard wrote: Patch 2 is complex and I don't fully understand what it is doing. A quick scan leads me to believe it is constructing a dynamic SSDT - though it's not clear why a dynamic SSDT is needed and why the existing mechanism (see build_ssdt()) for generating dynamic SSDTs is not used. It is constructing an addition to the DSDT table that is tacked on to the end of that table if IPMI is present. It is complex, but building ACPI namespace data is complex, and the data is not fixed length. You do not need to construct IPMI device dynamically in DSDT. Write it in AML and have _STA method that tells OSPM if device is present or not. There are lots of different options for IPMI devices. There are three different interface types, with two string lengths. They can all appear at arbitrary places in I/O or memory space. They can have an interrupt or not. I would like to be able to represent all off the possibilities so users can simulate any arbitrary machine they want. I considered writing it in AML 8 times and figuring the offsets to set the various values, but that seems rather messy to me. How different are they. Can you give human readable example? If the real desire is to have a single IPMI device type at a single address with a single interrupt always on, we could do that. The BIOS would still need a way to know that the device was present or not, so something will have to be passed. I'm not sure that reading from the standard address to detect the device is reliable enough, but that could be done, too. -corey -- Gleb. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v2 0/2] Add IPMI SMBIOS/ACPI support
On 08/13/2012 01:25 AM, Gleb Natapov wrote: On Sun, Aug 12, 2012 at 08:22:12PM -0500, Corey Minyard wrote: Patch 2 is complex and I don't fully understand what it is doing. A quick scan leads me to believe it is constructing a dynamic SSDT - though it's not clear why a dynamic SSDT is needed and why the existing mechanism (see build_ssdt()) for generating dynamic SSDTs is not used. It is constructing an addition to the DSDT table that is tacked on to the end of that table if IPMI is present. It is complex, but building ACPI namespace data is complex, and the data is not fixed length. You do not need to construct IPMI device dynamically in DSDT. Write it in AML and have _STA method that tells OSPM if device is present or not. There are lots of different options for IPMI devices. There are three different interface types, with two string lengths. They can all appear at arbitrary places in I/O or memory space. They can have an interrupt or not. I would like to be able to represent all off the possibilities so users can simulate any arbitrary machine they want. I considered writing it in AML 8 times and figuring the offsets to set the various values, but that seems rather messy to me. If the real desire is to have a single IPMI device type at a single address with a single interrupt always on, we could do that. The BIOS would still need a way to know that the device was present or not, so something will have to be passed. I'm not sure that reading from the standard address to detect the device is reliable enough, but that could be done, too. -corey ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v2 0/2] Add IPMI SMBIOS/ACPI support
On Fri, Aug 10, 2012 at 08:48:58AM -0500, Corey Minyard wrote: On 08/08/2012 11:11 AM, miny...@acm.org wrote: I went ahead and kept the structure passing because I've added ACPI support. After thinking about it a while, I think if you have to pass anything to SMBIOS (like IPMI is present) you might as well pass the whole structure, and making things fixed in the BIOS that can change in the hardware doesn't seem like a good idea. Note that the acpi-element code might make building the SSDT table a little cleaner, if that is interesting. I haven't heard anything on this patch set. Any comments? Patch 1 has the same problem as the last set - it introduces a new struct to carry info from QEMU to SeaBIOS when a standard struct (smbios) already exists. Patch 2 is complex and I don't fully understand what it is doing. A quick scan leads me to believe it is constructing a dynamic SSDT - though it's not clear why a dynamic SSDT is needed and why the existing mechanism (see build_ssdt()) for generating dynamic SSDTs is not used. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v2 0/2] Add IPMI SMBIOS/ACPI support
On 08/12/2012 07:49 PM, Kevin O'Connor wrote: On Fri, Aug 10, 2012 at 08:48:58AM -0500, Corey Minyard wrote: On 08/08/2012 11:11 AM, miny...@acm.org wrote: I went ahead and kept the structure passing because I've added ACPI support. After thinking about it a while, I think if you have to pass anything to SMBIOS (like IPMI is present) you might as well pass the whole structure, and making things fixed in the BIOS that can change in the hardware doesn't seem like a good idea. Note that the acpi-element code might make building the SSDT table a little cleaner, if that is interesting. I haven't heard anything on this patch set. Any comments? Patch 1 has the same problem as the last set - it introduces a new struct to carry info from QEMU to SeaBIOS when a standard struct (smbios) already exists. That structure is also used by the ACPI code to build the ACPI structure. The data in the SMBIOS structure is not sufficient to build the ACPI structure. Patch 2 is complex and I don't fully understand what it is doing. A quick scan leads me to believe it is constructing a dynamic SSDT - though it's not clear why a dynamic SSDT is needed and why the existing mechanism (see build_ssdt()) for generating dynamic SSDTs is not used. It is constructing an addition to the DSDT table that is tacked on to the end of that table if IPMI is present. It is complex, but building ACPI namespace data is complex, and the data is not fixed length. -corey ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v2 0/2] Add IPMI SMBIOS/ACPI support
On 08/08/2012 11:11 AM, miny...@acm.org wrote: I went ahead and kept the structure passing because I've added ACPI support. After thinking about it a while, I think if you have to pass anything to SMBIOS (like IPMI is present) you might as well pass the whole structure, and making things fixed in the BIOS that can change in the hardware doesn't seem like a good idea. Note that the acpi-element code might make building the SSDT table a little cleaner, if that is interesting. I haven't heard anything on this patch set. Any comments? -corey ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] [PATCH v2 0/2] Add IPMI SMBIOS/ACPI support
I went ahead and kept the structure passing because I've added ACPI support. After thinking about it a while, I think if you have to pass anything to SMBIOS (like IPMI is present) you might as well pass the whole structure, and making things fixed in the BIOS that can change in the hardware doesn't seem like a good idea. Note that the acpi-element code might make building the SSDT table a little cleaner, if that is interesting. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
