date:20110216

[Qemu-devel] [Bug 604872] Re: qemu-system-arm segfaults emulating versatile machine after running debootstrap --second-stage inside vm

2011-02-16 Thread Peter Maydell

The commit in qemu-linaro is:
http://git.linaro.org/gitweb?p=qemu/qemu-linaro.git;a=commit;h=98eac7cab4392ab28fa22265e27906f5b9c6c9da

I asked you to undo the status change just because I don't own qemu-
linaro (Ubuntu) and don't know what counts as fix released (eg maybe
that only happens when it goes into a stable ubuntu release?). It's fix
released as far as Linaro QEMU is concerned, though.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/604872

Title:
  qemu-system-arm segfaults emulating versatile machine after running
  debootstrap --second-stage inside vm

Status in QEMU:
  Fix Committed
Status in “qemu-linaro” package in Ubuntu:
  Triaged

Bug description:
  Binary package hint: qemu-kvm

  As I'm now implementing the support for creating a rootstock rootfs
  without requiring root, I need to run the deboostrap' second stage
  inside a VM, to correctly install the packages into the rootfs.

  qemu-system-arm fails right after debootstrap finish the second stage,
  giving a segmentation fault.

  Command:
  qemu-system-arm -M versatilepb -cpu cortex-a8 -kernel vmlinuz -no-reboot 
-nographic -drive file=qemu-armel-201007122016.img,aio=native,cache=none -m 256 
-append 'console=ttyAMA0,115200n8 root=/dev/sda rw mem=256M devtmpfs.mount=0 
init=/bin/installer'
  Uncompressing 
Linux.
 done, booting the kernel.
  [0.00] Initializing cgroup subsys cpuset
  [0.00] Initializing cgroup subsys cpu
  [0.00] Linux version 2.6.32-21-versatile (buildd@cushaw) (gcc version 
4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #32-Ubuntu Fri Apr 16 08:14:53 UTC 2010 (Ubuntu 
2.6.32-21.32-versatile 2.6.32.11+drm33.2)
  ...
  I: Base system installed successfully.
  I: Starting basic services in VM
  Segmentation fault (core dumped)

  [492816.197352] qemu-system-arm[16024]: segfault at cf6ba8fc
  ip cf6ba8fc sp 7fffd0e68680 error 14

  Image:
   * rootfs: 
http://rsalveti.net/pub/ubuntu/rootstock/qemu-armel-201007122016.img (md5 
1d063ac8a65c798bb004cd1c4c7970c5)
   * kernel: 
http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/vmlinuz

  I'm able to reproduce the bug on Maverick (amd64) and Lucid (x86).

  Maverick qemu-kvm-extras: 0.12.4+noroms-0ubuntu4
  Lucid qemu-kvm-extras: 0.12.3+noroms-0ubuntu9.2

  ProblemType: Bug
  DistroRelease: Ubuntu 10.10
  Package: qemu-kvm-extras 0.12.4+noroms-0ubuntu4
  ProcVersionSignature: Ubuntu 2.6.35-6.9-generic 2.6.35-rc3
  Uname: Linux 2.6.35-6-generic x86_64
  Architecture: amd64
  Date: Mon Jul 12 18:55:35 2010
  InstallationMedia: Ubuntu 10.04 LTS Lucid Lynx - Release amd64 (20100427.1)
  KvmCmdLine: Error: command ['ps', '-C', 'kvm', '-F'] failed with exit code 1: 
UIDPID  PPID  CSZ   RSS PSR STIME TTY  TIME CMD
  MachineType: LENOVO 2764CTO
  PccardctlIdent:
   Socket 0:
 no product info available
  PccardctlStatus:
   Socket 0:
 no card
  ProcCmdLine: BOOT_IMAGE=/vmlinuz-2.6.35-6-generic 
root=/dev/mapper/primary-root ro crashkernel=384M-2G:64M,2G-:128M quiet splash
  ProcEnviron:
   LANG=en_US.utf8
   SHELL=/bin/bash
  SourcePackage: qemu-kvm
  dmi.bios.date: 04/19/2010
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 7UET86WW (3.16 )
  dmi.board.name: 2764CTO
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Available
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvr7UET86WW(3.16):bd04/19/2010:svnLENOVO:pn2764CTO:pvrThinkPadT400:rvnLENOVO:rn2764CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.name: 2764CTO
  dmi.product.version: ThinkPad T400
  dmi.sys.vendor: LENOVO

[Qemu-devel] Re: [RFC] Some more io-thread optimizations

2011-02-16 Thread Jan Kiszka

