Re: [SeaBIOS] Analysis of the current state and proposed future path for SeaBIOS.
Fred . wrote: > Analysis of the current state and proposed future path for SeaBIOS. Please say if and how you want to contribute further. //Peter ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [BUG] [Seabios] PCI 64bit BARs on Win2008 - unable to start the device. (ACPI lacks the _DSM method)
On Wed, Dec 14, 2011 at 05:30:23PM +1300, Alexey Korolev wrote: > Hi, > >> > >>It shouldn't be that hard to add the latter though. seabios needs two > >>more pci_region_type (PCI_REGION_TYPE_MEM_64 and > >>PCI_REGION_TYPE_PREFMEM_64) to track and map 64bit bars separately. And > >>a address space window where it can map 64bit bars to. > >Right. This is a thing I'm thinking about now. I seems that the > >specifying 0x0 address in 64bit BARS is a bad idea. At least older > >versions of Linux just hang as soon as requested range does not > >fit in first 4GB. > >So the only option would be specifying the particular address > >range. It seems this works for everything - yet. > I wonder if there any particular reason to separate prefetchable a > non-prefetchable memory regions in pciinit? Extra two more regions > would make code more complex. If I understand this correctly, the prefmem and normal mem separation is for pci bridges. Devices behind a bridge need to have all their prefmem regions consecutive and not overlapping with all the normal mem ranges. That way the bridge device can advertise just one prefmem region and one normal mem region which encapsulates all the devices behind it. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [BUG] [Seabios] PCI 64bit BARs on Win2008 - unable to start the device. (ACPI lacks the _DSM method)
2. Get a range toward the upper end of the memory, around 1<<40 Yes. This solution works great. And this is very simple as well. Just wondering if it will be good as a complete solution? I would have tried this first too ;) Care to share the patches so we can review& merge them? No worries. Just need to complete and test the code and I'll post RFC patches shortly. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] [BUG] [Seabios] PCI 64bit BARs on Win2008 - unable to start the device. (ACPI lacks the _DSM method)
Hi, It shouldn't be that hard to add the latter though. seabios needs two more pci_region_type (PCI_REGION_TYPE_MEM_64 and PCI_REGION_TYPE_PREFMEM_64) to track and map 64bit bars separately. And a address space window where it can map 64bit bars to. Right. This is a thing I'm thinking about now. I seems that the specifying 0x0 address in 64bit BARS is a bad idea. At least older versions of Linux just hang as soon as requested range does not fit in first 4GB. So the only option would be specifying the particular address range. It seems this works for everything - yet. I wonder if there any particular reason to separate prefetchable a non-prefetchable memory regions in pciinit? Extra two more regions would make code more complex. Regards, Alexey ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] IRQ issues
On Tue, Dec 13, 2011 at 01:44:04PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> Latest seabios master has trouble with interrupts. Running qemu 1.0,
> Fedora 16 (linux kernel 3.1) as guest. Linux ends up disabling both IRQ
> 10 and 11. Device drivers seem to miss interrupts:
>
> ehci_hcd :00:1d.7: Unlink after no-IRQ? Controller is probably
> using the wrong IRQ.
>
> Bisecting points to this commit:
>
> commit a65f417c8430ce6781cbbfe84381a97d60628d81
Looks like RefOf() does something weird on Linux. I hate AML.
The patch below fixes the irq issue for me - can you check as well?
-Kevin
diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
index aff3f48..7082b65 100644
--- a/src/acpi-dsdt.dsl
+++ b/src/acpi-dsdt.dsl
@@ -508,10 +508,6 @@ DefinitionBlock (
}
Return (0x0B)
}
-Method (IQDI, 1, NotSerialized) {
-// _DIS method - disable interrupt
-Or(DerefOf(Arg0), 0x80, Arg0)
-}
Method (IQCR, 1, NotSerialized) {
// _CRS method - get current settings
Name (PRR0, ResourceTemplate ()
@@ -525,11 +521,13 @@ DefinitionBlock (
}
Return (PRR0)
}
-Method (IQSR, 2, NotSerialized) {
-// _SRS method - set interrupt
-CreateDWordField (Arg1, 0x05, PRRI)
-Store (PRRI, Arg0)
-}
+// _DIS method - disable interrupt
+#define DISIRQ(PRQVAR) \
+Or(PRQVAR, 0x80, PRQVAR)\
+// _SRS method - set interrupt
+#define SETIRQ(PRQVAR, IRQINFO) \
+CreateDWordField (IRQINFO, 0x05, PRRI) \
+Store (PRRI, PRQVAR)
Device(LNKA) {
Name(_HID, EISAID("PNP0C0F")) // PCI interrupt link
@@ -539,9 +537,9 @@ DefinitionBlock (
{ 5, 10, 11 }
})
Method (_STA, 0, NotSerialized) { Return (IQST(PRQ0)) }
-Method (_DIS, 0, NotSerialized) { IQDI(RefOf(PRQ0)) }
+Method (_DIS, 0, NotSerialized) { DISIRQ(PRQ0) }
Method (_CRS, 0, NotSerialized) { Return (IQCR(PRQ0)) }
-Method (_SRS, 1, NotSerialized) { IQSR(RefOf(PRQ0), Arg0) }
+Method (_SRS, 1, NotSerialized) { SETIRQ(PRQ0, Arg0) }
}
Device(LNKB) {
Name(_HID, EISAID("PNP0C0F")) // PCI interrupt link
@@ -551,9 +549,9 @@ DefinitionBlock (
{ 5, 10, 11 }
})
Method (_STA, 0, NotSerialized) { Return (IQST(PRQ1)) }
-Method (_DIS, 0, NotSerialized) { IQDI(RefOf(PRQ1)) }
+Method (_DIS, 0, NotSerialized) { DISIRQ(PRQ1) }
Method (_CRS, 0, NotSerialized) { Return (IQCR(PRQ1)) }
-Method (_SRS, 1, NotSerialized) { IQSR(RefOf(PRQ1), Arg0) }
+Method (_SRS, 1, NotSerialized) { SETIRQ(PRQ1, Arg0) }
}
Device(LNKC) {
Name(_HID, EISAID("PNP0C0F")) // PCI interrupt link
@@ -563,9 +561,9 @@ DefinitionBlock (
{ 5, 10, 11 }
})
Method (_STA, 0, NotSerialized) { Return (IQST(PRQ2)) }
-Method (_DIS, 0, NotSerialized) { IQDI(RefOf(PRQ2)) }
+Method (_DIS, 0, NotSerialized) { DISIRQ(PRQ2) }
Method (_CRS, 0, NotSerialized) { Return (IQCR(PRQ2)) }
-Method (_SRS, 1, NotSerialized) { IQSR(RefOf(PRQ2), Arg0) }
+Method (_SRS, 1, NotSerialized) { SETIRQ(PRQ2, Arg0) }
}
Device(LNKD) {
Name(_HID, EISAID("PNP0C0F")) // PCI interrupt link
@@ -575,9 +573,9 @@ DefinitionBlock (
{ 5, 10, 11 }
})
Method (_STA, 0, NotSerialized) { Return (IQST(PRQ3)) }
-Method (_DIS, 0, NotSerialized) { IQDI(RefOf(PRQ3)) }
+Method (_DIS, 0, NotSerialized) { DISIRQ(PRQ3) }
Method (_CRS, 0, NotSerialized) { Return (IQCR(PRQ3)) }
-Method (_SRS, 1, NotSerialized) { IQSR(RefOf(PRQ3), Arg0) }
+Method (_SRS, 1, NotSerialized) { SETIRQ(PRQ3, Arg0) }
}
Device(LNKS) {
Name(_HID, EISAID("PNP0C0F")) // PCI interrupt link
@@ -587,7 +585,7 @@ DefinitionBlock (
{ 9 }
})
Method (_STA, 0, NotSerialized) { Return (IQST(PRQ0)) }
-Method (_DIS, 0, NotSerialized) { IQDI(RefOf(PRQ0)) }
+Method (_DIS, 0, NotSerialized) { DISIRQ(PRQ0) }
Method (_CRS, 0, NotSerialized) { Return (IQCR(PRQ0)) }
}
}
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [SeaBIOS PATCH v3] hotplug: Add device per func in ACPI DSDT tables
On Tue, Dec 06, 2011 at 07:32:55PM -0500, Amos Kong wrote: > - Original Message - > > On Tue, Dec 06, 2011 at 01:39:35PM +0800, Amos Kong wrote: > > > Only func 0 is registered to guest driver (we can > > > only found func 0 in slot->funcs list of driver), > > > the other functions could not be cleaned when > > > hot-removing the whole slot. This patch adds > > > device per function in ACPI DSDT tables. > > > Notify only when func0 is added and removed. > > > > > > Have tested with linux/winxp/win7, hot-adding/hot-remving, > > > single/multiple function device, they are all fine(all > > > added devices can be removed). > > > > > This includes some bits I wrote but this is not an ack > > of the patch yet :) > > > > I find it surprising that this works: a function > > has _EJ0 so would not guest expect that ejecting > > a single one will only remove it, and not all functions? > > Removing single func is not supported by specific, and current code > (qemu/kernel pci driver) process hot-remove with the whole slot. > We could not hot-remove single func with/without this patch. > > Register _EJ0() for each func, then all the funcs will be record > into the function list of the slot. Just as an update - it's not clear to me what this patch does, and it seems like Michael had some concerns. Also, it doesn't seem right to hardcode the generation of that many devices (248) in the AML code. So, unless there are further comments I'm going to hold off on this patch. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
[SeaBIOS] IRQ issues
Hi, Latest seabios master has trouble with interrupts. Running qemu 1.0, Fedora 16 (linux kernel 3.1) as guest. Linux ends up disabling both IRQ 10 and 11. Device drivers seem to miss interrupts: ehci_hcd :00:1d.7: Unlink after no-IRQ? Controller is probably using the wrong IRQ. Bisecting points to this commit: commit a65f417c8430ce6781cbbfe84381a97d60628d81 Author: Kevin O'Connor Date: Sun Sep 25 23:08:58 2011 -0400 Consolidate DSDT copy-and-paste PCI IRQ code into method calls. Use method calls in LNK[ABCDS] object methods - this reduces the cut-and-paste code. It also makes it simpler and the object size smaller. Signed-off-by: Kevin O'Connor Ideas anyone? thanks, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] (no subject)
On Tue, Dec 13, 2011 at 1:34 AM, Peter Stuge wrote: > Fred . wrote: >> A BIOS password would add an additional line of defense and protect >> against booting from a removable device such as CD or USB. > > Compile out those drivers. But those drivers and functionality are great. I would like _ME_ to be able to boot from CD and USB. I just don't want other people to be able to boot from CD and USB. ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [BUG] [Seabios] PCI 64bit BARs on Win2008 - unable to start the device. (ACPI lacks the _DSM method)
Hi, >> Two possible ideas: >> 1. Pass the value in from qemu > Do you mean to create the 64bit region dynamically? I've tried to obtain > RAM size somehow inside DSL code, but the ACPI spec doesn't tell how to > do that. There is a global variable IIRC. You could also check the e820 table passed in from qemu. >> 2. Get a range toward the upper end of the memory, around 1<<40 >> > Yes. This solution works great. And this is very simple as well. Just > wondering if it will be good as a complete solution? I would have tried this first too ;) Care to share the patches so we can review & merge them? thanks, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
