Hi Peter,
On Sat, Jul 13, 2013 at 4:12 AM, Peter Maydell wrote:
> The OpenRISC kernel ignores CLONE_SETTLS in its copy_thread()
> implementation, so a cpu_set_tls() implementation is a no-op.
> cpu_clone_regs() was setting the syscall return value in the
> wrong register -- it is gpr[11], not gpr
On 13 July 2013 08:40, Jia Liu wrote:
> Hi Peter,
>
> On Sat, Jul 13, 2013 at 4:12 AM, Peter Maydell
> wrote:
>> The OpenRISC kernel ignores CLONE_SETTLS in its copy_thread()
>> implementation, so a cpu_set_tls() implementation is a no-op.
>> cpu_clone_regs() was setting the syscall return value
13.07.2013 00:29, Ed Maste wrote:
> Signed-off-by: Ed Maste
> ---
> The issue comes from slirp/mbuf.h #defining m_flags, which conflicts with
> a header included via on FreeBSD.
Umgh. How.. disgusting... :(
Here's the code in question.
/* header at beginning of each mbuf: */
struct m_hdr {
On 06/24/2013 12:49 PM, Chegu Vinod wrote:
> Introduce an asynchronous version of run_on_cpu() i.e. the caller
> doesn't have to block till the call back routine finishes execution
> on the target vcpu.
>
> Signed-off-by: Chegu Vinod
> Reviewed-by: Paolo Bonzini
> ---
> cpus.c|
On 06/24/2013 12:49 PM, Chegu Vinod wrote:
> The auto-converge migration capability allows the user to specify if they
> choose live migration seqeunce to automatically detect and force convergence.
>
> Signed-off-by: Chegu Vinod
> Reviewed-by: Paolo Bonzini
> Reviewed-by: Eric Blake
> ---
> i
On Fri, Jul 12, 2013 at 05:37:19PM +1000, Alexey Kardashevskiy wrote:
> sPAPR PHB emulates IO ports on PCI via a special memory region which
> routes all reads/writes further via cpu_in*/cpu_out* which are eventually
> processed by MemoryRegionOps implemented by devices.
Hrm. That double dispatch
On 06/24/2013 12:47 PM, Chegu Vinod wrote:
> If a user chooses to turn on the auto-converge migration capability
> these changes detect the lack of convergence and throttle down the
> guest. i.e. force the VCPUs out of the guest for some duration
> and let the migration thread catchup and help conv
Le 12/07/2013 22:12, Peter Maydell a écrit :
For m68k, per-thread data is a purely kernel construct with no
CPU level support. Implement it via a field in the TaskState structure,
used by cpu_set_tls() and the set_thread_area/get_thread_area
syscalls. This allows us to enable compilation with NPT
Hi,
I'm using KVM win7(32bit) guest, and found that, guest cpu was almostly
60% when it's idle.
The host is centos6.3, with qemu-1.5.1.
In the guest, I found that:
1) All the cpu is eat by one task called "system interrupt";
2) The virtio net device and USB Uni
On 13 July 2013 11:28, Laurent Vivier wrote:
> Le 12/07/2013 22:12, Peter Maydell a écrit :
>> --- a/linux-user/syscall.c
>> +++ b/linux-user/syscall.c
>> @@ -8558,6 +8558,11 @@ abi_long do_syscall(void *cpu_env, int num,
>> abi_long arg1,
>> #elif defined(TARGET_I386) && defined(TARGET_ABI32)
>
Il 11/07/2013 14:46, Andreas Färber ha scritto:
> sPAPR has its MemoryRegion marked Little Endian:
>
> http://git.qemu.org/?p=qemu.git;a=blobdiff;f=hw/spapr_pci.c;h=a08ed11166595bdc493065beb64d4ce5b7b0dded;hp=c2c3079d21d5be2647faf85a8c608ac995d2ca62;hb=a3cfa18eb075c7ef78358ca1956fe7b01caa1724;hpb=
On Sat, Jul 13, 2013 at 9:38 AM, Paolo Bonzini wrote:
> Il 11/07/2013 14:46, Andreas Färber ha scritto:
>> sPAPR has its MemoryRegion marked Little Endian:
>>
>> http://git.qemu.org/?p=qemu.git;a=blobdiff;f=hw/spapr_pci.c;h=a08ed11166595bdc493065beb64d4ce5b7b0dded;hp=c2c3079d21d5be2647faf85a8c608a
Anthony Liguori a écrit :
On Sat, Jul 13, 2013 at 9:38 AM, Paolo Bonzini wrote:
Il 11/07/2013 14:46, Andreas Färber ha scritto:
sPAPR has its MemoryRegion marked Little Endian:
http://git.qemu.org/?p=qemu.git;a=blobdiff;f=hw/spapr_pci.c;h=a08ed11166595bdc493065beb64d4ce5b7b0dded;hp=c2c3079d21
On 07/12/2013 01:12 PM, Peter Maydell wrote:
> The target-specific headers (target_cpu.h and target_signal.h)
> might need to use the target-independent structure and function
> definitions of qemu.h; so include them only at the bottom of
> qemu.h, not the top.
>
> Signed-off-by: Peter Maydell
R
On 07/12/2013 01:12 PM, Peter Maydell wrote:
> Provide the missing cpu_set_tls(), and resolve the FIXME in
> cpu_clone_regs() by clearing the carry flag for the child.
> This allows us to turn on building with NPTL for SPARC.
>
> Signed-off-by: Peter Maydell
Reviewed-by: Richard Henderson
r~
On 13 July 2013 05:12, Michael Tokarev wrote:
> Remaining:
>
> struct mbuf {
> union M_dat {
> charm_dat_[1]; /* ANSI don't like 0 sized arrays */
> char*m_ext_;
> } M_dat;
> };
>
> #define m_dat M_dat.m_dat_
> #define m_ext
On Sat, Jul 13, 2013 at 12:24 AM, Richard Henderson wrote:
> On 07/11/2013 11:32 PM, Liu Ping Fan wrote:
>> Refcnt's atomic inc/dec ops are frequent and its idiom need no seq_cst
>> order. So to get better performance, it worth to adopt _relaxed
>> other than _seq_cst memory model on them.
>
> You
Refcnt's atomic inc/dec ops are frequent and its idiom need no seq_cst
order. So to get better performance, it worth to adopt _relaxed
other than _seq_cst memory model on them.
We resort to gcc builtins. If gcc supports C11 memory model, __atomic_*
buitlins is used, otherwise __sync_* builtins.
S
On Fri, Jul 12, 2013 at 09:33:28AM +0800, Hu Tao wrote:
> On Thu, Jul 11, 2013 at 11:49:01AM +0300, Michael S. Tsirkin wrote:
> > On Thu, Jul 11, 2013 at 07:13:39AM +0200, Igor Mammedov wrote:
> > > On Wed, 10 Jul 2013 13:10:03 +0300
> > > "Michael S. Tsirkin" wrote:
> > >
> > > > On Wed, Jun 26,
Il 14/07/2013 04:53, Liu Ping Fan ha scritto:
> Refcnt's atomic inc/dec ops are frequent and its idiom need no seq_cst
> order. So to get better performance, it worth to adopt _relaxed
> other than _seq_cst memory model on them.
>
> We resort to gcc builtins. If gcc supports C11 memory model, __at
On 07/10/2013 08:49:35 AM, Richard Henderson wrote:
On 07/09/2013 10:43 AM, Rob Landley wrote:
> Do you have a kernel .config that boots on this board? I'd really
like to try
> this out myself...
I haven't worked on this in quite some time. But I've located two
branches
that look like the
Il 13/07/2013 17:22, Anthony Liguori ha scritto:
> 1) MMIO request goes to sPAPR PIO area, the vCPU was in BE mode but by
> the time the handler is called, the value is in host byte order.
>
> 2) sPAPR (incorrectly) byte swaps by marking the region as little
> endian (data is now garbage)
>
> 3)
Il 09/07/2013 03:01, Richard Henderson ha scritto:
> Honor the implementation maximum access size, and at least check
> the minimum access size.
>
> Signed-off-by: Richard Henderson
> ---
> exec.c | 68
> ++
> 1 file changed, 56 in
23 matches
Mail list logo