[Qemu-devel] Isochronous devices support in QEMU
Hi all, I've few questions about QEMU: 1) I read in QEMU's official documentation that in case of using host system devices "USB devices requiring real time streaming (i.e. USB Video Cameras) are not supported yet". Also there is no isochronous transfer based virtual USB device in QEMU. I want to know what is current status of Iso. support in QEMU? Can I test my Linux based USB host application for ARM with physical iso devices in host USB port? 2) I found a function "ohci_service_iso_td" in usb-ohci.c file in QEMU source code. 3) I am developing a Linux based USB device using Gadget API. Does QEMU provide USB function controller emulation in such a way that I can run plug this USB device at run time with host machine and can test it? Regards, Taimoor _ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969
[Qemu-devel] SeaBIOS error with Nextstep bootloader
Ok, QEMU is absolutely unable to boot nextstep/openstep, while using SeaBIOS. Changing to old Bochs BIOS, makes it work, however no video is output (until NeXT starts using VESA). Until all that numerous issues with SeaBIOS are solved (may the keyboard problem with DOS' Scandisk be also a BIOS problem -needs to test-) Bochs BIOS should continue to be included at least as a command line option (like -use-old-bios) I attached images. <> <>
[Qemu-devel] Re: Commit 085219f79cad broke Sparc-32 back in 2.6.28.
On Sunday 21 February 2010 18:28:20 Bartlomiej Zolnierkiewicz wrote: > On Monday 22 February 2010 12:57:19 am David Miller wrote: > > From: Rob Landley > > Date: Sun, 21 Feb 2010 10:25:09 -0600 > > > > > 085219f79cad89291699bd2bfb21c9fdabafe65f is first bad commit > > > commit 085219f79cad89291699bd2bfb21c9fdabafe65f > > > Author: Sam Ravnborg > > > Date: Fri Jan 2 18:47:34 2009 -0800 > > > > > > sparc32: use proper types in struct stat > > > > > > Like sparc64 use proper types in struct stat > > > > > > Signed-off-by: Sam Ravnborg > > > Signed-off-by: David S. Miller > > > > > > This commit breaks stat and makes sparc32 essentially unusable. It > > > changes the size of the various types in stat.h, and means that if you > > > "mount -t tmpfs /tmp /tmp" and then try to ls /tmp, ls dies with a > > > memory allocation error. > > > > > > I've confirmed that reverting it fixes the problem. > > > > Thanks for tracking this down Rob, I'll work on a fix and > > push it around. > > Looking at how whole sparc32 has been apparently broken for over a year now > because of a purely cleanup patch I wonder if it would be appropriate to > make sparc32 into 'legacy only' and provide 'a stability promise' for it? > > Just an idea.. ;) Actually, the problem is that lots of people seem to expect current kernels to be broken on non-x86 targets, so they keep using old versions. (In the case of the debian release everybody kept pointing me to on "but it works fine!" grounds, a 2.6.18 kernel.) Lots of them only upgrade once idiots like me have gone across the minefield and made it safe. :) "Current is always broken so nobody uses current" != "nobody uses this platform". More "sparc people use distros rather than building their own systems from source, and tend not to be aggressive about upgrading". Back in 2007 arm was broken for me for two or three releases (according to my blog it broke in 2.6.20 and the patch that fixed it ( http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4454/1 ) was not yet in 2.6.22-rc7. That doesn't mean arm isn't widely used, just that nobody with that hardware was seriously trying to use the current version of the kernel. My Firmware LInux project is working on implementing automated regression testing under QEMU. Once I've got a platform working (which sparc wasn't until now) I can provide much more prompt breakage reports in future, at least for the basic stuff like this... Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds
Re: [Qemu-devel] SeaBIOS error with Juniper FreeBSD kernel
> On Sat, Feb 20, 2010 at 9:05 PM, Kevin O'Connor wrote: >> Should a kernel fail during boot, I'd suspect it doesn't like one of >> the apm/pcibios callbacks, or it doesn't like one of the >> smbios/mptable/acpi tables. You could try compiling the SeaBIOS code >> (see http://seabios.org/Download ) and increasing the debugging by >> modifying src/config.h. Specifically, you could increase >> CONFIG_DEBUG_LEVEL, and set DEBUG_HDL_pcibios32 and DEBUG_HDL_apm to >> 1. Also, you could try disabling some of the features to see if that >> prevents the fault (eg, disabling CONFIG_ACPI / CONFIG_SMBIOS / >> CONFIG_MPTABLE). > I have narrowed it down to SMBIOS. If I disable CONFIG_SMBIOS the image boots up fine. -Brandon
Re: [Qemu-devel] SeaBIOS error with Juniper FreeBSD kernel
On Sat, Feb 20, 2010 at 9:05 PM, Kevin O'Connor wrote: > On Sat, Feb 20, 2010 at 05:23:59PM -0700, Brandon Bennett wrote: >> When booting a Juniper JunOS kernel (FreeBSD based) I am getting a >> panic: unkown/reserved trap error immediately after the kernel loads. >> If i use an older pc-bios with the '-bios' option everything works so >> it seems to be an issue with the SeaBios. >> >> With #DEBUG_BIOS enabled in hw/pc.c here is what i am getting during boot. > > Thanks Brandon, > > I don't see anything in the log that looks suscpicious. Are these > JunOS images available for download somewhere? JunOS is the operating system that runs on Juniper Networks Routers. The routers control plane is made up of standard x86 hardware so you an run the software on a standard x86 box or hardware virtualizer like qemu to run labs to test configurations and study for new tests, etc. This is called an Olive. You can read more about it here http://juniper.cluepon.net/index.php/Olive It's not freely available. > Should a kernel fail during boot, I'd suspect it doesn't like one of > the apm/pcibios callbacks, or it doesn't like one of the > smbios/mptable/acpi tables. You could try compiling the SeaBIOS code > (see http://seabios.org/Download ) and increasing the debugging by > modifying src/config.h. Specifically, you could increase > CONFIG_DEBUG_LEVEL, and set DEBUG_HDL_pcibios32 and DEBUG_HDL_apm to > 1. Also, you could try disabling some of the features to see if that > prevents the fault (eg, disabling CONFIG_ACPI / CONFIG_SMBIOS / > CONFIG_MPTABLE). I turned up the CONFIG_DEBUG_LEVEL to 8 and left DEBUG_HDL_pcibios and DEBUG_HDL_apm at 9. I'll play around with disabling the various options you stated above in a bit. Here is the output from that debug: bbenn...@strongbad:~/Lab/JNCIP-M$ qemu -m 512m -hda olive-base-8.1R4.3.img -cdrom 4.11-RELEASE-i386-miniinst.iso -boot c -nographic -bios ~/Devel/out-debug/bios.bin Start bios (version pre-0.5.2-20100221_145730-ubuntu) enabling shadow ram init ivt init bda Find memory size Add to e820 map: 2000 1 Add to e820 map: 1 Add to e820 map: fffc 0004 2 Add to e820 map: 000a 0005 -1 Add to e820 map: 0009f400 0c00 2 Add to e820 map: 000f 0001 2 Ram Size=0x2000 (0x high) malloc setup Add to e820 map: 1fff 0001 2 init pic init timer tsc calibrate start=42359373 end=47360586 diff=5001213 CPU Mhz=2913 math cp init qemu_cfg_present=1 Found 1 cpu(s) max supported 1 cpu(s) pci setup PIIX3/PIIX4 init: elcr=00 0c PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237 PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000 PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010 region 4: 0xc000 PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113 PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8 region 0: 0xf000 region 1: 0xf200 region 6: 0xf201 PCI: bus=0 devfn=0x18: vendor_id=0x8086 device_id=0x100e region 0: 0xf202 region 1: 0xc040 region 6: 0xf204 init smm init bios32 init PMM init PNPBIOS table init keyboard init mouse init PIR table init MPTable pmm_malloc zone=0x000f640c handle= size=32768 align=10 ret=0x1ffe7fe0 (info=0x1ffeffe0) pmm_malloc zone=0x000f63f4 handle= size=224 align=10 ret=0x000f7ec0 (info=0x1ffe7fc0) pmm_malloc zone=0x000f63f4 handle= size=16 align=10 ret=0x000f7eb0 (info=0x1ffe7fa0) pmm_free data=0x1ffe7fe0 olddata=0x1ffeffe0 oldallocdata=0x1fff info=0x1ffeffe0 MP table addr=0x000f7eb0 MPC table addr=0x000f7ec0 size=224 init SMBIOS tables pmm_malloc zone=0x000f640c handle= size=32768 align=10 ret=0x1ffdff80 (info=0x1ffe7f80) pmm_malloc zone=0x000f63f4 handle= size=31 align=10 ret=0x000f7e90 (info=0x1ffdff60) pmm_malloc zone=0x000f63e8 handle= size=263 align=10 ret=0x1ef0 (info=0x1ffdff40) SMBIOS ptr=0x000f7e90 table=0x1ef0 pmm_free data=0x1ffdff80 olddata=0x1ffe7f80 oldallocdata=0x1ffe7fa0 info=0x1ffe7f80 init ACPI tables pmm_malloc zone=0x000f63f4 handle= size=36 align=10 ret=0x000f7e60 (info=0x1ffdff20) pmm_malloc zone=0x000f63e8 handle= size=116 align=10 ret=0x1e70 (info=0x1ffdff00) pmm_malloc zone=0x000f63e8 handle= size=64 align=40 ret=0x1e00 (info=0x1ffdfee0) pmm_malloc zone=0x000f63e8 handle= size=7714 align=10 ret=0x1fffdfd0 (info=0x1ffdfec0) pmm_malloc zone=0x000f63e8 handle= size=56 align=10 ret=0x1fffdf90 (info=0x1ffdfea0) pmm_malloc zone=0x000f63e8 handle= size=224 align=10 ret=0x1fffdeb0 (info=0x1ffdfe80) pmm_malloc zone=0x000f63e8 handle= size=56 align=10 ret=0x1fffde70 (info=0x1ffdfe60) pmm_malloc zone=0x000f63e8 handle= size=52 align=10 ret=0x1fffde30 (info=0x1ffdfe40) ACPI tables: RSDP=0x000f7e60 RSDT=0x1fffde30 Scan for VGA option rom Attempting to init PCI bdf 00:02.0 (dev/ven 00b81013) Attempting to map option rom on dev 00:02.0 Option rom sizing returned f201 In
[Qemu-devel] Re: [PATCH 11/20] eepro100: Use symbolic names for bits in EEPROM id
Michael S. Tsirkin schrieb:
> On Sun, Feb 14, 2010 at 05:16:20PM +0100, Stefan Weil wrote:
>> Signed-off-by: Stefan Weil
>> ---
>> hw/eepro100.c | 17 -
>> 1 files changed, 16 insertions(+), 1 deletions(-)
>>
>> diff --git a/hw/eepro100.c b/hw/eepro100.c
>> index c647322..01bcd6d 100644
>> --- a/hw/eepro100.c
>> +++ b/hw/eepro100.c
>> @@ -272,6 +272,21 @@ typedef enum {
>> eeprom_smbus_addr = 0x90,
>> } EEPROMOffset;
>>
>> +/* Bit values for EEPROM ID word. */
>> +typedef enum {
>> + eeprom_id_mdm = BIT(0), /* Modem */
>> + eeprom_id_stb = BIT(1), /* Standby Enable */
>> + eeprom_id_wmr = BIT(2), /* ??? */
>> + eeprom_id_wol = BIT(5), /* Wake on LAN */
>> + eeprom_id_dpd = BIT(6), /* Deep Power Down */
>> + eeprom_id_alt = BIT(7), /* */
>> + /* BITS(10, 8) device revision */
>> + eeprom_id_bd = BIT(11), /* boot disable */
>> + eeprom_id_id = BIT(13), /* id bit */
>> + /* BITS(15, 14) signature */
>> + eeprom_id_valid = BIT(14), /* signature for valid eeprom */
>> +} eeprom_id_bit;
>
> The type name is unused - don't add it?
Maybe it will be used some day?
Adding a type name now makes the code more uniform
and avoids two deltas when it is used.
There are a lot of symbolic names which are unused
today, for example most of above enum values.
This is common practice.
> Can constants be upper case?
Of course they can. Is this a QEMU coding convention?
I did not see a hint in CODING_STYLE.
If it is the coding style: UPPER_CASE or CamelCase?
Will it be required for all future modifications
of QEMU code?
>
>
>> +
>> /* Default values for MDI (PHY) registers */
>> static const uint16_t eepro100_mdi_default[] = {
>> /* MDI Registers 0 - 6, 7 */
>> @@ -643,7 +658,7 @@ static void nic_selective_reset(EEPRO100State * s)
>> uint16_t *eeprom_contents = eeprom93xx_data(s->eeprom);
>> //~ eeprom93xx_reset(s->eeprom);
>> memcpy(eeprom_contents, s->conf.macaddr.a, 6);
>> - eeprom_contents[eeprom_id] = 0x4000;
>> + eeprom_contents[eeprom_id] = eeprom_id_valid;
>> if (s->device == i82557B || s->device == i82557C)
>> eeprom_contents[5] = 0x0100;
>> eeprom_contents[eeprom_phy_id] = 1;
>> --
>> 1.6.6.1
>>
>>
[Qemu-devel] Re: [PATCH 05/20] eepro100: Add all supported devices to pci.c
Michael S. Tsirkin schrieb:
> On Sun, Feb 14, 2010 at 05:16:14PM +0100, Stefan Weil wrote:
>
>> All eepro100 devices work with drivers which
>> only use basic features.
>>
>> They were tested with gpxe boot.
>>
>> Signed-off-by: Stefan Weil
>> ---
>> hw/pci.c | 18 ++
>> 1 files changed, 18 insertions(+), 0 deletions(-)
>>
>> diff --git a/hw/pci.c b/hw/pci.c
>> index eb2043e..1ba3f92 100644
>> --- a/hw/pci.c
>> +++ b/hw/pci.c
>> @@ -1436,9 +1436,18 @@ void do_pci_info(Monitor *mon, QObject **ret_data)
>>
>> static const char * const pci_nic_models[] = {
>> "ne2k_pci",
>> +"i82550",
>> "i82551",
>> +"i82557a",
>> "i82557b",
>> +"i82557c",
>> +"i82558a",
>> +"i82558b",
>> +"i82559a",
>> +"i82559b",
>> +"i82559c",
>> "i82559er",
>> +"i82562",
>> "rtl8139",
>> "e1000",
>> "pcnet",
>> @@ -1448,9 +1457,18 @@ static const char * const pci_nic_models[] = {
>>
>> static const char * const pci_nic_names[] = {
>> "ne2k_pci",
>> +"i82550",
>> "i82551",
>> +"i82557a",
>> "i82557b",
>> +"i82557c",
>> +"i82558a",
>> +"i82558b",
>> +"i82559a",
>> +"i82559b",
>> +"i82559c",
>> "i82559er",
>> +"i82562",
>> "rtl8139",
>> "e1000",
>> "pcnet",
>>
>
> One wonders: would it be cleaner to have a single eepro100 device
> with specific model as qdev option?
Technically that would be possible, too.
You could even have a single pci ethernet device and
specify vendor and device id as qdev options.
I prefer the "official" device names which are also
used in the Intel documentation. eepro100 or e100
are marketing names (more of them exist).
Please note that this patch was marked as optional.
The arrays pci_nic_names and pci_nic_models are
not really needed, and as soon as the table of available
nics is automatically derived from the device information,
all variants of i825xx are supported automatically.
Regards
Stefan Weil
[Qemu-devel] Re: [PATCH] Seabios e820 reservation portion v3
On Tue, Feb 16, 2010 at 09:46:08AM +0100, Jes Sorensen wrote: > On 02/16/10 01:43, Kevin O'Connor wrote: > >On Mon, Feb 15, 2010 at 06:33:59PM +0100, Jes Sorensen wrote: > >>Hi, > >> > >>This is the Seabios part to match my e820 reservation via fw_cfg patch. > > > >This still has 'struct e820_entry' which is too similar to 'struct > >e820entry' in memmap.h. Otherwise, it looks good to me. > > Hmmm didn't catch that one earlier, thanks for pointing it out. I have > renamed it to struct e820_reservation to make it different. > > Hope this version does the trick then. Thanks - commit 0360e8e6. -Kevin
Re: [Qemu-devel] [PATCH] QEMU e820 reservation patch
On Sun, Feb 21, 2010 at 06:44:55PM +0100, Jes Sorensen wrote: > On 02/19/10 22:02, Anthony Liguori wrote: > >I noticed that you use this for the TSS page with EPT but you don't use > >this interface for the rest of memory. I'm curious what you think the > >right long term split is? If QEMU is not managing the full e820 table, > >can we reasonable add entries on our own? > > I'd like to have QEMU handle more, I picked the TSS page because we > changed the location of that in the past and it was the one that > triggered my patch in the first place. Now we have the infrastructure, > it will be easier to add more. What parts of the memory map do you envision qemu managing? On qemu, SeaBIOS manages the map for ram under 1M, creates the map for high-memory based on the max memory sizes located in cmos, and it manages reserved entries for the acpi/smbios tables. (It also adds an entry for the rom (the last 256K of the 4gig space), which, BTW, would be nice to include in your patch.) Interestingly, on coreboot, SeaBIOS reads the memory map from coreboot and calculates the max memory sizes (the opposite of what it does on qemu). Also, it's coreboot that generates the bios tables - SeaBIOS uses the passed in memory map to locate the tables and copy the required parts into the f-segment. Are you thinking of moving qemu more torwards what coreboot does, or did you have a different idea in mind? -Kevin
Re: [Qemu-devel] [PATCH] QEMU e820 reservation patch
On 02/19/10 22:02, Anthony Liguori wrote: Acked-by: Anthony Liguori Would be nice to use git-send-email in the future as your attachments are often rendered poorly by mail clients. Just switching over from quilt to git, and still having issues with git-send-email. It does some things nicely, other things are a pain in the b**t with it, especially for single patch submissions. I noticed that you use this for the TSS page with EPT but you don't use this interface for the rest of memory. I'm curious what you think the right long term split is? If QEMU is not managing the full e820 table, can we reasonable add entries on our own? I'd like to have QEMU handle more, I picked the TSS page because we changed the location of that in the past and it was the one that triggered my patch in the first place. Now we have the infrastructure, it will be easier to add more. Cheers, Jes
[Qemu-devel] qemu-kvm 0.12.2 VNC segfault
I've just had a segfault from one of the qemu-kvm virtual machines we run.
This is qemu-kvm 0.12.2 running with the in-kernel kvm modules on linux
2.6.32.7 on a dual quad-core Xeon E5420 machine, with ksm enabled.
The backtrace looks like
#0 vnc_update_client (vs=0x83f0, has_dirty=18) at vnc.c:908
#1 0x004c015b in vnc_refresh (opaque=) at
vnc.c:2305
#2 0x00405f50 in qemu_run_timers (ptimer_head=0x836cc0,
current_time=1606536889) at /packages/qemu-kvm-0.12/src-gktOMQ/vl.c:1127
#3 0x00408edf in main_loop_wait (timeout=1000) at
/packages/qemu-kvm-0.12/src-gktOMQ/vl.c:4036
#4 0x00421d7a in kvm_main_loop () at
/packages/qemu-kvm-0.12/src-gktOMQ/qemu-kvm.c:2121
#5 0x0040b755 in main (argc=,
argv=0x7fffcc2fa1b8, envp=) at
/packages/qemu-kvm-0.12/src-gktOMQ/vl.c:4209
and the segfault itself is rather puzzling.
#0 vnc_update_client (vs=0x83f0, has_dirty=18) at vnc.c:908
908 if (vs->need_update && vs->csock != -1) {
(gdb) p vs
$1 = (VncState *) 0x83f0
(gdb) p *vs
Cannot access memory at address 0x83f0
The call site in vnc_refresh() looks like:
vs = vd->clients;
while (vs != NULL) {
rects += vnc_update_client(vs, has_dirty);
vs = vs->next;
}
but when I go up a stack frame and look at the vd over which this loop would be
iterating:
(gdb) up
#1 0x004c015b in vnc_refresh (opaque=) at
vnc.c:2305
2305rects += vnc_update_client(vs, has_dirty);
(gdb) p *vd->clients
$2 = {csock = 17, ds = 0x19b2760, dirty = {{0, 0, 0, 0} ,
{50331648, 0, 0, 0}, {50331648, 0, 0, 0}, {50331648, 0, 0, 0}, {50331648, 0, 0,
0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0}, {16777216,
0, 0, 0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0}, {16777216, 0, 0, 0},
{16777216, 0, 0, 0}, {50331648, 0, 0, 0}, {0, 0, 0, 0} },
vd = 0x1ef60b0, need_update = 0, force_update = 0, features = 0, absolute = 0,
last_x = -1, last_y = -1, vnc_encoding = 0, tight_quality = 0 '\0',
tight_compression = 0 '\0', major = 0, minor = 0, challenge = '\0' , output = {capacity = 1036, offset = 0, buffer = 0x1ec7420 "RFB
003.008\n¦\177"}, input = {capacity = 0, offset = 0, buffer = 0x0},
write_pixels = 0, send_hextile_tile = 0, clientds = {flags = 0 '\0', width = 0,
height = 0, linesize = 0, data = 0x0, pf = {bits_per_pixel = 0 '\0',
bytes_per_pixel = 0 '\0', depth = 0 '\0', rmask = 0, gmask = 0, bmask = 0,
amask = 0, rshift = 0 '\0', gshift = 0 '\0', bshift = 0 '\0', ashift = 0 '\0',
rmax = 0 '\0', gmax = 0 '\0', bmax = 0 '\0', amax = 0 '\0', rbits = 0 '\0',
gbits = 0 '\0', bbits = 0 '\0', abits = 0 '\0'}}, audio_cap = 0x0, as = {freq =
44100, nchannels = 2, fmt = AUD_FMT_S16, endianness = 0}, read_handler =
0x4bdb30 , read_handler_expect = 12, modifiers_state = '\0'
, zlib = {capacity = 0, offset = 0, buffer = 0x0}, zlib_tmp
= {capacity = 0, offset = 0, buffer = 0x0}, zlib_stream = {{next_in = 0x0,
avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg =
0x0, state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0, data_type = 0, adler =
0, reserved = 0}, {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0,
avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0, zfree = 0,
opaque = 0x0, data_type = 0, adler = 0, reserved = 0}, {next_in = 0x0, avail_in
= 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out = 0, msg = 0x0,
state = 0x0, zalloc = 0, zfree = 0, opaque = 0x0, data_type = 0, adler = 0,
reserved = 0}, {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0,
avail_out = 0, total_out = 0, msg = 0x0, state = 0x0, zalloc = 0, zfree = 0,
opaque = 0x0, data_type = 0, adler = 0, reserved = 0}}, next = 0x0}
(gdb) p vd->clients.next
$3 = (VncState *) 0x0
So the first client in vd is fine, and the next pointer is set to zero, not
0x83f0.
Some sort of race where a client disconnects and is removed from the client
list while the vnc_refresh() loop is iterating over it, maybe?
Cheers,
Chris.
[Qemu-devel] Re: [PATCH 11/20] eepro100: Use symbolic names for bits in EEPROM id
On Sun, Feb 14, 2010 at 05:16:20PM +0100, Stefan Weil wrote:
> Signed-off-by: Stefan Weil
> ---
> hw/eepro100.c | 17 -
> 1 files changed, 16 insertions(+), 1 deletions(-)
>
> diff --git a/hw/eepro100.c b/hw/eepro100.c
> index c647322..01bcd6d 100644
> --- a/hw/eepro100.c
> +++ b/hw/eepro100.c
> @@ -272,6 +272,21 @@ typedef enum {
> eeprom_smbus_addr = 0x90,
> } EEPROMOffset;
>
> +/* Bit values for EEPROM ID word. */
> +typedef enum {
> +eeprom_id_mdm = BIT(0), /* Modem */
> +eeprom_id_stb = BIT(1), /* Standby Enable */
> +eeprom_id_wmr = BIT(2), /* ??? */
> +eeprom_id_wol = BIT(5), /* Wake on LAN */
> +eeprom_id_dpd = BIT(6), /* Deep Power Down */
> +eeprom_id_alt = BIT(7), /* */
> +/* BITS(10, 8) device revision */
> +eeprom_id_bd = BIT(11), /* boot disable */
> +eeprom_id_id = BIT(13), /* id bit */
> +/* BITS(15, 14) signature */
> +eeprom_id_valid = BIT(14), /* signature for valid eeprom */
> +} eeprom_id_bit;
The type name is unused - don't add it?
Can constants be upper case?
> +
> /* Default values for MDI (PHY) registers */
> static const uint16_t eepro100_mdi_default[] = {
> /* MDI Registers 0 - 6, 7 */
> @@ -643,7 +658,7 @@ static void nic_selective_reset(EEPRO100State * s)
> uint16_t *eeprom_contents = eeprom93xx_data(s->eeprom);
> //~ eeprom93xx_reset(s->eeprom);
> memcpy(eeprom_contents, s->conf.macaddr.a, 6);
> -eeprom_contents[eeprom_id] = 0x4000;
> +eeprom_contents[eeprom_id] = eeprom_id_valid;
> if (s->device == i82557B || s->device == i82557C)
> eeprom_contents[5] = 0x0100;
> eeprom_contents[eeprom_phy_id] = 1;
> --
> 1.6.6.1
>
>
[Qemu-devel] Re: [PATCH 05/20] eepro100: Add all supported devices to pci.c
On Sun, Feb 14, 2010 at 05:16:14PM +0100, Stefan Weil wrote:
> All eepro100 devices work with drivers which
> only use basic features.
>
> They were tested with gpxe boot.
>
> Signed-off-by: Stefan Weil
> ---
> hw/pci.c | 18 ++
> 1 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/hw/pci.c b/hw/pci.c
> index eb2043e..1ba3f92 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -1436,9 +1436,18 @@ void do_pci_info(Monitor *mon, QObject **ret_data)
>
> static const char * const pci_nic_models[] = {
> "ne2k_pci",
> +"i82550",
> "i82551",
> +"i82557a",
> "i82557b",
> +"i82557c",
> +"i82558a",
> +"i82558b",
> +"i82559a",
> +"i82559b",
> +"i82559c",
> "i82559er",
> +"i82562",
> "rtl8139",
> "e1000",
> "pcnet",
> @@ -1448,9 +1457,18 @@ static const char * const pci_nic_models[] = {
>
> static const char * const pci_nic_names[] = {
> "ne2k_pci",
> +"i82550",
> "i82551",
> +"i82557a",
> "i82557b",
> +"i82557c",
> +"i82558a",
> +"i82558b",
> +"i82559a",
> +"i82559b",
> +"i82559c",
> "i82559er",
> +"i82562",
> "rtl8139",
> "e1000",
> "pcnet",
One wonders: would it be cleaner to have a single eepro100 device
with specific model as qdev option?
--
MST
[Qemu-devel] Commit 085219f79cad broke Sparc-32 back in 2.6.28.
On Saturday 20 February 2010 17:12:22 Rob Landley wrote: > On Saturday 20 February 2010 15:59:31 Blue Swirl wrote: > > > I've got 2.6.32 booting to a command prompt (albeit with serial console > > > and intentionall restricted set of hardware). But then it misbehaves. > > > > > > I'll try getting 2.6.18 to build with a known .config, and then bisect > > > forward if that seems to work... > > > > Good plan. Bisecting backwards could be interesting too, to find out > > which releases are actually working out of the box. > > I started by iterating through the release versions. It's working up > through 2.6.28, then 2.6.29 has the out of memory error in my init script. > > Bisecting now... > > Rob And the commit that broke it bisects to: 085219f79cad89291699bd2bfb21c9fdabafe65f is first bad commit commit 085219f79cad89291699bd2bfb21c9fdabafe65f Author: Sam Ravnborg Date: Fri Jan 2 18:47:34 2009 -0800 sparc32: use proper types in struct stat Like sparc64 use proper types in struct stat Signed-off-by: Sam Ravnborg Signed-off-by: David S. Miller This commit breaks stat and makes sparc32 essentially unusable. It changes the size of the various types in stat.h, and means that if you "mount -t tmpfs /tmp /tmp" and then try to ls /tmp, ls dies with a memory allocation error. I've confirmed that reverting it fixes the problem. Looking at the actual diff, here's the hunk that causes problems: --- a/arch/sparc/include/asm/stat_32.h +++ b/arch/sparc/include/asm/stat_32.h short st_nlink; - unsigned short st_uid; - unsigned short st_gid; + uid_t st_uid; + gid_t st_gid; The symptom (in my uClibc+busybox root filesystem) is: / # mount -t tmpfs /tmp /tmp / # ls -l /tmp ls: can't open '/tmp': Cannot allocate memory total 0 The problem is that both uid_t and gid_t are "int" instead of "short". This patch changes the size of those types. (I note that this is apparently a known issue, there's __compat_uid_t and friends in the sparc asm directory...) Rob -- Latency is more important than throughput. It's that simple. - Linus Torvalds
Re: [Qemu-devel] [PATCH] terminal attributes is not restored when using /dev/tty monitor
On Sun, Feb 21, 2010 at 07:32:41AM -0700, David S. Ahern wrote:
> Date: Sun, 21 Feb 2010 07:32:41 -0700
> From: "David S. Ahern"
> To: Shahar Havivi
> CC: Anthony Liguori , Dor Laor ,
> qemu-devel@nongnu.org
> Subject: Re: [Qemu-devel] [PATCH] terminal attributes is not restored when
> using /dev/tty monitor
>
>
>
> On 02/20/2010 12:42 PM, Shahar Havivi wrote:
> > On Sat, Feb 20, 2010 at 11:03:41AM -0600, Anthony Liguori wrote:
> >> Date: Sat, 20 Feb 2010 11:03:41 -0600
> >> From: Anthony Liguori
> >> To: "David S. Ahern"
> >> Cc: Dor Laor , Shahar Havivi ,
> >>qemu-devel@nongnu.org
> >> Subject: Re: [Qemu-devel] [PATCH] terminal attributes is not restored when
> >>using /dev/tty monitor
> >>
> >> On 02/20/2010 09:18 AM, David S. Ahern wrote:
> >>> On 02/20/2010 01:30 AM, Shahar Havivi wrote:
> when exiting qemu that run with "-monitor /dev/tty", the launching
> terminal get weird behaviour because no restore terminals action has
> taken.
> added chr_close and register atexit() code for tty devices (like stdio
> does)
>
> Signed-off-by: Shahar Havivi
> ---
> qemu-char.c | 14 ++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/qemu-char.c b/qemu-char.c
> index 75dbf66..de16883 100644
> --- a/qemu-char.c
> +++ b/qemu-char.c
> @@ -1002,6 +1002,7 @@ static void tty_serial_init(int fd, int speed,
> speed, parity, data_bits, stop_bits);
> #endif
> tcgetattr (fd,&tty);
> +oldtty = tty;
>
> #define check_speed(val) if (speed<= val) { spd = B##val; break; }
> speed = speed * 10 / 11;
> @@ -1173,6 +1174,17 @@ static int tty_serial_ioctl(CharDriverState *chr,
> int cmd, void *arg)
> return 0;
> }
>
> +static void tty_exit(void)
> +{
> +tcsetattr(0, TCSANOW,&oldtty);
> +}
> +
> +static void qemu_chr_close_tty(struct CharDriverState *chr)
> +{
> +tty_exit();
> +fd_chr_close(chr);
> +}
> >>>
> >>> The close callback needs to close the fd for the device as well. I have
> >>> sent a patch to handle this; waiting for it to be included:
> >>>
> >>> http://permalink.gmane.org/gmane.comp.emulators.qemu/63472
> >>
> >> It didn't apply with git-am. I'm not sure why, am investigating now.
> >>
> >> Regards,
> >>
> >> Anthony Liguori
> >>
> > Note that the method fd_chr_close() is closing the fd_in, no need to the
> > close logic again, and when opening a monitor with /dev/tty the
> > chr->chr_close not called that is why you need to register with
> > atexit(). (same as stdio monitor does).
> > Shahar.
>
> I don't see that fd_chr_close() closes the fd; it only unregisters the
> handler.
>
> David
you right, my bad.
Re: [Qemu-devel] [PATCH] terminal attributes is not restored when using /dev/tty monitor
On 02/20/2010 12:42 PM, Shahar Havivi wrote:
> On Sat, Feb 20, 2010 at 11:03:41AM -0600, Anthony Liguori wrote:
>> Date: Sat, 20 Feb 2010 11:03:41 -0600
>> From: Anthony Liguori
>> To: "David S. Ahern"
>> Cc: Dor Laor , Shahar Havivi ,
>> qemu-devel@nongnu.org
>> Subject: Re: [Qemu-devel] [PATCH] terminal attributes is not restored when
>> using /dev/tty monitor
>>
>> On 02/20/2010 09:18 AM, David S. Ahern wrote:
>>> On 02/20/2010 01:30 AM, Shahar Havivi wrote:
when exiting qemu that run with "-monitor /dev/tty", the launching
terminal get weird behaviour because no restore terminals action has
taken.
added chr_close and register atexit() code for tty devices (like stdio
does)
Signed-off-by: Shahar Havivi
---
qemu-char.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/qemu-char.c b/qemu-char.c
index 75dbf66..de16883 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -1002,6 +1002,7 @@ static void tty_serial_init(int fd, int speed,
speed, parity, data_bits, stop_bits);
#endif
tcgetattr (fd,&tty);
+oldtty = tty;
#define check_speed(val) if (speed<= val) { spd = B##val; break; }
speed = speed * 10 / 11;
@@ -1173,6 +1174,17 @@ static int tty_serial_ioctl(CharDriverState *chr,
int cmd, void *arg)
return 0;
}
+static void tty_exit(void)
+{
+tcsetattr(0, TCSANOW,&oldtty);
+}
+
+static void qemu_chr_close_tty(struct CharDriverState *chr)
+{
+tty_exit();
+fd_chr_close(chr);
+}
>>>
>>> The close callback needs to close the fd for the device as well. I have
>>> sent a patch to handle this; waiting for it to be included:
>>>
>>> http://permalink.gmane.org/gmane.comp.emulators.qemu/63472
>>
>> It didn't apply with git-am. I'm not sure why, am investigating now.
>>
>> Regards,
>>
>> Anthony Liguori
>>
> Note that the method fd_chr_close() is closing the fd_in, no need to the
> close logic again, and when opening a monitor with /dev/tty the
> chr->chr_close not called that is why you need to register with
> atexit(). (same as stdio monitor does).
> Shahar.
I don't see that fd_chr_close() closes the fd; it only unregisters the
handler.
David
Re: [Qemu-devel] [PATCH] terminal attributes is not restored when using /dev/tty monitor
On 02/20/2010 10:03 AM, Anthony Liguori wrote:
> On 02/20/2010 09:18 AM, David S. Ahern wrote:
>> On 02/20/2010 01:30 AM, Shahar Havivi wrote:
>>
>>> when exiting qemu that run with "-monitor /dev/tty", the launching
>>> terminal get weird behaviour because no restore terminals action has
>>> taken.
>>> added chr_close and register atexit() code for tty devices (like stdio
>>> does)
>>>
>>> Signed-off-by: Shahar Havivi
>>> ---
>>> qemu-char.c | 14 ++
>>> 1 files changed, 14 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/qemu-char.c b/qemu-char.c
>>> index 75dbf66..de16883 100644
>>> --- a/qemu-char.c
>>> +++ b/qemu-char.c
>>> @@ -1002,6 +1002,7 @@ static void tty_serial_init(int fd, int speed,
>>> speed, parity, data_bits, stop_bits);
>>> #endif
>>> tcgetattr (fd,&tty);
>>> +oldtty = tty;
>>>
>>> #define check_speed(val) if (speed<= val) { spd = B##val; break; }
>>> speed = speed * 10 / 11;
>>> @@ -1173,6 +1174,17 @@ static int tty_serial_ioctl(CharDriverState
>>> *chr, int cmd, void *arg)
>>> return 0;
>>> }
>>>
>>> +static void tty_exit(void)
>>> +{
>>> +tcsetattr(0, TCSANOW,&oldtty);
>>> +}
>>> +
>>> +static void qemu_chr_close_tty(struct CharDriverState *chr)
>>> +{
>>> +tty_exit();
>>> +fd_chr_close(chr);
>>> +}
>>>
>>
>> The close callback needs to close the fd for the device as well. I have
>> sent a patch to handle this; waiting for it to be included:
>>
>> http://permalink.gmane.org/gmane.comp.emulators.qemu/63472
>>
>
> It didn't apply with git-am. I'm not sure why, am investigating now.
>
> Regards,
>
> Anthony Liguori
>
Are you referring to my patch? I'm still learning the git commands, so
maybe I messed something up. I used git format-patch followed git send-mail.
If I save the email (Thunderbird client, saving the copy I received of
what I sent using git send-mail), strip out the mail headers and use
patch it applies fine - but with the warning "(Stripping trailing CRs
from patch.)"
David
[Qemu-devel] [PATCH] fix 'i' format handling in memory dump
It was broken by 09b9418c6d0. (!env && !is_physical) != (!is_physical)
when env is true.
Signed-off-by: Gleb Natapov
diff --git a/monitor.c b/monitor.c
index b1a6edc..19470d1 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1297,8 +1297,6 @@ static void memory_dump(Monitor *mon, int count, int
format, int wsize,
int flags;
flags = 0;
env = mon_get_cpu();
-if (!is_physical)
-return;
#ifdef TARGET_I386
if (wsize == 2) {
flags = 1;
--
Gleb.
[Qemu-devel] Re: [PATCH] QEMU kill CR3_CACHE references
On 02/19/2010 08:43 AM, Jes Sorensen wrote: Hi, The CR3 caching was never implemented in QEMU and is obsoleted by NPT/EPT. This patch removes the unused references to it from target-i386/kvm.c. Applied, thanks. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH 8/9] KVM: Rework of guest debug state writing
On 02/19/2010 08:22 PM, Jan Kiszka wrote: So far we synchronized any dirty VCPU state back into the kernel before updating the guest debug state. This was a tribute to a deficite in x86 kernels before 2.6.33. But as this is an arch-dependent issue, it is better handle in the x86 part of KVM and remove the writeback point for generic code. This also avoids overwriting the flushed state later on if user space decides to change some more registers before resuming the guest. Inferring one property of kvm.ko from another is not good, since it creates problems with backports. Better to create a separate KVM_CAP_ for the issue you're testing (and we can retroactively apply it to 2.6.33). -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH 2/9] qemu-kvm: Clean up register access API
On 02/19/2010 08:22 PM, Jan Kiszka wrote: qemu-kvm's functions for accessing the VCPU registers are kvm_arch_load/save_regs. Use them directly instead of going through various wrappers. Specifically, we do not need on_vcpu wrapping as all users either already run in the related thread or call while the vm is stopped. This is now also validated during runtime via asserts. +assert(kvm_cpu_is_stopped(env) || env->thread_id == kvm_get_thread_id()); The kvm_cpu_is_stopped() part is wrong, for two reasons. First, a future ABI revolution might switch to syscalls and thus make the association between vcpu and thread implicit. This will allow us to drop vcpu->mutex, eventually. Second, kvm_cpu_is_stopped() will be racy in a threaded future version of qemu. All vcpu ioctls should be made from the vcpu thread. Documentation/kvm/api.txt has this to say about the matter: - vcpu ioctls: These query and set attributes that control the operation of a single virtual cpu. Only run vcpu ioctls from the same thread that was used to create the vcpu. So it isn't just me. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH 0/9] qemu-kvm: Extended use of upstream code
On 02/19/2010 08:22 PM, Jan Kiszka wrote: Spin-off from my longer series as Marcelo asked for the last patch as the next step. I don't see any value in reordering the series, so I just but off the lower bits. This part mostly cleans up common KVM code that is also present upstream. It also includes the fixed guest debug writeback, first for upstream (patch 8 should be queued into uq/master as well), then merged into qemu-kvm while dropping the qemu-kvm copy of the guest debugging code. The differences to previous postings of the full series are: - rebased over qemu-kvm - fixed guest state writeback to avoid conflicts with SET_VCPU_EVENTS, rather use them on modern kernels (I know Gleb will hate me for this, but I'm convinced it's cleaner that way) Applied all, some issues pointed out as reply to individual patch. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH][uq/master] KVM: x86: Fix eflags corruption in kvm mode
On 02/19/2010 07:21 PM, Jan Kiszka wrote: This should explain a lot of the weird breakages of upstream KVM we've seen recently (actually we should have seen it much earlier): Stop translating eflags into TCG format when in kvm mode as we never translate it back and rather sync this broken state into the kernel. Applied to uq/master and uq/stable-0.12, thanks (though realistically 0.12 kvm users should stick with qemu-kvm). qemu-kvm is not affected as it has it own cpu loop - maybe the way to go for upstream as well on the long-term. Or use a skeleton main loop and a function pointer table, like kvm does with vmx and svm. -- error compiling committee.c: too many arguments to function
