[Qemu-devel] Re: Help

2009/9/4 <address@hidden>

Send Qemu-devel mailing list submissions to
address@hidden

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
address@hidden

You can reach the person managing the list at
address@hidden

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 <address@hidden>
Subject: [Qemu-devel] Re: [PATCH] qemu-kvm: fix segfault when running
kvm without /dev/kvm, falling back to non-accelerated mode
To: Mark McLoughlin <address@hidden>
Cc: address@hidden, address@hidden
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Sep 3, 2009 at 3:01 PM, Mark McLoughlin<address@hidden> 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/address@hidden/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<address@hidden> 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 <address@hidden>
Subject: [Qemu-devel] Defaults for qdev properties inherited from bus
To: address@hidden
Message-ID: <address@hidden>
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 <address@hidden>
Subject: Re: [Qemu-devel] [PATCH v3 00/29] QMonitor
To: Mark McLoughlin <address@hidden>
Cc: address@hidden, address@hidden, address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=US-ASCII

On Thu, 03 Sep 2009 22:06:52 +0100
Mark McLoughlin <address@hidden> 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 <address@hidden>
>
> Cheers,
> Mark.
>

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

Message: 4
Date: Thu, 3 Sep 2009 19:12:23 -0300
From: Luiz Capitulino <address@hidden>
Subject: Re: [Qemu-devel] [RFC 0/5] Monitor handlers convertion to
QObject
To: Gerd Hoffmann <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=US-ASCII

On Thu, 03 Sep 2009 22:30:08 +0200
Gerd Hoffmann <address@hidden> 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 <address@hidden>
Subject: [Qemu-devel] Re: [PATCH] qemu-kvm: fix segfault when running
kvm without /dev/kvm, falling back to non-accelerated mode
To: Dustin Kirkland <address@hidden>
Cc: Mark McLoughlin <address@hidden>, address@hidden,
address@hidden
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=UTF-8

On Thu, Sep 3, 2009 at 6:48 PM, Dustin Kirkland<address@hidden> wrote:
> On Thu, Sep 3, 2009 at 3:01 PM, Mark McLoughlin<address@hidden> 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/address@hidden/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<address@hidden> 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 <address@hidden>
Subject: [Qemu-devel] Why qemu-nbd so slow?
To: address@hidden
Message-ID:
<address@hidden>
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" <address@hidden>
Subject: Re: [Qemu-devel] [PATCH v2] Build *-user targets as PIE
To: "Kirill A. Shutemov" <address@hidden>, address@hidden
Message-ID:
<address@hidden>
Content-Type: text/plain; charset=UTF-8

On Thu, Sep 3, 2009 at 8:17 PM, Reimar
Döffinger<address@hidden> 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<address@hidden> 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" <address@hidden>
Subject: Re: [Qemu-devel] QEMU as a "virtual smart card"?
To: Blue Swirl <address@hidden>
Cc: John, address@hidden, Forrester <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain; charset=UTF-8

On Wed, 2 Sep 2009 17:58:18 +0300
Blue Swirl <address@hidden> wrote:

> On Wed, Sep 2, 2009 at 2:47 AM, Jamie Lokier<address@hidden>
> 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
address@hidden
http://lists.nongnu.org/mailman/listinfo/qemu-devel

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

From:	周雄
Subject:	[Qemu-devel] Re: Help
Date:	Fri, 4 Sep 2009 16:12:30 +0800