On 10/18/2012 11:27 AM, Vasilis Liaskovitis wrote:
> On Wed, Oct 17, 2012 at 12:03:51PM +0200, Avi Kivity wrote:
>> On 10/17/2012 11:19 AM, Vasilis Liaskovitis wrote:
>> >>
>> >> I don't think so, but probably there's a limit of DIMMs that real
>> >> controllers have, something like 8 max.
>> >
>> > In the case of i440fx specifically, do you mean that we should model the DRB
>> > (Dram row boundary registers in section 3.2.19 of the i440fx spec) ?
>> >
>> > The i440fx DRB registers only supports up to 8 DRAM rows (let's say 1 row
>> > maps 1-1 to a DimmDevice for this discussion) and only supports up to 2GB of
>> > memory afaict (bit 31 and above is ignored).
>> >
>> > I 'd rather not model this part of the i440fx - having only 8 DIMMs seems too
>> > restrictive. The rest of the patchset supports up to 255 DIMMs so it would be a
>> > waste imho to model an old pc memory controller that only supports 8 DIMMs.
>> >
>> > There was also an old discussion about i440fx modeling here:
>> > https://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg02705.html
>> > the general direction was that i440fx is too old and we don't want to precisely
>> > emulate the DRB registers, since they lack flexibility.
>> >
>> > Possible solutions:
>> >
>> > 1) is there a newer and more flexible chipset that we could model?
>>
>> Look for q35 on this list.
>
> thanks, I 'll take a look. It sounds like the other options below are more
> straightforward now, but let me know if you prefer q35 integration as a priority.
At least validate that what you're doing fits with how q35 works.
>>
>> >
>> > We could for example model:
>> > - an 8-bit non-cumulative register for each DIMM, denoting how many
>> > 128MB chunks it contains. This allowes 32GB for each DIMM, and with 255 DIMMs we
>> > describe a bit less than 8TB. These registers require 255 bytes.
>> > - a 16-bit cumulative register for each DIMM again for 128MB chunks. This allows
>> > us to describe 8TB of memory (but the registers take up double the space, because
>> > they describe cumulative memory amounts)
>>
>> There is no reason to save space. Why not have two 64-bit registers per
>> DIMM, one describing the size and the other the base address, both in
>> bytes? Use a few low order bits for control.
>
> Do we want this generic scheme above to be tied into the i440fx/pc machine?
Yes. q35 should work according to its own specifications.
> Or have it as a separate generic memory bus / pmc usable by others (e.g. in
> hw/dimm.c)?
> The 64-bit values you describe are already part of DimmDevice properties, but
> they are not hardware registers described as part of a chipset.
>
> In terms of control bits, did you want to mimic some other chipset registers? -
> any examples would be useful.
I don't have any real requirements. Just make it simple and easily
accessible to ACPI code.
>
>>
>> >
>> > 3) let everything be handled/abstracted by dimmbus - the chipset DRB modelling
>> > is not done (at least for i440fx, other machines could). This is the least precise
>> > in terms of emulation. On the other hand, if we are not really trying to emulate
>> > the real (too restrictive) hardware, does it matter?
>>
>> We could emulate base memory using the chipset, and extra memory using
>> the scheme above. This allows guests that are tied to the chipset to
>> work, and guests that have more awareness (seabios) to use the extra
>> features.
>
> But if we use the real i440fx pmc DRBs for base memory, this means base memory
> would be <= 2GB, right?
>
> Sounds like we 'd need to change the DRBs anyway to describe useful amounts of
> base memory (e.g. 512MB chunks and check against address lines [36:29] can
> describe base memory up to 64GB, though that's still limiting for very large
> VMs). But we'd be diverting from the real hardware again.
Then there's no point. Modelling real hardware allows guests written to
work against that hardware to function correctly. If you diverge, they
won't.
>
> Then we can model base memory with "tweaked" i440fx pmc's DRB registers - we
> could only use DRB[0] (one DIMM describing all of base memory) or more.
>
> DIMMs would be allowed to be hotplugged in the generic mem-controller scheme only
> (unless it makes sense to allow hotplug in the remaining pmc DRBs and
> start using the generic scheme once we run out of emulated DRBs)
>
440fx seems a lost cause, so we can go wild and just implement pv dimms.
For q35 I'd like to stay within the spec.
--
error compiling committee.c: too many arguments to function
Hi,
Seabios bits for q35 support, I'm posting the qemu changes separately. The
patches require '-M pc_q35' and -L 'seabios dir with q35 changes' on the
qemu command line. Hopefully, we can make it the default for x86 at some future
point when we feel comfortable with it.
The current patches have been tested with basic install testing and memory testing
on f16, f17, windows 7 and windows 8. They can be run on the various BSD flavors
by adding a 'piix4-ide' device to the pci bus. ie: -device piix4-ide. Patches
have also been reported to work with a small dsdt change on OSX 10.6 as well.
I've dropped the ahci migration bits, which means q35 is not migratable at the
moment. I simply haven't had time to make them more complete yet.
I'm hoping that we'll come to some agreement on the minimal functionality
required for q35 to be merged.
Git trees:
git://github.com/jibaron/q35-qemu.gitgit://github.com/jibaron/q35-seabios.git
Notes:
I've dropped automatic load of the dsdt table on the piix for now. We can't
pull this in until we have snapshot of the dsdt aml, and I wanted it to be
done at a clean seabios freeze point (Although I guess that could be the
current snapshot). I don't see the harm in pulling this in later though.
I've also gone to a model of the pci host being sparse:
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller
00:01.0 VGA compatible controller: Cirrus Logic GD 5446
00:02.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
The idea is only to populate the essential stuff at 1f, and have the rest
filled out via command line options. In this way we have minimal bus configuration
with 1 slot occupied as in piix. Should make things easier for libvirt. And this
way user has complete control over things. For example, I have added support that
when '-usb' is passed the usb controllers for ich9 are filled out.
Todo:
-add ahci migration back (need to cover more fields, but basically works)
-add base addr for hpet in LPC device (for osx per agraf)
-convert hotplug to use MemoryRegionPortio for hotplug (need an IsaDevice?)
Thanks,
-Jason
Changes from v2:
-Patch restructure (broke out ich9 chips + data structures separately)
-added passthrough support
-add support for -usb to fill out host pci bus
-Dropped automatic load of dsdt table for piix
-cleanups
-dropped wmask on smbus (mst)
-sparse host bus
Changes from v1:
-Updated end of low mem from 0xe0000000 -> 0xb0000000 (Gerd Hoffmann)
-so 0xb000000-0xc000000 is memconfig
-0xc000000-0xfec00000 is 32-bit pci window
-style/various cleanups
-introduced IF_AHCI
-introduced mach_if
-split dsdt out of bios, now passed for piix4 as well (Paolo, Gerd)
-Removed add opaque argument to pci_map_irq_fn (Michael S. Tsirkin)
-removed patches that were merged in v1
Isaku Yamahata (5):
seabios: acpi: add mcfg table.
seabios: acpi, fadt: make while fadt initialization chipset specific
seabios: pci: enable SERR of normal device.
seabios: add q35 initialization functions.
seabios: q35: add dsdt
Jan Kiszka (1):
seabios: q35: Register PCI IRQs as active high in APIC mode
Jason Baron (2):
seabios: make mttr UC area setup dynamic
seabios: q35: add basic hotplug support
Makefile | 2 +-
src/acpi.c | 176 ++++++++-
src/acpi.h | 17 +
src/config.h | 1 -
src/dev-q35.h | 46 +++
src/mtrr.c | 5 +-
src/pci.h | 1 +
src/pciinit.c | 87 +++++-
src/post.c | 6 +-
src/q35-acpi-dsdt.dsl | 980 +++++++++++++++++++++++++++++++++++++++++++++++++
src/shadow.c | 13 +
src/smm.c | 37 ++
12 files changed, 1344 insertions(+), 27 deletions(-)
create mode 100644 src/dev-q35.h
create mode 100644 src/q35-acpi-dsdt.dsl
Am Donnerstag, den 18.10.2012, 12:25 +0200 schrieb Christian Gmeiner:
[…]
> USB is finally working :) http://dpaste.com/815054/
Congrats. Please attach such outputs.
> But the next problems says hello: handle_hwpic1 irq=0
[…]
That warrants a new thread, does not it?
Thanks,
Paul
On Wed, Oct 17, 2012 at 07:42:33AM +0200, Christian Gmeiner wrote:
> 2012/10/17 Kevin O'Connor <kevin(a)koconnor.net>:
> > On Tue, Oct 16, 2012 at 04:11:08PM +0200, Christian Gmeiner wrote:
> >> I have made some success to get USB working - current SeaBios ehci
> >> driver does not support toggling between
> >> DATA0 and DATA1. Here is my current patch to get a little bit more running:
> >
> > The toggle bit should be updated automatically by the controller. It
> > should not be necessary to do it manually. If this is impacting your
> > results, something subtle must going on.
> >
>
> Maybe you are right (starred at the spec for some minutes), but who
> updates the toggle bit in the qh?
>
> So I think that this line is needed:
> pipe->qh.token|= (pipe->pipe.toogle?QTD_TOGGLE:0);
The controller is supposed to update the toggle bit in the qh. The
same qh is used for all transfers, so it should already be up to date
between transfers. It is possible something subtle is going on here.
-Kevin
On 10/17/2012 11:19 AM, Vasilis Liaskovitis wrote:
>>
>> I don't think so, but probably there's a limit of DIMMs that real
>> controllers have, something like 8 max.
>
> In the case of i440fx specifically, do you mean that we should model the DRB
> (Dram row boundary registers in section 3.2.19 of the i440fx spec) ?
>
> The i440fx DRB registers only supports up to 8 DRAM rows (let's say 1 row
> maps 1-1 to a DimmDevice for this discussion) and only supports up to 2GB of
> memory afaict (bit 31 and above is ignored).
>
> I 'd rather not model this part of the i440fx - having only 8 DIMMs seems too
> restrictive. The rest of the patchset supports up to 255 DIMMs so it would be a
> waste imho to model an old pc memory controller that only supports 8 DIMMs.
>
> There was also an old discussion about i440fx modeling here:
> https://lists.nongnu.org/archive/html/qemu-devel/2011-07/msg02705.html
> the general direction was that i440fx is too old and we don't want to precisely
> emulate the DRB registers, since they lack flexibility.
>
> Possible solutions:
>
> 1) is there a newer and more flexible chipset that we could model?
Look for q35 on this list.
>
> 2) model and document
^--- the critical bit
> a generic (non-existent) i440fx that would support more
> and larger DIMMs. E.g. support 255 DIMMs. If we want to use a description
> similar to the i440fx DRB registers, the registers would take up a lot of space.
> In i440fx there is one 8-bit DRB register per DIMM, and DRB[i] describes how
> many 8MB chunks are contained in DIMMs 0...i. So, the register values are
> cumulative (and total described memory cannot exceed 256x8MB = 2GB)
Our i440fx has already been extended by support for pci and cpu hotplug,
and I see no reason not to extend it for memory. We can allocate extra
mmio space for registers if needed. Usually I'm against this sort of
thing, but in this case we don't have much choice.
>
> We could for example model:
> - an 8-bit non-cumulative register for each DIMM, denoting how many
> 128MB chunks it contains. This allowes 32GB for each DIMM, and with 255 DIMMs we
> describe a bit less than 8TB. These registers require 255 bytes.
> - a 16-bit cumulative register for each DIMM again for 128MB chunks. This allows
> us to describe 8TB of memory (but the registers take up double the space, because
> they describe cumulative memory amounts)
There is no reason to save space. Why not have two 64-bit registers per
DIMM, one describing the size and the other the base address, both in
bytes? Use a few low order bits for control.
>
> 3) let everything be handled/abstracted by dimmbus - the chipset DRB modelling
> is not done (at least for i440fx, other machines could). This is the least precise
> in terms of emulation. On the other hand, if we are not really trying to emulate
> the real (too restrictive) hardware, does it matter?
We could emulate base memory using the chipset, and extra memory using
the scheme above. This allows guests that are tied to the chipset to
work, and guests that have more awareness (seabios) to use the extra
features.
--
error compiling committee.c: too many arguments to function
ron minnich wrote:
> I don't even know what to say :-)
>
> Checking out SeaBIOS revision 51755c3b5ed9dcdfdef8cee56631d68642bde416
> Already on 'master'
> fatal: reference is not a tree: 51755c3b5ed9dcdfdef8cee56631d68642bde416
Sorry for not testing more thoroughly, the checkout did work for me,
I didn't expect the "regression" caused by:
commit eb129bbcb654d90c331b7898222d64f769c08437
Author: Patrick Georgi <patrick(a)georgi-clan.de>
Date: Wed May 9 21:07:17 2012 +0200
Update SeaBIOS URL
We have a http accessible SeaBIOS mirror at review.coreboot.org.
Use it.
Apparently our http accessible SeaBIOS mirror isn't getting updated,
so the SeaBIOS 1.7.1 release does not exist in what gets cloned.
If the above commit is reverted:
git revert eb129bbcb654d90c331b7898222d64f769c08437
..and the build/seabios directory is deleted, then the build will
work again. I am not sure that this is the right fix however.
I would prefer to have a reliable HTTP URL rather than reverting.
Here is an nginx snippet that allows to serve git http: from the
same virtual host as a gitweb:
location ~* ^/[^/]*\.git {
alias /usr/libexec/git-core/git-http-backend;
include /etc/nginx/fastcgi_params;
fastcgi_param DOCUMENT_ROOT /var/lib/git;
fastcgi_param GIT_PROJECT_ROOT /var/lib/git;
fastcgi_pass
unix:/var/run/spawn-fcgi/git-http;
}
And here's the fcgiwrap start script, to create that FastCGI socket.
All goes on one line of course.
#!/bin/sh
exec spawn-fcgi -n -s /var/run/spawn-fcgi/git-http -u gitweb -U nginx
-d /var/lib/git -f /usr/bin/fcgiwrap
Maybe it can help make direct HTTP access available for the actual
repository. Please let's not mess with mirroring. If nginx+fastcgi
does not fit the current hosting then I guess it will be Apache or
lighttpd, in which case the interwebs should have some snippets
equivalent to the above.
//Peter
All,
I've added code to output.c to implement a I2C console interface.
Everything was working great on my AMD/Persimmon until I added additional code
to determine what south bridge I was on. I'm evidently not correctly handling
the 16/32 bit code segments correctly. It's evident when I run the debugger
and watch the disassembly. Not only is the disassembly wrong but it isn't
even consistent between runs.
The new code is below, along with the modified putc_debug().
Any suggestions would be appreciated.
Thanks,
Dave
#if MODE16
#define FIXUP_CODE_SEG_LOCATION VAR16
#elif MODESEGMENT
#define FIXUP_CODE_SEG_LOCATION VAR32SEG
#else
#define FIXUP_CODE_SEG_LOCATION
#endif
struct amd_i2c_list{
u16 sb_ven;
u16 sb_dev;
u8 sb_ver;
u8 base_access;
};
/* send a debug character to the i2c port */
static void debug_i2c(char data)
{
static int FIXUP_CODE_SEG_LOCATION i2c_amd_iobase = 0;
static int FIXUP_CODE_SEG_LOCATION i2c_inited = 0;
static const FIXUP_CODE_SEG_LOCATION struct amd_i2c_list amd_smbus_table[] = {
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS, 0x39, 2 }, /* ATI/AMD SB700 base in pci space */
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SBX00_SMBUS, 0x42, 1 }, /* ATI/AMD SB800 base in pmreg */
{ PCI_VENDOR_ID_ATI, PCI_DEVICE_ID_ATI_SB900_SM, 0x14, 1 }, /* ATI/AMD SB900 base in pmreg */
};
volatile u16 rd_vendor, rd_device;
volatile u8 rd_ver, base_access;
int i;
u32 x;
if (!CONFIG_DEBUG_I2C)
return;
/* check to see if we already tried init and it failed */
if (i2c_inited && !i2c_amd_iobase)
return;
/* check to see if the base address has been initialized */
if (!i2c_inited) {
i2c_inited=1;
/* check for the AMD/ATI southbridges */
rd_vendor = pci_config_readw(0xA0, 0x00);
rd_device = pci_config_readw(0xA0, 0x02);
rd_ver = pci_config_readb(0xA0, 0x08);
base_access=0;
for (i=0;i < sizeof(amd_smbus_table)/sizeof(amd_smbus_table[0]);++i) {
if ((amd_smbus_table[i].sb_ven==rd_vendor)
&& (amd_smbus_table[i].sb_dev==rd_device)
&& (amd_smbus_table[i].sb_ver==rd_ver)) {
base_access = amd_smbus_table[i].base_access;
break;
}
}
switch (base_access) {
case 1:
/* check the PM regs for the SM bus base address */
outb (0x2D, 0xCD6);
i2c_amd_iobase = inb(0xCD7)<<8;
outb (0x2C, 0xCD6);
i2c_amd_iobase |= inb(0xCD7);
if ((i2c_amd_iobase!=0) && ((i2c_amd_iobase&0x01)==0x01)) {
/* Found a SBx00 base address in PM reg space */
i2c_amd_iobase &= 0xffe0;
}
else {
/* can not find a valid base address */
i2c_amd_iobase = 0;
}
break;
case 2:
/* check PCI config space for SM bus base address */
x = pci_config_readl(0xA0, 0x90);
if ((x!=0) && ((x&0x01)==0x01)) {
/* Found a SBx00 base address in PCI cfg space */
i2c_amd_iobase = (int)(x & 0xffe0);
}
else {
/* can not find a valid base address */
i2c_amd_iobase = 0;
}
break;
default:
i2c_amd_iobase = 0;
break;
}
/* add checks for other vendors SMBUS controllers here */
}
if (i2c_amd_iobase) {
/* this sequence will send out addr/data on the AMD SBx00 smbus */
int timeout=DEBUG_TIMEOUT;
/* check to see if the h/w is idle */
do {
if (!timeout--)
return; // Ran out of time.
}
while ((inb(i2c_amd_iobase) & 0x01)!=0x00);
outb (0xFF, i2c_amd_iobase + 0); // clear error status
outb (0x1F, i2c_amd_iobase + 1); // clear error status
outb (data, i2c_amd_iobase + 3); // tx index
outb (CONFIG_DEBUG_I2C_DEVICE_ADDR, i2c_amd_iobase + 4); // slave address and write bit
outb (0x44, i2c_amd_iobase + 2); // command it to go
/* check to see if the h/w is done */
do {
if (!timeout--)
return; // Ran out of time.
}
while ((inb(i2c_amd_iobase) & 0x01)!=0x00);
}
}
// Write a character to debug port(s).
static void
putc_debug(struct putcinfo *action, char c)
{
if (! CONFIG_DEBUG_LEVEL)
return;
if (CONFIG_DEBUG_IO)
// Send character to debug port.
outb(c, GET_GLOBAL(DebugOutputPort));
if (CONFIG_DEBUG_I2C)
debug_i2c(c);
if (c == '\n')
debug_serial('\r');
debug_serial(c);
}
