On 02.12.2009, at 19:53, Artyom Tarasenko wrote:
2009/12/2 Anthony Liguori anth...@codemonkey.ws:
Artyom Tarasenko wrote:
2009/12/1 Alexander Graf ag...@suse.de:
Hi,
Could someone with commit rights please stand up to feel responsible for
PPC?
Usually, when I send a patch to
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Dec 02, 2009 at 07:30:18PM +0100, Juan Quintela wrote:
We can change things to be int32_t if that makes more sense (they were sent
as uint32).
vmstate checks that the type of the value that you sent and the function
that you use for sending
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Dec 02, 2009 at 01:04:36PM +0100, Juan Quintela wrote:
viltio_blak_dma_restart_bh() was unsafe, it used req-next after having
(possible) put req in another list
Signed-off-by: Juan Quintela quint...@redhat.com
Sounds good, but why is this
Michael S. Tsirkin m...@redhat.com wrote:
You probably can just roll not used anymore
lines in the parent patch. It does not help
splitting this part out IMO.
I reordered the other patches several times.
Later, Juan.
On Wed, Dec 02, 2009 at 07:50:33PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Dec 02, 2009 at 07:22:11PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Dec 02, 2009 at 01:04:13PM +0100, Juan Quintela wrote:
diff --git
On Wed, Dec 02, 2009 at 07:55:51PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Dec 02, 2009 at 07:30:18PM +0100, Juan Quintela wrote:
We can change things to be int32_t if that makes more sense (they were sent
as uint32).
vmstate checks that the type
On Wed, Dec 02, 2009 at 07:56:58PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Dec 02, 2009 at 01:04:36PM +0100, Juan Quintela wrote:
viltio_blak_dma_restart_bh() was unsafe, it used req-next after having
(possible) put req in another list
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Dec 02, 2009 at 07:22:11PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Dec 02, 2009 at 01:04:13PM +0100, Juan Quintela wrote:
diff --git a/hw/virtio.c b/hw/virtio.c
index c136005..b565bf9 100644
---
Michael S. Tsirkin m...@redhat.com wrote:
I don't understand.
container_of is just more generic than DO_UPCAST.
So why *ever* use DO_UPCAST? Let's get rid of it.
functions that use a PCIDevice and you pass FooState require that
PCIDevice to be the 1st element in the struct.
Notice that it is
* Jan Kiszka jan.kis...@siemens.com [2009-12-02 12:45]:
So far, so consistent. Could you try kvm-kmod-2.6.32-rc7 on top of that?
Sure, can you remind me of the kvm-kmod build magic for building that
branch?
If you want to build from git, check Wolfgang's nice README. But it
Artyom Tarasenko wrote:
I thought attaching a second copy were the way to send the patch properly.
Attaching as an application/octet-stream is not terribly helpful. It
basically means you've attached a binary blob.
Is the proper way described somewhere?
The proper way is to use a
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Dec 02, 2009 at 01:04:31PM +0100, Juan Quintela wrote:
Signed-off-by: Juan Quintela quint...@redhat.com
---
hw/virtio-net.c | 148
---
1 files changed, 64 insertions(+), 84 deletions(-)
Anthony Liguori wrote:
I've got all of the patches I'm considering for 0.12 currently in
staging. I'm going to work through and test/commit these in a few
chunks over the next few days before freezing the tree.
If you have a pending patch that you think should be in 0.12, please
check to
* Ryan Harper ry...@us.ibm.com [2009-12-02 13:11]:
* Jan Kiszka jan.kis...@siemens.com [2009-12-02 12:45]:
So far, so consistent. Could you try kvm-kmod-2.6.32-rc7 on top of that?
Sure, can you remind me of the kvm-kmod build magic for building that
branch?
If you want
Ryan Harper wrote:
* Ryan Harper ry...@us.ibm.com [2009-12-02 13:11]:
* Jan Kiszka jan.kis...@siemens.com [2009-12-02 12:45]:
So far, so consistent. Could you try kvm-kmod-2.6.32-rc7 on top of that?
Sure, can you remind me of the kvm-kmod build magic for building that
branch?
If you want
Jan Kiszka wrote:
Anthony Liguori wrote:
I've got all of the patches I'm considering for 0.12 currently in
staging. I'm going to work through and test/commit these in a few
chunks over the next few days before freezing the tree.
If you have a pending patch that you think should be in 0.12,
Michael S. Tsirkin m...@redhat.com wrote:
On Wed, Dec 02, 2009 at 07:38:03PM +0100, Juan Quintela wrote:
Michael S. Tsirkin m...@redhat.com wrote:
I expect it fits in practice.
But you should range check the value and fail migration on error.
That is only
needed for old versions that we
On Wed, 02 Dec 2009 10:46:11 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
I've got all of the patches I'm considering for 0.12 currently in
staging. I'm going to work through and test/commit these in a few
chunks over the next few days before freezing the tree.
If you have a
Anthony Liguori wrote:
I've got all of the patches I'm considering for 0.12 currently in
staging.
http://repo.or.cz/w/qemu/aliguori-queue.git
I see you have my rng and size patches in there, thanks for the quick
review!
Is it too late to get the timer based socket reconnect patch in and the
Ian Molton wrote:
Anthony Liguori wrote:
I've got all of the patches I'm considering for 0.12 currently in
staging.
http://repo.or.cz/w/qemu/aliguori-queue.git
I see you have my rng and size patches in there, thanks for the quick
review!
Is it too late to get the timer
Anthony Liguori wrote:
Ian Molton wrote:
Actually, that patch would break a production environment. You cannot
sleep in qemu. It will severely impact the guest.
I refer to the version posted today, which doesnt sleep, but uses a
timer instead. (or did I miss something and a callled function
Luiz Capitulino wrote:
On Wed, 02 Dec 2009 10:46:11 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
I've got all of the patches I'm considering for 0.12 currently in
staging. I'm going to work through and test/commit these in a few
chunks over the next few days before freezing the
Ian Molton wrote:
Anthony Liguori wrote:
Ian Molton wrote:
Actually, that patch would break a production environment. You cannot
sleep in qemu. It will severely impact the guest.
I refer to the version posted today, which doesnt sleep, but uses a
timer instead. (or did I
Ian Molton wrote:
Anthony Liguori wrote:
sleep() in qemu is very, very wrong. It will pause the guest's
execution and all sorts of badness can ensue.
Quite...
The right thing to do is set a timer and not generate data while
disconnected.
New patch attached, now with less
On Wed, 02 Dec 2009 13:54:20 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
Luiz Capitulino wrote:
On Wed, 02 Dec 2009 10:46:11 -0600
Anthony Liguori anth...@codemonkey.ws wrote:
I've got all of the patches I'm considering for 0.12 currently in
staging. I'm going to work
Reposting as requested. hopefully t-brid doesnt whitespace-mangle it.
Anthony Liguori wrote:
sleep() in qemu is very, very wrong. It will pause the guest's
execution and all sorts of badness can ensue.
Quite...
The right thing to do is set a timer and not generate data while
Am Mittwoch 02 Dezember 2009 09:54:04 schrieb Alexander Graf:
Experience has shown that it doesn't work like that. It happens the
person writing the patches never provides a fix, and the committer
receives the complains, and in fine fixes the commit.
Then revert the patch. I also think
Jan Kiszka wrote:
Artyom Tarasenko wrote:
2009/12/1 Alexander Graf ag...@suse.de:
Hi,
Could someone with commit rights please stand up to feel responsible for
PPC?
Usually, when I send a patch to qemu-devel, I know who to address to
increase chances of it getting committed. For
While x86 only needs to sync cr0-4 to know all about its MMU state and enable
qemu to resolve virtual to physical addresses, we need to sync all of the
segment registers on PPC to know which mapping we're in.
So let's grab the segment register contents to be able to use the x monitor
command and
Some recent change made PPC guests always start at address 0x0 because env
isn't synced to kvm_state on first bootup.
I'm not sure if this is the correct bugfix, but at least it makes PPC boot
again with KVM enabled.
Signed-off-by: Alexander Graf ag...@suse.de
---
hw/ppc_newworld.c |4
Hello Ian,
Pasting chunks, then commenting:
+static int qemu_chr_sched_reconnect(TCPCharDriver *s)
+{
+struct reconnect_list *new = qemu_malloc(sizeof(*new));
+struct timeval tv;
+
+if(!new)
+return 1;
Qemu_malloc will never return 0, so sched function can return void.
+
Add generic support for debugging consoles (simple I/O ports which
when written to cause debugging output to be written to a target.)
The current implementation matches Bochs' port 0xe9, allowing the same
debugging code to be used for both Bochs and Qemu.
There is no vm state associated with the
On Wed, 2 Dec 2009, H. Peter Anvin wrote:
Add generic support for debugging consoles (simple I/O ports which
when written to cause debugging output to be written to a target.)
The current implementation matches Bochs' port 0xe9, allowing the same
debugging code to be used for both Bochs and
Add generic support for debugging consoles (simple I/O ports which
when written to cause debugging output to be written to a target.)
The current implementation matches Bochs' port 0xe9, allowing the same
debugging code to be used for both Bochs and Qemu.
There is no vm state associated with the
Hi,
In qemu 0.11.0, it handle lddqu as:
case 0x3f0: /* lddqu */
if (mod == 3)
goto illegal_op;
gen_lea_modrm(s, modrm, reg_addr, offset_addr);
gen_sto_env_A0(s-mem_index, offsetof(CPUX86State,xmm_regs[reg]));
break;
It st the
On Wed, Dec 02, 2009 at 01:04:16PM +0100, Jan Kiszka wrote:
Gleb Natapov wrote:
On Tue, Dec 01, 2009 at 10:51:26AM -0200, Glauber Costa wrote:
This is a repost of the -smp series. Note that it depends on
irqchip-in-kernel,
that is already in staging. Also, you'll have to enable the
201 - 236 of 236 matches
Mail list logo