On 2011-02-15 23:03, Marcelo Tosatti wrote:
 On Mon, Feb 14, 2011 at 10:50:42AM +0100, Jan Kiszka wrote:
 Hi,

 patch below further reduces the io-thread overhead in tcg mode so that
 specifically emulating smp boxes gets noticeably faster. Its essence:
 poll the file descriptors until select returns 0, keeping the global
 mutex locked. This reduces ping pong with the vcpu threads, most
 noticeably in tcg mode where we run in lock-step.

 Split up in two patches, I'm planning to route those changes via the kvm
 queue (as they collide with other patches there).

 Jan
 
 Not sure this makes sense for all cases. There could be scenarios where
 a single pass is more efficient (think latency to acquire mutex from
 vcpu context in kvm mode, with intensive file IO in progress).

Yeah, likely true. Only TCG has these insane long lock-holding times and
requires signal-based mutex handover. I will exclude KVM from this.

Jan



signature.asc
Description: OpenPGP digital signature

[Qemu-devel] Re: [PATCH] fix halt emulation with icount and CONFIG_IOTHREAD (v2)

2011-02-16 Thread Jan Kiszka

On 2011-02-15 21:56, Marcelo Tosatti wrote:
 Note: to be applied to uq/master.
 
 In icount mode, halt emulation should take into account the nearest event 
 when sleeping.
 
 Signed-off-by: Marcelo Tosatti mtosa...@redhat.com
 Reported-and-tested-by: Edgar E. Iglesias edgar.igles...@gmail.com
 
 diff --git a/cpus.c b/cpus.c
 index 468544c..21c3eba 100644
 --- a/cpus.c
 +++ b/cpus.c
 @@ -770,7 +770,7 @@ static void qemu_tcg_wait_io_event(void)
  CPUState *env;
  
  while (all_cpu_threads_idle()) {
 -qemu_cond_timedwait(tcg_halt_cond, qemu_global_mutex, 1000);
 +qemu_cond_timedwait(tcg_halt_cond, qemu_global_mutex, 
 qemu_calculate_timeout());
  }
  
  qemu_mutex_unlock(qemu_global_mutex);

As we agree that timeouts are wrong here, let's check if Paolo's patches
make a difference.

If not, it would still be better to understand the actual issue. After
trying too many voodoo patches myself, I've finally found that mutex
ping pong between iothread and vcpus by starring at a trace in kernelshark.

Jan



signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] Re: [RFC] qapi: events in QMP

2011-02-16 Thread Kevin Wolf

