From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38601 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P9Rcq-0005Xk-Ab for qemu-devel@nongnu.org; Fri, 22 Oct 2010 20:06:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P9Rco-00085n-Qn for qemu-devel@nongnu.org; Fri, 22 Oct 2010 20:06:20 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59205) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P9Rco-00085a-J1 for qemu-devel@nongnu.org; Fri, 22 Oct 2010 20:06:18 -0400 Date: Fri, 22 Oct 2010 17:06:13 -0700 From: Chris Wright Subject: Re: [Qemu-devel] KVM call minutes for Oct 19 Message-ID: <20101023000613.GM27794@x200.localdomain> References: <20101020131925.GH15143@redhat.com> <4CBEECE6.8030605@codemonkey.ws> <4CBF7154.2070304@redhat.com> <9DABD2D4-389E-4D05-8A4C-2DE1E20D3B5C@suse.de> <4CBFEF95.9060703@redhat.com> <4CC039DA.5090607@codemonkey.ws> <20101022172916.GF27794@x200.localdomain> <4CC1CC55.2040700@codemonkey.ws> <20101022182047.GH27794@x200.localdomain> <4CC1DDB0.5090403@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CC1DDB0.5090403@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Chris Wright , "kvm@vger.kernel.org" , "dlaor@redhat.com" , Alexander Graf , "qemu-devel@nongnu.org" , Paolo Bonzini * Anthony Liguori (anthony@codemonkey.ws) wrote: > On 10/22/2010 01:20 PM, Chris Wright wrote: > >I'm not sure about that. That same new shiny Fedora 21 QEMU has no idea > >what the right OS specific command to run in guest is. Granted, it's > >not likely that "reboot" or "shutdown -r now" are likely to change for > >Linux guests, do we assume cygwin for Windows guests? > > No, but I'll waive my hands and say that I'm sure Windows has some > appropriate mechanism to do the same thing (like PowerShell). OK (bleh), but it's still specific to the guest OS. > > Really seems to > >make more sense to have a stable ABI and negotiate version. > > I guess the point is: we can always teach QEMU about how to work > around older guests. We (usually) can't control the software that's > present on the guest itself. I don't understand why we'd work around an older guest if the host <-> guest interface is stable. Sure it can be extended, but old interfaces should keep on Just Working (TM). > The more logic we have in QEMU, the less we have to change the > software in the guest which means the more likely things will work. Maybe you're saying the advantage of injecting the raw commands into the guest is that a host rev will automagically give an old guest new functionality? > >Also, from the point of view of a cloud where a VM agent is awfully > >close to provider having backdoor into VM...a freeform vm_system() > >doesn't seem like it'd be real popular. > > This is the best (irrational) argument against this practice. > Obviously, there's no real security concern here, but the end-user > view may be troubling. Heh, cloud + security == irrational fear, basic axiom > That said, VMware has an interface for exactly this at least it's an > established practice. OK, what about other bits of API? I recall seeing things like cut'n paste, reboot, ballooning, time, few bits that spice would care about... Are you thinking that as well, or all in terms of read/write/exec? thanks, -chris