From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MjTuU-00022v-Pu for qemu-devel@nongnu.org; Fri, 04 Sep 2009 04:12:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MjTuP-0001wI-6a for qemu-devel@nongnu.org; Fri, 04 Sep 2009 04:12:41 -0400 Received: from [199.232.76.173] (port=48596 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MjTuP-0001vz-0u for qemu-devel@nongnu.org; Fri, 04 Sep 2009 04:12:37 -0400 Received: from mx20.gnu.org ([199.232.41.8]:26283) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MjTuO-0005IN-4w for qemu-devel@nongnu.org; Fri, 04 Sep 2009 04:12:36 -0400 Received: from mail-pz0-f186.google.com ([209.85.222.186]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MjTuM-0002hD-10 for qemu-devel@nongnu.org; Fri, 04 Sep 2009 04:12:34 -0400 Received: by pzk16 with SMTP id 16so590726pzk.18 for ; Fri, 04 Sep 2009 01:12:31 -0700 (PDT) MIME-Version: 1.0 Date: Fri, 4 Sep 2009 16:12:30 +0800 Message-ID: <79a843c30909040112x5275f5a0tdb3515643f0ce44a@mail.gmail.com> From: =?GB2312?B?1tzQ2w==?= Content-Type: multipart/alternative; boundary=0016e64b038ec8b1d10472bc0fe9 Subject: [Qemu-devel] Re: Help List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --0016e64b038ec8b1d10472bc0fe9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hello everybody Am I already in the list now...? 2009/9/4 > Send Qemu-devel mailing list submissions to > qemu-devel@nongnu.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.nongnu.org/mailman/listinfo/qemu-devel > or, via email, send a message with subject or body 'help' to > qemu-devel-request@nongnu.org > > You can reach the person managing the list at > qemu-devel-owner@nongnu.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Qemu-devel digest..." > > > Today's Topics: > > 1. Re: [PATCH] qemu-kvm: fix segfault when running kvm without > /dev/kvm, falling back to non-accelerated mode (Dustin Kirkland) > 2. Defaults for qdev properties inherited from bus > (Markus Armbruster) > 3. Re: [PATCH v3 00/29] QMonitor (Luiz Capitulino) > 4. Re: [RFC 0/5] Monitor handlers convertion to QObject > (Luiz Capitulino) > 5. Re: [PATCH] qemu-kvm: fix segfault when running kvm without > /dev/kvm, falling back to non-accelerated mode (Glauber Costa) > 6. Why qemu-nbd so slow? (shawn du) > 7. Re: [PATCH v2] Build *-user targets as PIE (Kirill A. Shutemov) > 8. Re: QEMU as a "virtual smart card"? (Bud P. Bruegger) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 3 Sep 2009 16:48:49 -0500 > From: Dustin Kirkland > Subject: [Qemu-devel] Re: [PATCH] qemu-kvm: fix segfault when running > kvm without /dev/kvm, falling back to non-accelerated mode > To: Mark McLoughlin > Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org > Message-ID: > > Content-Type: text/plain; charset=3DISO-8859-1 > > On Thu, Sep 3, 2009 at 3:01 PM, Mark McLoughlin wrote: > > On Thu, 2009-09-03 at 12:31 -0500, Dustin Kirkland wrote: > >> qemu-kvm: fix segfault when running kvm without /dev/kvm, falling back > >> to non-accelerated mode > >> > >> We're seeing segfaults on systems without access to /dev/kvm. It > >> looks like the global kvm_allowed is being set just a little too late > >> in vl.c. This patch moves the kvm initialization a bit higher in the > >> vl.c main, just after options processing, and solves the segfaults. > >> We're carrying this patch in Ubuntu 9.10 Alpha. Please apply > >> upstream, or advise if and why this might not be the optimal solution. > > > > Ah discussion about an alternative fix for this fizzled out recently: > > > > http://www.mail-archive.com/kvm@vger.kernel.org/msg19890.html > > Ah, thanks Mark. In that thread, I found Daniel's suggestion the most > reasonable, and user-friendly: > > On Mon, Jul 27, 2009 at 1:44 PM, Daniel P. Berrange > wrote: > > Well, we could go for logic like: > > > > * No arg given =3D> try kvm, try kqemu, try tcg > > * --accelmode arg given =3D> try $arg, and fail if unavailable > > > > then libvirt would simply always supply --accelmode for all VMs, > > while people running qemu manually would get best available > > > > :-Dustin > > > > > ------------------------------ > > Message: 2 > Date: Thu, 03 Sep 2009 23:49:50 +0200 > From: Markus Armbruster > Subject: [Qemu-devel] Defaults for qdev properties inherited from bus > To: qemu-devel@nongnu.org > Message-ID: <873a73d7gh.fsf@pike.pond.sub.org> > Content-Type: text/plain; charset=3Dus-ascii > > Devices inherit some properties from their bus. For instance, ISA > devices inherit iobase, iobase2, and PCI devices inherit addr. > > Properties have a default value. For inherited properties, the same > default value has to do for all devices on the same kind of bus, because > the default value is inherited from the bus along with the property. > > This isn't always a problem. For instance, PCI addr defaulting to "pick > one" is exactly right for most devices. Not so for the ISA iobases: > devices have different default I/O addresses. > > Note that isa_create_simple() mask this problem: it takes iobases as > arguments, and the property default value is not used. The problem > becomes visible when devices are created with -device. > > One way to deal with this is to code the true default values in the > device's init() callback: check whether the value is still the > inherited, unwanted default, and if yes, set it to the true default. > Like this: > > if (dev->iobase[0] =3D=3D -1) > dev->iobase[0] =3D 0x441; > if (dev->iobase[1] =3D=3D -1) > dev->iobase[1] =3D 0x443; > > Workable, if not exactly elegant. > > A related problem is validation of property vales. Devices may accept > only a subset of the values the property inherited from the bus accepts. > For instance, ISA devices can typically use only to a fixed set of I/O > addresses. The bus's PropertyInfo doesn't know them, so this doesn't > get checked. > > One way to deal with this is to validate in the device's init() > callback: fail it when the values aren't acceptable. Like this: > > if (dev->iobase[0] !=3D 0x441 || dev->iobase[1] !=3D 0x443) > return -1; > > Detects bad configuration relatively late. Is this okay? > > > > > ------------------------------ > > Message: 3 > Date: Thu, 3 Sep 2009 19:00:40 -0300 > From: Luiz Capitulino > Subject: Re: [Qemu-devel] [PATCH v3 00/29] QMonitor > To: Mark McLoughlin > Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, avi@redhat.com > Message-ID: <20090903190040.169e4dbe@doriath> > Content-Type: text/plain; charset=3DUS-ASCII > > On Thu, 03 Sep 2009 22:06:52 +0100 > Mark McLoughlin wrote: > > > On Fri, 2009-08-28 at 15:27 -0300, Luiz Capitulino wrote: > > > Basically, this series introduces high-level data types (QInt, > QString, > > > QDict) and port all Monitor command handlers to use them to receive > > > arguments. > > > > Very nice, carefully prepared series. Well done. > > > > It all looks good to me. I even went through each of the command > > conversions to verify that the parameter names in the implementation > > matched the names in the format and that optional parameters are handle= d > > correctly etc. I couldn't spot a single issue. > > Wow, thanks a lot Mark. > > > > > Acked-by: Mark McLoughlin > > > > Cheers, > > Mark. > > > > > > > > ------------------------------ > > Message: 4 > Date: Thu, 3 Sep 2009 19:12:23 -0300 > From: Luiz Capitulino > Subject: Re: [Qemu-devel] [RFC 0/5] Monitor handlers convertion to > QObject > To: Gerd Hoffmann > Cc: qemu-devel@nongnu.org > Message-ID: <20090903191223.6544898b@doriath> > Content-Type: text/plain; charset=3DUS-ASCII > > On Thu, 03 Sep 2009 22:30:08 +0200 > Gerd Hoffmann wrote: > > > Hi, > > > > > Some people have suggested us to define errors codes, but I dislike > this > > > because I have the impression we will end up defining errors > per-handlers, > > > which is a lot of work and more protocol definitions to maintain. > > > > What about error messages? > > Yes, I had error messages in mind. > > Handlers that handle errors today already print error messages, > this way the additional effort would be with the ones which don't > handle errors. > > However, my initial argument is not very strong. We already have > per-handlers errors today and will also have them with strings. > > > I've recently added some infrastructure for error messages: > > qemu_error() + friends. Intention is to direct error messages to the > > correct place, especially for code which can be called from multiple > > paths. Device creation for example can be triggered by command line > > (errors should go to stderr) or via hotplug monitor commands (errors > > should go to the monitor). > > > > You might want to add a third error sink which stuffs error messages > > into a Qstring, so you can pass them along as Qobject without the code > > emitting the error message knowing anything about it. > > Ok, I will review qemu_error() and consider your suggestion. > > > > > > Another issue in this subject is that sometimes we will have to do > > > a not so small refactor to get the proper error code. I mean, sometim= es > > > the functions which the handlers call return void, and those function= s > in > > > turn call other functions which also return void. This seem to be the > > > case of do_balloon(), for example. > > > > There are also a few places which call exit(1) on error. Which is ok > > when something goes wrong while creating the virtual machine, but not > > when some monitor command failed ... > > Right. > > > > > > A possible solution is to only return error when it's easy, otherwi= se > we > > > could always return 0 (which is what we have today), the problem thou= gh > > > is that changing this in the future will cause trouble. > > > > Serious code audit is more work initially, but I think we well be very > > happy we did it in the long run ... > > That's right. > > I'm doing my best to have the protocol working ASAP, but it's > unfortunate that sometimes the Right Thing takes more time. > > > > > ------------------------------ > > Message: 5 > Date: Thu, 3 Sep 2009 19:18:24 -0300 > From: Glauber Costa > Subject: [Qemu-devel] Re: [PATCH] qemu-kvm: fix segfault when running > kvm without /dev/kvm, falling back to non-accelerated mode > To: Dustin Kirkland > Cc: Mark McLoughlin , qemu-devel@nongnu.org, > kvm@vger.kernel.org > Message-ID: > <5d6222a80909031518h2bf804fbk1f7a52424d3e8649@mail.gmail.com> > Content-Type: text/plain; charset=3DUTF-8 > > On Thu, Sep 3, 2009 at 6:48 PM, Dustin Kirkland > wrote: > > On Thu, Sep 3, 2009 at 3:01 PM, Mark McLoughlin > wrote: > >> On Thu, 2009-09-03 at 12:31 -0500, Dustin Kirkland wrote: > >>> qemu-kvm: fix segfault when running kvm without /dev/kvm, falling bac= k > >>> to non-accelerated mode > >>> > >>> We're seeing segfaults on systems without access to /dev/kvm. It > >>> looks like the global kvm_allowed is being set just a little too late > >>> in vl.c. This patch moves the kvm initialization a bit higher in the > >>> vl.c main, just after options processing, and solves the segfaults. > >>> We're carrying this patch in Ubuntu 9.10 Alpha. Please apply > >>> upstream, or advise if and why this might not be the optimal solution= . > >> > >> Ah discussion about an alternative fix for this fizzled out recently: > >> > >> http://www.mail-archive.com/kvm@vger.kernel.org/msg19890.html > > > > Ah, thanks Mark. In that thread, I found Daniel's suggestion the most > > reasonable, and user-friendly: > > > > On Mon, Jul 27, 2009 at 1:44 PM, Daniel P. Berrange > wrote: > >> Well, we could go for logic like: > >> > >> * No arg given =3D> try kvm, try kqemu, try tcg > >> * --accelmode arg given =3D> try $arg, and fail if unavailable > >> > >> then libvirt would simply always supply --accelmode for all VMs, > >> while people running qemu manually would get best available > I sent some patches to do that, but they were incomplete, and I was > preempted by something else. > If you want, you can wait for my cycles to come back, or pick from where = I > left > > > > -- > Glauber Costa. > "Free as in Freedom" > http://glommer.net > > "The less confident you are, the more serious you have to act." > > > > > ------------------------------ > > Message: 6 > Date: Fri, 4 Sep 2009 12:14:02 +0800 > From: shawn du > Subject: [Qemu-devel] Why qemu-nbd so slow? > To: qemu-devel@nongnu.org > Message-ID: > <958448fc0909032114v21c354e1yd09a0a12880d305c@mail.gmail.com> > Content-Type: text/plain; charset=3D"iso-8859-1" > > Hi, > > I am using qemu-nbd to export a root disk image for kvm. The VM took very > long time to boot, can anyone identify why? > > Thanks, > Shawn > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.gnu.org/pipermail/qemu-devel/attachments/20090904/c2d58b8b/a= ttachment.html > > ------------------------------ > > Message: 7 > Date: Fri, 4 Sep 2009 07:33:25 +0300 > From: "Kirill A. Shutemov" > Subject: Re: [Qemu-devel] [PATCH v2] Build *-user targets as PIE > To: "Kirill A. Shutemov" , qemu-devel@nongnu.org > Message-ID: > > Content-Type: text/plain; charset=3DUTF-8 > > On Thu, Sep 3, 2009 at 8:17 PM, Reimar > D=F6ffinger wrote: > > On Thu, Sep 03, 2009 at 06:07:21PM +0300, Kirill A. Shutemov wrote: > >> On Thu, Sep 3, 2009 at 5:38 PM, Paul Brook > wrote: > >> >> PIE code usually is a bit slower. Approximately, 1% for i386 > according to > >> >> some tests. RISC architectures should be affected less, since they > have > >> >> more registers. On other hand we are getting rid from text > relocations on > >> >> i386 which make executable loading slower. So... > >> > > >> > I think you've got that backwards. > >> > A traditional (fixed address) executable requires no load-time > relocation for > >> > internal references because all addresses are known at static link > time. PIE > >> > require the dynamic linker adjust all absolute addresses. > >> > >> Usermode qemu on i386 is not a traditional executable, sicne it uses > >> -Wl,-shared for linking. In result we've got an executable which looks > >> like PIE, but dynamic linker have to resolve text relocations. I think > >> the best way it to create a true PIE without a text relocations. > > > > It is close to getting of topic, but since you state it, why try so har= d > > to avoid text relocations? > > Sure, there are advantages (the biggest one is less issues with > > mis-/insufficiently configured selinux I think), possibly better sharin= g > > of pages when many instances are run and better delayed loading, but on > > x86/i386 that doesn't sound like a clear advantage compared to the in > > some cases quite relevant speed loss. > > Do you have any numbers about speed loss? > > > Also, since this patch adds --disable-pie, isn't the hack currently use= d > > still necessary for that case? > > Or is --disable-pie supposed to disable self-hosting? Then maybe the > > option should be named --disable-self-hosting (and if that is indeed th= e > > only side-effect it might be better to disable it by default)? > > > > > > > ------------------------------ > > Message: 8 > Date: Thu, 3 Sep 2009 17:09:31 +0200 > From: "Bud P. Bruegger" > Subject: Re: [Qemu-devel] QEMU as a "virtual smart card"? > To: Blue Swirl > Cc: John, qemu-devel@nongnu.org, Forrester > Message-ID: <20090903170931.1e7d5772@bud-laptop> > Content-Type: text/plain; charset=3DUTF-8 > > On Wed, 2 Sep 2009 17:58:18 +0300 > Blue Swirl wrote: > > > On Wed, Sep 2, 2009 at 2:47 AM, Jamie Lokier > > wrote: > > > Bud P. Bruegger wrote: > > >> At least looking naively at QEMU, it seems that its CPU and RAM are > > >> well protected from the host operating system--in a way to say > > >> make it practically impossible for some malware to extract the > > >> secret key used in a virtual machine. > > > > > > No, the CPU and RAM state inside QEMU is easily read from the host. > > > Just run a debugger and attach to the running QEMU process. It's > > > not completely simple, but it's far from secure. > > > > For additional complexity, the CPU registers, memory, instruction set > > and I/O could be encrypted but there is still a problem: where to > > store the keys. The keys could be handled by another host process, > > which could also try to attest that no debugger is attached (at least > > on that level of virtualization). Performance would suck of course and > > the attestation process could be fooled. > > First of all thanks to everyone for the replies and advice. > > As for encryption of RAM and processor, wouldn't it be necessary to > decrypt things before using it and that would be visible to the > observer on the host machine? > > While surely not bullet proof and impossible to crack, I thought that > there may be other ways of rising the hurdle quite a bit. > > Assume that I wanted to protect a secret algorithm in some C program. > Normally this is compiled into the machine code of a certain processor > and there are standard tools (disassembler, debugger) that can be used > to figure out what the secret algorithm does. > > A virtual machine has a virtual processor. Assume now that I was to > shuffle around machine instructions both in the processor of the > virtual machine and in the back-end of my c-compiler. I imagine that > it would be possible to automate this process (some refactoring tool?) > and to do some random shuffling. > > At this point, I guess before looking at the code I'd have to create my > own tools (disassembler, debugger) before even starting to look at what > is happening. > > So maybe there would even be some more room to generate a "random > virtual processor" together with a "random C compiler". Kind of like > generating a key pair :-) > > That would still leave RAM unprotected, I guess... But maybe there > could be a way of adding some "random" RAM/CPU combination with enough > entropy.. > > do you think that is a valid idea? > > best cheers > -b > > > > > ------------------------------ > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > > End of Qemu-devel Digest, Vol 78, Issue 28 > ****************************************** > --0016e64b038ec8b1d10472bc0fe9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hello everybody

Am I already in the list now...?

2009/9/4 <qemu-devel-request@nongnu.org>
Send Qemu-devel mailing list submissions to
=A0 =A0 =A0 =A0qemu-devel@nongnu.= org

To subscribe or unsubscribe via the World Wide Web, visit
=A0 =A0 =A0 =A0http://lists.nongnu.org/mailman/listinfo/qemu-devel<= /a>
or, via email, send a message with subject or body 'help' to
=A0 =A0 =A0 =A0qemu-devel= -request@nongnu.org

You can reach the person managing the list at
=A0 =A0 =A0 =A0qemu-devel-o= wner@nongnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Qemu-devel digest..."


Today's Topics:

=A0 1. Re: [PATCH] qemu-kvm: fix segfault when running kvm =A0 =A0 =A0 wit= hout
=A0 =A0 =A0/dev/kvm, falling back to non-accelerated mode (Dustin Kirkland= )
=A0 2. Defaults for qdev properties inherited from bus
=A0 =A0 =A0(Markus Armbruster)
=A0 3. Re: [PATCH v3 00/29] QMonitor (Luiz Capitulino)
=A0 4. Re: [RFC 0/5] Monitor handlers convertion to QObject
=A0 =A0 =A0(Luiz Capitulino)
=A0 5. Re: [PATCH] qemu-kvm: fix segfault when running kvm =A0 =A0 =A0 wit= hout
=A0 =A0 =A0/dev/kvm, falling back to non-accelerated mode (Glauber Costa)<= br> =A0 6. Why qemu-nbd so slow? (shawn du)
=A0 7. Re: [PATCH v2] Build *-user targets as PIE (Kirill A. Shutemov)
=A0 8. Re: QEMU as a "virtual smart card"? (Bud P. Bruegger)


----------------------------------------------------------------------

Message: 1
Date: Thu, 3 Sep 2009 16:48:49 -0500
From: Dustin Kirkland <kirklan= d@canonical.com>
Subject: [Qemu-devel] Re: [PATCH] qemu-kvm: fix segfault when running
=A0 =A0 =A0 =A0kvm =A0 =A0 without /dev/kvm, falling back to non-accelerat= ed mode
To: Mark McLoughlin <markmc@redhat.= com>
Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
Message-ID:
=A0 =A0 =A0 =A0<d9c105ea0909031448v4d727c1cpaaa60d1e28820660@mail.g= mail.com>
Content-Type: text/plain; charset=3DISO-8859-1

On Thu, Sep 3, 2009 at 3:01 PM, Mark McLoughlin<markmc@redhat.com> wrote:
> On Thu, 2009-09-03 at 12:31 -0500, Dustin Kirkland wrote:
>> qemu-kvm: fix segfault when running kvm without /dev/kvm, falling = back
>> to non-accelerated mode
>>
>> We're seeing segfaults on systems without access to /dev/kvm. = =A0It
>> looks like the global kvm_allowed is being set just a little too l= ate
>> in vl.c. =A0This patch moves the kvm initialization a bit higher i= n the
>> vl.c main, just after options processing, and solves the segfaults= .
>> We're carrying this patch in Ubuntu 9.10 Alpha. =A0Please appl= y
>> upstream, or advise if and why this might not be the optimal solut= ion.
>
> Ah discussion about an alternative fix for this fizzled out recently:<= br> >
> =A0http://www.mail-archive.com/kvm@vger.kernel.org/ms= g19890.html

Ah, thanks Mark. =A0In that thread, I found Daniel's suggestion the mos= t
reasonable, and user-friendly:

On Mon, Jul 27, 2009 at 1:44 PM, Daniel P. Berrange<berrange@redhat.com> wrote:
> Well, we could go for logic like:
>
> =A0* No arg given =A0 =A0 =A0 =A0 =A0=3D> try kvm, try kqemu, try t= cg
> =A0* --accelmode arg given =3D> try $arg, and fail if unavailable >
> then libvirt would simply always supply --accelmode for all VMs,
> while people running qemu manually would get best available



:-Dustin




------------------------------

Message: 2
Date: Thu, 03 Sep 2009 23:49:50 +0200
From: Markus Armbruster <armbru@red= hat.com>
Subject: [Qemu-devel] Defaults for qdev properties inherited from bus
To: qemu-devel@nongnu.org
Message-ID: <873a73d= 7gh.fsf@pike.pond.sub.org>
Content-Type: text/plain; charset=3Dus-ascii

Devices inherit some properties from their bus. =A0For instance, ISA
devices inherit iobase, iobase2, and PCI devices inherit addr.

Properties have a default value. =A0For inherited properties, the same
default value has to do for all devices on the same kind of bus, because the default value is inherited from the bus along with the property.

This isn't always a problem. =A0For instance, PCI addr defaulting to &q= uot;pick
one" is exactly right for most devices. =A0Not so for the ISA iobases:=
devices have different default I/O addresses.

Note that isa_create_simple() mask this problem: it takes iobases as
arguments, and the property default value is not used. =A0The problem
becomes visible when devices are created with -device.

One way to deal with this is to code the true default values in the
device's init() callback: check whether the value is still the
inherited, unwanted default, and if yes, set it to the true default.
Like this:

=A0 =A0if (dev->iobase[0] =3D=3D -1)
=A0 =A0 =A0 =A0dev->iobase[0] =3D 0x441;
=A0 =A0if (dev->iobase[1] =3D=3D -1)
=A0 =A0 =A0 =A0dev->iobase[1] =3D 0x443;

Workable, if not exactly elegant.

A related problem is validation of property vales. =A0Devices may accept only a subset of the values the property inherited from the bus accepts. For instance, ISA devices can typically use only to a fixed set of I/O
addresses. =A0The bus's PropertyInfo doesn't know them, so this doe= sn't
get checked.

One way to deal with this is to validate in the device's init()
callback: fail it when the values aren't acceptable. =A0Like this:

=A0 =A0if (dev->iobase[0] !=3D 0x441 || dev->iobase[1] !=3D 0x443) =A0 =A0 =A0 =A0return -1;

Detects bad configuration relatively late. =A0Is this okay?




------------------------------

Message: 3
Date: Thu, 3 Sep 2009 19:00:40 -0300
From: Luiz Capitulino <lcapitu= lino@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 00/29] QMonitor
To: Mark McLoughlin <markmc@redhat.= com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, avi@redhat.com
Message-ID: <20090903190040.169e4dbe@doriath>
Content-Type: text/plain; charset=3DUS-ASCII

On Thu, 03 Sep 2009 22:06:52 +0100
Mark McLoughlin <markmc@redhat.com<= /a>> wrote:

> On Fri, 2009-08-28 at 15:27 -0300, Luiz Capitulino wrote:
> > =A0Basically, this series introduces high-level data types (QInt,= QString,
> > QDict) and port all Monitor command handlers to use them to recei= ve
> > arguments.
>
> Very nice, carefully prepared series. Well done.
>
> It all looks good to me. I even went through each of the command
> conversions to verify that the parameter names in the implementation > matched the names in the format and that optional parameters are handl= ed
> correctly etc. I couldn't spot a single issue.

=A0Wow, thanks a lot Mark.

>
> Acked-by: Mark McLoughlin <mar= kmc@redhat.com>
>
> Cheers,
> Mark.
>





------------------------------

Message: 4
Date: Thu, 3 Sep 2009 19:12:23 -0300
From: Luiz Capitulino <lcapitu= lino@redhat.com>
Subject: Re: [Qemu-devel] [RFC 0/5] Monitor handlers convertion to
=A0 =A0 =A0 =A0QObject
To: Gerd Hoffmann <kraxel@redhat.co= m>
Cc: qemu-devel@nongnu.org
Message-ID: <20090903191223.6544898b@doriath>
Content-Type: text/plain; charset=3DUS-ASCII

On Thu, 03 Sep 2009 22:30:08 +0200
Gerd Hoffmann <kraxel@redhat.com> wrote:

> =A0 =A0Hi,
>
> > =A0 Some people have suggested us to define errors codes, but I d= islike this
> > because I have the impression we will end up defining errors per-= handlers,
> > which is a lot of work and more protocol definitions to maintain.=
>
> What about error messages?

=A0Yes, I had error messages in mind.

=A0Handlers that handle errors today already print error messages,
this way the additional effort would be with the ones which don't
handle errors.

=A0However, my initial argument is not very strong. We already have
per-handlers errors today and will also have them with strings.

> I've recently added some infrastructure for error messages:
> qemu_error() + friends. =A0Intention is to direct error messages to th= e
> correct place, especially for code which can be called from multiple > paths. =A0Device creation for example can be triggered by command line=
> (errors should go to stderr) or via hotplug monitor commands (errors > should go to the monitor).
>
> You might want to add a third error sink which stuffs error messages > into a Qstring, so you can pass them along as Qobject without the code=
> emitting the error message knowing anything about it.

=A0Ok, I will review qemu_error() and consider your suggestion.

>
> > =A0 Another issue in this subject is that sometimes we will have = to do
> > a not so small refactor to get the proper error code. I mean, som= etimes
> > the functions which the handlers call return void, and those func= tions in
> > turn call other functions which also return void. This seem to be= the
> > case of do_balloon(), for example.
>
> There are also a few places which call exit(1) on error. =A0Which is o= k
> when something goes wrong while creating the virtual machine, but not<= br> > when some monitor command failed ...

=A0Right.

>
> > =A0 A possible solution is to only return error when it's eas= y, otherwise we
> > could always return 0 (which is what we have today), the problem = though
> > is that changing this in the future will cause trouble.
>
> Serious code audit is more work initially, but I think we well be very=
> happy we did it in the long run ...

=A0That's right.

=A0I'm doing my best to have the protocol working ASAP, but it's unfortunate that sometimes the Right Thing takes more time.




------------------------------

Message: 5
Date: Thu, 3 Sep 2009 19:18:24 -0300
From: Glauber Costa <glommer@gmail.= com>
Subject: [Qemu-devel] Re: [PATCH] qemu-kvm: fix segfault when running
=A0 =A0 =A0 =A0kvm =A0 =A0 without /dev/kvm, falling back to non-accelerat= ed mode
To: Dustin Kirkland <kirkland@= canonical.com>
Cc: Mark McLoughlin <markmc@redhat.= com>, qemu-devel@nongnu.org= ,
=A0 =A0 =A0 =A0kvm@vger.kernel.org<= /a>
Message-ID:
=A0 =A0 =A0 =A0<5d6222a80909031518h2bf804fbk1f7a52424d3e8649@mail.g= mail.com>
Content-Type: text/plain; charset=3DUTF-8

On Thu, Sep 3, 2009 at 6:48 PM, Dustin Kirkland<kirkland@canonical.com> wrote:
> On Thu, Sep 3, 2009 at 3:01 PM, Mark McLoughlin<markmc@redhat.com> wrote:
>> On Thu, 2009-09-03 at 12:31 -0500, Dustin Kirkland wrote:
>>> qemu-kvm: fix segfault when running kvm without /dev/kvm, fall= ing back
>>> to non-accelerated mode
>>>
>>> We're seeing segfaults on systems without access to /dev/k= vm. =A0It
>>> looks like the global kvm_allowed is being set just a little t= oo late
>>> in vl.c. =A0This patch moves the kvm initialization a bit high= er in the
>>> vl.c main, just after options processing, and solves the segfa= ults.
>>> We're carrying this patch in Ubuntu 9.10 Alpha. =A0Please = apply
>>> upstream, or advise if and why this might not be the optimal s= olution.
>>
>> Ah discussion about an alternative fix for this fizzled out recent= ly:
>>
>> =A0http://www.mail-archive.com/kvm@vger.kernel.or= g/msg19890.html
>
> Ah, thanks Mark. =A0In that thread, I found Daniel's suggestion th= e most
> reasonable, and user-friendly:
>
> On Mon, Jul 27, 2009 at 1:44 PM, Daniel P. Berrange<berrange@redhat.com> wrote:
>> Well, we could go for logic like:
>>
>> =A0* No arg given =A0 =A0 =A0 =A0 =A0=3D> try kvm, try kqemu, t= ry tcg
>> =A0* --accelmode arg given =3D> try $arg, and fail if unavailab= le
>>
>> then libvirt would simply always supply --accelmode for all VMs, >> while people running qemu manually would get best available
I sent some patches to do that, but they were incomplete, and I was
preempted by something else.
If you want, you can wait for my cycles to come back, or pick from where I = left



--
Glauber =A0Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."



------------------------------

Message: 6
Date: Fri, 4 Sep 2009 12:14:02 +0800
From: shawn du <yyangdu@gmail.com>
Subject: [Qemu-devel] Why qemu-nbd so slow?
To: qemu-devel@nongnu.org
Message-ID:
=A0 =A0 =A0 =A0<958448fc0909032114v21c354e1yd09a0a12880d305c@mail.g= mail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

Hi,

I am using qemu-nbd to export a root disk image for kvm. The VM took very long time to boot, can anyone identify why?

Thanks,
Shawn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.gnu.org/piperm= ail/qemu-devel/attachments/20090904/c2d58b8b/attachment.html

------------------------------

Message: 7
Date: Fri, 4 Sep 2009 07:33:25 +0300
From: "Kirill A. Shutemov" <kirill@shutemov.name>
Subject: Re: [Qemu-devel] [PATCH v2] Build *-user targets as PIE
To: "Kirill A. Shutemov" <kirill@shutemov.name>, = qemu-devel@nongnu.org
Message-ID:
=A0 =A0 =A0 =A0<cc557aab0909032133q48081343ye195857132585228@mail.g= mail.com>
Content-Type: text/plain; charset=3DUTF-8

On Thu, Sep 3, 2009 at 8:17 PM, Reimar
D=F6ffinger<Reimar.Doeffinge= r@gmx.de> wrote:
> On Thu, Sep 03, 2009 at 06:07:21PM +0300, Kirill A. Shutemov wrote: >> On Thu, Sep 3, 2009 at 5:38 PM, Paul Brook<paul@codesourcery.com> wrote:
>> >> PIE code usually is a bit slower. Approximately, 1% for i= 386 according to
>> >> some tests. RISC architectures should be affected less, s= ince they have
>> >> more registers. On other hand we are getting rid from tex= t relocations on
>> >> i386 which make executable loading slower. So...
>> >
>> > I think you've got that backwards.
>> > A traditional (fixed address) executable requires no load-tim= e relocation for
>> > internal references because all addresses are known at static= link time. PIE
>> > require the dynamic linker adjust all absolute addresses.
>>
>> Usermode qemu on i386 is not a traditional executable, sicne it us= es
>> -Wl,-shared for linking. In result we've got an executable whi= ch looks
>> like PIE, but dynamic linker have to resolve text relocations. I t= hink
>> the best way it to create a true PIE without a text relocations. >
> It is close to getting of topic, but since you state it, why try so ha= rd
> to avoid text relocations?
> Sure, there are advantages (the biggest one is less issues with
> mis-/insufficiently configured selinux I think), possibly better shari= ng
> of pages when many instances are run and better delayed loading, but o= n
> x86/i386 that doesn't sound like a clear advantage compared to the= in
> some cases quite relevant speed loss.

Do you have any numbers about speed loss?

> Also, since this patch adds --disable-pie, isn't the hack currentl= y used
> still necessary for that case?
> Or is --disable-pie supposed to disable self-hosting? Then maybe the > option should be named --disable-self-hosting (and if that is indeed t= he
> only side-effect it might be better to disable it by default)?
>




------------------------------

Message: 8
Date: Thu, 3 Sep 2009 17:09:31 +0200
From: "Bud P. Bruegger" <bruegger@ancitel.it>
Subject: Re: [Qemu-devel] QEMU as a "virtual smart card"?
To: Blue Swirl <blauwirbel@gmail= .com>
Cc: John, qemu-devel@nongnu.org, Forrester <forrester@ancitel.= it>
Message-ID: <20090903170931.1e7d5772@bud-laptop>
Content-Type: text/plain; charset=3DUTF-8

On Wed, 2 Sep 2009 17:58:18 +0300
Blue Swirl <blauwirbel@gmail.com= > wrote:

> On Wed, Sep 2, 2009 at 2:47 AM, Jamie Lokier<jamie@shareable.org>
> wrote:
> > Bud P. Bruegger wrote:
> >> At least looking naively at QEMU, it seems that its CPU and R= AM are
> >> well protected from the host operating system--in a way to sa= y
> >> make it practically impossible for some malware to extract th= e
> >> secret key used in a virtual machine.
> >
> > No, the CPU and RAM state inside QEMU is easily read from the hos= t.
> > Just run a debugger and attach to the running QEMU process. =A0It= 's
> > not completely simple, but it's far from secure.
>
> For additional complexity, the CPU registers, memory, instruction set<= br> > and I/O could be encrypted but there is still a problem: where to
> store the keys. The keys could be handled by another host process,
> which could also try to attest that no debugger is attached (at least<= br> > on that level of virtualization). Performance would suck of course and=
> the attestation process could be fooled.

First of all thanks to everyone for the replies and advice.

As for encryption of RAM and processor, wouldn't it be necessary to
decrypt things before using it and that would be visible to the
observer on the host machine?

While surely not bullet proof and impossible to crack, I thought that
there may be other ways of rising the hurdle quite a bit.

Assume that I wanted to protect a secret algorithm in some C program.
Normally this is compiled into the machine code of a certain processor
and there are standard tools (disassembler, debugger) that can be used
to figure out what the secret algorithm does.

A virtual machine has a virtual processor. =A0Assume now that I was to
shuffle around machine instructions both in the processor of the
virtual machine and in the back-end of my c-compiler. =A0I imagine that
it would be possible to automate this process (some refactoring tool?)
and to do some random shuffling.

At this point, I guess before looking at the code I'd have to create my=
own tools (disassembler, debugger) before even starting to look at what
is happening.

So maybe there would even be some more room to generate a "random
virtual processor" together with a "random C compiler". =A0K= ind of like
generating a key pair :-)

That would still leave RAM unprotected, I guess... =A0But maybe there
could be a way of adding some "random" RAM/CPU combination with e= nough
entropy..

do you think that is a valid idea?

best cheers
-b




------------------------------

_______________________________________________
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel


End of Qemu-devel Digest, Vol 78, Issue 28
******************************************

--0016e64b038ec8b1d10472bc0fe9--