From: Don Slutz <dslutz@verizon.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>,
Jan Beulich <JBeulich@suse.com>, Tim Deegan <tim@xen.org>
Cc: Lars Kurth <lars.kurth@citrix.com>, Keir Fraser <keir@xen.org>,
Ian Campbell <ian.campbell@citrix.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
Don Slutz <dslutz@verizon.com>,
xen-devel <xen-devel@lists.xen.org>
Subject: Re: [RFC] When to use "domain creation flag" or "HVM param"?
Date: Tue, 24 Feb 2015 11:48:38 -0500 [thread overview]
Message-ID: <54ECAB66.7010802@terremark.com> (raw)
In-Reply-To: <54EC5760.1000807@citrix.com>
On 02/24/15 05:50, Andrew Cooper wrote:
> On 24/02/15 10:31, Jan Beulich wrote:
>>>>> On 24.02.15 at 11:24, <tim@xen.org> wrote:
>>> At 15:08 -0500 on 23 Feb (1424700515), Don Slutz wrote:
>>>> Currently Jan Beulich is not happy with the addition of a new domain
>>>> creation flag. Andrew Cooper is not happy with a HVM param. I am stuck
>>>> in the middle.
> The vmware backdoor is however slightly more complicated, in that it
> also involves qemu. What would be the effects be for a domain where Xen
> believes the backdoor is active, but qemu is not running appropriately?
>
Right now for a QEMU that does not support vmport=on as a machine
property, QEMU will terminate and the domain will not be created.
If QEMU is started without this and Xen then activates the backdoor,
QEMU will act like any other unsupported ioport access. This does mean
that you will lose the use of a mouse under current Xorg GUI.
I have not tried to hot-plug the vmport and vmmouse devices in QEMU.
That may take some changes to work.
-Don Slutz
> ~Andrew
>
next prev parent reply other threads:[~2015-02-24 16:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-23 20:08 [RFC] When to use "domain creation flag" or "HVM param"? Don Slutz
2015-02-24 10:24 ` Tim Deegan
2015-02-24 10:31 ` Jan Beulich
2015-02-24 10:43 ` Tim Deegan
2015-02-24 10:50 ` Andrew Cooper
2015-02-24 16:48 ` Don Slutz [this message]
2015-02-26 10:52 ` Tim Deegan
2015-02-26 11:09 ` Lars Kurth
2015-02-26 15:33 ` Julien Grall
2015-02-26 15:43 ` Tim Deegan
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=54ECAB66.7010802@terremark.com \
--to=dslutz@verizon.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=keir@xen.org \
--cc=lars.kurth@citrix.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.