On 04/26/2010 04:53 AM, Anthony Liguori wrote:
On 04/25/2010 06:51 AM, Avi Kivity wrote:
It depends on what things you think are important. A lot of
libvirt's complexity is based on the fact that it uses a daemon and
needs to deal with the security implications of that. You don't
need explic
On 04/25/2010 07:42 PM, Jan Kiszka wrote:
Unrelated:
cpu_physical_sync_dirty_bitmap(isa_mem_base + 0xa, 0xa8000);
cpu_physical_sync_dirty_bitmap(isa_mem_base + 0xa8000, 0xb);
Will this sync to the right place (whatever those windows alias to)?
It should. Or w
Hi,
I am trying to debug a VM using gdb. I connected gdb to Qemu (latest
code from git repo), and issued below command:
...
(gdb) watch *0x77f44cd8
(gdb) c
The idea is to catch the write access to address 0x77f44cd8.
But after the "c" command, I saw that the window title of my VM
continuously f
On 04/25/2010 06:51 AM, Avi Kivity wrote:
It depends on what things you think are important. A lot of
libvirt's complexity is based on the fact that it uses a daemon and
needs to deal with the security implications of that. You don't need
explicit labelling if you don't use a daemon.
I do
On 04/23/2010 10:36 AM, Fernando Luis Vázquez Cao wrote:
On 04/23/2010 02:17 PM, Yoshiaki Tamura wrote:
Dor Laor wrote:
[...]
Second, even if it wasn't the case, the tsc delta and kvmclock are
synchronized as part of the VM state so there is no use of trapping it
in the middle.
I should stud
24.04.2010 17:05, Andreas Färber wrote:
Am 22.04.2010 um 11:40 schrieb Michael Tokarev:
11.03.2010 18:34, Michael Tokarev wrote:
[]
On version 0.12.3, -drive serial=XXX option does not work.
Below patch fixes it. 'serial' is pointer, not array.
--- qemu-kvm-0.12.3+dfsg/vl.c 2010-02-26 11:34:
On 4/25/10, Richard Henderson wrote:
> Single-stepping was not properly updating npc, resulting in some
> instructions being executed twice. In addition, we were emitting
> dead code at the end of the TB.
>
> Fix both by teaching gen_goto_tb to avoid goto_tb for single-step
> and removing the
Thanks, applied.
On 4/25/10, Richard Henderson wrote:
> Signed-off-by: Richard Henderson
> ---
> linux-user/main.c |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/linux-user/main.c b/linux-user/main.c
> index b394c00..71a1b67 100644
> --- a/linux-user/mai
Signed-off-by: Richard Henderson
---
linux-user/main.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/linux-user/main.c b/linux-user/main.c
index b394c00..71a1b67 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -940,7 +940,8 @@ static void flush_windows(CPU
Single-stepping was not properly updating npc, resulting in some
instructions being executed twice. In addition, we were emitting
dead code at the end of the TB.
Fix both by teaching gen_goto_tb to avoid goto_tb for single-step
and removing the special-case code in gen_intermediate_code_internal.
Signed-off-by: David Ahern
---
hw/usb-ehci.c | 41 +
1 files changed, 29 insertions(+), 12 deletions(-)
diff --git a/hw/usb-ehci.c b/hw/usb-ehci.c
index 29baf74..e2f8e54 100644
--- a/hw/usb-ehci.c
+++ b/hw/usb-ehci.c
@@ -144,7 +144,7 @@
#define NB_MAXIN
Hi Jan:
Another patch for the ehci branch - emptying out my patch queue as I need to
set this aside for a while.
I am testing qemu and qemu-kvm with 3 different USB keys -- all Kingstons of
various sizes 1 GB, 4GB and 8GB. I am definitely seeing different behaviors
with the 4GB and 8GB workin
Current code of monitor command: 'change', used to open file for read-write
uncoditionally. Change to open it as read-only for CDROM, and read-write for
all others.
Signed-off-by: Naphtali Sprei
---
monitor.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/monitor.c
Avi Kivity wrote:
> On 04/25/2010 06:07 PM, Jan Kiszka wrote:
>>
>>> The fact that the API assumes a single user is what's broken IMO.
>>>
>>> If the API were to take a memory slot as parameter you could say it is
>>> the responsibility of the slot's owner to multiplex (and since vga has a
>>> sing
David Ahern wrote:
> Update usb-linux to handle maximum of 16k transfers. The 16k limit
> is imposed by USBFS. EHCI allows up to 20k per request.
>
> USBFS cannot be increased to 20k due to constraints on memory use (wants
> contiguous memory in allocations that are powers of 2). This change
> bre
On 04/25/2010 06:07 PM, Jan Kiszka wrote:
The fact that the API assumes a single user is what's broken IMO.
If the API were to take a memory slot as parameter you could say it is
the responsibility of the slot's owner to multiplex (and since vga has a
single owner, no need to multiplex). But
David Ahern wrote:
> Signed-off-by: David Ahern
Looks good. Picked it up for 'ehci', but this patch should already be
considered for upstream as well.
Thanks,
Jan
> ---
> usb-linux.c | 374
> +++
> 1 files changed, 224 insertions(+), 15
On 4/25/10, Richard Henderson wrote:
> On 04/23/2010 11:36 AM, Blue Swirl wrote:
> > On 4/23/10, Richard Henderson wrote:
> >> The ABI-specific types used by linux_binprm and image_info
> >> are different after forcing TARGET_ABI32 on. Which means
> >> that the parameters that load_elf_bin
Avi Kivity wrote:
> On 04/25/2010 05:51 PM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>
>>> On 04/25/2010 05:29 PM, Jan Kiszka wrote:
>>>
> There isn't. But I don't like hidden breakage.
>
>
It's (so far) an unproblematic API property we can document. I
Thanks, applied.
On 4/23/10, Richard Henderson wrote:
> Greatly simplify the subpage implementation by not supporting
> multiple devices at the same address at different widths. We
> don't need full copies of mem_read/mem_write/opaque for each
> address, only a single index back into the main
On 04/25/2010 05:51 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 04/25/2010 05:29 PM, Jan Kiszka wrote:
There isn't. But I don't like hidden breakage.
It's (so far) an unproblematic API property we can document. I don't
like changing APIs just for "there might be th
Avi Kivity wrote:
> On 04/25/2010 05:29 PM, Jan Kiszka wrote:
>>
>>> There isn't. But I don't like hidden breakage.
>>>
>> It's (so far) an unproblematic API property we can document. I don't
>> like changing APIs just for "there might be the case that...".
>>
>
> I guess it's one of th
On 04/23/2010 09:33 PM, Anthony Liguori wrote:
This is a different ambiguity, about the semantic results of the
commands,
where as I'm refering to the execution order. If I look at a libvirt log
file and see a set of JSON commands logged, I want to know that this
ordering
from the logs, was ind
On 04/25/2010 05:29 PM, Jan Kiszka wrote:
There isn't. But I don't like hidden breakage.
It's (so far) an unproblematic API property we can document. I don't
like changing APIs just for "there might be the case that...".
I guess it's one of those agree to disagree things. I disli
Avi Kivity wrote:
> On 04/25/2010 04:57 PM, Jan Kiszka wrote:
>>
>>> It's still a good idea. The current API assumes that there will be only
>>> one slot-based client (or that multiple clients will keep the refcount
>>> themselves).
>>>
>>> After the bytemap -> multiple bitmaps conversion this ca
On 04/25/2010 04:57 PM, Jan Kiszka wrote:
It's still a good idea. The current API assumes that there will be only
one slot-based client (or that multiple clients will keep the refcount
themselves).
After the bytemap -> multiple bitmaps conversion this can be extended to
each client getting i
Avi Kivity wrote:
> On 04/24/2010 10:34 AM, Jan Kiszka wrote:
>> Marcelo Tosatti wrote:
>>
>>> Otherwise there is no way to differentiate between global and slot
>>> specific logging, so for example
>>>
>>> vga dirty log start
>>> migration start
>>> migration fail
>>>
>>> Disables dirty logging
On 04/23/2010 08:04 PM, Marcelo Tosatti wrote:
Looks good.
--
error compiling committee.c: too many arguments to function
On 04/24/2010 10:34 AM, Jan Kiszka wrote:
Marcelo Tosatti wrote:
Otherwise there is no way to differentiate between global and slot
specific logging, so for example
vga dirty log start
migration start
migration fail
Disables dirty logging for the vga slot.
This is not true (unless t
On 04/25/2010 06:39 AM, Anthony Liguori wrote:
On 04/24/2010 04:46 AM, Avi Kivity wrote:
On 04/23/2010 09:29 PM, Anthony Liguori wrote:
Maybe. We'll still have issues. For example, sVirt: if a QMP
command names a labeled resource, the non-libvirt user will have no
way of knowing how to label
30 matches
Mail list logo