The exac error message is like the following.
Sorry for missing some of the error message in my last email.
qemu: hardware error: icp_control_write: Bad offset 7fffe8
CPU #0:
R00= R01=0113 R02=0100 R03=
R04= R05= R06= R07=
R08=cb80 R0
Hi there
I made an ARM Linux2.6.10 image(zImage) and I tried to run it on QEMU using the
following command.
qemu-system-arm -kernel zImage -nographic
I got an error message like:
CPU #0:
R00= R01=0113 R02=0100 R03=
R04= R05= R06= R07=
R0
After messing around with bcc, as86 and ld86 I finally got the vgabios to
compile.
Everything works as it should I'm guessing. I've attached the output from lspci
from the guest. I'll spend sometime looking at the device models and see how I
can implement a model of what I'm interested in.
Is
On Fri, 2010-08-20 at 13:12 -0500, Anthony Liguori wrote:
> On 08/20/2010 11:14 AM, Markus Armbruster wrote:
> >> The real problem is how we do reset. We shouldn't register a reset
> >> handler for every qdev device but rather register a single reset
> >> handler that walks the device tree and cal
Old versions of the BOCHs VGA BIOS (cira 2003) made use of VBE
registers at 0xff80/81. In VBE API version 0xb0c2 these were
moved to 0x1ce/cf. Unfortunately, QEMU still registers handlers
for the old range. If a guest attempts to assign an I/O device
overlapping this region, QEMU exits with a hw
On Fri, Aug 20, 2010 at 6:44 PM, Blue Swirl wrote:
> On Fri, Aug 20, 2010 at 1:47 PM, Markus Armbruster wrote:
>> Anthony Liguori writes:
>>
>>> On 08/17/2010 03:04 AM, Jes Sorensen wrote:
On 08/13/10 20:02, Blue Swirl wrote:
> On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Fil
On Fri, Aug 20, 2010 at 7:59 PM, Artyom Tarasenko
wrote:
> 2010/8/19 Blue Swirl :
>
>>> Is there a list of what is missing? You mentioned the pci bridges
>>> before. What else?
>>> Shall we maintain the TODO file for everything we find? Including
>>> things we may fix within a few days after findi
I'm not sure what the problem was but I had checked out the code on a windows
machine and then copied it over to a linux box. That was causing problems
somehow.
I've managed to compile qemu and seabios but vgabios is taking forever to
compile. The problem seems to be bcc. I've tried a simple he
2010/8/19 Blue Swirl :
>> Is there a list of what is missing? You mentioned the pci bridges
>> before. What else?
>> Shall we maintain the TODO file for everything we find? Including
>> things we may fix within a few days after finding?
>
> Actually, we have a TODO file, see under target-sparc. Th
In the KVM Forum we talked about making the current QMP's interface stable
and deprecating it as soon as the right one is available.
This series updates some QMP docs to reflect that and also has a small fix
for the greeting message which would harder to change later.
changelog
-
v1 -> v
A number of changes I prefer to do in one shot:
- Fix example
- Small clarifications
- Add multiple monitors example
- Add 'Development Process' section
Signed-off-by: Luiz Capitulino
---
QMP/README | 71 ---
1 files changed, 48 insertio
From: Miguel Di Ciurcio Filho
Update the documentation of 'query-version' to output the string version broken
down.
Signed-off-by: Miguel Di Ciurcio Filho
Signed-off-by: Luiz Capitulino
---
qemu-monitor.hx | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git
Signed-off-by: Luiz Capitulino
---
qemu-monitor.hx | 26 --
1 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/qemu-monitor.hx b/qemu-monitor.hx
index 9c27b31..5c1da33 100644
--- a/qemu-monitor.hx
+++ b/qemu-monitor.hx
@@ -35,7 +35,29 @@ information on the S
From: Miguel Di Ciurcio Filho
This code was originally developed by Daniel P. Berrange
Signed-off-by: Miguel Di Ciurcio Filho
Signed-off-by: Luiz Capitulino
---
monitor.c | 23 +++
1 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/monitor.c b/monitor.c
ind
On Thu, Aug 19, 2010 at 9:51 PM, Anthony Liguori wrote:
> On 08/19/2010 04:21 PM, Blue Swirl wrote:
>>>
>>> Should CPUs appear in the QEMU device tree?
>>>
>>
>> They have several properties that should be user visible.
>>
>
> Sure, but that's an argument for having some of the qdev features (like
On Fri, 20 Aug 2010 18:04:57 +0200
Markus Armbruster wrote:
> Luiz Capitulino writes:
>
> > A number of changes I prefer to do in one shot:
> >
> > - Fix example
> > - Small clarifications
> > - Add multiple monitors example
> > - Add 'Development Process' section
> >
> > Signed-off-by: Luiz Ca
Hi,
On Aug 19, 2010, at 2:49 PM, Adam Lackorzynski wrote:
>
> On Thu Aug 19, 2010 at 14:34:10 +0200, Alexander Graf wrote:
>>
>> On 19.08.2010, at 14:32, Adam Lackorzynski wrote:
>>
>>>
>>> On Thu Aug 19, 2010 at 13:40:54 +0200, Alexander Graf wrote:
On 19.08.2010, at 13:36, Adam L
On Fri, Aug 20, 2010 at 1:47 PM, Markus Armbruster wrote:
> Anthony Liguori writes:
>
>> On 08/17/2010 03:04 AM, Jes Sorensen wrote:
>>> On 08/13/10 20:02, Blue Swirl wrote:
>>>
On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Filho
wrote:
> The existing code that I have to
On 08/20/2010 12:01 PM, Markus Armbruster wrote:
Anthony Liguori writes:
On 08/19/2010 04:21 PM, Blue Swirl wrote:
Should CPUs appear in the QEMU device tree?
They have several properties that should be user visible.
Sure, but that's an argument for having some
On Fri, Aug 20, 2010 at 5:15 AM, devsk <618...@bugs.launchpad.net> wrote:
> What's this bugdb for then? I now have to subscribe to a list, just to
> send the patch?
It's probably there to report bugs. But it's much easier to review
submitted code when it's sent to the list. I don't think you have
On 08/20/2010 11:14 AM, Markus Armbruster wrote:
The real problem is how we do reset. We shouldn't register a reset
handler for every qdev device but rather register a single reset
handler that walks the device tree and calls reset on every reachable
device.
Then we can always call reset in ini
Anthony Liguori writes:
> On 08/19/2010 04:21 PM, Blue Swirl wrote:
>>> Should CPUs appear in the QEMU device tree?
>>>
>> They have several properties that should be user visible.
>>
>
> Sure, but that's an argument for having some of the qdev features
> (like variant properties) be co
Anthony Liguori writes:
> On 08/20/2010 10:47 AM, Markus Armbruster wrote:
>> Alex Williamson writes:
>>
>>
>>> On Fri, 2010-08-20 at 11:00 +0200, Markus Armbruster wrote:
>>>
Alex Williamson writes:
> Several devices rely on their reset() function being cal
Luiz Capitulino writes:
> A number of changes I prefer to do in one shot:
>
> - Fix example
> - Small clarifications
> - Add multiple monitors example
> - Add 'Development Process' section
>
> Signed-off-by: Luiz Capitulino
> ---
> QMP/README | 71 -
On 08/20/2010 10:47 AM, Markus Armbruster wrote:
Alex Williamson writes:
On Fri, 2010-08-20 at 11:00 +0200, Markus Armbruster wrote:
Alex Williamson writes:
Several devices rely on their reset() function being called to
initialize device state, e1000 and rtl8139 in partic
Alex Williamson writes:
> On Fri, 2010-08-20 at 11:00 +0200, Markus Armbruster wrote:
>> Alex Williamson writes:
>>
>> > Several devices rely on their reset() function being called to
>> > initialize device state, e1000 and rtl8139 in particular. When
>> > the device is hot added, the reset do
On Fri, Aug 20, 2010 at 04:49:20PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >AT (well XT) keycodes aren't that bad a choice, at least if you go for the
> >extended mapping used by the Linux keyboard driver.
>
> Hmm, as far I know those extended mappings are not standardized. Uses
> linux this ju
Hi,
AT (well XT) keycodes aren't that bad a choice, at least if you go for the
extended mapping used by the Linux keyboard driver.
Hmm, as far I know those extended mappings are not standardized. Uses
linux this just as internal representation? Or can you actually feed a
linux guest with
On 08/20/2010 09:09 AM, Gerd Hoffmann wrote:
Hi,
Fetch
http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/sdms/Bios/lsi_bios.zip
-> unzip -> boot with "-option-rom 8xx_64.rom"
Maybe we could switch PCIDevice to default romfile to try to
.rom if none is specified. Since
On 08/20/2010 09:03 AM, Gerd Hoffmann wrote:
Hi,
Again this is libspice interface (and I think also wire protocol), so
I can't change it. I can convert dz into some button_mask bits before
calling kbd_mouse_event, but looking at the vnc code it seems qemu
expects the mouse wheel events being
On Fri, Aug 20, 2010 at 12:10 PM, Yoshiaki Tamura
wrote:
> Setting fd = -1 to qemu_set_fd_handler2() causes bus error at FD_SET
> in main_loop_wait().
>
> Signed-off-by: Yoshiaki Tamura
> ---
> ui/vnc.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/ui/vnc.c b/ui/
On Fri, Aug 20, 2010 at 03:56:52PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> >It's not actually ps/2 data. It's AT scan codes plus an internal
> >encoding to indicate press vs. release using the high bit. Additionally,
> >some special keys are encoded with two calls to kbd_put_keycode using
> >the 0
Hi,
Fetch
http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/sdms/Bios/lsi_bios.zip
-> unzip -> boot with "-option-rom 8xx_64.rom"
Maybe we could switch PCIDevice to default romfile to try to
.rom if none is specified. Since qdev names are unique, this
should work well.
Hi,
Again this is libspice interface (and I think also wire protocol), so
I can't change it. I can convert dz into some button_mask bits before
calling kbd_mouse_event, but looking at the vnc code it seems qemu
expects the mouse wheel events being passed via dz not button_state.
That's unfor
Hi,
It's not actually ps/2 data. It's AT scan codes plus an internal
encoding to indicate press vs. release using the high bit. Additionally,
some special keys are encoded with two calls to kbd_put_keycode using
the 0xe0 prefix (the grey code).
Wheee. From a brief look at the code it seems
Anthony Liguori writes:
> On 08/17/2010 03:04 AM, Jes Sorensen wrote:
>> On 08/13/10 20:02, Blue Swirl wrote:
>>
>>> On Fri, Aug 13, 2010 at 3:22 PM, Miguel Di Ciurcio Filho
>>> wrote:
>>>
The existing code that I have touched don't follow the current coding
style guidance,
On 08/20/2010 02:44 AM, Gerd Hoffmann wrote:
On 08/18/10 17:16, Alexander Graf wrote:
This has been discussed several times before. The proper solution
is to teach the bios how to boot off SCSI devices. IIRC support for
virtio devices already exists, implementing support for the SCSI
controlle
On 08/20/2010 07:42 AM, Gerd Hoffmann wrote:
Hi,
+static void mouse_motion(SpiceMouseInstance *sin, int dx, int dy, int
dz,
+ uint32_t buttons_state)
+{
+ kbd_mouse_event(dx, dy, dz, buttons_state);
dz is an odd interface. We use it to represent additional buttons which
really makes no sens
On 08/20/2010 07:34 AM, Gerd Hoffmann wrote:
+static const SpiceKbdInterface kbd_interface = {
+ .base.type = SPICE_INTERFACE_KEYBOARD,
+ .base.description = "qemu keyboard",
+ .base.major_version = SPICE_INTERFACE_KEYBOARD_MAJOR,
+ .base.minor_version = SPICE_INTERFACE_KEYBOARD_MINOR,
+ .push_
Hi,
+static void mouse_motion(SpiceMouseInstance *sin, int dx, int dy, int
dz,
+ uint32_t buttons_state)
+{
+ kbd_mouse_event(dx, dy, dz, buttons_state);
dz is an odd interface. We use it to represent additional buttons which
really makes no sense. If you still can, I'd suggest moving dz int
On Fri, 2010-08-20 at 11:00 +0200, Markus Armbruster wrote:
> Alex Williamson writes:
>
> > Several devices rely on their reset() function being called to
> > initialize device state, e1000 and rtl8139 in particular. When
> > the device is hot added, the reset doesn't occur, often leaving
> > th
+static const SpiceKbdInterface kbd_interface = {
+ .base.type = SPICE_INTERFACE_KEYBOARD,
+ .base.description = "qemu keyboard",
+ .base.major_version = SPICE_INTERFACE_KEYBOARD_MAJOR,
+ .base.minor_version = SPICE_INTERFACE_KEYBOARD_MINOR,
+ .push_scan_freg = kbd_push_key,
+ .get_leds = kbd_ge
On (Fri) Aug 20 2010 [06:18:11], Amit Shah wrote:
> If the machine is stopped and 'info balloon' is invoked, the monitor
> process just hangs waiting for info from the guest. Return the most
> recent balloon data in that case.
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=623903
>
> Reporte
On (Thu) Aug 19 2010 [06:51:04], Amit Shah wrote:
> Free malloc'ed memory, unregister from savevm and clean up virtio-common
> bits on device hot-unplug.
>
> This was found performing a migration after device hot-unplug.
>
> Reported-by:
> Signed-off-by: Amit Shah
> ---
> hw/virtio-pci.c
+#ifdef CONFIG_SPICE
Now's probably a good time to make vm_config_groups a list that can be
dynamically added to so that you can register the option group from
within spice.c.
This would require a new qemu_opts_parse() that took a name of an
QemuOptsList instead of the pointer to it but then yo
Switch tree to lookup-by-name using qemu_find_opts().
Also hook up virtfs options so qemu_find_opts works for them too.
Signed-off-by: Gerd Hoffmann
---
blockdev.c |4 +-
hw/pci-hotplug.c |2 +-
hw/qdev-properties.c |2 +-
hw/qdev.c|2 +-
hw/usb-msd.c
Signed-off-by: Gerd Hoffmann
---
qemu-options.hx |4
vl.c| 17 +
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/qemu-options.hx b/qemu-options.hx
index db86feb..453f129 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -482,7 +482,6 @@
Hi,
This patch series allows to register additional QemuOptLists at
runtime, makes (almost) all QemuOptsLists static and switches
over to a name-based lookup of the lists. virtfs is the first
user of the runtime-registering, spice will follow.
Gerd Hoffmann (3):
QemuOpts: allow new option gr
Signed-off-by: Gerd Hoffmann
---
qemu-config.c | 18 +-
qemu-config.h |1 +
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index 95abe61..68880c2 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -342,7 +342,7 @@ QemuOptsList q
From: Blue Swirl [mailto:blauwir...@gmail.com]
> On Thu, Aug 19, 2010 at 8:44 PM, Artyom Tarasenko
> wrote:
> > 2010/8/19 Blue Swirl :
> >> On Thu, Aug 19, 2010 at 10:15 AM, Laurikainen, Tuukka
> >> wrote:
> >>> Hi,
> >>>
> >>> As the Sparc64 support is not complete, I thought I'd ask here before
Anthony Liguori wrote:
> On 08/19/2010 03:09 PM, Blue Swirl wrote:
>> On Thu, Aug 19, 2010 at 7:33 PM, Anthony
>> Liguori wrote:
>>
>>> On 06/12/2010 04:14 PM, Blue Swirl wrote:
>>>
Clean up APIC and IOAPIC. Convert both devices to qdev.
v1->v2:
Remove apic.h reorganiza
Hi,
You can see the rest of the plumbing in the tree.
Hmm, "make test" (and trying to build anything in tests/) fails with
separate source/build dirs. But it isn't obvious to me why it does.
The Makefile takes care to set vpath, so I think it should have picked
up the source files just f
This patch applies on top of 9P2000.L patches that we have on the list.
I took a look at how 9P server is handling open() flags in 9P2000.L path.
I think we can do away with the valid_flags() function and simplify the
code. The reasoning is as follows:
O_NOCTTY: (If the file is a terminal, don't m
On 08/20/2010 02:48 AM, Amit Shah wrote:
If the machine is stopped and 'info balloon' is invoked, the monitor
process just hangs waiting for info from the guest. Return the most
recent balloon data in that case.
See https://bugzilla.redhat.com/show_bug.cgi?id=623903
Reported-by:
Signed-off-by:
Setting fd = -1 to qemu_set_fd_handler2() causes bus error at FD_SET
in main_loop_wait().
Signed-off-by: Yoshiaki Tamura
---
ui/vnc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ui/vnc.c b/ui/vnc.c
index 7fc40ac..c7a1831 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -1184
On Thu, 19 Aug 2010, Anthony Liguori wrote:
> On 08/19/2010 05:52 PM, malc wrote:
> > > Yes, but the programming model was different.
> > >
> > > Look at the PIC compared to the lapic. The PIC is programmed via pio at a
> > > fixed location. There is only one PIC and it interacts with the syste
Alex Williamson writes:
> Several devices rely on their reset() function being called to
> initialize device state, e1000 and rtl8139 in particular. When
> the device is hot added, the reset doesn't occur, often leaving
> the device in an unusable state. Adding a call to reset() after
> init()
Stefan Weil writes:
> Am 02.08.2010 10:40, schrieb Markus Armbruster:
>> Stefan Weil writes:
>>
>>> All other error messages in qemu-option.c display the name
>>> of the invalid parameter. This seems to be reasonable for
>>> invalid identifiers, too. Without it, a debugger is needed
>>> to find
On 08/19/2010 11:51 PM, Anthony Liguori wrote:
Neither approach maps well to real hardware. An x86 CPU cannot exist
without a local APIC and a local APIC cannot exist without an x86
CPU. The
two are fundamentally tied together.
What about 486? Or 82489?
Don't confuse the local APIC with the P
2010/8/19 Blue Swirl :
>> Hi,
>>
>> As the Sparc64 support is not complete, I thought I'd ask here before
>> reporting a bug.
>>
>> Trying to boot a Debian netboot cd image for Sparc with Qemu 0.12.5:
>>
>> # qemu-system-sparc64 -boot d -cdrom debian-505-sparc-businesscard.iso
>> -nographic -hda sp
On 08/18/10 17:16, Alexander Graf wrote:
This has been discussed several times before. The proper solution
is to teach the bios how to boot off SCSI devices. IIRC support for
virtio devices already exists, implementing support for the SCSI
controller shouldn't be that much harder.
Couldn't we
61 matches
Mail list logo