Am 16.02.2011 01:59, schrieb Anthony Liguori:
 On 02/15/2011 07:38 AM, Luiz Capitulino wrote:
 On Tue, 15 Feb 2011 10:20:01 +0100
 Kevin Wolfkw...@redhat.com  wrote:


 Am 14.02.2011 20:34, schrieb Anthony Liguori:
  
 On 02/14/2011 12:34 PM, Luiz Capitulino wrote:

 On Mon, 14 Feb 2011 08:39:11 -0600
 Anthony Liguorianth...@codemonkey.ws   wrote:


  
 On 02/14/2011 06:45 AM, Luiz Capitulino wrote:


 So the question is: how does the schema based design support extending
 commands or events? Does it require adding new commands/events?


  
 Well, let me ask you, how do we do that today?

 Let's say that I want to add a new parameter to the `change' function so
 that I can include a salt parameter as part of the password.

 The way we'd do this today is by checking for the 'salt' parameter in
 qdict, and if it's not present, use a random salt or something like that.


 You likely want to do what you did before. Of course that you have to
 consider if what you're doing is extending an existing command or badly
 overloading it (like change is today), in this case you'll want to add
 a new command instead.

 But yes, the use-case here is extending an existing command.


  
 However, if I'm a QMP client, how can I tell whether you're going to
 ignore my salt parameter or actually use it?  Nothing in QMP tells me
 this today.  If I set the salt parameter in the `change' command, I'll
 just get a success message.


 I'm sorry?

 { execute: change, arguments: { device: vnc, target: 
 password, arg: 1234, salt: r1 } }
 {error: {class: InvalidParameter, desc: Invalid parameter 
 'salt', data: {name: salt}}}

  
 So I'm supposed to execute the command, and if execution fails, drop the
 new parameter?  If we add a few optional parameters, does that mean I
 have to try every possible combination of parameters?

 How is that different from trying out multiple commands? In the end, you
 always need some meta information like a schema in order to avoid trying
 out which parameters the server supports.

 Anyway, I think there's a second interesting point: Adding parameters
 does cause these problems, but it's different for data sent from qemu to
 the client (return values and events). If we add more information there,
 an older client can just ignore it, without even looking at a schema.

 So I think we should consider this for return values and definitely do
 it for events. Sending out five different messages for a single event
 that are completely redundant and only differ in the number of fields is
 just insane (okay, they wouldn't actually get on the wire because a
 client registers only for one of them, but the code for generating them
 must exist).
  
 That's my point when I asked about events in the other thread.

 
 Okay, I had confused myself about this.  It's not quite as bad as I had 
 been saying.
 
 One of the reasons to have generated allocation function is so that we 
 can make sure to always pad structures.  Since all optional fields has a 
 bool to indicate the fields presence, by setting the allocated structure 
 to zero, we can support forwards compatibility for structures.

I think in most cases we would even get away with a default value
instead of the bool. For example for strings, NULL would be a very clear
indication that the field wasn't there in the JSON message. I think it
works also for most (if not all) integer fields, but maybe having a bool
has_* field is safer there.

Or maybe we can add an indication to the schema that specifies if a
default value should be generated or (for the rare cases where it's
needed) a has_* field is added.

 So we can add new members to structures with no libqmp compatibility 
 problem.  It's only if we add new arguments to signals or commands that 
 we will break the ABI.

Yeah, that makes sense.

 If we expect to add fields later, we just have to make sure we use a 
 structure to encapsulate things.

As stated before, I think we should use structures for all events. I
still don't understand why we should have an exception for events. Any
other command returns structures, too, and you don't automagically pull
their fields up one level anywhere except for events.

Kevin

[Qemu-devel] Re: qemu compiling error on ppc64: kvm.c:81: error: 'struct kvm_sregs' has no member named 'pvr'

2011-02-16 Thread Avi Kivity


On 02/15/2011 05:59 PM, Dushyant Bansal wrote:
2. How to configure makefiles to get output of printk statements 
inside kvm/arch/powerpc/kvm/trace.h
Better don't make them printks - just use the tracing framework. I'd 
write up a small howto here myself, but I'm pretty much on the jump 
to my plane for vacation. Avi, could you please guide him a bit on 
how to get data out of tracepoints?

   Thanks for the quick reply :)
I have added some more trace parameters in the tracing framework and 
currently, it is working fine.

1. Add new field in struct kvm_vcpu_stat (kvm_host.h)
2. Add corresponding entry in struct kvm_stats_debugfs_item 
debugfs_entries[] (book3s.c)

3. Increment or Decrement that field where ever necessary.


Those aren't tracepoints; they're deprecated debug statistics.

For tracepoints, see

  include/trace/events/kvm.h (general kvm tracepoints)
  arch/powerpc/kvm/trace.h (ppc specific tracepoints)
  arch/powerpc/kvm/book3s_mmu_hpte.c (examples of use, look for 
trace_kvm_*)

  Documentation/trace/tracepoints.txt (documentation, likely outdated)

--
error compiling committee.c: too many arguments to function

[Qemu-devel] Oferta do dia: Maior segurança e conforto com 70% OFF em Balanceamento e Alinhamento no Venancio Centro Automotivo (de R$40,00 por R$12,00)

2011-02-16 Thread Shopping do Povo

Não consegue visualizar a newsletter? Click aqui (
http://shoppingdopovo.com.br/site/index.php?option=com_acymailingctrl=archivetask=viewmailid=39key=e917fb84d1ba64e267277cdc9bde4ee8subid=117104-9a9cec8a6fdd74f317649577265edc31
) para abrir no navegador.

Oferta do dia: Maior segurança e conforto com 70% OFF em Balanceamento e
Alinhamento no Venancio Centro Automotivo (de R$40,00 por R$12,00)

Compartilhe com seus amigos:

Maior segurança e conforto com 70% OFF em Balanceamento e Alinhamento no
Venancio Centro Automotivo (de R$40,00 por R$12,00).

70% de desconto em Balanceamento e Alinhamento no Venancio Centro Automotivo
(de R$40,00 por R$12,00).
Alinhamento: evita o desgaste dos pneus, proporciona conforto na direção e
aumenta a vida útil da suspensão.
Balanceamento: prolonga a vida útil dos rolamentos de roda e dos pneus.
Mais segurança para seu veículo em viagens, passeios e no seu dia a dia.
Equipamentos de alta tecnologia.
Mecânicos experientes nas áreas de suspensão, alinhamento e balanceamento.

NOSSAS COMUNIDADES

Ganhe Indicando o Site

Cadastre-se grátis no Clube de Associados e comece a ganhar dinheiro cada vez
que seus amigos fizerem uma compra

Espalhe a Nóticia

Convide amigos do Orkut, Facebook, Twitter, MSN, Yahoo, Gmail, Hotmail, e onde
mais estiverem.

Email: cont...@shoppingdopovo.com.br

Click em Alterar cidade (
http://shoppingdopovo.com.br/site/index.php?option=com_acymailingctrl=usertask=modifysubid=117104key=9a9cec8a6fdd74f317649577265edc31
), para
receber email de outra cidade ou parar de receber nossos emails.
Copyright © 2010 Shopping do Povo. Todos os Direitos Reservados

95 matches

Mail list logo