qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Kevin Wolf <kwolf@redhat.com>
Cc: aliguori@us.ibm.com, Corey Bryant <bryntcor@us.ibm.com>,
	Markus Armbruster <armbru@redhat.com>,
	qemu-devel@nongnu.org, Blue Swirl <blauwirbel@gmail.com>,
	Tyler C Hicks <tchicks@us.ibm.com>
Subject: Re: [Qemu-devel] [PATCH] Add support for fd: protocol
Date: Mon, 23 May 2011 16:55:13 -0500	[thread overview]
Message-ID: <4DDAD7C1.80708@codemonkey.ws> (raw)
In-Reply-To: <4DDA83C2.5060104@redhat.com>

On 05/23/2011 10:56 AM, Kevin Wolf wrote:
> Am 23.05.2011 17:24, schrieb Markus Armbruster:
>> Kevin Wolf<kwolf@redhat.com>  writes:
>>
>> An fd: protocol can't easily support reopen.  So fail it.  This doesn't
>> break any existing usage.  It's just a restriction on the new protocol.
>> Restrictions can render the new protocol useless in practice, but we're
>> not "breaking qemu without libvirt" there.
>>
>> Perhaps we can make relax the restriction on some system by avoiding the
>> reopen in a system-dependent way.
>
> Right, you only get the regression once libvirt starts using it (or even
> worse, qemu itself, like Blue Swirl suggested). Doesn't make it much better.

libvirt already has the problem you describe.  QEMU is designed assuming 
that we can access whatever resources the invoking user can.  That's how 
our UI is constructed.

But libvirt chooses to invoke QEMU in such a way that the actual QEMU 
process does not have the same rights as the invoking user.  In fact, 
the context is entirely different.

That means that to get isolation, libvirt has to understand what QEMU 
does for each operation and then do some magic behind the scenes to make 
it all work.

This is not different really.  'commit' could require magic in libvirt 
anyway if libvirt was smart enough to mark the backing file with 
read-only rights.

libvirt already has to parse image file formats to figure out backing 
files so it can set the permissions right.

Regards,

Anthony Liguori


> Kevin
>

  parent reply	other threads:[~2011-05-23 21:55 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-20 18:48 [Qemu-devel] [PATCH] Add support for fd: protocol Corey Bryant
2011-05-20 19:05 ` Anthony Liguori
2011-05-20 19:25 ` Blue Swirl
2011-05-20 19:42   ` Anthony Liguori
2011-05-20 19:53     ` Blue Swirl
2011-05-23 14:28       ` Kevin Wolf
2011-05-23 15:24         ` Markus Armbruster
2011-05-23 15:56           ` Kevin Wolf
2011-05-23 19:50             ` Blue Swirl
2011-05-23 21:55             ` Anthony Liguori [this message]
2011-05-23 18:20           ` Corey Bryant
2011-05-23  9:45 ` Daniel P. Berrange
2011-05-23 10:19   ` Stefan Hajnoczi
2011-05-23 10:30     ` Daniel P. Berrange
2011-05-23 12:59       ` Anthony Liguori
2011-05-23 14:35         ` Markus Armbruster
2011-05-23 22:49           ` Jamie Lokier
2011-05-24  8:39             ` Stefan Hajnoczi
2011-05-24 15:31               ` Jamie Lokier
2011-05-23 12:50   ` Anthony Liguori
2011-05-23 13:06     ` Daniel P. Berrange
2011-05-23 13:09     ` Stefan Hajnoczi
2011-05-23 13:21       ` Anthony Liguori
2011-05-23 13:26         ` Stefan Hajnoczi
2011-05-23 13:42           ` Daniel P. Berrange
2011-05-23  9:48 ` Daniel P. Berrange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4DDAD7C1.80708@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=aliguori@us.ibm.com \
    --cc=armbru@redhat.com \
    --cc=blauwirbel@gmail.com \
    --cc=bryntcor@us.ibm.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=tchicks@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).