On 2012-07-03 08:43, Wen Congyang wrote:
>> I'm not talking about changing the interface to the guest, I'm talking
>> about how to model it in QEMU. And that difference would be transparent
>> to the guest. I pointed you to examples like hw/kvm/clock.c.
>
> OK, I will read the code in hw/kvm/clock
At 07/03/2012 02:36 PM, Jan Kiszka Wrote:
> On 2012-07-03 08:07, Wen Congyang wrote:
>> At 06/28/2012 04:26 PM, Jan Kiszka Wrote:
>>> On 2012-06-28 03:15, Wen Congyang wrote:
At 06/27/2012 10:39 PM, Jan Kiszka Wrote:
> On 2012-06-27 09:02, Wen Congyang wrote:
>> When the guest is panic
On 2012-07-02 13:08, Liu, Jinsong wrote:
> Eduardo, Jan, Andreas
>
> As we sync 3 months ago, I wait until qemu1.1 done, then re-write patch based
> on qemu1.1.
> Now it's time to re-write my patch based on qemu1.1.
>
> Attached is a RFC patch for exposing tsc deadline timer to guest.
> I have c
On 2012-07-03 08:07, Wen Congyang wrote:
> At 06/28/2012 04:26 PM, Jan Kiszka Wrote:
>> On 2012-06-28 03:15, Wen Congyang wrote:
>>> At 06/27/2012 10:39 PM, Jan Kiszka Wrote:
On 2012-06-27 09:02, Wen Congyang wrote:
> When the guest is panicked, it will write 0x1 to the port KVM_PV_PORT.
>
At 06/28/2012 04:26 PM, Jan Kiszka Wrote:
> On 2012-06-28 03:15, Wen Congyang wrote:
>> At 06/27/2012 10:39 PM, Jan Kiszka Wrote:
>>> On 2012-06-27 09:02, Wen Congyang wrote:
When the guest is panicked, it will write 0x1 to the port KVM_PV_PORT.
So if qemu reads 0x1 from this port, we can
>
>> Maybe
>> we can change the BSP of POK in order to support the MPC8544DS board.
>
> It's not only the board. Kernel mode is vastly different from the 601
> you're probably targeting today.
>
Currently POK
supposes to run on a sort of ppc750 processor (I am invoking Qemu with -cpu
ppc32
Hello,
I'm developing with QEMU to run arm binaries. Right now I can't tell if the
Thumb32 vmul.f64 instruction encoded(ee25 7b07) is executing or not. I
would like to see where QEMU increments the PC so as to see if this
instruction is getting skipped or to trace it's behavior.
I've looked extens
Public bug reported:
Here the steps to reproduce:
1. qemu-img create -f qcow2 test.qcow2 100M
2. qemu-system-ppc -m 1024 -hda test.qcow2
3. change to the console via Ctrl-Alt-2 and save a snapshot: "savevm test"
4. quit
5. start again and go to the console
6. load the snapshot via "loadvm test"
7
Hi All,
This RFC comes from the recent discussion Re coroutines and the block
layer - the current topic of disucussion there has shifted to
"bdrv_read() from device init", so rather than continuing the
discussion as a tangent to the unrelated original topic I'm recreating
the thread.
So anyways,
The Buildbot has detected a new failure on builder default_i386_rhel61 while
building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_i386_rhel61/builds/298
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: kraxel_rhel61_32bit
No functional changes -- machine is still outwardly mpc8544ds.
The references that are not changed contain mpc8544 hardware details that
need to be parameterized if/when a different e500 platform wants to
change them.
Signed-off-by: Scott Wood
---
v2: no changes
hw/ppc/e500.c | 27 ++
Currently the only mpc8544ds-ism that is factored out is
toplevel compatible and model. In the future the generic e500
code is expected to become more generic.
Signed-off-by: Scott Wood
---
v2: Use the right part of the makefile for hw/ppc files
hw/ppc/Makefile.objs |3 +-
hw/ppc/e500.c
This gives the kernel a paravirtualized machine to target, without
requiring both sides to pretend to be targeting a specific board
that likely has little to do with the host in KVM scenarios. This
avoids the need to add new boards to QEMU, just to be able to
run KVM on new CPUs.
Signed-off-by: S
Rename the file (with no changes other than fixing up the header paths)
in preparation for refactoring into a generic e500 platform. Also move
it into the newly created ppc/ directory.
Signed-off-by: Scott Wood
---
v2: Use the right part of the makefile for hw/ppc files
hw/ppc/Makefile.objs
[resent with the proper address for qemu-devel, sorry...]
The current ppc_mpc8544ds.c is split into a generic (eventually) e500
backend, and two platform frontends (mpc8544ds and a generic paravirt
e500 platform) that instantiate the backend.
Currently the only distinction between the subplatform
On 07/02/2012 04:02 PM, Corey Bryant wrote:
> Here's another option that Kevin and I discussed today on IRC. I've
> modified a few minor details since the discussion. And Kevin please
> correct me if anything is wrong.
>
> Proposal Four: Pass a set of fds via 'pass-fds'. The group of fds
> shou
According to the Intel manual
"Intel® 64 and IA-32 Architectures Software Developer’s Manual
Volume 3", "3.4.4 Segment Loading Instructions in IA-32e Mode":
"When in compatibility mode, FS and GS overrides operate as defined by
32-bit mode behavior regardless of the value loaded into the upper 32
Max,
On 02.07.2012 17:18, Max Filippov wrote:
> On Mon, Jul 2, 2012 at 2:29 PM, Vitaly Chipounov
> wrote:
>> An instruction with address and segment size override triggers the bug.
>> inc dword ptr gs:260h[ebx*4] gets incorrectly translated to:
>> (uint32_t)(gs.base + ebx * 4 + 0x260)
>> instead
On 06/26/2012 06:54 PM, Eric Blake wrote:
On 06/26/2012 04:28 PM, Corey Bryant wrote:
With this proposed series, we have usage akin to:
1. pass_fd FDSET={M} -> returns a string "/dev/fd/N" showing QEMU's
view of the FD
2. drive_add file=/dev/fd/N
3. if failure:
cl
On 07/02/2012 04:17 PM, Alexander Graf wrote:
>
> On 02.07.2012, at 23:16, Scott Wood wrote:
>
>> On 07/02/2012 04:08 PM, Alexander Graf wrote:
>>>
>>> On 02.07.2012, at 23:07, Scott Wood wrote:
>>>
How is hw/ppc/e500.o better than ppc/e500.o?
>>>
>>> If I read this correctly, he's suggestin
On 02.07.2012, at 23:16, Scott Wood wrote:
> On 07/02/2012 04:08 PM, Alexander Graf wrote:
>>
>> On 02.07.2012, at 23:07, Scott Wood wrote:
>>
>>> On 07/02/2012 03:58 PM, Andreas Färber wrote:
Am 02.07.2012 22:32, schrieb Scott Wood:
> On 07/02/2012 12:06 PM, Scott Wood wrote:
>> O
On 07/02/2012 04:08 PM, Alexander Graf wrote:
>
> On 02.07.2012, at 23:07, Scott Wood wrote:
>
>> On 07/02/2012 03:58 PM, Andreas Färber wrote:
>>> Am 02.07.2012 22:32, schrieb Scott Wood:
On 07/02/2012 12:06 PM, Scott Wood wrote:
> On 07/02/2012 11:50 AM, Andreas Färber wrote:
>> Am
On 02.07.2012, at 23:07, Scott Wood wrote:
> On 07/02/2012 03:58 PM, Andreas Färber wrote:
>> Am 02.07.2012 22:32, schrieb Scott Wood:
>>> On 07/02/2012 12:06 PM, Scott Wood wrote:
On 07/02/2012 11:50 AM, Andreas Färber wrote:
> Am 28.06.2012 01:50, schrieb Scott Wood:
>> hw/ppc/Make
On 07/02/2012 03:58 PM, Andreas Färber wrote:
> Am 02.07.2012 22:32, schrieb Scott Wood:
>> On 07/02/2012 12:06 PM, Scott Wood wrote:
>>> On 07/02/2012 11:50 AM, Andreas Färber wrote:
Am 28.06.2012 01:50, schrieb Scott Wood:
> hw/ppc/Makefile.objs |2 +-
> hw/{pp
Am 02.07.2012 22:32, schrieb Scott Wood:
> On 07/02/2012 12:06 PM, Scott Wood wrote:
>> On 07/02/2012 11:50 AM, Andreas Färber wrote:
>>> Am 28.06.2012 01:50, schrieb Scott Wood:
hw/ppc/Makefile.objs |2 +-
hw/{ppce500_mpc8544ds.c => ppc/e500.c} | 16 -
On 07/02/2012 12:06 PM, Scott Wood wrote:
> On 07/02/2012 11:50 AM, Andreas Färber wrote:
>> Hi Scott,
>>
>> Am 28.06.2012 01:50, schrieb Scott Wood:
>>> Rename the file (with no changes other than fixing up the header paths)
>>> in preparation for refactoring into a generic e500 platform. Also mo
On 02.07.2012, at 19:44, Eli Lewis wrote:
>>
>
>> Well, PReP is dead since the mid-90's, no [1]? :) I'd be surprised if
>> you could get recent hardware still supporting it. Plus, I don't think it
>> really makes all that much sense. PReP is basically a 90's x86 machine with
>> PPC CPU. Not
On Mon, Jul 2, 2012 at 4:04 PM, Sebastian Malcolm
<686...@bugs.launchpad.net> wrote:
> Stefan, you fixed this in QEMU 24 Jan 2011 so this bug can be marked as
> Fixed Released?
Yes
> However, I cannot see a way to set "removable=on" for usb-storage
> devices started via libvirt (in 12.04, with l
On Mon, Jul 02, 2012 at 07:56:58PM +0100, Daniel P. Berrange wrote:
> On Mon, Jul 02, 2012 at 03:06:32PM -0300, Eduardo Habkost wrote:
> > Resending series, after fixing some coding style issues. Does anybody has
> > any
> > feedback about this proposal?
> >
> > Changes v1 -> v2:
> > - Coding st
Changes v1 -> v2:
- Do not initialize variable to false, to make checkpatch.pl happy
Signed-off-by: Eduardo Habkost
---
cpu-all.h |2 +-
vl.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/cpu-all.h b/cpu-all.h
index 9dc249a..2beed5a 100644
--- a/cpu-all.h
Resending series, after fixing some coding style issues. Does anybody has any
feedback about this proposal?
Changes v1 -> v2:
- Coding style fixes
Original cover letter:
I was investigating if there are any mechanisms that allow manually pinning of
guest RAM to specific host NUMA nodes, in the
On Mon, Jul 02, 2012 at 03:06:32PM -0300, Eduardo Habkost wrote:
> Resending series, after fixing some coding style issues. Does anybody has any
> feedback about this proposal?
>
> Changes v1 -> v2:
> - Coding style fixes
>
> Original cover letter:
>
> I was investigating if there are any mecha
Changes v1 -> v2:
- Fix trailing space issue
- Rebase against new code using g_strdup_printf()
Signed-off-by: Eduardo Habkost
---
exec.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/exec.c b/exec.c
index 1e98244..456ac73 100644
--- a/exec
Cc: Blue Swirl
Signed-off-by: Eduardo Habkost
---
exec.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/exec.c b/exec.c
index c8bfd27..d856325 100644
--- a/exec.c
+++ b/exec.c
@@ -24,6 +24,9 @@
#include
#endif
+#include
+#include
+
#include "qemu-com
Stefan, you fixed this in QEMU 24 Jan 2011 so this bug can be marked as
Fixed Released?
SEE: http://lists.gnu.org/archive/html/qemu-devel/2011-01/msg02425.html
Append ",removable=on" to a device definition for USB Mass Storage Devices to
override the removable bit (but off by default):
> qemu -u
This make QEMU create files inside the -mem-path directory using
more predictable names, and not remove them afterwards.
This allow (for example) users or management layers to use numactl
later, to set NUMA policy for the guest RAM.
Changes v1 -> v2:
- Fix trailing space issue
- Coding style ch
I can confirm this does not work in precise, however it looks like
creating files (and directories etc) was not implemented in qemu-kvm
1.0. File creation was added with commit
daf0b9aca9f67323266af1a92e8ea06f9d7bf408 .
This should work in quantal - if it does not, then that is a new bug.
However
On 06/28/2012 03:49 PM, Blue Swirl wrote:
On Wed, Jun 27, 2012 at 9:25 PM, Anthony Liguori wrote:
On 06/21/2012 03:04 AM, Avi Kivity wrote:
On 06/19/2012 09:58 PM, Blue Swirl wrote:
At least qemu-ifup/down scripts, migration exec and smbd have been
mentioned. Only the system calls made by
While we are at it, rename it to "length", as "memory" doesn't mean
anything.
Changes v1 -> v2:
- Rebase after coding style changes
Signed-off-by: Eduardo Habkost
---
exec.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/exec.c b/exec.c
index d856325..1e9824
Cc: Blue Swirl
Signed-off-by: Eduardo Habkost
---
exec.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/exec.c b/exec.c
index 8244d54..c8bfd27 100644
--- a/exec.c
+++ b/exec.c
@@ -2392,7 +2392,7 @@ static void *file_ram_alloc(RAMBlock *block,
unlink(filename);
On 06/22/2012 07:06 AM, Amit Shah wrote:
On (Wed) 20 Jun 2012 [16:29:22], Anthony Liguori wrote:
On 06/20/2012 01:59 AM, Amit Shah wrote:
The Linux kernel already has a virtio-rng driver, this is the device
implementation.
When the guest asks for entropy from the virtio hwrng, it puts a buffer
On Mon, Jul 02, 2012 at 11:08:14AM +, Liu, Jinsong wrote:
> Eduardo, Jan, Andreas
>
> As we sync 3 months ago, I wait until qemu1.1 done, then re-write patch based
> on qemu1.1.
> Now it's time to re-write my patch based on qemu1.1.
>
> Attached is a RFC patch for exposing tsc deadline timer
>
> Well, PReP is dead since the mid-90's, no [1]? :) I'd be surprised if
> you could get recent hardware still supporting it. Plus, I don't think it
> really makes all that much sense. PReP is basically a 90's x86 machine with
> PPC CPU. Not exactly what you'd consider elegant design.
>
> Wh
On 07/02/2012 11:50 AM, Andreas Färber wrote:
> Hi Scott,
>
> Am 28.06.2012 01:50, schrieb Scott Wood:
>> Rename the file (with no changes other than fixing up the header paths)
>> in preparation for refactoring into a generic e500 platform. Also move
>> it into the newly created ppc/ directory.
On 07/02/2012 04:16 AM, Juan Quintela wrote:
>
> Hi
>
> Please send in any agenda items you are interested in covering.
Can we discuss the future of 'getfd', the possibility of 'pass-fd', or
even the enhancement of all existing monitor commands to take an
optional 'nfds' JSON argument for atomic
On Mon, Jul 2, 2012 at 11:25 AM, Catalin Patulea wrote:
>
> FPREM1 now passes the TestFloat floatx80_rem suite (and FPREM is implemented
> very
> similarly).
>
> The code (the bulk of which is remainder_kernel and do_fprem) is derived from
> Bochs SVN revision 11224 dated 2012-06-21 10:33:37 -070
If you create a usb-storage device on the qemu command line
and then try to delete it via the monitor, QEMU asserts:
$ dd if=/dev/zero bs=4096 count=1024 of=usb.img
$ ./i386-softmmu/qemu-system-i386 -clock unix -monitor stdio -usb
-drive if=none,file=usb.img,id=myusb -device
usb-storage,id=myusb,
FPREM1 now passes the TestFloat floatx80_rem suite (and FPREM is implemented
very
similarly).
The code (the bulk of which is remainder_kernel and do_fprem) is derived from
Bochs SVN revision 11224 dated 2012-06-21 10:33:37 -0700, with conversions to
Qemu type aliases, C features only, etc. as nee
Add exynos4210 Clock Management Units emulation
Signed-off-by: Maksim Kozlov
---
hw/arm/Makefile.objs |1 +
hw/exynos4210.c | 16 +
hw/exynos4210.h | 42 ++
hw/exynos4210_cmu.c | 1464 ++
4 files changed, 1523 insertions(+), 0 de
Add using of functionality provided by CMU - get_rate and
register_clock_handler.
Signed-off-by: Maksim Kozlov
---
hw/exynos4210_uart.c | 48 +++-
1 files changed, 47 insertions(+), 1 deletions(-)
diff --git a/hw/exynos4210_uart.c b/hw/exynos4210_u
These patches add exynos4210 Clock Management Unit emulation
and usage of it by exynos4210 UART
Changelog:
v1->v2:
- hw/exynos4210_cmu.c: the 'const' qualifier was added to
global structures and arrays which shouldn't be changed
in runtime. Also, useless type casts were de
Am 02.07.2012 18:38, schrieb Scott Wood:
> On 07/02/2012 11:33 AM, Stuart Yoder wrote:
>> On Wed, Jun 27, 2012 at 6:51 PM, Scott Wood wrote:
>>> +static QEMUMachine e500plat_machine = {
>>> +.name = "e500plat",
>>> +.desc = "e500plat",
>>> +.init = e500plat_init,
>>> +.max_cpus = 1
Hi Scott,
Am 28.06.2012 01:50, schrieb Scott Wood:
> Rename the file (with no changes other than fixing up the header paths)
> in preparation for refactoring into a generic e500 platform. Also move
> it into the newly created ppc/ directory.
>
> Signed-off-by: Scott Wood
> ---
> hw/ppc/Makefil
On 07/02/2012 11:33 AM, Stuart Yoder wrote:
> On Wed, Jun 27, 2012 at 6:51 PM, Scott Wood wrote:
>> +static QEMUMachine e500plat_machine = {
>> +.name = "e500plat",
>> +.desc = "e500plat",
>> +.init = e500plat_init,
>> +.max_cpus = 15,
>> +};
>
> Can we call the generic e500 machi
On Wed, Jun 27, 2012 at 6:51 PM, Scott Wood wrote:
> This gives the kernel a paravirtualized machine to target, without
> requiring both sides to pretend to be targeting a specific board
> that likely has little to do with the host in KVM scenarios. This
> avoids the need to add new boards to QEM
Add support for (re-)initializing endpoints which belong to a specific
interface only. Use this in usb-host when changing altsetting for an
interface, so other interfaces are not disturbed.
Signed-off-by: Gerd Hoffmann
---
hw/usb.h|2 +-
hw/usb/bus.c|2 +-
hw/usb/cor
On 07/02/12 17:47, Gerd Hoffmann wrote:
>> diff --git a/hw/usb/core.c b/hw/usb/core.c
>> index 0e02da7..eacda74 100644
>> --- a/hw/usb/core.c
>> +++ b/hw/usb/core.c
>> @@ -407,7 +407,9 @@ void usb_packet_complete(USBDevice *dev, USBPacket *p)
>> int ret;
>>
>> usb_packet_check_state(p,
On 02.07.2012 17:05, Avi Kivity wrote:
On 06/28/2012 12:38 PM, Peter Lieven wrote:
does anyone know whats that here in handle_mmio?
/* hack: Red Hat 7.1 generates these weird accesses. */
if ((addr> 0xa-4&& addr<= 0xa)&& kvm_run->mmio.len == 3)
return 0;
Just wha
> diff --git a/hw/usb/core.c b/hw/usb/core.c
> index 0e02da7..eacda74 100644
> --- a/hw/usb/core.c
> +++ b/hw/usb/core.c
> @@ -407,7 +407,9 @@ void usb_packet_complete(USBDevice *dev, USBPacket *p)
> int ret;
>
> usb_packet_check_state(p, USB_PACKET_ASYNC);
> -assert(QTAILQ_FIRST(&e
On Mon, Jul 2, 2012 at 2:29 PM, Vitaly Chipounov
wrote:
> An instruction with address and segment size override triggers the bug.
> inc dword ptr gs:260h[ebx*4] gets incorrectly translated to:
> (uint32_t)(gs.base + ebx * 4 + 0x260)
> instead of
> gs.base + (uint32_t)(ebx * 4 + 0x260)
Do I unders
On 06/28/2012 12:38 PM, Peter Lieven wrote:
> does anyone know whats that here in handle_mmio?
>
> /* hack: Red Hat 7.1 generates these weird accesses. */
> if ((addr > 0xa-4 && addr <= 0xa) && kvm_run->mmio.len == 3)
> return 0;
>
Just what it says. There is a 4-byte ac
On Fri, Jun 29, 2012 at 9:13 AM, Andreas Färber wrote:
> Please run scripts/checkpatch.pl for CODING_STYLE issues, I spotted one
> slightly misplaced if brace, and one empty line at the bottom seemed to
> have indentation (git-am complains about that, too).
Done. The only issue left is a false pos
On Mon, 2012-07-02 at 16:31 +0200, Jan Kiszka wrote:
> On 2012-07-02 16:26, Alex Williamson wrote:
> > On Mon, 2012-07-02 at 14:38 +0200, Jan Kiszka wrote:
> >> This per-device notifier shall be triggered by any interrupt router
> >> along the path of a device's legacy interrupt signal on routing c
On Mon, Jul 2, 2012 at 3:15 PM, Markus Armbruster wrote:
> Andreas Färber writes:
>
>> Am 02.07.2012 14:55, schrieb Stefan Hajnoczi:
>>> On Fri, Jun 29, 2012 at 05:34:40PM +0200, Markus Armbruster wrote:
Best to use the same type, to avoid unwanted truncation or sign
extension.
>>>
On Thu, Jun 28, 2012 at 5:36 AM, wrote:
> From: lvroyce
>
>
> Signed-off-by: Royce Lv
> ---
> qmp-commands.hx | 30 +++---
> 1 files changed, 15 insertions(+), 15 deletions(-)
Reviewed-by: Stefan Hajnoczi
On 2012-07-02 16:26, Alex Williamson wrote:
> On Mon, 2012-07-02 at 14:38 +0200, Jan Kiszka wrote:
>> This per-device notifier shall be triggered by any interrupt router
>> along the path of a device's legacy interrupt signal on routing changes.
>> For simplicity reasons and as this is a slow path
On 07/01/2012 10:18 PM, Will Drewry wrote:
On Sun, Jul 1, 2012 at 8:25 AM, Paolo Bonzini wrote:
Il 18/06/2012 23:53, Corey Bryant ha scritto:
Can each thread have separate seccomp whitelists? For example CPU
threads should not need pretty much anything but the I/O thread needs
I/O.
No, s
On Mon, 2012-07-02 at 14:38 +0200, Jan Kiszka wrote:
> Add a PCI IRQ path discovery function that walks from a given device to
> the host bridge, returning the mode (enabled/inverted/disabled) and the
> IRQ number that is reported to the attached interrupt controller. For
> this purpose, another ho
On 06/26/2012 07:39 PM, Alexander Graf wrote:
> When running QEMU without -cpu parameter, the user usually wants a sane
> default. So far, we're using the qemu64/qemu32 CPU type, which basically
> means "the maximum TCG can emulate".
>
> That's a really good default when using TCG, but when runnin
On Mon, 2012-07-02 at 14:38 +0200, Jan Kiszka wrote:
> This per-device notifier shall be triggered by any interrupt router
> along the path of a device's legacy interrupt signal on routing changes.
> For simplicity reasons and as this is a slow path anyway, no further
> details on the routing chang
On 2012-07-02 13:05, Gerd Hoffmann wrote:
> Hi,
>
>> What I also so in the trace is that the USB core apparently stumbled as
>> a request that took very long too complete finally returned, and then
>> the assertion triggered over this request.
>
> Can I get such a trace please? usb_host_req_*
On 06/26/2012 07:39 PM, Alexander Graf wrote:
> During discussions on whether to make -cpu host the default in SLE, I found
> myself disagreeing to the thought, because it potentially opens a big can
> of worms for potential bugs. But if I already am so opposed to it for SLE, how
> can it possibly
Am 26.06.2012 18:39, schrieb Alexander Graf:
> During discussions on whether to make -cpu host the default in SLE, I found
s/make -cpu host the default/support/?
> myself disagreeing to the thought, because it potentially opens a big can
> of worms for potential bugs. But if I already am so oppos
From: lvroyce
Signed-off-by: Royce Lv
---
qmp-commands.hx | 30 +++---
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 2e1a38e..e0d0e4d 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -1420,9 +1420,9 @@ Ex
An instruction with address and segment size override triggers the bug.
inc dword ptr gs:260h[ebx*4] gets incorrectly translated to:
(uint32_t)(gs.base + ebx * 4 + 0x260)
instead of
gs.base + (uint32_t)(ebx * 4 + 0x260)
Signed-off-by: Vitaly Chipounov
---
target-i386/translate.c |2 +-
1 fil
Andreas Färber writes:
> Am 02.07.2012 14:55, schrieb Stefan Hajnoczi:
>> On Fri, Jun 29, 2012 at 05:34:40PM +0200, Markus Armbruster wrote:
>>> Best to use the same type, to avoid unwanted truncation or sign
>>> extension.
>>>
>>> BlockConf can't use plain int for cyls, heads and secs, because
>
On 26.06.2012, at 18:39, Alexander Graf wrote:
> During discussions on whether to make -cpu host the default in SLE, I found
> myself disagreeing to the thought, because it potentially opens a big can
> of worms for potential bugs. But if I already am so opposed to it for SLE, how
> can it possib
On Mon, 02 Jul 2012 07:47:56 -0500
Anthony Liguori wrote:
> > So far, there haven't been any calls for a change of the wire protocol.
>
> Changing all existing errors and repurposing 'desc' is effectively changing
> the
> wire protocol.
We're not going to change existing errors and I disagree
On 2 July 2012 13:25, Paolo Bonzini wrote:
> Il 02/07/2012 12:43, Peter Maydell ha scritto:
>>> > I can reproduce this with v1.1.0, but not with master, which suggests
>>> > it has been fixed at some point. I might try to bisect to find out
>>> > what exactly the fix was.
>> Bisection suggests com
On Sun, 01 Jul 2012 15:33:13 +0200
Paolo Bonzini wrote:
> Il 13/06/2012 12:54, Paolo Bonzini ha scritto:
> > Il 13/06/2012 10:22, Laszlo Ersek ha scritto:
> >> Inspired by [1], the first half of this series attempts to implement a new
> >> visitor that should clean up defining and processing comm
Am 02.07.2012 14:55, schrieb Stefan Hajnoczi:
> On Fri, Jun 29, 2012 at 05:34:40PM +0200, Markus Armbruster wrote:
>> Best to use the same type, to avoid unwanted truncation or sign
>> extension.
>>
>> BlockConf can't use plain int for cyls, heads and secs, because
>> integer properties require an
Hi,
Am 29.06.2012 15:55, schrieb Eli Lewis:
>
> I would like to use qemu to emulate a muliticore PowerPC PReP machine but it
> see that the SMP is not
> supported for the PReP architecture. In fact, running:
>
>
> qemu-system-ppc -M prep -smp 2
>
> It returns this message:
>
>
> Number of
On Fri, Jun 29, 2012 at 05:34:40PM +0200, Markus Armbruster wrote:
> Best to use the same type, to avoid unwanted truncation or sign
> extension.
>
> BlockConf can't use plain int for cyls, heads and secs, because
> integer properties require an exact width.
>
> Signed-off-by: Markus Armbruster
On 06/28/2012 02:50 AM, Markus Armbruster wrote:
Anthony Liguori writes:
On 06/26/2012 06:21 AM, Markus Armbruster wrote:
"Daniel P. Berrange" writes:
On Tue, Jun 26, 2012 at 09:54:21AM +0200, Markus Armbruster wrote:
Luiz Capitulino writes:
On Thu, 21 Jun 2012 13:42:19 +0100
"Daniel
Add a PCI IRQ path discovery function that walks from a given device to
the host bridge, returning the mode (enabled/inverted/disabled) and the
IRQ number that is reported to the attached interrupt controller. For
this purpose, another host bridge callback function is introduced:
route_intx_to_irq.
Back to the roots: This implements pci_device_route_intx_to_irq and the
PCI INTx routing notifier, but only those, without any caching for
existing emulated devices. I tried to carry over all other refactorings
and comment on the previous version.
Please review/merge.
Jan Kiszka (2):
pci: Add p
This per-device notifier shall be triggered by any interrupt router
along the path of a device's legacy interrupt signal on routing changes.
For simplicity reasons and as this is a slow path anyway, no further
details on the routing changes are provided. Instead, the callback is
expected to use pci
Am 02.07.2012 14:32, schrieb Paolo Bonzini:
> Il 26/06/2012 00:43, Anthony Liguori ha scritto:
>> In order to create qdev objects via -late-object, we almost always have to
>> specify the parent_bus which is usually created during machine init. Until
>> we
>> properly support two stage init, intr
Why does this lack recursive realization?
(I'm not top posting, I'm replying to the commit message. :))
Paolo
Il 26/06/2012 00:43, Anthony Liguori ha scritto:
> Signed-off-by: Anthony Liguori
> ---
> hw/qdev.c | 36 +++-
> 1 files changed, 35 insertions(+), 1
Il 26/06/2012 00:43, Anthony Liguori ha scritto:
> In order to create qdev objects via -late-object, we almost always have to
> specify the parent_bus which is usually created during machine init. Until we
> properly support two stage init, introduce a -late-object option that allows
> for
> crea
Il 26/06/2012 00:01, Anthony Liguori ha scritto:
> The various object_property_set_* functions are inconsistent because I
> didn't write them. I'm not sure why they take value/name. They should
> take name/value IMHO.
void object_property_set(Object *obj, Visitor *v, const char *name,
Am 02.07.2012 11:37, schrieb Paolo Bonzini:
> Il 02/07/2012 11:31, Peter Maydell ha scritto:
>> On 2 July 2012 10:08, Igor Mitsyanko wrote:
>>> So, what's the consensus here, for now new devices go to
>>> hw/arm/Makefile.objs while somebody moves all new and old not cpu-specific
>>> devices (not j
Il 02/07/2012 12:43, Peter Maydell ha scritto:
>>> >> Once apt starts to do disk I/O the kernel throws numerous SCSI errors:
>>> >> [ 165.292240] sd 0:0:0:0: [sda] Result: hostbyte=DID_OK
>>> >> driverbyte=DRIVER_SENSE
>>> >> [ 165.292653] sd 0:0:0:0: [sda] Sense Key : Aborted Command [current]
>
On 2 July 2012 13:04, Andreas Färber wrote:
> Am 02.07.2012 11:31, schrieb Peter Maydell:
>> On 2 July 2012 10:08, Igor Mitsyanko wrote:
>>> So, what's the consensus here, for now new devices go to
>>> hw/arm/Makefile.objs while somebody moves all new and old not cpu-specific
>>> devices (not jus
On 07/02/2012 03:44 PM, Andreas Färber wrote:
Am 01.07.2012 17:26, schrieb Paolo Bonzini:
Il 29/06/2012 14:26, Andreas Färber ha scritto:
Oh, I see. Should we place this device to hw/Makefile.objs in v2?
That would've been nice, but I'll do it as a follow-up now.
Yes, so we can also use Ant
Am 02.07.2012 14:10, schrieb Alexey Kardashevskiy:
> 02.07.2012 20:36, Paolo Bonzini пишет:
>> Il 21/06/2012 16:04, Andreas Färber ha scritto:
>>>
>>> *If* the file is built per target (hw/ppc64/Makefile.objs), then you can
>>> use *-softmmu/config-target.mak and just need to use a different
>>> Ma
02.07.2012 20:36, Paolo Bonzini пишет:
> Il 21/06/2012 16:04, Andreas Färber ha scritto:
>>
>> *If* the file is built per target (hw/ppc64/Makefile.objs), then you can
>> use *-softmmu/config-target.mak and just need to use a different
>> Makefile than before.
>>
>> *If* the file is built per libhw
Am 02.07.2012 12:36, schrieb Paolo Bonzini:
> Il 21/06/2012 16:04, Andreas Färber ha scritto:
>>
>> *If* the file is built per target (hw/ppc64/Makefile.objs), then you can
>> use *-softmmu/config-target.mak and just need to use a different
>> Makefile than before.
>>
>> *If* the file is built per
On 06/28/2012 10:22 PM, Juan Quintela wrote:
> 1st: we were synchonizing the dirty bitmap before calling
> memory_global_dirty_log_start().
>
> 2nd: We are marking all pages as dirty anywhere, no reason to go
> through all the bitmap to "mark" dirty same pages twice.
>
> So, call remov
Am 02.07.2012 11:31, schrieb Peter Maydell:
> On 2 July 2012 10:08, Igor Mitsyanko wrote:
>> So, what's the consensus here, for now new devices go to
>> hw/arm/Makefile.objs while somebody moves all new and old not cpu-specific
>> devices (not just exynos-related) from hw/arm/Makefile.objs to
>> h
1 - 100 of 186 matches
Mail list logo
