On 10/21/09 16:32, Glauber Costa wrote:
On Wed, Oct 21, 2009 at 03:38:31PM +0200, Gerd Hoffmann wrote:
On 10/20/09 16:04, Glauber Costa wrote:
Currently, the msrs involved in setting up pvclock are not saved over
migration and/or save/restore. This patch puts their value in special
fields in ou
On Tue, Oct 20, 2009 at 08:57:13PM +0200, Paolo Bonzini wrote:
> On 10/20/2009 08:39 PM, Mark McLoughlin wrote:
>> On Thu, 2009-10-08 at 22:37 +0200, Michael S. Tsirkin wrote:
>>> With commit ee3993069ff55fa6f1c64daf1e09963e340db8e4,
>>> "posix-aio-compat: avoid signal race when spawning a thread"
On Wed, Oct 21, 2009 at 05:42:34PM +0200, Michael S. Tsirkin wrote:
> On Tue, Oct 20, 2009 at 08:57:13PM +0200, Paolo Bonzini wrote:
> > On 10/20/2009 08:39 PM, Mark McLoughlin wrote:
> >> On Thu, 2009-10-08 at 22:37 +0200, Michael S. Tsirkin wrote:
> >>> With commit ee3993069ff55fa6f1c64daf1e09963
On 21.10.2009, at 16:29, Anthony Liguori wrote:
Alexander Graf wrote:
S390 requires vmas for guests to be < 256 GB. So we need to
directly export
mmaps "try to use this vma as start address" feature to not
accidently get
over that limit.
Signed-off-by: Alexander Graf
---
cpu-common.h |
On Wed, Oct 21, 2009 at 8:52 PM, Glauber Costa wrote:
> Why don't we provide a mechanism to make a macro out of a sequence of
> monitor commands, and let the user assign whatever he wants out of that?
Presto! never thought about thatwhat are we supposed to do in
order to provide such mechanis
On Wed, Oct 21, 2009 at 2:04 PM, Mulyadi Santosa
wrote:
> On Wed, Oct 21, 2009 at 8:52 PM, Glauber Costa wrote:
>> Why don't we provide a mechanism to make a macro out of a sequence of
>> monitor commands, and let the user assign whatever he wants out of that?
>
> Presto! never thought about that
I have a couple of questions regarding sparc64 softmmu support in Qemu:
- Is this part of Qemu being actively developed? Judging by the commits to the
git repo, it doesn't look like there's a whole lot of focus on development of
this right now?
- Does anyone know what's left to be done for the s
On Wed, Oct 21, 2009 at 11:24 PM, Glauber Costa wrote:
> You can provide a monitor command to do that
>
> something in the lines of:
> - add_macro
> - remove_macro
> - list_macros
Please CMIIW, "command_list" here refers to at least one of monitor
commands, right? meaning, i.e one could do:
ad
On Wed, Oct 21, 2009 at 2:44 PM, Mulyadi Santosa
wrote:
> On Wed, Oct 21, 2009 at 11:24 PM, Glauber Costa wrote:
>> You can provide a monitor command to do that
>>
>> something in the lines of:
>> - add_macro
>> - remove_macro
>> - list_macros
>
> Please CMIIW, "command_list" here refers to at
Alexander Graf wrote:
On 21.10.2009, at 16:29, Anthony Liguori wrote:
Alexander Graf wrote:
S390 requires vmas for guests to be < 256 GB. So we need to directly
export
mmaps "try to use this vma as start address" feature to not
accidently get
over that limit.
Signed-off-by: Alexander Graf
Glauber Costa wrote:
Why don't we provide a mechanism to make a macro out of a sequence of
monitor commands, and let the user assign whatever he wants out of that?
Really? This seems exceedingly complicated to me.
Redirecting the kernel output to serial and logging is a considerably
bette
On Wed, Oct 21, 2009 at 11:55 PM, Anthony Liguori wrote:
> Really? This seems exceedingly complicated to me.
>
> Redirecting the kernel output to serial and logging is a considerably better
> solution.
I'll respectfully consider everybody's thought hereinteresting
discussion so far though. m
On 21.10.2009, at 18:54, Anthony Liguori wrote:
Alexander Graf wrote:
On 21.10.2009, at 16:29, Anthony Liguori wrote:
Alexander Graf wrote:
S390 requires vmas for guests to be < 256 GB. So we need to
directly export
mmaps "try to use this vma as start address" feature to not
accidently
On Wed, Oct 21, 2009 at 2:55 PM, Anthony Liguori wrote:
> Glauber Costa wrote:
>>
>> Why don't we provide a mechanism to make a macro out of a sequence of
>> monitor commands, and let the user assign whatever he wants out of that?
>>
>
> Really? This seems exceedingly complicated to me.
>
> Redir
I've uploaded them here:
http://www.kernel.org/pub/linux/kernel/people/mst/
you can't see them in mirrors yet but will be able to soon when
kernel.org mirroring system catches them.
There is no difference in optimizations except that here:
for (i = 0; i < aiocb->aio_niov && count; ++i)
On Wed, Oct 21, 2009 at 07:28:54PM +0200, Paolo Bonzini wrote:
>> I've uploaded them here:
>> http://www.kernel.org/pub/linux/kernel/people/mst/
>> you can't see them in mirrors yet but will be able to soon when
>> kernel.org mirroring system catches them.
>
> There is no difference in optimization
I suggest trying to make the sigset_t static, since that generates
exactly the same code as the "nohang" case, and exactly the same stack
layout as the "hang" case.
(In case this wasn't clear: the sigfillset of a static sigset_t should
hang, proving that it's stack layout that comes to the re
On Wed, Oct 21, 2009 at 07:44:14PM +0200, Paolo Bonzini wrote:
>
>>> I suggest trying to make the sigset_t static, since that generates
>>> exactly the same code as the "nohang" case, and exactly the same stack
>>> layout as the "hang" case.
>
> (In case this wasn't clear: the sigfillset of a stati
Hello,
I am getting the following error trying to compile sheepdog on Ubuntu 9.10 (
2.6.31-14 x64 ) :
cd shepherd; make
make[1]: Entering directory `/home/shiny/Packages/sheepdog-2009102101/shepherd'
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE shepherd.c -o
shepherd.o
shep
Hello,
when i try to compile, i'm getting the following error ( Using ubuntu 9.10, x64
) :
cd shepherd; make
make[1]: Entering directory `/home/shiny/Packages/sheepdog-2009102101/shepherd'
cc -c -g -O2 -Wall -Wstrict-prototypes -I../include -D_GNU_SOURCE shepherd.c -o
shepherd.o
shepherd.c
Alexander Graf wrote:
So you would prefer a special #ifdef for s390 in generic code over a
specifically for this purpose exported function?
Well, you're the boss. I like the special function better, but
whatever you say.
How is someone supposed to figure out what _qemu_ram_alloc is for?
No
Glauber Costa wrote:
On Wed, Oct 21, 2009 at 2:55 PM, Anthony Liguori wrote:
Glauber Costa wrote:
Why don't we provide a mechanism to make a macro out of a sequence of
monitor commands, and let the user assign whatever he wants out of that?
Really? This seems exceedingly comp
Hi Liran,
lir...@il.ibm.com wrote:
To support live migration without shared storage we need to be able to trace
writes to disk while migrating. This Patch expose handler registration for
above components to be notified about block writes.
diff --git a/block.c b/block.c
index 33f3d65..bf5f7a6
On 21.10.2009, at 20:06, Anthony Liguori wrote:
Alexander Graf wrote:
So you would prefer a special #ifdef for s390 in generic code over
a specifically for this purpose exported function?
Well, you're the boss. I like the special function better, but
whatever you say.
How is someone sup
lir...@il.ibm.com wrote:
This patch adds the option to activate non-shared storage migration from the
monitor.
The migration command is as follows:
(qemu) migrate -d tcp:0: # for ordinary live migration
(qemu) migrate -d -b tcp:0: # for live migration with complete storage copy
(qemu) mig
Liran Schour wrote:
qemu_savevm_state will call all registered components with 3 phases: START,
PART, END. Only the PART phase is iterative.
In case of storage live migration we have lot more data to copy then memory
and usually the dirty rate is much less then memory dirty rate. I thought
about
lir...@il.ibm.com wrote:
This patch introduces block migration called during live migration. Block
are being copied to the destination in an async way. First the code will
transfer the whole disk and then transfer all dirty blocks accumulted during
the migration.
Still need to improve transitio
Alexander Graf wrote:
On 21.10.2009, at 20:06, Anthony Liguori wrote:
Alexander Graf wrote:
So you would prefer a special #ifdef for s390 in generic code over a
specifically for this purpose exported function?
Well, you're the boss. I like the special function better, but
whatever you say.
Mulyadi Santosa wrote:
> On Wed, Oct 21, 2009 at 11:24 PM, Glauber Costa wrote:
> > You can provide a monitor command to do that
> >
> > something in the lines of:
> > - add_macro
> > - remove_macro
> > - list_macros
>
> Please CMIIW, "command_list" here refers to at least one of monitor
> com
At every word of the sigset (using gdb commands to disable/enable the
watchpoints around the sigfillset, you avoid spurious triggers).
Not sure how do you mean. When would I enable the watchpoint?
301 static void *aio_thread(void *unused)
302 {
303 pid_t pid;
304 stat
On 10/21/2009 08:06 PM, Anthony Liguori wrote:
Alexander Graf wrote:
So you would prefer a special #ifdef for s390 in generic code over a
specifically for this purpose exported function?
Well, you're the boss. I like the special function better, but
whatever you say.
How is someone supposed t
Paolo Bonzini wrote:
What about this:
-ram_addr_t qemu_ram_alloc(ram_addr_t size)
+ram_addr_t qemu_ram_alloc_at(ram_addr_t size, void *map_at)
{
RAMBlock *new_block;
size = TARGET_PAGE_ALIGN(size);
new_block = qemu_malloc(sizeof(*new_block));
-new_block->host = qemu_vmalloc
On Wed, Oct 21, 2009 at 7:41 PM, Nick Couchman wrote:
> I have a couple of questions regarding sparc64 softmmu support in Qemu:
> - Is this part of Qemu being actively developed? Judging by the commits to
> the git repo, it doesn't look like there's a whole lot of focus on
> development of this
While S390x was one of the first targets that were supported by KVM it always
lacked qemu system emulation support.
In order to change that sad fact, I figured I'd just take on the task myself,
taking kuli (http://www.ibm.com/developerworks/linux/linux390/kuli.html),
Documentation/s390/kvm.txt and
On our S390x Virtio machine we don't have anywhere to display early printks
on, because we don't know about VGA or serial ports.
So instead we just forward everything to the virtio console that we created
anyways.
Signed-off-by: Alexander Graf
---
hw/virtio-console.c |7 +++
hw/virtio-c
KVM on S390x requires the virtual address space of the guest's RAM to be
within the first 256GB.
The general direction I'd like to see KVM on S390 move is that this requirement
is losened, but for now that's what we're stuck with.
So let's just hack up qemu_ram_alloc until KVM behaves nicely :-).
In order to debug funny kernel breakages it's always good to have a working
gdb stub around.
While Uli's patches don't include one one, I needed one that's at least good
enough for 'bt' and some variable examinations during early bootup.
So here it is - the absolute basics to get the qemu gdb stu
In order to use the new S390x virtio bus we just introduced, we also
need a machine description that sets up the machine according to our
PV specification.
Let's add that machine description and be happy!
Signed-off-by: Alexander Graf
---
v2 -> v3
- use qemu_ram_alloc
use qemu_ram_alloc (s
MP State is implemented in the generic code, so let's move the variable
it accesses to generic code as well.
Still unbreaks PPC and now even S390x w/ KVM.
Signed-off-by: Alexander Graf
---
cpu-defs.h|1 +
target-i386/cpu.h |1 -
2 files changed, 1 insertions(+), 1 deletions(-)
On S390x we don't want to go through the hassle of emulating real existing
hardware, because we don't need to for running Linux.
So let's instead implement a machine that is 100% based on VirtIO which we
fortunately implement already.
This patch implements the bus that is the groundwork for such
All "normal" system emulation targets in qemu I'm aware of display output
on either VGA or serial output.
Our S390x virtio machine doesn't have such kind of legacy hardware. So
instead we need to default to a virtio console.
I'm not particularly proud of this patch. It would be a lot better to
ha
Right now only S390x Linux userspace emulation is supported. Let's enable
the basics for system emulation so we can run virtual machines with KVM!
Signed-off-by: Alexander Graf
---
target-s390x/cpu.h | 86 -
target-s390x/exec.h |5 +++
S390x was one of the first platforms that received support for KVM back in the
day. Unfortunately until now there hasn't been a qemu implementation that would
enable users to actually run guests.
So let's include support for KVM S390x in qemu!
Signed-off-by: Alexander Graf
---
v1 -> v2:
- us
>>> On 2009/10/21 at 13:06, Blue Swirl wrote:
> On Wed, Oct 21, 2009 at 7:41 PM, Nick Couchman
> wrote:
>> I have a couple of questions regarding sparc64 softmmu support in Qemu:
>> - Is this part of Qemu being actively developed? Judging by the commits to
> the git repo, it doesn't look like
On Mon, Oct 19, 2009 at 1:44 PM, wrote:
> Current ARM translator code has several places where it leaves
> temporary TCG variables alive. This patch removes all such instances I
> have found so far. Sorry for the mangled inlined patch, the mailserver
> I use doesn't like patches so I've also incl
On Wed, Oct 21, 2009 at 10:19 PM, Nick Couchman wrote:
On 2009/10/21 at 13:06, Blue Swirl wrote:
>> On Wed, Oct 21, 2009 at 7:41 PM, Nick Couchman
>> wrote:
>>> I have a couple of questions regarding sparc64 softmmu support in Qemu:
>>> - Is this part of Qemu being actively developed? Jud
On Wed, Oct 21, 2009 at 04:52:00PM +0200, Gerd Hoffmann wrote:
> On 10/21/09 16:32, Glauber Costa wrote:
>> On Wed, Oct 21, 2009 at 03:38:31PM +0200, Gerd Hoffmann wrote:
>>> On 10/20/09 16:04, Glauber Costa wrote:
Currently, the msrs involved in setting up pvclock are not saved over
migr
Paolo Bonzini schrieb:
> On 10/20/2009 06:17 PM, Stefan Weil wrote:
>> This patch makes make quiet again.
>>
>> There is already a similar patch from Juan Quintela,
>> but maybe this shorter form is preferred.
>
> This patch would reintroduce an ordering problem between building
> config*.h and bui
Anthony Liguori wrote:
However, an ugly #ifdef immediately tells someone, oh, s390 kvm needs
this terrible hack, so let's keep bugging those guys to eliminate the
need for that.
/me moves cleaning up memslot handling a little further up the prio
list. I fear it still won't make it to queue head
Thanks for your feedback. I'll iron out the issues you mentioned,
please look at my further inlined comments below.
Cheers,
Juha
On Oct 21, 2009, at 22:20, ext Laurent Desnogues wrote:
>> @@ -4676,12 +4694,16 @@ static int disas_neon_data_insn(CPUState *
>> env, DisasContext *s, uint32_t insn
On 10/21/2009 11:17 PM, Stefan Weil wrote:
Paolo Bonzini schrieb:
On 10/20/2009 06:17 PM, Stefan Weil wrote:
This patch makes make quiet again.
There is already a similar patch from Juan Quintela,
but maybe this shorter form is preferred.
This patch would reintroduce an ordering problem betw
Revised patch for getting rid of tcg temporary variable leaks in
target-arm/translate.c. This version also includes the leak patch for
gen_set_cpsr macro, now converted as a static inline function, which I
sent earlier as a separate patch on top of this patch. This patch (the
attached version) shou
On Oct 21, 2009, at 13:46, ext Laurent Desnogues wrote:
>> @@ -4624,31 +4624,31 @@ static int disas_neon_data_insn(CPUState *
>> env, DisasContext *s, uint32_t insn)
>> switch (size) {
>> case 0:
>> if (op
101 - 153 of 153 matches
Mail list logo
