[Qemu-devel] Re: Help

[周雄 <jencce2002@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 18387 bytes --]

hello everybody

Am I already in the list now...?

2009/9/4 <qemu-devel-request@nongnu.org>

> 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 <kirkland@canonical.com>
> Subject: [Qemu-devel] Re: [PATCH] qemu-kvm: fix segfault when running
>        kvm     without /dev/kvm, falling back to non-accelerated mode
> To: Mark McLoughlin <markmc@redhat.com>
> Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org
> Message-ID:
>        <d9c105ea0909031448v4d727c1cpaaa60d1e28820660@mail.gmail.com>
> Content-Type: text/plain; charset=ISO-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.  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<berrange@redhat.com>
> wrote:
> > Well, we could go for logic like:
> >
> >  * No arg given          => try kvm, try kqemu, try tcg
> >  * --accelmode arg given => 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@redhat.com>
> 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=us-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] == -1)
>        dev->iobase[0] = 0x441;
>    if (dev->iobase[1] == -1)
>        dev->iobase[1] = 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] != 0x441 || dev->iobase[1] != 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 <lcapitulino@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=US-ASCII
>
> On Thu, 03 Sep 2009 22:06:52 +0100
> Mark McLoughlin <markmc@redhat.com> 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 handled
> > correctly etc. I couldn't spot a single issue.
>
>  Wow, thanks a lot Mark.
>
> >
> > Acked-by: Mark McLoughlin <markmc@redhat.com>
> >
> > Cheers,
> > Mark.
> >
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 3 Sep 2009 19:12:23 -0300
> From: Luiz Capitulino <lcapitulino@redhat.com>
> Subject: Re: [Qemu-devel] [RFC 0/5] Monitor handlers convertion to
>        QObject
> To: Gerd Hoffmann <kraxel@redhat.com>
> Cc: qemu-devel@nongnu.org
> Message-ID: <20090903191223.6544898b@doriath>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 03 Sep 2009 22:30:08 +0200
> Gerd Hoffmann <kraxel@redhat.com> 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, sometimes
> > > the functions which the handlers call return void, and those functions
> 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, 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 ...
>
>  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 <glommer@gmail.com>
> Subject: [Qemu-devel] Re: [PATCH] qemu-kvm: fix segfault when running
>        kvm     without /dev/kvm, falling back to non-accelerated mode
> To: Dustin Kirkland <kirkland@canonical.com>
> Cc: Mark McLoughlin <markmc@redhat.com>, qemu-devel@nongnu.org,
>        kvm@vger.kernel.org
> Message-ID:
>        <5d6222a80909031518h2bf804fbk1f7a52424d3e8649@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-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, 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<berrange@redhat.com>
> wrote:
> >> Well, we could go for logic like:
> >>
> >>  * No arg given          => try kvm, try kqemu, try tcg
> >>  * --accelmode arg given => 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 <yyangdu@gmail.com>
> Subject: [Qemu-devel] Why qemu-nbd so slow?
> To: qemu-devel@nongnu.org
> Message-ID:
>        <958448fc0909032114v21c354e1yd09a0a12880d305c@mail.gmail.com>
> Content-Type: text/plain; charset="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/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:
>        <cc557aab0909032133q48081343ye195857132585228@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Sep 3, 2009 at 8:17 PM, Reimar
> Döffinger<Reimar.Doeffinger@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 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 hard
> > to avoid text relocations?
> > Sure, there are advantages (the biggest one is less issues with
> > mis-/insufficiently configured selinux I think), possibly better sharing
> > 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 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 the
> > 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=UTF-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 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
> ******************************************
>

[-- Attachment #2: Type: text/html, Size: 23612 bytes --]