From: Fabrice Bellard <fabrice@bellard.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: Host <-> guest interface port?
Date: Wed, 05 May 2004 20:31:09 +0200 [thread overview]
Message-ID: <409932ED.10409@bellard.org> (raw)
In-Reply-To: <409827F1.7050209@aclaro.com>
I would prefer a network based solution first. Changing the interface to
use a CPU specific hack won't be difficult in the future.
Fabrice.
Matthew Mastracci wrote:
> Fabrice Bellard wrote:
>
>> Matthew Mastracci wrote:
>>
>>> Would it be possible to add a host/guest interface port, akin to how
>>> VMWare handles this? It's a convenient way to get/set various
>>> properties from the host while running the guest operating system.
>>> This also allows a smoother mouse interface - ie: auto
>>> capture/release of the mouse as it hits the screen boundaries,
>>> clipboard synchronization as well as synchronization of the guest's
>>> clock with the host's.
>>>
>>> Some more info on the VMWare port is here:
>>> http://chitchat.at.infoseek.co.jp/vmware/backdoor.html
>>
>>
>>
>> Of course it is possible to add that, but first we must define the
>> features we want and implement the necessary support in the guest
>> OSes, which seems to be the most difficult AFAIK. Clipboard support
>> would be interesting. Does anyone know how to implement it for Linux
>> and Windows guests ?
>>
> I can implement text-clipboard-passing for a windows guest without much
> effort. If the CPU protection for the IO port is disabled, even when
> running at IOPL3, it could be implemented entirely in userspace.
>
> It would be nice to define standard register values for the different
> features, as well as add functionality to query the availability of the
> feature. For instance, the first two registers could define the
> supported interface:
>
> Register 0: Returns the maximum supported register index by the current
> version of QEMU
> Register 1: Write to the register with a given register index - returns
> 1 if supported or 0 if unsupported or disabled.
>
> Possible register functionality (off the top of my head):
> - Get host clock: returns the host clock time in UTC (useful for clock
> sync between guest/host)
> - Get host clock TZ: returns the host clock offset relative to UTC
> - Set host's clipboard
> - Get host's clipboard
> - Attach/detach virtual device (floppy/cd/etc)
> - Transfer file (?)
> - Read guest filesystem
next prev parent reply other threads:[~2004-05-05 18:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-04 16:16 [Qemu-devel] Host <-> guest interface port? Matthew Mastracci
2004-05-04 22:12 ` Fabrice Bellard
2004-05-04 22:46 ` Michael L Torrie
2004-05-04 23:32 ` [Qemu-devel] " Matthew Mastracci
2004-05-05 18:31 ` Fabrice Bellard [this message]
2004-05-05 2:58 ` [Qemu-devel] " Jim C. Brown
2004-05-05 15:17 ` [Qemu-devel] " Matthew Mastracci
2004-05-06 21:48 ` Jim C. Brown
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=409932ED.10409@bellard.org \
--to=fabrice@bellard.org \
--cc=qemu-devel@nongnu.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 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).