Blue Swirl wrote:
The translation block (TB) refers to a block of host instructions,
translated from some block of target instructions under some
assumptions. The assumptions used when translating (for example, user
vs supervisor mode in the CPU state) are recorded to TB flags. If the
CPU state c
While most of the ARMv5 instructions are backward compatible with ARMv4, there
are few important differences. Most notably the stack pop and load instructions
ignore the lowest bit, which is used by ARMv5 to switch to Thumb mode. A
base-updated data-abort model is used on ARM7TDMI, CP15 coprocessor
* Jan Kiszka [2009-12-01 17:44]:
> Seeking on vmstate save/load does not work if the underlying file is a
> stream. We could try to make all QEMUFile* forward-seek-aware, but first
> attempts in this direction indicated that it's saner to convert the few
> qemu_fseek-on-vmstates users to plain rea
Seeking on vmstate save/load does not work if the underlying file is a
stream. We could try to make all QEMUFile* forward-seek-aware, but first
attempts in this direction indicated that it's saner to convert the few
qemu_fseek-on-vmstates users to plain reads/writes.
This fixes various subtle vmst
On Wed, 2 Dec 2009, Alexander Graf wrote:
>
> On 01.12.2009, at 19:33, Dima Ilyevsky wrote:
>
> > Hello All,
> >
> > I have a question about read permissions of TBL SPR for all ppc processors:
> > I have discovered that my application, compiled by WindRiver diab compiler
> > and running in vxw
On 01.12.2009, at 19:33, Dima Ilyevsky wrote:
> Hello All,
>
> I have a question about read permissions of TBL SPR for all ppc processors:
> I have discovered that my application, compiled by WindRiver diab compiler
> and running in vxworks OS on ppc405 architecture bumps into exception
> gene
On 01.12.2009, at 19:51, Anthony Liguori wrote:
> Alexander Graf wrote:
>> 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 kvm/vnc
Blue Swirl wrote:
Of course, my main unclear subsystems are PPC and S390.
I'd recommend the following committers:
PPC: Blue Swirl
S390: Aurelien
If you have other subsystems you feel uncertain on responsibilities,
please add them to the list incl. committer recommendation.
PPC is tough
This iteration addresses all of the comments from the last round. Thanks to
everyone for their careful reviews and helpful comments. The most significant
change in this version is my use of the QObject API, so a concentrated review
in that area would be most appreciated. I am hoping to target 0.
From: qemu-devel-bounces+chris.krumme=windriver@nongnu.org
[mailto:qemu-devel-bounces+chris.krumme=windriver@nongnu.org] On
Behalf Of Dima Ilyevsky
Sent: Tuesday, December 01, 2009 12:33 PM
To: qemu-devel@nongnu.org
Subject:
Jan Kiszka wrote:
> Signed-off-by: Jan Kiszka
> ---
>
> This may partly or fully explain the e1000 issue Pierre reported first.
> However, there are more bugs in the current migration code, e.g. in
> qemu_fseek when used with streams, it still doesn't work properly here.
> Need a break...
You ar
On Tue, Dec 1, 2009 at 6:51 PM, Anthony Liguori wrote:
> Alexander Graf wrote:
>>
>> 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. Fo
Signed-off-by: Jan Kiszka
---
This may partly or fully explain the e1000 issue Pierre reported first.
However, there are more bugs in the current migration code, e.g. in
qemu_fseek when used with streams, it still doesn't work properly here.
Need a break...
hw/hw.h |2 +-
1 files changed, 1
Krumme, Chris wrote:
Hello Ian,
Since you did not inline your source I will paste in a chunk:
@@ -2030,10 +2036,18 @@ static void tcp_chr_read(void *opaque)
if (s->listen_fd >= 0) {
qemu_set_fd_handler(s->listen_fd, tcp_chr_accept, NULL,
chr);
}
-qemu_set
Alexander Graf wrote:
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 kvm/vnc/block I just CC
Anthony, for Audio I just CC malc, etc.
There
2009/12/1 Carsten Otte :
> Alexander Graf wrote:
>>>
>>> I don't know what psw.mask represent, but it may be wrong. It should be
>>> a way to identify which TB can be reused, that is they have been
>>> generated in the same CPU mode.
>>
>> psw.mask is rougly the same as RFLAGS, cr0 and cr4 on x86_6
Hello All,
I have a question about read permissions of TBL SPR for all ppc processors:
I have discovered that my application, compiled by WindRiver diab compiler
and running in vxworks OS on ppc405 architecture bumps into exception
generated when trying to read TBL or TBU registers:
program
Exce
Krumme, Chris wrote:
> Hello Ian,
Hi!
> Should you be introducing a while sleep loop into Qemu here?
>
> I would think you should be returning 'no data', maybe after trying
> once.
Indeed.
I could have sworn I tried that. Too much crack, will re-do.
Pierre Riteau wrote:
> On 1 déc. 2009, at 15:20, Jan Kiszka wrote:
>
>> Inject progress report in percentage into the block live stream. This
>> can be read out and displayed easily on restore.
>
>
> I guess that this patch only reports percentage for the initial bulk copy of
> the image.
> I h
>
> On S390X:
>
> /suse/agraf/work/kvm-s390/qemu.works/kvm-all.c: In function ‘kvm_set_irq’:
> /suse/agraf/work/kvm-s390/qemu.works/kvm-all.c:425: error:
> ‘KVM_IRQ_LINE_STATUS’ undeclared (first use in this function)
> /suse/agraf/work/kvm-s390/qemu.works/kvm-all.c:425: error: (Each
> undeclared
On 1 déc. 2009, at 15:20, Jan Kiszka wrote:
> Inject progress report in percentage into the block live stream. This
> can be read out and displayed easily on restore.
I guess that this patch only reports percentage for the initial bulk copy of
the image.
I haven't tested this scenario, but the
Glauber Costa wrote:
> This patch provides the file i8259-kvm.c, which implements a schim over
> the kvm in-kernel PIC.
>
> Signed-off-by: Glauber Costa
> ---
> Makefile.target |2 +-
> hw/i8259-kvm.c | 112
> +++
> hw/pc.c |8
Glauber Costa wrote:
> This patch provides the file apic-kvm.c, which implements a schim over
> the kvm in-kernel APIC.
>
> Signed-off-by: Glauber Costa
> ---
> Makefile.target |2 +-
> hw/apic-kvm.c | 157
> +
> hw/pc.c |
Here is a collection of minor pci related fixes and cleanupsthat has
accumulated in my tree. I think some of these make sense for 0.11 as
well, I will follow up separately.
The following changes since commit 3098b9fde97a224e803048c83bebeea176966358:
Aurelien Jarno (1):
Revert "vga: do n
Kevin Wolf wrote:
> We're leaking file descriptors to child processes. Set FD_CLOEXEC on file
> descriptors that don't need to be passed to children to stop this
> misbehaviour.
>
> Signed-off-by: Kevin Wolf
> ---
> block/raw-posix.c |2 +-
> gdbstub.c |6 +++
> kvm-all.c
Excerpts from Markus Armbruster's message of Mon Nov 30 11:55:34 -0200 2009:
> Commit a7d27b53 made zero-sized allocations a fatal error, deviating
> from ISO C's malloc() & friends. Revert that, but take care never to
> return a null pointer, like malloc() & friends may do (it's
> implementation
On 12/01/09 15:34, Avi Kivity wrote:
On 12/01/2009 02:40 PM, Gerd Hoffmann wrote:
Even more advanced: Make zero_length_malloc page-sized and
page-aligned, then munmap int, so dereferencing it actually traps.
That will cause vma fragmentation.
I was thinking about a single unmapped page, whi
On 12/01/09 15:08, Markus Armbruster wrote:
For what it's worth, it violates the spec for malloc(). For zero-sized
allocations, we may either return a null pointer (but we already decided
we don't want to), or an object different from any other object alive.
Which clearly rules out the fixed m
Hello Ian,
Since you did not inline your source I will paste in a chunk:
@@ -2030,10 +2036,18 @@ static void tcp_chr_read(void *opaque)
if (s->listen_fd >= 0) {
qemu_set_fd_handler(s->listen_fd, tcp_chr_accept, NULL,
chr);
}
-qemu_set_fd_handler(s->fd, NUL
On 12/01/2009 02:40 PM, Gerd Hoffmann wrote:
Even more advanced: Make zero_length_malloc page-sized and
page-aligned, then munmap int, so dereferencing it actually traps.
That will cause vma fragmentation. Since we don't trap malloc(n)[n] for
n > 0, we may as well not trap it for n = 0.
The opts id is always allocated via qemu_strdup, so it need not be
const, but it has to be released on opts deletion.
Signed-off-by: Jan Kiszka
---
qemu-option.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/qemu-option.c b/qemu-option.c
index 49efd39..b009109 10064
On Tuesday 01 December 2009, Glauber Costa wrote:
> On Tue, Dec 01, 2009 at 12:57:27PM +, Paul Brook wrote:
> > > You might want to have a 'static uint8_t zero_length_malloc[0]' and
> > > return that instead of the magic cookie '1'. Makes the code more
> > > readable IMHO and you'll also have
Inject progress report in percentage into the block live stream. This
can be read out and displayed easily on restore.
Signed-off-by: Jan Kiszka
---
Changes in v2:
- Print banner only if there is really some block device to restore
block-migration.c | 30 ++
1 fi
The effect of this patch with current block migration is that its stage
2, ie. the first full walk-through of the block devices will be
performed completely before RAM migration starts. This ensures that
continuously changing RAM pages are not re-synchronized all the time
while block migration is n
Glauber Costa writes:
> On Tue, Dec 01, 2009 at 12:57:27PM +, Paul Brook wrote:
>> > You might want to have a 'static uint8_t zero_length_malloc[0]' and
>> > return that instead of the magic cookie '1'. Makes the code more
>> > readable IMHO and you'll also have symbol in gdb when debugging
On Tue, Dec 01, 2009 at 12:57:27PM +, Paul Brook wrote:
> > You might want to have a 'static uint8_t zero_length_malloc[0]' and
> > return that instead of the magic cookie '1'. Makes the code more
> > readable IMHO and you'll also have symbol in gdb when debugging qemu.
>
> Having multiple ma
Juan Quintela wrote:
> Jan Kiszka wrote:
>> Juan Quintela wrote:
>>> Pierre Riteau wrote:
e482dc3eaac43f88beea133843ae38c661262e97 breaks migration of a VM using an
e1000 device (which is the default...).
Origin host is Debian Lenny 32-bits, destination host is Fedora 12 32-bit.
Gerd Hoffmann writes:
>> diff --git a/qemu-malloc.c b/qemu-malloc.c
>> index 295d185..aeeb78b 100644
>> --- a/qemu-malloc.c
>> +++ b/qemu-malloc.c
>> @@ -44,22 +44,12 @@ void qemu_free(void *ptr)
>>
>> void *qemu_malloc(size_t size)
>> {
>> -if (!size) {
>> -abort();
>> -}
>>
> You might want to have a 'static uint8_t zero_length_malloc[0]' and
> return that instead of the magic cookie '1'. Makes the code more
> readable IMHO and you'll also have symbol in gdb when debugging qemu.
Having multiple malloc return the same pointer sounds like a really bad idea.
Paul
On 12/01/09 13:40, Gerd Hoffmann wrote:
+ return oom_check(malloc(size ? size : 1));
void *qemu_realloc(void *ptr, size_t size)
{
+ return oom_check(realloc(ptr, size ? size : 1));
qemu_realloc(qemu_malloc(0), 42);
should better work correctly ...
Oops, scratch that.
"return malloc(size
On Tue, 1 Dec 2009 11:38:52 +
"Daniel P. Berrange" wrote:
> On Thu, Nov 26, 2009 at 10:58:50PM -0200, Luiz Capitulino wrote:
> > Hi,
> >
> > This series has a number of improvements over v0 and is a serious
> > candidate for inclusion.
> >
> > Something I'd like to make clear is that QMP
It is much faster than pthread_{g,s}et_specific.
Signed-off-by: Glauber Costa
---
configure | 17 +
vl.c | 16
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/configure b/configure
index dca5a43..ce7bcc4 100755
--- a/configure
+++ b/confi
We don't support smp without irqchip in kernel, so only abort in
that situation
Signed-off-by: Glauber Costa
---
kvm-all.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 286d0ee..db5daf6 100644
--- a/kvm-all.c
+++ b/kvm-all.c
All reset functions are called from the same place, and this was a leftover
Signed-off-by: Glauber Costa
---
kvm-all.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 318a4e6..ecd1102 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -204,8 +204,6 @@
The proposal in this patch is to add a system_reset caller that only
resets state related to the cpu. This will guarantee that does functions
are called from the cpu-threads, not the I/O thread.
In principle, it might seem close to the remote execution mechanism, but:
* It does not involve any ex
Before signalling a cpu, we have to set exit_request = 1, otherwise
it may go back to executing itself. So every cpu wakeup becomes
at least two statements. The qemu_cpu_kick already provides semantics
to that. So use it all over.
Signed-off-by: Glauber Costa
---
vl.c |6 +++---
1 files chan
This have already been identified in qemu-kvm. We have to synchronously
tell the kernel about the APIC state. Otherwise, other cpus can see
bogus state for this lapic.
Signed-off-by: Glauber Costa
---
hw/apic-kvm.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/hw/apic
This fix a bug with -smp in kvm. Since we have updated apic_base,
we also have to tell kernel about it. So instead of just updating
mp_state, update every regs.
It is mandatory that this happens synchronously, without waiting for
the next vcpu run. Otherwise, if we are migrating, or initializing
t
This function is similar to qemu-kvm's on_vcpu mechanism. Totally synchronous,
and guarantees that a given function will be executed at the specified vcpu.
This patch also convert usage within the breakpoints system
Signed-off-by: Glauber Costa
---
cpu-all.h |3 ++
cpu-defs.h | 14 ++
If we are using in-kernel irqchip, halted state belongs in the kernel.
So everytime we grab kernel's idea of mpstate, we also need to propagate
halted state to userspace.
Signed-off-by: Glauber Costa
---
target-i386/kvm.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git
When we have irqchip in kernel, halted state is kernel
business. So don't initialize it in our code.
Signed-off-by: Glauber Costa
---
hw/apic-kvm.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/hw/apic-kvm.c b/hw/apic-kvm.c
index 089fa45..e5a0bfc 100644
--- a/hw/apic
Since we'll have multiple cpu threads, at least for kvm, we need a way to store
and retrieve the CPUState associated with the current execution thread.
For the I/O thread, this will be NULL.
I am using pthread functions for that, for portability, but we could as well
use __thread keyword.
Signed-
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 io-thread, for the
time
being.
>From the last version, main change is that I am not calling queue_work
>automatically
from vcpu ioctls. queue_work is only u
diff --git a/qemu-malloc.c b/qemu-malloc.c
index 295d185..aeeb78b 100644
--- a/qemu-malloc.c
+++ b/qemu-malloc.c
@@ -44,22 +44,12 @@ void qemu_free(void *ptr)
void *qemu_malloc(size_t size)
{
-if (!size) {
-abort();
-}
-return oom_check(malloc(size));
+return oom_check
Glauber Costa wrote:
> On Tue, Dec 1, 2009 at 10:17 AM, Jan Kiszka wrote:
>> Avi Kivity wrote:
>>> On 11/30/2009 07:30 PM, Jan Kiszka wrote:
>> No. But what's wrong with on_vcpu?
>>
> intrinsically racy. signal passing slow down things, etc.
>
> That said, as I've stated many
On Tue, Dec 1, 2009 at 10:17 AM, Jan Kiszka wrote:
> Avi Kivity wrote:
>> On 11/30/2009 07:30 PM, Jan Kiszka wrote:
> No. But what's wrong with on_vcpu?
>
intrinsically racy. signal passing slow down things, etc.
That said, as I've stated many times: I don't believe there's
Glauber Costa wrote:
> Hi guys,
>
> This is an early version of smp support in kvm that kinda works.
> It has some known problems that I am still tracking. For example,
> it does not reset very well. Also, initialization is a bit slow,
> probably because of the number of remote ioctl calls involved
Avi Kivity wrote:
> On 11/30/2009 07:30 PM, Jan Kiszka wrote:
No. But what's wrong with on_vcpu?
>>> intrinsically racy. signal passing slow down things, etc.
>>>
>>> That said, as I've stated many times: I don't believe there's anything
>>> fundamentally wrong with on_vcpu. But
On 11/30/2009 07:30 PM, Jan Kiszka wrote:
No. But what's wrong with on_vcpu?
intrinsically racy. signal passing slow down things, etc.
That said, as I've stated many times: I don't believe there's anything
fundamentally wrong with on_vcpu. But we might get benefits from a re-design
of
Jamie Lokier wrote:
> I'm a bit puzzled.
>
> Why isn't virtio-rng getting entropy from /dev/random on the host?
/dev/random may not be available. Besides, not all entropy comes from
/dev/random.
-Ian
Anthony Liguori wrote:
> Ian Molton wrote:
>> Hi folks,
>>
>> I need my source of data for virtio-rng to be reliable - IOW. if the
>> server dies and comes back up, I want qemu to reconnect and suck down
>> fresh entropy, rather than hand the rngd process on the guest.
>>
>> I'm using the chardev '
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 kvm/vnc/block I just CC
Anthony, for Audio I just CC malc, etc.
There are some subsystems
On Thu, Nov 26, 2009 at 10:58:50PM -0200, Luiz Capitulino wrote:
> Hi,
>
> This series has a number of improvements over v0 and is a serious
> candidate for inclusion.
>
> Something I'd like to make clear is that QMP is still unstable:
> some commands output are being fixed and most of the err
On 01.12.2009, at 10:46, Carsten Otte wrote:
> Alexander Graf wrote:
>>> I don't know what psw.mask represent, but it may be wrong. It should be
>>> a way to identify which TB can be reused, that is they have been
>>> generated in the same CPU mode.
>> psw.mask is rougly the same as RFLAGS, cr0 a
Gerd Hoffmann writes:
> The patch decuples the -chardev switch and the actual chardev
> initialization. Without this patch qemu ignores chardev entries
> coming via -readconfig.
>
> Signed-off-by: Gerd Hoffmann
Makes sense to me.
Kevin Wolf writes:
> Currently qcow2 unnecessarily rounds up the length of the backing format
> string
> to the next multiple of 8. At the same time, the array in BlockDriverState can
> only hold 15 characters, so in effect backing formats with 9 characters or
> more
> don't work (e.g. host_dev
Alexander Graf wrote:
I don't know what psw.mask represent, but it may be wrong. It should be
a way to identify which TB can be reused, that is they have been
generated in the same CPU mode.
psw.mask is rougly the same as RFLAGS, cr0 and cr4 on x86_64 combined. So IMHO
it looked like a pretty
Alexander Graf writes:
> Currently we have this stupid role of disallowing:
>
> if (r)
> break;
>
> By disallowing this we clutter the code, making it less readable without
> buying us anything. In fact, nobody actually sticks to this because it'd show
> just how much bad taste the progra
On Mon, Nov 30, 2009 at 09:34:58PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Fri, Nov 27, 2009 at 09:42:19PM +0100, Sebastian Herbszt wrote:
> >>Gleb Natapov wrote:
> >>>On Thu, Nov 26, 2009 at 09:55:28PM +0100, Sebastian Herbszt wrote:
> Gleb Natapov wrote:
> >On Wed, Nov
Aurelien Jarno wrote:
+static inline int cpu_mmu_index (CPUState *env)
+{
+/* XXX: Currently we don't implement virtual memory */
+return 0;
Is it correct? It means that memory access will aways be kernel memory
accesses. IIRC, even with KVM enabled, softmmu accesses are possible in
som
Alexander Graf wrote:
For the technical reason I hope Carsten can provide some insight.
As for the implementation reason - S390 KVM (the kernel part) doesn't do
memslots properly :-).
I'm sorry, I cannot comment on that :-(.
On Friday 27 November 2009 05:17:32 Vincent Sanders wrote:
> I appear to be unable to take a hint, your silence on this patch in
> the past probably ought to have been a clue. however this will be the
> last time I bother to try and get anything merged so you wont have to
> be disturbed again.
>
>
72 matches
Mail list logo
