Hello, I'm trying to emulate an x86 application on linux for sparc by using
qemu user space emulator. However, it doesn't work correctly. Any ideas?
Yours, sincerely
Chen Baozi
On Sun, Jun 13, 2010 at 7:52 AM, Chen Baozi wrote:
> Hello, I'm trying to emulate an x86 application on linux for sparc by using
> qemu user space emulator. However, it doesn't work correctly. Any ideas?
It's hard to say on this level of information. Which x86 application?
Can you provide traces
On Sat, Jun 12, 2010 at 07:57:52PM +0200, Paolo Bonzini wrote:
> On 06/12/2010 06:44 PM, Jan Kiszka wrote:
> >>Yes, but only for this line. What I mean is something more generic
> >>like:
> >>
> >>"#"*) # comment
> >> continue
> >> ;;
> >>
> >
> >IMO, that would only paper over suboptimally
On Fri, Jun 11, 2010 at 06:13:49AM -0700, Richard Henderson wrote:
> On 06/11/2010 01:06 AM, Aurelien Jarno wrote:
> >> That said, all the hardware to which either I or agraf have access are the
> >> latest
> >> z10 machines. Frankly I expect that to be true of most if not all
> >> machines, sin
From: Jan Kiszka
Setting the main counter while the HPET is enabled may not be a good
idea of the guest, but it is supported and should, thus, not spam the
host console with warnings.
Signed-off-by: Jan Kiszka
---
hw/hpet.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --
As the discussion around how to extend the IRQ framework /wrt
de-coalescing or message passing support still hasn't settled yet, this
series now skips the related changes, just focusing on the HPET. No
further changes compared to v3. Please merge.
Jan Kiszka (13):
hpet: Catch out-of-bounds timer
From: Jan Kiszka
We have to update the qemu timer when the per-timer enable bit is
toggled, just like for HPET_CFG_ENABLE changes.
Signed-off-by: Jan Kiszka
---
hw/hpet.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 6974935..041dd84 1
From: Jan Kiszka
Also prevent out-of-bounds write access to the timers but don't spam the
host console if it triggers.
Signed-off-by: Jan Kiszka
---
hw/hpet.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 8729fb2..1980906 100644
--- a
From: Jan Kiszka
Register the HPET as a sysbus device and create it that way. As it can
route its IRQs to any ISA IRQ, we need to connect it to all 24 of them.
Once converted to qdev, we can move reset handler and vmstate
registration into its hands as well.
Signed-off-by: Jan Kiszka
---
hw/hp
From: Jan Kiszka
This moves the private HPET structures into the C module, simplifies
some helper functions and fixes most coding style issues (biggest chunk
was improper switch-case indention). No functional changes.
Signed-off-by: Jan Kiszka
Reviewed-by: Juan Quintela
---
hw/hpet.c |
From: Jan Kiszka
Properly initialize HPETTimer::tn and HPETTimer::state once during
hpet_init instead of (re-)writing them on every reset.
Signed-off-by: Jan Kiszka
---
hw/hpet.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index bcb160b..fd
From: Jan Kiszka
Required for hpet.
Signed-off-by: Jan Kiszka
---
hw/hw.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/hw/hw.h b/hw/hw.h
index fc2d184..36be0be 100644
--- a/hw/hw.h
+++ b/hw/hw.h
@@ -474,6 +474,16 @@ extern const VMStateInfo vmstate_info_un
From: Jan Kiszka
Allow the intercept the RTC IRQ for the HPET legacy mode. Then push
routing to IRQ8 completely into the HPET. This allows to turn
hpet_in_legacy_mode() into a private function. Furthermore, this stops
the RTC from clearing IRQ8 even if the HPET is in control.
This patch comes wi
From: Jan Kiszka
By implementing this feature we can also remove a nasty way to kill qemu
(by trying to enable level-triggered hpet interrupts).
Signed-off-by: Jan Kiszka
---
hw/hpet.c | 32 ++--
1 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/hw/
From: Jan Kiszka
Instead of keeping a static reference around, pass the state to
hpet_enabled and hpet_get_ticks. All callers now have it at hand. Will
once allow to instantiate the HPET more than a single time.
Signed-off-by: Jan Kiszka
---
hw/hpet.c | 38 +--
From: Jan Kiszka
This command was of minimal use before, now it is useless as the hpet
become a qdev device and is thus easily discoverable. We should
definitely not set query-hpet in QMP's stone, and there is also no good
reason to keep it for the interactive monitor.
Signed-off-by: Jan Kiszka
From: Jan Kiszka
This implements the HPET capability of routing IRQs to the front-side
bus, aka MSI support. This feature can be enabled via the qdev property
"msi" and is off by default.
Note that switching it on can cause guests (at least Linux) to use the
HPET as timer instead of the LAPIC. K
From: Jan Kiszka
One HPET block supports up to 32 timers. Allow to instantiate more than
the recommended and implemented minimum of 3. The number is configured
via the qdev property "timers". It is also saved/restored so that it
need not match between migration peers.
Signed-off-by: Jan Kiszka
Am 13.06.2010 um 07:16 schrieb Izumi Tsutsui:
Please email the patch to qemu-devel@nongnu.org via git-send-email.
Isn't the following post enough? What's incomplete on this?
http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg00449.html
That is still not a proper git-format-patch patch
> >> Please email the patch to qemu-devel@nongnu.org via git-send-email.
> > Isn't the following post enough? What's incomplete on this?
> > http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg00449.html
>
> That is still not a proper git-format-patch patch, it is missing among
> others t
On Sun, Jun 13, 2010 at 02:21:21PM +0200, Andreas Färber wrote:
> Am 13.06.2010 um 07:16 schrieb Izumi Tsutsui:
>
> >>Please email the patch to qemu-devel@nongnu.org via git-send-email.
> >Isn't the following post enough? What's incomplete on this?
> >http://lists.nongnu.org/archive/html/qemu-deve
Thanks, applied all.
On Sun, Jun 13, 2010 at 12:15 PM, Jan Kiszka wrote:
> As the discussion around how to extend the IRQ framework /wrt
> de-coalescing or message passing support still hasn't settled yet, this
> series now skips the related changes, just focusing on the HPET. No
> further change
Am 13.06.2010 um 15:10 schrieb Jonathan A. Kollasch:
On Sun, Jun 13, 2010 at 02:21:21PM +0200, Andreas Färber wrote:
Am 13.06.2010 um 07:16 schrieb Izumi Tsutsui:
Please email the patch to qemu-devel@nongnu.org via git-send-email.
Isn't the following post enough? What's incomplete on this?
h
Am 13.06.2010 um 14:50 schrieb Izumi Tsutsui:
Please email the patch to qemu-devel@nongnu.org via git-send-email.
Isn't the following post enough? What's incomplete on this?
http://lists.nongnu.org/archive/html/qemu-devel/2010-06/
msg00449.html
That is still not a proper git-format-patch pat
Currently HPET ACPI table is created regardless of whether qemu actually
created hpet device. This may confuse some guests that don't check that
hpet is functional before using it. Solve this by passing info about
hpets in qemu to seabios via fw config interface. Additional benefit is
that seabios
Load hpet info for HPET ACPI table from qemu instead of using hardcoded
values. Use hardcoded values anyway if old qemu is detected.
Signed-off-by: Gleb Natapov
diff --git a/src/acpi.c b/src/acpi.c
index 0559443..eeecca1 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -469,7 +469,7 @@ build_ssdt(voi
> I think we could solve all problems (well, maybe not world peace, yet)
> by switching to message based system for all of DMA and IRQs.
>
> Each device would have a message input port and way to output messages.
>
> Examples:
>
> Zero copy memory access from device D1 to D2 to host memory (D3)
On 06/13/2010 03:49 AM, Aurelien Jarno wrote:
>> Also, what era is that second machine without highgprs? Is it running an
>> old kernel, or a 32-bit kernel?
>
> I have very few infos about it, it's an IBM System z10 machine running a
> 64-bit 2.6.26 kernel.
Ah, I see it now: ea2a4d3a3a929ef49495
> TBH I preferred the original system whereby the source can query the state
> of the sink (i.e "are you ignoring this line?"). Note that conceptually
> this should be *querying* state, not responding to an event.
People are still pushing qemu_irq as an message passing interface, so I'm
going to
On Sun, Jun 13, 2010 at 09:02:40AM -0700, Richard Henderson wrote:
> On 06/13/2010 03:49 AM, Aurelien Jarno wrote:
> >> Also, what era is that second machine without highgprs? Is it running an
> >> old kernel, or a 32-bit kernel?
> >
> > I have very few infos about it, it's an IBM System z10 mach
Gleb Natapov wrote:
> Currently HPET ACPI table is created regardless of whether qemu actually
> created hpet device. This may confuse some guests that don't check that
> hpet is functional before using it. Solve this by passing info about
> hpets in qemu to seabios via fw config interface. Additio
Blue Swirl wrote:
> Clean up APIC and IOAPIC. Convert both devices to qdev.
Wanted to give this a try, but patches are line-wrapped. Please fix.
Jan
>
> v1->v2:
> Remove apic.h reorganization.
> Add IOAPIC and APIC qdev conversions.
> Use CPUState also in 5/7. However on 6/7 we have to again us
Am 13.06.2010 um 18:56 schrieb Jan Kiszka:
Blue Swirl wrote:
Clean up APIC and IOAPIC. Convert both devices to qdev.
Wanted to give this a try, but patches are line-wrapped. Please fix.
Threading the patches would also be appreciated.
Git's default changed at some point, this can be overrid
On Sun, Jun 13, 2010 at 06:56:37PM +0200, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > Currently HPET ACPI table is created regardless of whether qemu actually
> > created hpet device. This may confuse some guests that don't check that
> > hpet is functional before using it. Solve this by passing in
Gleb Natapov wrote:
> On Sun, Jun 13, 2010 at 06:56:37PM +0200, Jan Kiszka wrote:
>> Gleb Natapov wrote:
>>> Currently HPET ACPI table is created regardless of whether qemu actually
>>> created hpet device. This may confuse some guests that don't check that
>>> hpet is functional before using it. S
On Sun, Jun 13, 2010 at 4:56 PM, Jan Kiszka wrote:
> Blue Swirl wrote:
>> Clean up APIC and IOAPIC. Convert both devices to qdev.
>
> Wanted to give this a try, but patches are line-wrapped. Please fix.
I've pushed the patches here:
git://repo.or.cz/qemu/blueswirl.git
http://repo.or.cz/w/qemu/blu
On Sun, Jun 13, 2010 at 5:03 PM, Andreas Färber wrote:
> Am 13.06.2010 um 18:56 schrieb Jan Kiszka:
>
>> Blue Swirl wrote:
>>>
>>> Clean up APIC and IOAPIC. Convert both devices to qdev.
>>
>> Wanted to give this a try, but patches are line-wrapped. Please fix.
>
> Threading the patches would also
On Sun, Jun 13, 2010 at 4:34 PM, Paul Brook wrote:
>> TBH I preferred the original system whereby the source can query the state
>> of the sink (i.e "are you ignoring this line?"). Note that conceptually
>> this should be *querying* state, not responding to an event.
>
> People are still pushing
Move inclusion of stdbool.h to common header files, instead of including
in an ad-hoc manner.
Signed-off-by: Paul Brook
---
block/blkdebug.c |2 --
check-qjson.c|1 -
dyngen-exec.h|1 +
hw/9p.h |2 --
hw/eepro100.c|1 -
hw/hw.h
Hi,
Am 13.06.2010 um 19:53 schrieb Blue Swirl:
On Sun, Jun 13, 2010 at 5:03 PM, Andreas Färber > wrote:
Am 13.06.2010 um 18:56 schrieb Jan Kiszka:
Blue Swirl wrote:
Clean up APIC and IOAPIC. Convert both devices to qdev.
Wanted to give this a try, but patches are line-wrapped. Please fix.
On Sun, Jun 13, 2010 at 3:49 PM, Paul Brook wrote:
>> I think we could solve all problems (well, maybe not world peace, yet)
>> by switching to message based system for all of DMA and IRQs.
>>
>> Each device would have a message input port and way to output messages.
>>
>> Examples:
>>
>> Zero cop
> On Sun, Jun 13, 2010 at 3:49 PM, Paul Brook wrote:
> >> I think we could solve all problems (well, maybe not world peace, yet)
> >> by switching to message based system for all of DMA and IRQs.
> >>
> >> Each device would have a message input port and way to output messages.
> >>
> >> Examples
On Sun, Jun 13, 2010 at 6:39 PM, Paul Brook wrote:
>> On Sun, Jun 13, 2010 at 3:49 PM, Paul Brook wrote:
>> >> I think we could solve all problems (well, maybe not world peace, yet)
>> >> by switching to message based system for all of DMA and IRQs.
>> >>
>> >> Each device would have a message in
On Sun, Jun 13, 2010 at 07:41:14PM +0200, Jan Kiszka wrote:
> Gleb Natapov wrote:
> > On Sun, Jun 13, 2010 at 06:56:37PM +0200, Jan Kiszka wrote:
> >> Gleb Natapov wrote:
> >>> Currently HPET ACPI table is created regardless of whether qemu actually
> >>> created hpet device. This may confuse some
> >> For the memory access case, in practice the interface could be
> >> sysbus_memory_rw(DeviceState *parent, target_phys_addr_t addr,
> >> target_phys_addr_t size)
> >
> > Why "parent"?
>
> Parent device or bus host bridge device. Alternatively there could be
> a bus handle.
A device has no wa
> > And I think we can move the capability setup into init. But this is not
> > directly related to this patch, would just avoid adding this hunk to
> > hpet_reset.
>
> I actually did that initially and tried to init hpet_cfg there too, but
> then noticed that mmio[0].addr below is not initialized
On 13.06.2010, at 18:44, Aurelien Jarno wrote:
> On Sun, Jun 13, 2010 at 09:02:40AM -0700, Richard Henderson wrote:
>> On 06/13/2010 03:49 AM, Aurelien Jarno wrote:
Also, what era is that second machine without highgprs? Is it running an
old kernel, or a 32-bit kernel?
>>>
>>> I have
On Fri, Jun 04, 2010 at 12:14:24PM -0700, Richard Henderson wrote:
> Make better use of the LOAD HALFWORD IMMEDIATE, LOAD IMMEDIATE,
> and INSERT IMMEDIATE instruction groups.
>
> Signed-off-by: Richard Henderson
> ---
> tcg/s390/tcg-target.c | 129
> +++
On 06/12/2010 05:04 AM, Aurelien Jarno wrote:
>> +for (i = 0; i < 4; i++) {
>> +tcg_target_long mask = 0xull << i*16;
>> +if ((uval & mask) != 0 && (uval & ~mask) == 0) {
>
> Wouldn't it be simpler to use (uval & mask) == uval ?
Doh.
>> +/* Try for PC-relative address
Hello,
I'm trying to run the QEMU sh4 host support patch.
I found some problems on "qemu_st"and "st",so I modified them,
but still it causes segmentation fault.
I attach my modified patch. Does anyone know anything?
Anyone tried to use the QEMU sh4 host support patch?
I tried to run the QEMU that
Hello, all!
As my project, I want to implement our own architecture in QEMU(like arm,
sparc, ect) , but unfortunately I am new to this area.
I just want to know whether I can fix or revise QEMU, and it is possible to
use revised QEMU as a emulator.
First, I downloaded qemu-0.12.4 and I
Hi
I created a full virtualized DOM-U by XEN which is emulated by qemu-dm,
and I dont know hot to monitor it's disk and network in DOM-0.
I know I can press CTRL-ALT-2 to access the monitor, but it should be
done in dom-U.
Is there any solution to get the disk and network information of dom-U
in
On Sun, Jun 13, 2010 at 08:55:23PM +0100, Paul Brook wrote:
> > > And I think we can move the capability setup into init. But this is not
> > > directly related to this patch, would just avoid adding this hunk to
> > > hpet_reset.
> >
> > I actually did that initially and tried to init hpet_cfg th
On Sun, Jun 13, 2010 at 05:34:24PM +0100, Paul Brook wrote:
> > TBH I preferred the original system whereby the source can query the state
> > of the sink (i.e "are you ignoring this line?"). Note that conceptually
> > this should be *querying* state, not responding to an event.
>
> People are st
This is a follow-up to my ramblock overhaul RFC series. In trying to
come up with a useful name to give to a ramblock, we seemed to be leaning
towards something that represents the existing qdev hierarchy rather
than creating an arbitrary new namespace. I had some pointers that I
should use the s
qdev_get_dev_path() is intended to be the canonical utility for creating
a string representing the qdev hierarchy of a device. The path consists
of bus and device names as well as identified properties of the immediate
parent bus and device. This results in strings like:
"/main-system-bus/pci.0,
Use the now passed in DeviceState along with qdev_get_dev_path() to
create meaningful id strings for the SaveStateEntry. We append the
driver provided string so we can differentiate multiple savevm
handlers per device:
"/main-system-bus/pci.0,addr=03.0/i82551,mac=52:54:00:12:34:56/eeprom"
"/main-
This allows us to create a more meaningful savevm string.
Signed-off-by: Alex Williamson
---
hw/eepro100.c |4 ++--
hw/eeprom93xx.c |8
hw/eeprom93xx.h |4 ++--
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 92cfea7..c57
Stuff a pointer to the DeviceState into the VirtIONet structure so that
we can easily remove the vmstate entry later. Also, let vmstate track
the instance number (it should always be zero internally since the
device path should now be unique).
Signed-off-by: Alex Williamson
---
hw/virtio-net.c
Alex Williamson writes:
> qdev_get_dev_path() is intended to be the canonical utility for creating
> a string representing the qdev hierarchy of a device. The path consists
> of bus and device names as well as identified properties of the immediate
> parent bus and device. This results in strin
From: Jan Kiszka
The capability register is read-only from guest POV, so we do not need
to update it on reset.
Signed-off-by: Jan Kiszka
---
hw/hpet.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/hw/hpet.c b/hw/hpet.c
index 93fc399..e9b585c 100644
--- a/hw/h
61 matches
Mail list logo
