Avi Kivity wrote:
> > > Slot searching is quite fast since there's a small number of slots, and
> > > we sort the larger ones to be in the front, so positive lookups are fast.
> > > We cache negative lookups in the shadow page tables (an spte can be
> > > either "not mapped", "mapped to RAM"
All
When I reading the code, i find in the cpu_log_items the
CPU_LOG_IOPORT is not enabled since the
DEBUD_IOPORT is not defined.
I searched the configure file but find no option to enable this.
So currently the only way to do this is comment out the macro in ioport.c?
--
Wizard
2012/2/12 Paul Brook
> > +static void cadence_timer_sync(CadenceTimerState *s)
> > +{
> >...
> > +r = (int64_t)cadence_timer_get_steps(s, s->cpu_time - old_time);
> > +x = (int64_t)s->reg_value + ((s->reg_count & COUNTER_CTRL_DEC) ? -r
> :
> > r); +
> > +for (i = 0; i < 3; ++i) {
> >
On Sat, Feb 4, 2012 at 08:02, Paolo Bonzini wrote:
> Do not poke anymore in the struct when accessing qdev properties.
> Instead, ask the object to set the right value.
>
> Signed-off-by: Paolo Bonzini
> ---
> hw/qdev-addr.c | 5 ++-
> hw/qdev-properties.c | 78 +++
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka wrote:
> This enables acceleration for MMIO-based TPR registers accesses of
> 32-bit Windows guest systems. It is mostly useful with KVM enabled,
> either on older Intel CPUs (without flexpriority feature, can also be
> manually disabled for testing) or an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 11.02.2012 15:24, schrieb Jan Kiszka:
> On 2012-02-11 15:12, Andreas Färber wrote:
>> Am 11.02.2012 15:02, schrieb Jan Kiszka:
>>> On 2012-02-11 14:59, Andreas Färber wrote:
Am 11.02.2012 14:35, schrieb Jan Kiszka:
> On 2012-02-11 14:21, An
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka wrote:
> This will allow the APIC core to file a TPR access report. Depending on
> the accelerator and kernel irqchip mode, it will either be delivered
> right away or queued for later reporting.
>
> In TCG mode, we can restart the triggering instruction a
On 2012-02-11 15:16, Blue Swirl wrote:
> On Fri, Feb 10, 2012 at 18:31, Jan Kiszka wrote:
>> In order to perform critical manipulations on the VM state in the
>> context of a VCPU, specifically code patching, stopping and resuming of
>> all VCPUs may be necessary. resume_all_vcpus is already compa
On 2012-02-11 15:12, Andreas Färber wrote:
> Am 11.02.2012 15:02, schrieb Jan Kiszka:
>> On 2012-02-11 14:59, Andreas Färber wrote:
>>> Am 11.02.2012 14:35, schrieb Jan Kiszka:
On 2012-02-11 14:21, Andreas Färber wrote:
> CPU base class v3: http://patchwork.ozlabs.org/patch/139284/
> (
On Sat, Feb 11, 2012 at 14:18, Jan Kiszka wrote:
> On 2012-02-11 15:11, Blue Swirl wrote:
>> On Sat, Feb 11, 2012 at 14:00, Jan Kiszka wrote:
>>> On 2012-02-11 14:54, Blue Swirl wrote:
On Sat, Feb 11, 2012 at 12:43, Jan Kiszka wrote:
> On 2012-02-11 12:49, Andreas Färber wrote:
>> A
> +static void cadence_timer_sync(CadenceTimerState *s)
> +{
>...
> +r = (int64_t)cadence_timer_get_steps(s, s->cpu_time - old_time);
> +x = (int64_t)s->reg_value + ((s->reg_count & COUNTER_CTRL_DEC) ? -r :
> r); +
> +for (i = 0; i < 3; ++i) {
> +if (is_between((int64_t)s->reg_m
On 2012-02-11 15:11, Blue Swirl wrote:
> On Sat, Feb 11, 2012 at 14:00, Jan Kiszka wrote:
>> On 2012-02-11 14:54, Blue Swirl wrote:
>>> On Sat, Feb 11, 2012 at 12:43, Jan Kiszka wrote:
On 2012-02-11 12:49, Andreas Färber wrote:
> Am 11.02.2012 12:25, schrieb Blue Swirl:
>> I think us
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka wrote:
> In order to perform critical manipulations on the VM state in the
> context of a VCPU, specifically code patching, stopping and resuming of
> all VCPUs may be necessary. resume_all_vcpus is already compatible, now
> enable pause_all_vcpus for this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 11.02.2012 15:02, schrieb Jan Kiszka:
> On 2012-02-11 14:59, Andreas Färber wrote:
>> Am 11.02.2012 14:35, schrieb Jan Kiszka:
>>> On 2012-02-11 14:21, Andreas Färber wrote:
CPU base class v3: http://patchwork.ozlabs.org/patch/139284/
(v4
On Sat, Feb 11, 2012 at 14:00, Jan Kiszka wrote:
> On 2012-02-11 14:54, Blue Swirl wrote:
>> On Sat, Feb 11, 2012 at 12:43, Jan Kiszka wrote:
>>> On 2012-02-11 12:49, Andreas Färber wrote:
Am 11.02.2012 12:25, schrieb Blue Swirl:
> I think using cpu_single_env is an indication of a probl
On 2012-02-11 14:59, Andreas Färber wrote:
> Am 11.02.2012 14:35, schrieb Jan Kiszka:
>> On 2012-02-11 14:21, Andreas Färber wrote:
>>> CPU base class v3: http://patchwork.ozlabs.org/patch/139284/ (v4
>>> coming up)
>>>
>>> That doesn't prevent target-specific devices. Although Paolo does
>>> want
On 2012-02-11 14:54, Blue Swirl wrote:
> On Sat, Feb 11, 2012 at 12:43, Jan Kiszka wrote:
>> On 2012-02-11 12:49, Andreas Färber wrote:
>>> Am 11.02.2012 12:25, schrieb Blue Swirl:
I think using cpu_single_env is an indication of a problem, like poor
code, layering violation or poor API
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 11.02.2012 14:35, schrieb Jan Kiszka:
> On 2012-02-11 14:21, Andreas Färber wrote:
>> CPU base class v3: http://patchwork.ozlabs.org/patch/139284/ (v4
>> coming up)
>>
>> That doesn't prevent target-specific devices. Although Paolo does
>> want tha
On Sat, Feb 11, 2012 at 12:43, Jan Kiszka wrote:
> On 2012-02-11 12:49, Andreas Färber wrote:
>> Am 11.02.2012 12:25, schrieb Blue Swirl:
>>> I think using cpu_single_env is an indication of a problem, like poor
>>> code, layering violation or poor API (vmport). What is your use case?
>>
>> I coul
On 2012-02-11 14:21, Andreas Färber wrote:
> Am 11.02.2012 14:07, schrieb Jan Kiszka:
>> On 2012-02-11 14:06, Andreas Färber wrote:
>>> Am 11.02.2012 13:43, schrieb Jan Kiszka:
On 2012-02-11 12:49, Andreas Färber wrote:
> Am 11.02.2012 12:25, schrieb Blue Swirl:
>> I think using cpu_si
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 11.02.2012 14:07, schrieb Jan Kiszka:
> On 2012-02-11 14:06, Andreas Färber wrote:
>> Am 11.02.2012 13:43, schrieb Jan Kiszka:
>>> On 2012-02-11 12:49, Andreas Färber wrote:
Am 11.02.2012 12:25, schrieb Blue Swirl:
> I think using cpu_singl
Hello,
Am 12.04.2011 10:25, schrieb Guan Xuetao:
>
> The patch set adds new unicore32-linux-user support for qemu-stable-0.14
> Patch 1 adds target-unicore32 directory
> Patch 2 adds linux-user/unicore32 directory
> Patch 3 adds necessary modifications for other files
>
> V2->V3: reb
On 2012-02-11 14:06, Andreas Färber wrote:
> Am 11.02.2012 13:43, schrieb Jan Kiszka:
>> On 2012-02-11 12:49, Andreas Färber wrote:
>>> Am 11.02.2012 12:25, schrieb Blue Swirl:
I think using cpu_single_env is an indication of a problem,
like poor code, layering violation or poor API (vmpo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 11.02.2012 13:43, schrieb Jan Kiszka:
> On 2012-02-11 12:49, Andreas Färber wrote:
>> Am 11.02.2012 12:25, schrieb Blue Swirl:
>>> I think using cpu_single_env is an indication of a problem,
>>> like poor code, layering violation or poor API (vmport
On 2012-02-11 13:51, Andreas Färber wrote:
> Am 11.02.2012 13:45, schrieb Jan Kiszka:
>> On 2012-02-11 12:46, Andreas Färber wrote:
>>> Am 10.02.2012 19:31, schrieb Jan Kiszka:
Always add a byte before the final 512-bytes alignment to
reserve the space for the ROM checksum.
Sign
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 11.02.2012 13:45, schrieb Jan Kiszka:
> On 2012-02-11 12:46, Andreas Färber wrote:
>> Am 10.02.2012 19:31, schrieb Jan Kiszka:
>>> Always add a byte before the final 512-bytes alignment to
>>> reserve the space for the ROM checksum.
>>>
>>> Signed-
On 2012-02-11 12:46, Andreas Färber wrote:
> Am 10.02.2012 19:31, schrieb Jan Kiszka:
>> Always add a byte before the final 512-bytes alignment to reserve the
>> space for the ROM checksum.
>>
>> Signed-off-by: Jan Kiszka
>> ---
>> pc-bios/optionrom/optionrom.h |3 ++-
>> 1 files changed, 2 i
On 2012-02-11 12:49, Andreas Färber wrote:
> Am 11.02.2012 12:25, schrieb Blue Swirl:
>> I think using cpu_single_env is an indication of a problem, like poor
>> code, layering violation or poor API (vmport). What is your use case?
>
> I couldn't spot any in this series. Jan, note that any new use
On 2012-02-11 12:25, Blue Swirl wrote:
> On Sat, Feb 11, 2012 at 10:06, Jan Kiszka wrote:
>> On 2012-02-11 11:02, Blue Swirl wrote:
>>> On Fri, Feb 10, 2012 at 18:31, Jan Kiszka wrote:
As we have thread-local cpu_single_env now and KVM uses exactly one
thread per VCPU, we can drop the c
Am 11.02.2012 10:19, schrieb Blue Swirl:
> On Wed, Feb 8, 2012 at 15:36, Andreas Färber wrote:
>> This is not about whether or not we put a space somewhere.
>>
>> It's about reviewers and SubmitAPatch telling people to run
>> checkpatch.pl on patches and checkpatch.pl reporting this as an ERROR,
>
Am 11.02.2012 12:25, schrieb Blue Swirl:
> I think using cpu_single_env is an indication of a problem, like poor
> code, layering violation or poor API (vmport). What is your use case?
I couldn't spot any in this series. Jan, note that any new use of env or
cpu_single_env will need to be redone wh
Am 10.02.2012 19:31, schrieb Jan Kiszka:
> Always add a byte before the final 512-bytes alignment to reserve the
> space for the ROM checksum.
>
> Signed-off-by: Jan Kiszka
> ---
> pc-bios/optionrom/optionrom.h |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/pc-b
Am 11.02.2012 10:26, schrieb Blue Swirl:
> On Thu, Feb 9, 2012 at 15:30, Andreas Färber wrote:
>> Hello Blue,
>>
>> I recently stumbled over the following checkpatch.pl false positive:
>>
>> --8<--
>>
>> --- a/hw/his.c
>> +++ b/hw/his.c
>> @@ -1,1 +1,1 @@
>> -cpu_reset(CPUState *env);
>> +
On Sat, Feb 11, 2012 at 10:06, Jan Kiszka wrote:
> On 2012-02-11 11:02, Blue Swirl wrote:
>> On Fri, Feb 10, 2012 at 18:31, Jan Kiszka wrote:
>>> As we have thread-local cpu_single_env now and KVM uses exactly one
>>> thread per VCPU, we can drop the cpu_single_env updates from the loop
>>> and i
Thanks, applied.
On Tue, Feb 7, 2012 at 15:03, Jan Kiszka wrote:
> This fixes the regression introduced by cd7a45c95e: We lost the or'ing
> with the full_update flag.
>
> Signed-off-by: Jan Kiszka
> ---
>
> Applies on top of the other related fix:
> http://thread.gmane.org/gmane.comp.emulators.q
Thanks, applied.
On Sat, Feb 4, 2012 at 15:25, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Helpful to understand guest configurations of things like the i440FX's
> PAM or the state of ROM devices.
>
> Signed-off-by: Jan Kiszka
> ---
>
> Changes in v3:
> - refactored writable condition (which DO m
Thanks, applied.
On Sat, Feb 4, 2012 at 14:58, Jan Kiszka wrote:
> The conversion to memory regions broke lazy ROMD switching by forgetting
> to update the rom_mode state variable.
>
> Signed-off-by: Jan Kiszka
> ---
> hw/pflash_cfi02.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(
On Mon, Feb 6, 2012 at 15:57, Alexander Graf wrote:
>
> On 06.02.2012, at 16:21, Andreas Färber wrote:
>
>> Am 04.02.2012 12:49, schrieb Blue Swirl:
>>> Fix this error:
>>> /src/qemu/target-ppc/helper.c: In function 'booke206_tlb_to_page_size':
>>> /src/qemu/target-ppc/helper.c:1296:14: error: var
On 2012-02-11 11:02, Blue Swirl wrote:
> On Fri, Feb 10, 2012 at 18:31, Jan Kiszka wrote:
>> As we have thread-local cpu_single_env now and KVM uses exactly one
>> thread per VCPU, we can drop the cpu_single_env updates from the loop
>> and initialize this variable only once during setup.
>
> I d
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka wrote:
> As we have thread-local cpu_single_env now and KVM uses exactly one
> thread per VCPU, we can drop the cpu_single_env updates from the loop
> and initialize this variable only once during setup.
I don't think this is correct. Maybe you missed the
Hello everyone,
I am testing virtio-blk throughput (single thread, using hdparm -tT
). I want to know what is the guest/baremetal sequential read ratio
with the current qemu / qemu-kvm builds.
I have tried with qemu 1.0, 0.15, 0.14.1 , but my guest throughput is
limited to 65 MB/s. Baremetal is
Cool. Writes about 9 times the data of the actual snapshot size.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/741887
Title:
virsh snapshot-create too slow (kvm, qcow2, savevm)
Status in QEMU:
N
On Fri, Feb 10, 2012 at 17:47, Anthony Liguori wrote:
> On 02/09/2012 10:02 PM, malc wrote:
>>
>> On Fri, 10 Feb 2012, Evgeny Voevodin wrote:
>>
>>> On 02/09/2012 06:59 PM, Andreas F?rber wrote:
Disable warnings for spaces before opening parenthesis in
hw/{ac97,adlib,cs4231a,es1370,
On Thu, Feb 9, 2012 at 14:59, Andreas Färber wrote:
> Disable warnings for spaces before opening parenthesis in
> hw/{ac97,adlib,cs4231a,es1370,gus,sb16}.c.
>
> Signed-off-by: Andreas Färber
> Cc: Blue Swirl
> Cc: malc
> ---
> scripts/checkpatch.pl | 5 +
> 1 files changed, 5 insertions
On Thu, Feb 9, 2012 at 15:30, Andreas Färber wrote:
> Hello Blue,
>
> I recently stumbled over the following checkpatch.pl false positive:
>
> --8<--
>
> --- a/hw/his.c
> +++ b/hw/his.c
> @@ -1,1 +1,1 @@
> - cpu_reset(CPUState *env);
> + cpu_state_reset(CPUState *env);
>
> --- a/hw/hers.c
>
On Wed, Feb 8, 2012 at 15:36, Andreas Färber wrote:
> Am 08.02.2012 16:23, schrieb Anthony Liguori:
>> On 02/08/2012 09:04 AM, malc wrote:
>>> On Wed, 8 Feb 2012, Andreas F?rber wrote:
>>>
Arbitrarily reformatting your files is not okay. If you want a different
formatting, you need to fi
The standard include files are already included in qemu-common.h.
malloc.h and alloca.h were needed for alloca() which was removed
from TCG code some years ago when switching from dyngen to TCG
(see commit 49516bc0d622112caac9df628caf19010fda8b67).
Signed-off-by: Stefan Weil
---
tcg/tcg.c | 1
On Wed, Feb 8, 2012 at 15:23, Anthony Liguori wrote:
> On 02/08/2012 09:04 AM, malc wrote:
>>
>> On Wed, 8 Feb 2012, Andreas F?rber wrote:
>>
>>> malc,
>>>
>>> Arbitrarily reformatting your files is not okay. If you want a different
>>> formatting, you need to fix checkpatch.pl first to not error
On Thu, Feb 9, 2012 at 7:08 PM, Peter Lieven wrote:
> Hi,
>
> is anyone aware if there are still problems when enabling the threaded vnc
> server?
> I saw some VMs crashing when using a qemu-kvm build with
> --enable-vnc-thread.
>
> qemu-kvm-1.0[22646]: segfault at 0 ip 7fec1ca7ea0b sp 7fe
49 matches
Mail list logo
