From: Jan Kiszka
kvm_arch_reset_vcpu initializes mp_state, and that function is invoked
right after kvm_arch_init_vcpu.
Signed-off-by: Jan Kiszka
---
target-i386/kvm.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 30aa51c.
From: Jan Kiszka
Introduce the cpu_dump_state flag CPU_DUMP_CODE and implement it for
x86. This writes out the code bytes around the current instruction
pointer. Make use of this feature in KVM to help debugging fatal vm
exits.
Signed-off-by: Jan Kiszka
---
cpu-all.h|2 ++
kvm-
From: Jan Kiszka
No functional changes.
Signed-off-by: Jan Kiszka
---
kvm-all.c | 139 ++--
1 files changed, 79 insertions(+), 60 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 35fc73c..2538283 100644
--- a/kvm-all.c
+++ b/kvm-al
From: Jan Kiszka
For unknown reasons, xcr0 reset ended up in kvm_arch_update_guest_debug
on upstream merge. Fix this and also remove the misleading comment (1 is
THE reset value).
Signed-off-by: Jan Kiszka
---
target-i386/kvm.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff
From: Jan Kiszka
No longer used.
Signed-off-by: Jan Kiszka
---
kvm-all.c |4 ++--
kvm-stub.c |2 +-
kvm.h |4 ++--
target-i386/kvm.c |2 +-
target-ppc/kvm.c |2 +-
target-s390x/kvm.c |2 +-
vl.c |2 +-
7 files changed,
From: Jan Kiszka
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device with the sysbus. Its main purpose is to save and restore
the kernel state on migration, but this will also allow to visualize it
one day.
Signed-off-by: Jan Kiszka
CC: Glauber Costa
---
targ
From: Jan Kiszka
This code path will not yet be taken as we still lack in-kernel irqchip
support. But qemu-kvm can already make use of it and drop its own
mp_state access services.
Signed-off-by: Jan Kiszka
---
target-i386/kvm.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
dif
From: Jan Kiszka
First of all, we only need this EPT identity and TSS reservation on
Intel CPUs. Then, in order to support loading BIOSes > 256K, reorder the
code, adjusting the base if the kernel supports moving the identity map.
We can drop the check for KVM_CAP_SET_TSS_ADDR as we already depen
All previously sent patches against current uq combined, some smaller
tweaks applied, and 4 new patches added. Major news is support for
using up to 16M BIOSes and optional code dump for cpu_dump_state. Those
features are already present qemu-kvm but were reworked to provide
cleaner upstream versio
From: Jan Kiszka
It is not used, it is not needed, so let's remove it.
Signed-off-by: Jan Kiszka
---
kvm-all.c |6 ++
kvm-stub.c |4 ++--
kvm.h |2 +-
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 2538283..7518f2c 100644
--- a/
From: Jan Kiszka
Make sure to clear MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK, and
MSR_KVM_ASYNC_PF_EN so that a freshly booted guest cannot be disturbed
by old values.
Signed-off-by: Jan Kiszka
CC: Glauber Costa
---
target-i386/kvm.c | 10 ++
1 files changed, 10 insertions(+), 0 dele
From: Jan Kiszka
QEMU supports only one VM, so there is only one kvm_state per process,
and we gain nothing passing a reference to it around. Eliminate any need
to refer to it outside of kvm-all.c.
Signed-off-by: Jan Kiszka
CC: Alexander Graf
---
cpu-defs.h|2 -
kvm-all.c
From: Jan Kiszka
Simplify kvm_has_msr_star/hsave_pa to booleans and push their one-time
initialization into kvm_arch_init. Also handle potential errors of that
setup procedure.
Signed-off-by: Jan Kiszka
---
target-i386/kvm.c | 47 +++
1 files chang
From: Jan Kiszka
The ordering doesn't matter in this case, but better keep it consistent.
Signed-off-by: Jan Kiszka
---
target-i386/kvm.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index d4f253e..684430f 100644
--- a/targ
From: Jan Kiszka
COALESCED_MMIO, SYNC_MMU, EXT_CPUID, CLOCKSOURCE, NOP_IO_DELAY, PV_MMU -
all these caps predate features on which we already depend at build
time. Moreover, the check for KVM_CAP_EXT_CPUID is unneeded as we
already test & fail is a more recent feature is missing.
Signed-off-by:
From: Jan Kiszka
Report KVM_EXIT_UNKNOWN, KVM_EXIT_FAIL_ENTRY, and KVM_EXIT_EXCEPTION
with more details to stderr. The latter two are so far x86-only, so move
them into the arch-specific handler. Integrate the Intel real mode
warning on KVM_EXIT_FAIL_ENTRY that qemu-kvm carries, but actually
rest
From: Jan Kiszka
There is no need to restrict writing back MCE MSRs to reset or full
state updates as setting their values has no side effects.
Signed-off-by: Jan Kiszka
CC: Huang Ying
---
target-i386/kvm.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/ta
From: Jan Kiszka
Ensure that we stop the guest whenever we face a fatal or unknown exit
reason. If we stop, we also have to enforce a cpu loop exit.
Signed-off-by: Jan Kiszka
---
kvm-all.c | 15 +++
target-i386/kvm.c |4
target-ppc/kvm.c |4
3 files cha
Hi,
at least in kvm mode, the qemu_fair_mutex seems to have lost its
function of balancing qemu_global_mutex access between the io-thread and
vcpus. It's now only taken by the latter, isn't it?
This and the fact that qemu-kvm does not use this kind of lock made me
wonder what its role is and if i
Building vgabios from source as described above added the missing modes
for me too. But still the vga driver does not work properly - it builds
the screen very slowly line by line and takes 20 seconds or more just
for the login-screen.
After some hours I gave up on vga and switched to the vmware-
On 01/03/2011 11:46 AM, Jan Kiszka wrote:
Hi,
at least in kvm mode, the qemu_fair_mutex seems to have lost its
function of balancing qemu_global_mutex access between the io-thread and
vcpus. It's now only taken by the latter, isn't it?
This and the fact that qemu-kvm does not use this kind of l
Am 03.01.2011 11:01, Avi Kivity wrote:
> On 01/03/2011 11:46 AM, Jan Kiszka wrote:
>> Hi,
>>
>> at least in kvm mode, the qemu_fair_mutex seems to have lost its
>> function of balancing qemu_global_mutex access between the io-thread and
>> vcpus. It's now only taken by the latter, isn't it?
>>
>> T
On 01/03/2011 12:03 PM, Jan Kiszka wrote:
Am 03.01.2011 11:01, Avi Kivity wrote:
> On 01/03/2011 11:46 AM, Jan Kiszka wrote:
>> Hi,
>>
>> at least in kvm mode, the qemu_fair_mutex seems to have lost its
>> function of balancing qemu_global_mutex access between the io-thread and
>> vcpus. It'
Hi!
I have been playing a little with this: I'm writing a kernel for both x86 and
x86-64. While doing so, i'd like to debug the kernel using qemu (and it's gdb
stub) and gdb. This worked very well until qemu-0.11.1 (gdb version does not
seem to play any role...). From there on, debugging the 64
On 12/17/10 20:44, Alon Levy wrote:
This patchset adds three new devices, usb-ccid, ccid-card-passthru and
ccid-card-emulated, providing a CCID bus, a simple passthru protocol
implementing card requiring a client, and a standalone emulated card.
It also introduces a new directory libcaccard with
On 12/21/10 16:16, Olivier Galibert wrote:
Hi all,
Google sees patches to hw/usb-ehci.c from time to time, in
http://www.mail-archive.com/qemu-devel@nongnu.org/msg37741.html for
instance. Where is that code hiding, since I just can't find it in
the git tree?
I'm busy working on the qemu us
Please send any agenda items you are interested in covering.
thanks, Juan.
On Mon, Jan 03, 2011 at 11:39:01AM +0100, Gerd Hoffmann wrote:
> On 12/17/10 20:44, Alon Levy wrote:
> >This patchset adds three new devices, usb-ccid, ccid-card-passthru and
> >ccid-card-emulated, providing a CCID bus, a simple passthru protocol
> >implementing card requiring a client, and a stand
On 03.01.2011, at 09:33, Jan Kiszka wrote:
> From: Jan Kiszka
>
> QEMU supports only one VM, so there is only one kvm_state per process,
> and we gain nothing passing a reference to it around. Eliminate any need
> to refer to it outside of kvm-all.c.
Slightly unqemu'ish, but I like the simplic
Am 03.01.2011 11:27, Markus Duft wrote:
> Hi!
>
> I have been playing a little with this: I'm writing a kernel for both x86 and
> x86-64. While doing so, i'd like to debug the kernel using qemu (and it's gdb
> stub) and gdb. This worked very well until qemu-0.11.1 (gdb version does not
> seem t
Hi again,
another subtle difference between qemu-kvm and upstream:
When we leave the guest for an IO window (KVM_RUN returns EINTR or
EAGAIN), we call kvm_flush_coalesced_mmio_buffer in qemu-kvm but not in
upstream. When version is better? I can't find any rationales in both
git logs.
Jan
sig
On 01/03/2011 12:15 PM, Jan Kiszka wrote:
[snip]
>>
>> 1) is this a problem with qemu or was qemu "fixed" and gdb has a problem?
>>(that's why i CCd the gdb list ;)).
>> 2) is there any plan to fix this issue?
>> 3) is there some kind of workaround i can use (i'd be happy with an
>> ugly/unsup
On Mon, Jan 03, 2011 at 01:11:32PM +0100, Jan Kiszka wrote:
> Hi again,
>
> another subtle difference between qemu-kvm and upstream:
>
> When we leave the guest for an IO window (KVM_RUN returns EINTR or
> EAGAIN), we call kvm_flush_coalesced_mmio_buffer in qemu-kvm but not in
> upstream. When ve
On 01/03/2011 01:15 PM, Markus Duft wrote:
> On 01/03/2011 12:15 PM, Jan Kiszka wrote:
> [snip]
[snip]
> actually, i find that Ted Harkington was right: in 0.11.1 i can debug 32 bit
> code with qemu-system-x86_64 well enough (which means i debugged all the 32
> bit part of my kernel without ever
On 01/03/2011 02:11 PM, Jan Kiszka wrote:
Hi again,
another subtle difference between qemu-kvm and upstream:
When we leave the guest for an IO window (KVM_RUN returns EINTR or
EAGAIN), we call kvm_flush_coalesced_mmio_buffer in qemu-kvm but not in
upstream. When version is better? I can't find
Am 03.01.2011 13:32, Avi Kivity wrote:
> On 01/03/2011 02:11 PM, Jan Kiszka wrote:
>> Hi again,
>>
>> another subtle difference between qemu-kvm and upstream:
>>
>> When we leave the guest for an IO window (KVM_RUN returns EINTR or
>> EAGAIN), we call kvm_flush_coalesced_mmio_buffer in qemu-kvm but
From: Jan Kiszka
We must flush pending mmio writes if we leave kvm_cpu_exec for an IO
window. Otherwise we risk to loose those requests when migrating to a
different host during that window.
Signed-off-by: Jan Kiszka
---
kvm-all.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
The patch is in 0.13.0, so changing the status.
** Changed in: qemu
Status: Invalid => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/524447
Title:
virsh save is very slow
Stat
[ please keep CCs ]
Am 03.01.2011 13:27, Markus Duft wrote:
> On 01/03/2011 01:15 PM, Markus Duft wrote:
>> On 01/03/2011 12:15 PM, Jan Kiszka wrote:
>> [snip]
> [snip]
>> actually, i find that Ted Harkington was right: in 0.11.1 i can debug 32 bit
>> code with qemu-system-x86_64 well enough (whi
On 01/03/2011 02:00 PM, Jan Kiszka wrote:
> [ please keep CCs ]
>
> Am 03.01.2011 13:27, Markus Duft wrote:
>> On 01/03/2011 01:15 PM, Markus Duft wrote:
>>> On 01/03/2011 12:15 PM, Jan Kiszka wrote:
>>> [snip]
>> [snip]
>>> actually, i find that Ted Harkington was right: in 0.11.1 i can debug 32
From: Jan Kiszka
Introduce the cpu_dump_state flag CPU_DUMP_CODE and implement it for
x86. This writes out the code bytes around the current instruction
pointer. Make use of this feature in KVM to help debugging fatal vm
exits.
Signed-off-by: Jan Kiszka
---
Argh, the broken qemu-user build led
How should I interpret "Fix Released"?
qemu in maverick is still 0.12.5 and 0.12.3 in lucid.
Will this not be fixed in current stable LTS and non-LTS releases?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.n
is this issue dead ?? can i do something for help to fix it?
regards, daniel
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/638955
Title:
emulated netcards don't work with recent sunos kernel
Stat
On Mon, 20 Dec 2010 14:09:05 +0800
Lai Jiangshan wrote:
> On 12/17/2010 11:25 PM, Avi Kivity wrote:
> > On 12/17/2010 01:22 PM, Luiz Capitulino wrote:
> >> >
> >> > I think Avi's suggest is better, and I will use
> >> > "inject-nmi" (without cpu-index argument) to send NMI to all cpus,
> >> >
On Mon, 20 Dec 2010 18:00:34 +0100
Markus Armbruster wrote:
> Lai Jiangshan writes:
>
> > "cpu-index" is better name.
> >
> > Signed-off-by: Lai Jiangshan
> > ---
> > diff --git a/hmp-commands.hx b/hmp-commands.hx
> > index 4befbe2..8de7aa3 100644
> > --- a/hmp-commands.hx
> > +++ b/hmp-comma
03.01.2011 16:23, EsbenHaabendal wrote:
> How should I interpret "Fix Released"?
>
> qemu in maverick is still 0.12.5 and 0.12.3 in lucid.
Not all the world is ubuntu. In qemu (and qemu-kvm) the
issue is fixed in 0.13, which were released quite some
time ago.
> Will this not be fixed in current
On 01/03/11 12:00, Alon Levy wrote:
On Mon, Jan 03, 2011 at 11:39:01AM +0100, Gerd Hoffmann wrote:
Patch series looks good to me now. Doesn't apply cleanly to master
though (conflicts in configure), so it needs a rebase I guess. Also
a git tree to pull from would be nice.
rebased, pull from:
Signed-off-by: Fabien Chouteau
---
target-sparc/cpu.h |1 +
target-sparc/helper.c|3 ++-
target-sparc/translate.c | 10 ++
3 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/target-sparc/cpu.h b/target-sparc/cpu.h
index 7795be4..fe082e3 100644
--- a/targe
Signed-off-by: Fabien Chouteau
---
hw/grlib_apbuart.c | 208
1 files changed, 208 insertions(+), 0 deletions(-)
diff --git a/hw/grlib_apbuart.c b/hw/grlib_apbuart.c
new file mode 100644
index 000..a2ff8ed
--- /dev/null
+++ b/hw/grlib_apb
Hi everyone,
New version of the Leon3 emulation. Many modifications since v1, mostly to
follow the Qemu architecture and to implement features in a more generic way.
Again, please feel free to comment.
Regards,
Thi
Signed-off-by: Fabien Chouteau
---
hw/grlib_gptimer.c | 427
1 files changed, 427 insertions(+), 0 deletions(-)
diff --git a/hw/grlib_gptimer.c b/hw/grlib_gptimer.c
new file mode 100644
index 000..e33d506
--- /dev/null
+++ b/hw/grlib_gpt
Signed-off-by: Fabien Chouteau
---
Makefile.target |5 +-
hw/leon3.c | 202 ++
target-sparc/cpu.h | 39 ++---
target-sparc/helper.c|7 +-
target-sparc/helper.h|1 +
target-sparc/op_helper.c | 151
On Mon, Jan 03, 2011 at 02:53:02PM +0100, Gerd Hoffmann wrote:
> On 01/03/11 12:00, Alon Levy wrote:
> >On Mon, Jan 03, 2011 at 11:39:01AM +0100, Gerd Hoffmann wrote:
> >>Patch series looks good to me now. Doesn't apply cleanly to master
> >>though (conflicts in configure), so it needs a rebase I
Signed-off-by: Fabien Chouteau
---
hw/grlib_irqmp.c | 402 ++
1 files changed, 402 insertions(+), 0 deletions(-)
diff --git a/hw/grlib_irqmp.c b/hw/grlib_irqmp.c
new file mode 100644
index 000..9f947d1
--- /dev/null
+++ b/hw/grlib_irqmp.c
Signed-off-by: Fabien Chouteau
---
hw/grlib.h | 121
1 files changed, 121 insertions(+), 0 deletions(-)
diff --git a/hw/grlib.h b/hw/grlib.h
new file mode 100644
index 000..bb3c01e
--- /dev/null
+++ b/hw/grlib.h
@@ -0,0 +1,121 @@
Michael Tokarev writes:
> 03.01.2011 16:23, EsbenHaabendal wrote:
>> How should I interpret "Fix Released"?
>>
>> qemu in maverick is still 0.12.5 and 0.12.3 in lucid.
>
> Not all the world is ubuntu. In qemu (and qemu-kvm) the
> issue is fixed in 0.13, which were released quite some
> time ago
This patch series start by a cleanup to remove dead HPPA code, and then
implement correct NaN propagation rules for MIPS and PowerPC, following
commit 354f211b1a49a7387929e22d6e63849fcba48f8a.
We don't have any HPPA target, so let's remove HPPA specific code. It
can be re-added when someone adds an HPPA target.
Signed-off-by: Aurelien Jarno
---
fpu/softfloat-specialize.h |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/fpu/softfloat-specialize.h b/fpu/soft
On targets that define sNaN with the sNaN bit as one, simply clearing
this bit may correspond to an infinite value.
Convert it to a default NaN if SNAN_BIT_IS_ONE, as it corresponds to
the MIPS implementation, the only emulated CPU with SNAN_BIT_IS_ONE.
When other CPU of this type are added, this
Use float{32,64,x80,128}_maybe_silence_nan() instead of toggling the
sNaN bit manually. This allow per target implementation of sNaN to qNaN
conversion.
Signed-off-by: Aurelien Jarno
---
fpu/softfloat-specialize.h | 55 +--
1 files changed, 17 insertions
Add float{x80,128}_maybe_silence_nan() functions, they will be need by
propagateFloat{x80,128}NaN().
Signed-off-by: Aurelien Jarno
---
fpu/softfloat-specialize.h | 38 ++
fpu/softfloat.h|2 ++
2 files changed, 40 insertions(+), 0 deletions(-)
Implement the correct NaN propagation rules for MIPS targets by
providing an appropriate pickNaN function.
Signed-off-by: Aurelien Jarno
---
fpu/softfloat-specialize.h | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/fpu/softfloat-specialize.h b
Implement the correct NaN propagation rules for ARM targets by
providing an appropriate pickNaN function.
Also fix the #ifdef tests for default NaN definition, the correct name
is TARGET_PPC instead of TARGET_POWERPC.
Cc: Alexander Graf
Signed-off-by: Aurelien Jarno
---
fpu/softfloat-specializ
This patch adds functions to register and unregister notifiers for
migration state changes and a function to query the migration state.
The notifier is called on every state change. Once after establishing a
new migration object (which is in active state then) and once when the
state changes from
Signed-off-by: Gerd Hoffmann
---
MAINTAINERS |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 59effc7..25103dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -383,6 +383,14 @@ S: Odd Fixes
F: gdbstub*
F: gdb-xml/
+SPICE
+M: Gerd H
Hi,
This patch series adds spice client migration support to qemu, i.e.
allow the spice client to reconnect automatically to the new host after
vm migration.
It also adds a notifier for migration state changes because spice needs
to know when the migration completed and whenever it was successf
Handle spice client migration, i.e. inform a spice client connected
about the new host and connection parameters, so it can move over the
connection automatically.
Signed-off-by: Gerd Hoffmann
---
hmp-commands.hx | 20
qmp-commands.hx | 35 +++
I code, therefore I am
--- On Wed, 11/10/10, agraf <670...@bugs.launchpad.net> wrote:
> From: agraf <670...@bugs.launchpad.net>
> Subject: Re: [Qemu-devel] [Bug 670769] Re: CDROM size not updated when
> changing image files
> To: alex14...@yahoo.com
> Date: Wednesday, November 10, 2010, 8:11 A
On 3 January 2011 14:34, Aurelien Jarno wrote:
> On targets that define sNaN with the sNaN bit as one, simply clearing
> this bit may correspond to an infinite value.
>
> Convert it to a default NaN if SNAN_BIT_IS_ONE, as it corresponds to
> the MIPS implementation, the only emulated CPU with SNAN
Public bug reported:
I recognize that NetBSD is not one of the officially supported host OS.
However, qemu 0.13.0 is available in the NetBSD pkgsrc collection, and
works quite well. Well, with one exception (pun intended): It seems
that Floating Point exceptions don't get reported properly.
The
On 3 January 2011 14:34, Aurelien Jarno wrote:
> We don't have any HPPA target, so let's remove HPPA specific code. It
> can be re-added when someone adds an HPPA target.
>
> Signed-off-by: Aurelien Jarno
Reviewed-by: Peter Maydell
Do we want to get rid of the one remaining TARGET_HPPA which
i
Peter Maydell a écrit :
> On 3 January 2011 14:34, Aurelien Jarno wrote:
>> On targets that define sNaN with the sNaN bit as one, simply clearing
>> this bit may correspond to an infinite value.
>>
>> Convert it to a default NaN if SNAN_BIT_IS_ONE, as it corresponds to
>> the MIPS implementation,
Peter Maydell a écrit :
> On 3 January 2011 14:34, Aurelien Jarno wrote:
>> We don't have any HPPA target, so let's remove HPPA specific code. It
>> can be re-added when someone adds an HPPA target.
>>
>> Signed-off-by: Aurelien Jarno
>
> Reviewed-by: Peter Maydell
>
> Do we want to get rid of
On Mon, Jan 3, 2011 at 12:14 PM, Paul Goyette <696...@bugs.launchpad.net>wrote:
> Public bug reported:
>
> I recognize that NetBSD is not one of the officially supported host OS.
> However, qemu 0.13.0 is available in the NetBSD pkgsrc collection, and
> works quite well. Well, with one exception
Hi!
Another question: Shouldn't the APIC version be 0x14 for CPUs since P4/Xeon? At
least according to the Intel docs, since then the xAPIC is used, which has 0x14
as version (see intel manuals, vol 3a "10.4.8 Local APIC Version Register".
reading the APIC version register yields 0x11 for all C
On 3 January 2011 14:34, Aurelien Jarno wrote:
> Add float{x80,128}_maybe_silence_nan() functions, they will be need by
> propagateFloat{x80,128}NaN().
>
> Signed-off-by: Aurelien Jarno
Reviewed-by: Peter Maydell
-- PMM
On Mon, 3 Jan 2011, Paulo Cezar A Junior wrote:
>>printf("FPE signal handler invoked %d times.\n");
>
> this printf() does miss an argument :-)
Yes, it does. The signal handler is also missing a line:
siglongjmp(sigfpe_flt_env, 1);
That's what I get for extracting bits&pieces
On 01/03/2011 10:33 AM, Jan Kiszka wrote:
From: Jan Kiszka
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device with the sysbus. Its main purpose is to save and restore
the kernel state on migration, but this will also allow to visualize it
one day.
kvmclock i
This patchset adds three new devices, usb-ccid, ccid-card-passthru and
ccid-card-emulated, providing a CCID bus, a simple passthru protocol
implementing card requiring a client, and a standalone emulated card.
It also introduces a new directory libcaccard with CAC card emulation,
CAC is a type of
The passthru ccid card is a device sitting on the usb-ccid bus and
using a chardevice to communicate with a remote device using the
VSCard protocol defined in libcacard/vscard_common.h
Usage docs available in following patch in docs/ccid.txt
Signed-off-by: Alon Levy
---
Makefile.objs
On 01/03/2011 10:33 AM, Jan Kiszka wrote:
From: Jan Kiszka
COALESCED_MMIO, SYNC_MMU, EXT_CPUID, CLOCKSOURCE, NOP_IO_DELAY, PV_MMU -
all these caps predate features on which we already depend at build
time. Moreover, the check for KVM_CAP_EXT_CPUID is unneeded as we
already test& fail is a more
Add documentation for the usb-ccid device and accompanying two card
devices, ccid-card-emulated and ccid-card-passthru.
---
docs/ccid.txt | 135 +
1 files changed, 135 insertions(+), 0 deletions(-)
create mode 100644 docs/ccid.txt
diff --g
This devices uses libcacard (internal) to emulate a smartcard conforming
to the CAC standard. It attaches to the usb-ccid bus. Usage instructions
(example command lines) are in the following patch in docs/ccid.txt. It
uses libcacard which uses nss, so it can work with both hw cards and
certificates
On 01/03/2011 10:32 AM, Jan Kiszka wrote:
All previously sent patches against current uq combined, some smaller
tweaks applied, and 4 new patches added. Major news is support for
using up to 16M BIOSes and optional code dump for cpu_dump_state. Those
features are already present qemu-kvm but were
On 01/03/2011 10:33 AM, Jan Kiszka wrote:
From: Jan Kiszka
First of all, we only need this EPT identity and TSS reservation on
Intel CPUs.
kvm-amd will ignore it just fine. I'd like to keep arch differences
away from userspace.
Then, in order to support loading BIOSes> 256K, reorder the
This patchset fixes errors in the decoding and implementation of the
immediate forms of the VQSHL/VQSHLU ARM instructions.
Tested in the usual random-instruction-set way. This is the final part
of the maemo-qemu tree commit 03a2445a fixes (the first part being
the already-committed VQSHL-reg patchs
On Mon, 3 Jan 2011, Paul Goyette wrote:
> The following is a complete, standalone test program:
>
> #include
> #include
> #include
> #include
>
>volatile int flt_signal = 0;
>
> static sigjmp_buf sigfpe_flt_env;
> static void
> sigfpe_flt_actio
Add neon helper functions to implement VQSHLU, which is a
signed-to-unsigned version of VQSHL available only as an
immediate form.
Signed-off-by: Juha Riihimäki
Reviewed-by: Peter Maydell
---
target-arm/helpers.h |4 +++
target-arm/neon_helper.c | 47 ++
From: Juha Riihimäki
Fix errors in the decoding of ARM VQSHL/VQSHLU immediate forms,
including using the new VQSHLU helper functions where appropriate.
Signed-off-by: Peter Maydell
---
target-arm/translate.c | 51 +--
1 files changed, 36 insertions
Am 03.01.2011 17:04, Avi Kivity wrote:
> On 01/03/2011 10:33 AM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> If kvmclock is used, which implies the kernel supports it, register a
>> kvmclock device with the sysbus. Its main purpose is to save and restore
>> the kernel state on migration, but this w
On Mon, 2011-01-03 at 18:04 +0200, Avi Kivity wrote:
> On 01/03/2011 10:33 AM, Jan Kiszka wrote:
> > From: Jan Kiszka
> >
> > If kvmclock is used, which implies the kernel supports it, register a
> > kvmclock device with the sysbus. Its main purpose is to save and restore
> > the kernel state on mi
On Mon, 2011-01-03 at 09:33 +0100, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Make sure to clear MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK, and
> MSR_KVM_ASYNC_PF_EN so that a freshly booted guest cannot be disturbed
> by old values.
>
> Signed-off-by: Jan Kiszka
> CC: Glauber Costa
> ---
> targe
On Mon, 2011-01-03 at 09:33 +0100, Jan Kiszka wrote:
> From: Jan Kiszka
>
> If kvmclock is used, which implies the kernel supports it, register a
> kvmclock device with the sysbus. Its main purpose is to save and restore
> the kernel state on migration, but this will also allow to visualize it
>
Am 03.01.2011 17:40, Glauber Costa wrote:
> On Mon, 2011-01-03 at 09:33 +0100, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> Make sure to clear MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK, and
>> MSR_KVM_ASYNC_PF_EN so that a freshly booted guest cannot be disturbed
>> by old values.
>>
>> Signed-off-by
Am 03.01.2011 17:37, Glauber Costa wrote:
> On Mon, 2011-01-03 at 09:33 +0100, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> If kvmclock is used, which implies the kernel supports it, register a
>> kvmclock device with the sysbus. Its main purpose is to save and restore
>> the kernel state on migrat
Am 03.01.2011 17:06, Avi Kivity wrote:
> On 01/03/2011 10:33 AM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> First of all, we only need this EPT identity and TSS reservation on
>> Intel CPUs.
>
> kvm-amd will ignore it just fine. I'd like to keep arch differences
> away from userspace.
And I wou
On 01/03/2011 06:52 PM, Jan Kiszka wrote:
Am 03.01.2011 17:06, Avi Kivity wrote:
> On 01/03/2011 10:33 AM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> First of all, we only need this EPT identity and TSS reservation on
>> Intel CPUs.
>
> kvm-amd will ignore it just fine. I'd like to keep ar
On ARM, the FPSCR FZ bit (which controls whether denormals should be
flushed to zero) is supposed to cause this flushing to occur both
when the output of a calculation is a denormal (already implemented in
softfloat) and also when the input to a calculation is a denormal
(not implemented, as noted
On 3 January 2011 16:20, Peter Maydell wrote:
> This patchset fixes errors in the decoding and implementation of the
> immediate forms of the VQSHL/VQSHLU ARM instructions.
> Tested in the usual random-instruction-set way. This is the final part
> of the maemo-qemu tree commit 03a2445a fixes (the
On 01/03/2011 06:54 PM, Jan Kiszka wrote:
Am 03.01.2011 17:08, Avi Kivity wrote:
> On 01/03/2011 10:33 AM, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> COALESCED_MMIO, SYNC_MMU, EXT_CPUID, CLOCKSOURCE, NOP_IO_DELAY, PV_MMU -
>> all these caps predate features on which we already depend at buil
1 - 100 of 137 matches
Mail list logo
