* Xen 4.0 Feature Requests
@ 2009-04-21 14:17 Stephen Spector
2009-04-21 14:53 ` R: " Francesco Gallo
` (5 more replies)
0 siblings, 6 replies; 36+ messages in thread
From: Stephen Spector @ 2009-04-21 14:17 UTC (permalink / raw)
To: xen-users, 'xen-devel@lists.xensource.com'
[-- Attachment #1.1: Type: text/plain, Size: 480 bytes --]
With Xen 3.4 in test for final release shortly, it is time to submit your feature requests for the next release, Xen 4.0. The current product roadmap is at http://www.xen.org/download/roadmap.html and will be updated with the new features you submit once Xen 3.4 is released.
Please send me your features. Thanks.
Stephen Spector
Community Manager, Xen.org
stephen.spector@xen.org
(772) 621-5062
Blog: http://blog.xen.org
Twitter: http://www.twitter.com/xen_com_mgr
[-- Attachment #1.2: Type: text/html, Size: 5099 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* R: Xen 4.0 Feature Requests
2009-04-21 14:17 Xen 4.0 Feature Requests Stephen Spector
@ 2009-04-21 14:53 ` Francesco Gallo
2009-04-22 14:51 ` Kashif Ali
2009-04-21 16:48 ` Tim Moore
` (4 subsequent siblings)
5 siblings, 1 reply; 36+ messages in thread
From: Francesco Gallo @ 2009-04-21 14:53 UTC (permalink / raw)
To: 'Stephen Spector', xen-users, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 930 bytes --]
I would like to have dynamic memory mangement for overcommitting RAM (like
vmware
).
Thanks and regards,
Francesco Gallo
Da: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] Per conto di Stephen Spector
Inviato: martedì 21 aprile 2009 16.17
A: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com'
Oggetto: [Xen-users] Xen 4.0 Feature Requests
With Xen 3.4 in test for final release shortly, it is time to submit your
feature requests for the next release, Xen 4.0. The current product roadmap
is at http://www.xen.org/download/roadmap.html and will be updated with the
new features you submit once Xen 3.4 is released.
Please send me your features. Thanks.
Stephen Spector
Community Manager, Xen.org
stephen.spector@xen.org
(772) 621-5062
Blog: http://blog.xen.org
Twitter: http://www.twitter.com/xen_com_mgr
[-- Attachment #1.2: Type: text/html, Size: 6625 bytes --]
[-- Attachment #2: Type: text/plain, Size: 137 bytes --]
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: Xen 4.0 Feature Requests
2009-04-21 14:17 Xen 4.0 Feature Requests Stephen Spector
2009-04-21 14:53 ` R: " Francesco Gallo
@ 2009-04-21 16:48 ` Tim Moore
2009-04-21 17:37 ` Paul Schulze
` (2 more replies)
2009-04-21 18:43 ` Pasi Kärkkäinen
` (3 subsequent siblings)
5 siblings, 3 replies; 36+ messages in thread
From: Tim Moore @ 2009-04-21 16:48 UTC (permalink / raw)
To: 'Stephen Spector',
xen-users, 'xen-devel@lists.xensource.com'
[-- Attachment #1.1: Type: text/plain, Size: 964 bytes --]
1. PCI VGA Passthrough for VT-d
Support for everyday vendor cards from Nvidia primarily, then ATI and others .... (I know there is already limited support for Intel)
Thanks!
________________________________
From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Stephen Spector
Sent: 21 April 2009 15:17
To: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com'
Subject: [Xen-devel] Xen 4.0 Feature Requests
With Xen 3.4 in test for final release shortly, it is time to submit your feature requests for the next release, Xen 4.0. The current product roadmap is at http://www.xen.org/download/roadmap.html and will be updated with the new features you submit once Xen 3.4 is released.
Please send me your features. Thanks.
Stephen Spector
Community Manager, Xen.org
stephen.spector@xen.org
(772) 621-5062
Blog: http://blog.xen.org
Twitter: http://www.twitter.com/xen_com_mgr
[-- Attachment #1.2: Type: text/html, Size: 8664 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: RE: Xen 4.0 Feature Requests
2009-04-21 16:48 ` Tim Moore
@ 2009-04-21 17:37 ` Paul Schulze
2009-04-21 19:13 ` Jean Guyader
2009-04-22 1:08 ` Dirk Utterback
2 siblings, 0 replies; 36+ messages in thread
From: Paul Schulze @ 2009-04-21 17:37 UTC (permalink / raw)
To: Tim Moore
Cc: 'xen-devel@lists.xensource.com',
'Stephen Spector',
xen-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 21 Apr 2009, at 18:48, Tim Moore wrote:
> 1. PCI VGA Passthrough for VT-d
> Support for everyday vendor cards from Nvidia primarily, then
> ATI and others …. (I know there is already limited support for Intel)
>
> Thanks!
I second that, although with the fact, that ATI specs are open, the
first more or less proof of concept attempts might be easier to do for
ATI graphics cards.
Also (and not knowing, how far the work has gone on the subject), I
would like to add "Full AMD IOMMU support (at least at the same level
as VT-d)" to the list. Stone me, if thats already the case :) .
Thanks,
Paul.
- --
Paul Schulze
Mail: avlex82@gmail.com
Why can't a programmer tell the difference between Halloween and
Christmas?
Because OCT31 = DEC25.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
iEYEARECAAYFAknuBE8ACgkQj2zIQLJNnKPTdwCcCF20q2g7w3Klk46p9DVmvwa7
clEAoPiviHd1NCfJyrPlXVq+eaHl10A2
=1ItS
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests
2009-04-21 14:17 Xen 4.0 Feature Requests Stephen Spector
2009-04-21 14:53 ` R: " Francesco Gallo
2009-04-21 16:48 ` Tim Moore
@ 2009-04-21 18:43 ` Pasi Kärkkäinen
2009-04-21 20:03 ` Andy Burns
2009-04-22 0:31 ` Philipp Schmid
` (2 subsequent siblings)
5 siblings, 1 reply; 36+ messages in thread
From: Pasi Kärkkäinen @ 2009-04-21 18:43 UTC (permalink / raw)
To: Stephen Spector; +Cc: 'xen-devel@lists.xensource.com', xen-users
On Tue, Apr 21, 2009 at 10:17:04AM -0400, Stephen Spector wrote:
> With Xen 3.4 in test for final release shortly, it is time to submit your feature requests for the next release, Xen 4.0. The current product roadmap is at http://www.xen.org/download/roadmap.html and will be updated with the new features you submit once Xen 3.4 is released.
>
> Please send me your features. Thanks.
>
Online resizing of domU disks.
Earlier discussion about the subject:
http://lists.xensource.com/archives/html/xen-devel/2008-09/msg00158.html
http://lists.xensource.com/archives/html/xen-users/2008-04/msg00246.html
Upstream Linux kernel 2.6.28 supports online resizing of SCSI disks. Also
RHEL 5.3 (and CentOS 5.3) supports online resizing of SCSI disks.
Should I write more detailed description of this feature request?
-- Pasi
> Stephen Spector
> Community Manager, Xen.org
> stephen.spector@xen.org
> (772) 621-5062
> Blog: http://blog.xen.org
> Twitter: http://www.twitter.com/xen_com_mgr
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: RE: Xen 4.0 Feature Requests
2009-04-21 16:48 ` Tim Moore
2009-04-21 17:37 ` Paul Schulze
@ 2009-04-21 19:13 ` Jean Guyader
2009-04-22 1:08 ` Dirk Utterback
2 siblings, 0 replies; 36+ messages in thread
From: Jean Guyader @ 2009-04-21 19:13 UTC (permalink / raw)
To: Tim Moore; +Cc: xen-devel, Stephen Spector, xen-users
2009/4/21 Tim Moore <timothy.moore@expidas.net>:
> 1. PCI VGA Passthrough for VT-d
>
> Support for everyday vendor cards from Nvidia primarily, then ATI and
> others …. (I know there is already limited support for Intel)
>
I don't thing that something we can put into a roadmap.
Most of the issue we have can most of the time only be solve with new
driver or new firmware.
However we could commit to put the workaround we currently have in XCI into xen.
Thanks,
Jean
>
>
> ________________________________
>
> From: xen-devel-bounces@lists.xensource.com
> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Stephen Spector
> Sent: 21 April 2009 15:17
> To: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com'
> Subject: [Xen-devel] Xen 4.0 Feature Requests
>
>
>
> With Xen 3.4 in test for final release shortly, it is time to submit your
> feature requests for the next release, Xen 4.0. The current product roadmap
> is at http://www.xen.org/download/roadmap.html and will be updated with the
> new features you submit once Xen 3.4 is released.
>
>
>
> Please send me your features. Thanks.
>
>
>
> Stephen Spector
>
> Community Manager, Xen.org
>
> stephen.spector@xen.org
>
> (772) 621-5062
>
> Blog: http://blog.xen.org
>
> Twitter: http://www.twitter.com/xen_com_mgr
>
>
>
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests
2009-04-21 18:43 ` Pasi Kärkkäinen
@ 2009-04-21 20:03 ` Andy Burns
2009-04-21 20:10 ` Maximilian Wilhelm
0 siblings, 1 reply; 36+ messages in thread
From: Andy Burns @ 2009-04-21 20:03 UTC (permalink / raw)
To: xen-devel
2009/4/21 Pasi Kärkkäinen <pasik@iki.fi>:
> Online resizing of domU disks.
+1
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests
2009-04-21 20:03 ` Andy Burns
@ 2009-04-21 20:10 ` Maximilian Wilhelm
0 siblings, 0 replies; 36+ messages in thread
From: Maximilian Wilhelm @ 2009-04-21 20:10 UTC (permalink / raw)
To: xen-devel
Anno domini 2009 Andy Burns scripsit:
> 2009/4/21 Pasi Kärkkäinen <pasik@iki.fi>:
>
> > Online resizing of domU disks.
> +1
Add me ;)
Ciao
Max
--
Follow the white penguin.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests
2009-04-21 14:17 Xen 4.0 Feature Requests Stephen Spector
` (2 preceding siblings ...)
2009-04-21 18:43 ` Pasi Kärkkäinen
@ 2009-04-22 0:31 ` Philipp Schmid
2009-04-22 1:24 ` Akio Takebe
2009-04-22 16:14 ` [Xen-devel] " Thiago Camargo Martins Cordeiro
2009-05-03 18:27 ` Sander Eikelenboom
5 siblings, 1 reply; 36+ messages in thread
From: Philipp Schmid @ 2009-04-22 0:31 UTC (permalink / raw)
To: xen-users, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1191 bytes --]
Hi,
I would like to have a way to easily limit I/O for individual disks of
virtual machines (pv, hvm and hvm-studom).
Maybe in a similar way to the credit scheduler's weight?
You can already partition CPU-Time, RAM, Disk space, but not really
Disk I/O...
William Pitcock seems to do some work on a I/O QoS token-based
approach, maybe this is a good start?
Best regards,
Philipp Schmid
+43 699 17246437
http://netmonic.com
http://blog.netmonic.com
http://twitter.com/netmonic
On Apr 21, 2009, at 4:17 PM, Stephen Spector wrote:
> With Xen 3.4 in test for final release shortly, it is time to submit
> your feature requests for the next release, Xen 4.0. The current
> product roadmap is athttp://www.xen.org/download/roadmap.html and
> will be updated with the new features you submit once Xen 3.4 is
> released.
>
> Please send me your features. Thanks.
>
> Stephen Spector
> Community Manager, Xen.org
> stephen.spector@xen.org
> (772) 621-5062
> Blog: http://blog.xen.org
> Twitter: http://www.twitter.com/xen_com_mgr
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
[-- Attachment #1.2: Type: text/html, Size: 6779 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: RE: Xen 4.0 Feature Requests
2009-04-21 16:48 ` Tim Moore
2009-04-21 17:37 ` Paul Schulze
2009-04-21 19:13 ` Jean Guyader
@ 2009-04-22 1:08 ` Dirk Utterback
2009-04-22 1:14 ` Samuel Thibault
2 siblings, 1 reply; 36+ messages in thread
From: Dirk Utterback @ 2009-04-22 1:08 UTC (permalink / raw)
To: Tim Moore; +Cc: xen-devel, Stephen Spector, xen-users
[-- Attachment #1.1: Type: text/plain, Size: 1440 bytes --]
It would be very nice if PCI passthrough for all VT machines (not just for
VT-d boxes) is available.
Thanks,
Dirk
On Tue, Apr 21, 2009 at 9:48 AM, Tim Moore <timothy.moore@expidas.net>wrote:
> 1. PCI VGA Passthrough for VT-d
>
> Support for everyday vendor cards from Nvidia primarily, then ATI and
> others …. (I know there is already limited support for Intel)
>
>
>
> Thanks!
>
>
> ------------------------------
>
> *From:* xen-devel-bounces@lists.xensource.com [mailto:
> xen-devel-bounces@lists.xensource.com] *On Behalf Of *Stephen Spector
> *Sent:* 21 April 2009 15:17
> *To:* xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com'
> *Subject:* [Xen-devel] Xen 4.0 Feature Requests
>
>
>
> With Xen 3.4 in test for final release shortly, it is time to submit your
> feature requests for the next release, Xen 4.0. The current product roadmap
> is at http://www.xen.org/download/roadmap.html and will be updated with
> the new features you submit once Xen 3.4 is released.
>
>
>
> Please send me your features. Thanks.
>
>
>
> Stephen Spector
>
> Community Manager, Xen.org
>
> stephen.spector@xen.org
>
> (772) 621-5062
>
> Blog: http://blog.xen.org
>
> Twitter: http://www.twitter.com/xen_com_mgr
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
[-- Attachment #1.2: Type: text/html, Size: 5028 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: RE: Xen 4.0 Feature Requests
2009-04-22 1:08 ` Dirk Utterback
@ 2009-04-22 1:14 ` Samuel Thibault
2009-04-22 8:08 ` Dirk Utterback
0 siblings, 1 reply; 36+ messages in thread
From: Samuel Thibault @ 2009-04-22 1:14 UTC (permalink / raw)
To: Dirk Utterback; +Cc: xen-devel, Tim Moore, Stephen Spector, xen-users
Dirk Utterback, le Tue 21 Apr 2009 18:08:41 -0700, a écrit :
> It would be very nice if PCI passthrough for all VT machines (not just for
> VT-d boxes) is available.
Unsafe PCI passthrough is available. Safe PCI passthrough just can not
happen without VT-d.
Samuel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests
2009-04-22 0:31 ` Philipp Schmid
@ 2009-04-22 1:24 ` Akio Takebe
2009-04-22 1:32 ` TSC virtualization across different host frequency platform migration Dong, Eddie
2009-04-22 1:57 ` Xen 4.0 Feature Requests Ryo Tsuruta
0 siblings, 2 replies; 36+ messages in thread
From: Akio Takebe @ 2009-04-22 1:24 UTC (permalink / raw)
To: Philipp Schmid; +Cc: Ryo Tsuruta, xen-devel, xen-users
Hi,
There are some discussions of I/O QoS feature in upstream of linux.
We may be able to use such a feature with dom0 pv_ops of upstreams.
e.g.
http://lkml.indiana.edu/hypermail/linux/kernel/0904.2/01317.html
dm-ioband has rpm package of RHEL/CentOS, so you can use dm-ioband for xen.
http://lists.xensource.com/archives/html/xen-devel/2009-04/msg00116.html
If you are interested in dm-ioband, please comment to Ryo.
He would want feedbacks from many users.
Best Regards,
Akio Takebe
Philipp Schmid wrote:
> Hi,
>
> I would like to have a way to easily limit I/O for individual disks of
> virtual machines (pv, hvm and hvm-studom).
> Maybe in a similar way to the credit scheduler's weight?
>
> You can already partition CPU-Time, RAM, Disk space, but not really Disk
> I/O...
>
> William Pitcock seems to do some work on a I/O QoS token-based approach,
> maybe this is a good start?
>
> Best regards,
>
> Philipp Schmid
> +43 699 17246437
>
> http://netmonic.com
> http://blog.netmonic.com
> http://twitter.com/netmonic
>
> On Apr 21, 2009, at 4:17 PM, Stephen Spector wrote:
>
>> With Xen 3.4 in test for final release shortly, it is time to submit
>> your feature requests for the next release, Xen 4.0. The current
>> product roadmap is athttp://www.xen.org/download/roadmap.html and will
>> be updated with the new features you submit once Xen 3.4 is released.
>>
>> Please send me your features. Thanks.
>>
>> Stephen Spector
>> Community Manager, Xen.org
>> stephen.spector@xen.org
>> (772) 621-5062
>> Blog: http://blog.xen.org
>> Twitter: http://www.twitter.com/xen_com_mgr
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* TSC virtualization across different host frequency platform migration
2009-04-22 1:24 ` Akio Takebe
@ 2009-04-22 1:32 ` Dong, Eddie
2009-04-22 8:13 ` Keir Fraser
2009-04-22 15:47 ` Dan Magenheimer
2009-04-22 1:57 ` Xen 4.0 Feature Requests Ryo Tsuruta
1 sibling, 2 replies; 36+ messages in thread
From: Dong, Eddie @ 2009-04-22 1:32 UTC (permalink / raw)
To: xen-devel; +Cc: Tian, Kevin, Dong, Eddie, Keir Fraser, Zhang, Xiantao
[-- Attachment #1: Type: text/plain, Size: 647 bytes --]
Keir and all:
Recently we are considering the potential issue of TSC virtualization across different frequency platform migration. Current approach will lead to synchronization issue between guest TSC and wall clock. Software trap and emulate can solve the problem with the payment of performance overhead which is not optimal. We want to propose smart scaling algorithm which can continuously use HW TSC_OFFSET and maintain long time synchronization of guest TSC. The details are in attached document. Can you have a look and provide comments?
Thanks. BTW of course PV time is another solution which is not covered in this proposal.
Eddie
[-- Attachment #2: tsc-scale2.pdf --]
[-- Type: application/pdf, Size: 228149 bytes --]
[-- Attachment #3: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests
2009-04-22 1:24 ` Akio Takebe
2009-04-22 1:32 ` TSC virtualization across different host frequency platform migration Dong, Eddie
@ 2009-04-22 1:57 ` Ryo Tsuruta
1 sibling, 0 replies; 36+ messages in thread
From: Ryo Tsuruta @ 2009-04-22 1:57 UTC (permalink / raw)
To: takebe_akio; +Cc: xen-devel, xen-users, lists
Hi,
From: Akio Takebe <takebe_akio@jp.fujitsu.com>
Date: Wed, 22 Apr 2009 10:24:20 +0900
> dm-ioband has rpm package of RHEL/CentOS, so you can use dm-ioband for xen.
> http://lists.xensource.com/archives/html/xen-devel/2009-04/msg00116.html
>
> If you are interested in dm-ioband, please comment to Ryo.
> He would want feedbacks from many users.
Thanks you takebe-san for introducing dm-ioband.
I ran some benchmarks with Xen and got goot results.
Bandwidth control for Xen
- On a per Xen virtual block device basis.
http://people.valinux.co.jp/~ryov/dm-ioband/benchmark/xen-partition.html
- On a per Xen blktap process basis.
http://people.valinux.co.jp/~ryov/dm-ioband/benchmark/xen-blktap.html
You can download RPM packages for RHEL/CentOS from the below link.
http://people.valinux.co.jp/~ryov/dm-ioband/binary.html
And you can find configuration examples on the below link.
http://people.valinux.co.jp/~ryov/dm-ioband/manual/examples.html#AEN584
Please try to use dm-ioband and let me know your feedback.
Thanks,
Ryo Tsuruta
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: RE: Xen 4.0 Feature Requests
2009-04-22 1:14 ` Samuel Thibault
@ 2009-04-22 8:08 ` Dirk Utterback
2009-04-22 8:11 ` Samuel Thibault
0 siblings, 1 reply; 36+ messages in thread
From: Dirk Utterback @ 2009-04-22 8:08 UTC (permalink / raw)
To: Samuel Thibault, Dirk Utterback, Tim Moore,
xen-devel@lists.xensource.com
[-- Attachment #1.1: Type: text/plain, Size: 559 bytes --]
Samuel,
On Tue, Apr 21, 2009 at 6:14 PM, Samuel Thibault <
samuel.thibault@ens-lyon.org> wrote:
> Dirk Utterback, le Tue 21 Apr 2009 18:08:41 -0700, a écrit :
> > It would be very nice if PCI passthrough for all VT machines (not just
> for
> > VT-d boxes) is available.
>
> Unsafe PCI passthrough is available. Safe PCI passthrough just can not
> happen without VT-d.
>
I agree PCI passthrough without VT-d has drawbacks. I just want to
achieve
good performance but not security. Are you saying it is available now?
Thanks,
Dirk
[-- Attachment #1.2: Type: text/html, Size: 918 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: RE: Xen 4.0 Feature Requests
2009-04-22 8:08 ` Dirk Utterback
@ 2009-04-22 8:11 ` Samuel Thibault
0 siblings, 0 replies; 36+ messages in thread
From: Samuel Thibault @ 2009-04-22 8:11 UTC (permalink / raw)
To: Dirk Utterback; +Cc: xen-devel, Tim Moore, Stephen Spector, xen-users
Dirk Utterback, le Wed 22 Apr 2009 01:08:26 -0700, a écrit :
> Dirk Utterback, le Tue 21 Apr 2009 18:08:41 -0700, a écrit :
> > It would be very nice if PCI passthrough for all VT machines (not just
> for
> > VT-d boxes) is available.
>
> Unsafe PCI passthrough is available. Safe PCI passthrough just can not
> happen without VT-d.
>
>
> I agree PCI passthrough without VT-d has drawbacks. I just want to achieve
> good performance but not security. Are you saying it is available now?
Sure, just use pciback and assign the device to a domU.
Samuel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: TSC virtualization across different host frequency platform migration
2009-04-22 1:32 ` TSC virtualization across different host frequency platform migration Dong, Eddie
@ 2009-04-22 8:13 ` Keir Fraser
2009-04-22 8:49 ` Dong, Eddie
2009-04-22 15:47 ` Dan Magenheimer
1 sibling, 1 reply; 36+ messages in thread
From: Keir Fraser @ 2009-04-22 8:13 UTC (permalink / raw)
To: Dong, Eddie, xen-devel; +Cc: Tian, Kevin, Zhang, Xiantao
On 22/04/2009 02:32, "Dong, Eddie" <eddie.dong@intel.com> wrote:
> Keir and all:
> Recently we are considering the potential issue of TSC virtualization across
> different frequency platform migration. Current approach will lead to
> synchronization issue between guest TSC and wall clock. Software trap and
> emulate can solve the problem with the payment of performance overhead which
> is not optimal. We want to propose smart scaling algorithm which can
> continuously use HW TSC_OFFSET and maintain long time synchronization of guest
> TSC. The details are in attached document. Can you have a look and provide
> comments?
The important questions are: What guests get confused by an out-of-sync TSC?
And is coarse-grained re-sync (multi-second quantum?) good enough? As a
re-sync strategy well, yes, obviously it works but with some drawbacks.
It would be very nice if VT could be extended to scale the host TSC as well
as offset it. I would think that would be quite easy to do.
-- Keir
> Thanks. BTW of course PV time is another solution which is not covered in this
> proposal.
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: TSC virtualization across different host frequency platform migration
2009-04-22 8:13 ` Keir Fraser
@ 2009-04-22 8:49 ` Dong, Eddie
0 siblings, 0 replies; 36+ messages in thread
From: Dong, Eddie @ 2009-04-22 8:49 UTC (permalink / raw)
To: Keir Fraser, xen-devel; +Cc: Tian, Kevin, Dong, Eddie, Zhang, Xiantao
Keir Fraser wrote:
> On 22/04/2009 02:32, "Dong, Eddie" <eddie.dong@intel.com> wrote:
>
>> Keir and all:
>> Recently we are considering the potential issue of TSC
>> virtualization across different frequency platform migration.
>> Current approach will lead to synchronization issue between guest
>> TSC and wall clock. Software trap and emulate can solve the problem
>> with the payment of performance overhead which is not optimal. We
>> want to propose smart scaling algorithm which can continuously use
>> HW TSC_OFFSET and maintain long time synchronization of guest TSC.
>> The details are in attached document. Can you have a look and
>> provide comments?
>
> The important questions are: What guests get confused by an
> out-of-sync TSC? And is coarse-grained re-sync (multi-second
That is what I am interested too. Is there any report from real deployment
which utilize migration frequently?
thx, eddie
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: R: Xen 4.0 Feature Requests
2009-04-21 14:53 ` R: " Francesco Gallo
@ 2009-04-22 14:51 ` Kashif Ali
2009-04-22 19:49 ` Alessandro R.
0 siblings, 1 reply; 36+ messages in thread
From: Kashif Ali @ 2009-04-22 14:51 UTC (permalink / raw)
To: cluster, stephen.spector, xen-users, xen-devel
[-- Attachment #1.1: Type: text/plain, Size: 1583 bytes --]
If there is any way to monitor,limit and control network traffic coming at domUs with xen. I would like xen to have this feature as well.
Thanks,
Kashif
From: cluster@xinet.it
To: stephen.spector@citrix.com; xen-users@lists.xensource.com; xen-devel@lists.xensource.com
Subject: R: [Xen-users] Xen 4.0 Feature Requests
Date: Tue, 21 Apr 2009 16:53:04 +0200
CC:
I would like to have dynamic
memory mangement for overcommitting RAM (like vmware…).
Thanks and regards,
Francesco Gallo
Da: xen-users-bounces@lists.xensource.com
[mailto:xen-users-bounces@lists.xensource.com] Per conto di Stephen
Spector
Inviato: martedì 21 aprile 2009 16.17
A: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com'
Oggetto: [Xen-users] Xen 4.0 Feature Requests
With Xen 3.4 in test for final release
shortly, it is time to submit your feature requests for the next release, Xen
4.0. The current product roadmap is at http://www.xen.org/download/roadmap.html
and will be updated with the new features you submit once Xen 3.4 is released.
Please send me your features. Thanks.
Stephen Spector
Community Manager, Xen.org
stephen.spector@xen.org
(772) 621-5062
Blog: http://blog.xen.org
Twitter: http://www.twitter.com/xen_com_mgr
_________________________________________________________________
Rediscover Hotmail®: Now available on your iPhone or BlackBerry
http://windowslive.com/RediscoverHotmail?ocid=TXT_TAGLM_WL_HM_Rediscover_Mobile2_042009
[-- Attachment #1.2: Type: text/html, Size: 4045 bytes --]
[-- Attachment #2: Type: text/plain, Size: 137 bytes --]
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: TSC virtualization across different host frequency platform migration
2009-04-22 1:32 ` TSC virtualization across different host frequency platform migration Dong, Eddie
2009-04-22 8:13 ` Keir Fraser
@ 2009-04-22 15:47 ` Dan Magenheimer
2009-04-23 1:28 ` Dong, Eddie
1 sibling, 1 reply; 36+ messages in thread
From: Dan Magenheimer @ 2009-04-22 15:47 UTC (permalink / raw)
To: Dong, Eddie, xen-devel
Cc: Tian, Kevin, dan.magenheimer, Keir Fraser, Zhang, Xiantao
Hi Eddie/Kevin --
I'm sorry to be dense, but I don't understand the
details of your solution. I'm also not sure I
understand the problem you are trying to solve.
The problem description doesn't describe a problem,
just an event.
I'm guessing the problem is: When a guest chooses
TSC as its primary clocksource AND a migration later
occurs to a host with a different TSC frequency
THEN wallclock time (e.g. the "date" command)
becomes incorrect.
I'm also guessing that you are NOT trying to solve
the problem: An application that uses TSC
heavily to measure the passage of time AND
calibrates TSC on host A AND invisibly
migrates to host B with a different TSC
frequency THEN will NOT be able to accurately
measure the passage of time. However, it will
continue to be monotonically increasing.
In other words, you are trying to solve the OS problem
but not the application problem.
Is this correct? If so, then I think I understand
your proposal.
Also, I think it would be worthwhile to remeasure the
cost of trapping every TSC read, using current
processors and with some attempt in Xen to make
the emulation fast (returning Xen system time).
10% seems like a VERY large number, even if a database
is using TSC read to timestamp every transaction.
If software-emulated TSC read can be made fast enough,
then it solves both the OS and application problem.
Dan
> -----Original Message-----
> From: Dong, Eddie [mailto:eddie.dong@intel.com]
> Sent: Tuesday, April 21, 2009 7:33 PM
> To: xen-devel@lists.xensource.com
> Cc: Tian, Kevin; Dong, Eddie; Keir Fraser; Zhang, Xiantao
> Subject: [Xen-devel] TSC virtualization across different host
> frequency
> platform migration
>
>
> Keir and all:
> Recently we are considering the potential issue of TSC
> virtualization across different frequency platform migration.
> Current approach will lead to synchronization issue between
> guest TSC and wall clock. Software trap and emulate can solve
> the problem with the payment of performance overhead which is
> not optimal. We want to propose smart scaling algorithm which
> can continuously use HW TSC_OFFSET and maintain long time
> synchronization of guest TSC. The details are in attached
> document. Can you have a look and provide comments?
> Thanks. BTW of course PV time is another solution which
> is not covered in this proposal.
>
> Eddie
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [Xen-devel] Xen 4.0 Feature Requests
2009-04-21 14:17 Xen 4.0 Feature Requests Stephen Spector
` (3 preceding siblings ...)
2009-04-22 0:31 ` Philipp Schmid
@ 2009-04-22 16:14 ` Thiago Camargo Martins Cordeiro
2009-05-03 18:27 ` Sander Eikelenboom
5 siblings, 0 replies; 36+ messages in thread
From: Thiago Camargo Martins Cordeiro @ 2009-04-22 16:14 UTC (permalink / raw)
To: Stephen Spector; +Cc: xen-devel, xen-users
[-- Attachment #1.1: Type: text/plain, Size: 1015 bytes --]
Hi,
I guess Xen needs some kind of Virtual Ethernet Switch, virtual uplinks
(through SSH, for example), virtual cables, virtual plugs, so I can create a
virtual switch per client on each of my dom0 of my cluster, or maybe it
needs a easy way to integrate itself with VDE2.
Regards,
Thiago
2009/4/21 Stephen Spector <stephen.spector@citrix.com>
> With Xen 3.4 in test for final release shortly, it is time to submit your
> feature requests for the next release, Xen 4.0. The current product roadmap
> is at http://www.xen.org/download/roadmap.html and will be updated with
> the new features you submit once Xen 3.4 is released.
>
>
>
> Please send me your features. Thanks.
>
>
>
> Stephen Spector
>
> Community Manager, Xen.org
>
> stephen.spector@xen.org
>
> (772) 621-5062
>
> Blog: http://blog.xen.org
>
> Twitter: http://www.twitter.com/xen_com_mgr
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
[-- Attachment #1.2: Type: text/html, Size: 1846 bytes --]
[-- Attachment #2: Type: text/plain, Size: 137 bytes --]
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: R: Xen 4.0 Feature Requests
2009-04-22 14:51 ` Kashif Ali
@ 2009-04-22 19:49 ` Alessandro R.
2009-04-23 7:27 ` Robert Dunkley
0 siblings, 1 reply; 36+ messages in thread
From: Alessandro R. @ 2009-04-22 19:49 UTC (permalink / raw)
To: Kashif Ali; +Cc: cluster, xen-devel, stephen.spector, xen-users
A tool that permit to configure virtual bridge like real switch (e.g.
control VLAN, port status etc.)
On Wed, Apr 22, 2009 at 4:51 PM, Kashif Ali <kashif_quaidian@hotmail.com> wrote:
> If there is any way to monitor,limit and control network traffic coming at
> domUs with xen. I would like xen to have this feature as well.
>
> Thanks,
> Kashif
>
> ________________________________
> From: cluster@xinet.it
> To: stephen.spector@citrix.com; xen-users@lists.xensource.com;
> xen-devel@lists.xensource.com
> Subject: R: [Xen-users] Xen 4.0 Feature Requests
> Date: Tue, 21 Apr 2009 16:53:04 +0200
> CC:
>
> I would like to have dynamic memory mangement for overcommitting RAM (like
> vmware…).
>
>
>
> Thanks and regards,
>
> Francesco Gallo
>
>
>
> Da: xen-users-bounces@lists.xensource.com
> [mailto:xen-users-bounces@lists.xensource.com] Per conto di Stephen Spector
> Inviato: martedì 21 aprile 2009 16.17
> A: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com'
> Oggetto: [Xen-users] Xen 4.0 Feature Requests
>
>
>
> With Xen 3.4 in test for final release shortly, it is time to submit your
> feature requests for the next release, Xen 4.0. The current product roadmap
> is at http://www.xen.org/download/roadmap.html and will be updated with the
> new features you submit once Xen 3.4 is released.
>
>
>
> Please send me your features. Thanks.
>
>
>
> Stephen Spector
>
> Community Manager, Xen.org
>
> stephen.spector@xen.org
>
> (772) 621-5062
>
> Blog: http://blog.xen.org
>
> Twitter: http://www.twitter.com/xen_com_mgr
>
>
>
> ________________________________
> Rediscover Hotmail®: Now available on your iPhone or BlackBerry Check it
> out.
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
--
Alessandro R.
NOTICE
This message is for the named person's use only and it's confidential.
If you receive this message in error, please immediately delete it and
and notify the sender. Thank you.
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: TSC virtualization across different host frequency platform migration
2009-04-22 15:47 ` Dan Magenheimer
@ 2009-04-23 1:28 ` Dong, Eddie
2009-04-23 3:20 ` Tian, Kevin
0 siblings, 1 reply; 36+ messages in thread
From: Dong, Eddie @ 2009-04-23 1:28 UTC (permalink / raw)
To: Dan Magenheimer, xen-devel
Cc: Tian, Kevin, Dong, Eddie, Keir Fraser, Zhang, Xiantao
Dan Magenheimer wrote:
> Hi Eddie/Kevin --
>
> I'm sorry to be dense, but I don't understand the
> details of your solution. I'm also not sure I
> understand the problem you are trying to solve.
> The problem description doesn't describe a problem,
> just an event.
>
> I'm guessing the problem is: When a guest chooses
> TSC as its primary clocksource AND a migration later
> occurs to a host with a different TSC frequency
> THEN wallclock time (e.g. the "date" command)
> becomes incorrect.
Mostly yes though don't know if guest wall clock depends on TSC heavily.
>
> I'm also guessing that you are NOT trying to solve
> the problem: An application that uses TSC
> heavily to measure the passage of time AND
> calibrates TSC on host A AND invisibly
> migrates to host B with a different TSC
> frequency THEN will NOT be able to accurately
> measure the passage of time. However, it will
> continue to be monotonically increasing.
Yes, if we don't scale the TSC.
The proposal tries to solve the problem.
We can use software trap and emulate to scale the TSC so
that guest TSC after migration is same with that before migration.
But this is not optimial since the overhead may be too high. So we
propose to use smart scaling, which continuously use TSC_OFFSET,
but adjust the TSC_OFFSET value time to time (today it is fixed),
so that an application that uses TSC heavily to measure the passage of time
can get correct time.
thx, eddie
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: TSC virtualization across different host frequency platform migration
2009-04-23 1:28 ` Dong, Eddie
@ 2009-04-23 3:20 ` Tian, Kevin
2009-04-23 3:39 ` Dan Magenheimer
0 siblings, 1 reply; 36+ messages in thread
From: Tian, Kevin @ 2009-04-23 3:20 UTC (permalink / raw)
To: Dong, Eddie, Dan Magenheimer, xen-devel; +Cc: Keir Fraser, Zhang, Xiantao
[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]
>From: Dong, Eddie
>Sent: 2009年4月23日 9:29
>
>Dan Magenheimer wrote:
>> Hi Eddie/Kevin --
>>
>> I'm sorry to be dense, but I don't understand the
>> details of your solution. I'm also not sure I
>> understand the problem you are trying to solve.
>> The problem description doesn't describe a problem,
>> just an event.
>>
>> I'm guessing the problem is: When a guest chooses
>> TSC as its primary clocksource AND a migration later
>> occurs to a host with a different TSC frequency
>> THEN wallclock time (e.g. the "date" command)
>> becomes incorrect.
>
>Mostly yes though don't know if guest wall clock depends on
>TSC heavily.
>
>>
>> I'm also guessing that you are NOT trying to solve
>> the problem: An application that uses TSC
>> heavily to measure the passage of time AND
>> calibrates TSC on host A AND invisibly
>> migrates to host B with a different TSC
>> frequency THEN will NOT be able to accurately
>> measure the passage of time. However, it will
>> continue to be monotonically increasing.
>
>Yes, if we don't scale the TSC.
>The proposal tries to solve the problem.
>
>We can use software trap and emulate to scale the TSC so
>that guest TSC after migration is same with that before migration.
>
>But this is not optimial since the overhead may be too high. So we
>propose to use smart scaling, which continuously use TSC_OFFSET,
>but adjust the TSC_OFFSET value time to time (today it is fixed),
>so that an application that uses TSC heavily to measure the
>passage of time
>can get correct time.
>
So we're really not trying to solve the micro-level accuracy if app
tries to use TSC for that purpose, which always bias from bare
metal as long as running in a VM. Here we're trying to ensure
macro-level accuracy and thus ToD in guest after migration, with
performance optimized if app in VM uses gettimeofday frequently.
In that way, gap between trap vs. notrap would be orders of
magnitude.
Thanks
Kevin
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: TSC virtualization across different host frequency platform migration
2009-04-23 3:20 ` Tian, Kevin
@ 2009-04-23 3:39 ` Dan Magenheimer
2009-04-23 6:15 ` Tian, Kevin
0 siblings, 1 reply; 36+ messages in thread
From: Dan Magenheimer @ 2009-04-23 3:39 UTC (permalink / raw)
To: Tian, Kevin, Dong, Eddie, xen-devel; +Cc: Keir Fraser, Zhang, Xiantao
OK, I think I understand, but I think you are
solving a very limited problem ("make sure that
a user/program that requests time-of-day gets
an answer which is close to accurate") but
not solving the broader class of time problems,
and you may be making them worse. If your solution
is implemented and the OS or an application reads tsc,
the values obtained will be monotonically increasing
but will have large gaps, correct?
If software-emulated tsc reads is really 10% loss
in system performance, I agree that this might be
the lesser of two evils. But I don't believe the
10%.
> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@intel.com]
> Sent: Wednesday, April 22, 2009 9:21 PM
> To: Dong, Eddie; Dan Magenheimer; xen-devel@lists.xensource.com
> Cc: Keir Fraser; Zhang, Xiantao
> Subject: RE: [Xen-devel] TSC virtualization across different
> host frequency platform migration
>
>
> >From: Dong, Eddie
> >Sent: 2009年4月23日 9:29
> >
> >Dan Magenheimer wrote:
> >> Hi Eddie/Kevin --
> >>
> >> I'm sorry to be dense, but I don't understand the
> >> details of your solution. I'm also not sure I
> >> understand the problem you are trying to solve.
> >> The problem description doesn't describe a problem,
> >> just an event.
> >>
> >> I'm guessing the problem is: When a guest chooses
> >> TSC as its primary clocksource AND a migration later
> >> occurs to a host with a different TSC frequency
> >> THEN wallclock time (e.g. the "date" command)
> >> becomes incorrect.
> >
> >Mostly yes though don't know if guest wall clock depends on
> >TSC heavily.
> >
> >>
> >> I'm also guessing that you are NOT trying to solve
> >> the problem: An application that uses TSC
> >> heavily to measure the passage of time AND
> >> calibrates TSC on host A AND invisibly
> >> migrates to host B with a different TSC
> >> frequency THEN will NOT be able to accurately
> >> measure the passage of time. However, it will
> >> continue to be monotonically increasing.
> >
> >Yes, if we don't scale the TSC.
> >The proposal tries to solve the problem.
> >
> >We can use software trap and emulate to scale the TSC so
> >that guest TSC after migration is same with that before migration.
> >
> >But this is not optimial since the overhead may be too high. So we
> >propose to use smart scaling, which continuously use TSC_OFFSET,
> >but adjust the TSC_OFFSET value time to time (today it is fixed),
> >so that an application that uses TSC heavily to measure the
> >passage of time
> >can get correct time.
> >
>
> So we're really not trying to solve the micro-level accuracy if app
> tries to use TSC for that purpose, which always bias from bare
> metal as long as running in a VM. Here we're trying to ensure
> macro-level accuracy and thus ToD in guest after migration, with
> performance optimized if app in VM uses gettimeofday frequently.
> In that way, gap between trap vs. notrap would be orders of
> magnitude.
>
> Thanks
> Kevin
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: TSC virtualization across different host frequency platform migration
2009-04-23 3:39 ` Dan Magenheimer
@ 2009-04-23 6:15 ` Tian, Kevin
2009-04-23 13:58 ` Dan Magenheimer
0 siblings, 1 reply; 36+ messages in thread
From: Tian, Kevin @ 2009-04-23 6:15 UTC (permalink / raw)
To: Dan Magenheimer, Dong, Eddie, xen-devel
Cc: Yang, Xiaowei, Keir Fraser, Zhang, Xiantao
[-- Attachment #1: Type: text/plain, Size: 3776 bytes --]
>From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
>Sent: 2009年4月23日 11:40
>
>OK, I think I understand, but I think you are
>solving a very limited problem ("make sure that
>a user/program that requests time-of-day gets
>an answer which is close to accurate") but
>not solving the broader class of time problems,
>and you may be making them worse. If your solution
>is implemented and the OS or an application reads tsc,
>the values obtained will be monotonically increasing
>but will have large gaps, correct?
that's always the case even w/o migration, since VM can be
preempted at any time.
>
>If software-emulated tsc reads is really 10% loss
>in system performance, I agree that this might be
>the lesser of two evils. But I don't believe the
>10%.
That's really application specific, depending on the frequency
of gettimeofday, e.g. in some database transation to stamp
each record fastly. I had no exact data though. One of my
colleagues (Xiaowei Yang) once solved one severe performance
downgrade issue (orders of magnitude, >10%), when guest
is observed falling back to use vHPET instead of TSC. The
reason for fallback is not important here, but that actually inspires
us to pay more attention here.
Thanks,
Kevin
>
>> -----Original Message-----
>> From: Tian, Kevin [mailto:kevin.tian@intel.com]
>> Sent: Wednesday, April 22, 2009 9:21 PM
>> To: Dong, Eddie; Dan Magenheimer; xen-devel@lists.xensource.com
>> Cc: Keir Fraser; Zhang, Xiantao
>> Subject: RE: [Xen-devel] TSC virtualization across different
>> host frequency platform migration
>>
>>
>> >From: Dong, Eddie
>> >Sent: 2009年4月23日 9:29
>> >
>> >Dan Magenheimer wrote:
>> >> Hi Eddie/Kevin --
>> >>
>> >> I'm sorry to be dense, but I don't understand the
>> >> details of your solution. I'm also not sure I
>> >> understand the problem you are trying to solve.
>> >> The problem description doesn't describe a problem,
>> >> just an event.
>> >>
>> >> I'm guessing the problem is: When a guest chooses
>> >> TSC as its primary clocksource AND a migration later
>> >> occurs to a host with a different TSC frequency
>> >> THEN wallclock time (e.g. the "date" command)
>> >> becomes incorrect.
>> >
>> >Mostly yes though don't know if guest wall clock depends on
>> >TSC heavily.
>> >
>> >>
>> >> I'm also guessing that you are NOT trying to solve
>> >> the problem: An application that uses TSC
>> >> heavily to measure the passage of time AND
>> >> calibrates TSC on host A AND invisibly
>> >> migrates to host B with a different TSC
>> >> frequency THEN will NOT be able to accurately
>> >> measure the passage of time. However, it will
>> >> continue to be monotonically increasing.
>> >
>> >Yes, if we don't scale the TSC.
>> >The proposal tries to solve the problem.
>> >
>> >We can use software trap and emulate to scale the TSC so
>> >that guest TSC after migration is same with that before migration.
>> >
>> >But this is not optimial since the overhead may be too high. So we
>> >propose to use smart scaling, which continuously use TSC_OFFSET,
>> >but adjust the TSC_OFFSET value time to time (today it is fixed),
>> >so that an application that uses TSC heavily to measure the
>> >passage of time
>> >can get correct time.
>> >
>>
>> So we're really not trying to solve the micro-level accuracy if app
>> tries to use TSC for that purpose, which always bias from bare
>> metal as long as running in a VM. Here we're trying to ensure
>> macro-level accuracy and thus ToD in guest after migration, with
>> performance optimized if app in VM uses gettimeofday frequently.
>> In that way, gap between trap vs. notrap would be orders of
>> magnitude.
>>
>> Thanks
>> Kevin
>
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: R: Xen 4.0 Feature Requests
2009-04-22 19:49 ` Alessandro R.
@ 2009-04-23 7:27 ` Robert Dunkley
2009-04-23 13:38 ` Thiago Camargo Martins Cordeiro
0 siblings, 1 reply; 36+ messages in thread
From: Robert Dunkley @ 2009-04-23 7:27 UTC (permalink / raw)
To: Alessandro R., Kashif Ali; +Cc: cluster, xen-devel, stephen.spector, xen-users
I second this request, just an easy way of VLan tagging per NIC in the VM config file would be good.
Rob
-----Original Message-----
From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Alessandro R.
Sent: 22 April 2009 20:50
To: Kashif Ali
Cc: cluster@xinet.it; xen-devel@lists.xensource.com; stephen.spector@citrix.com; xen-users@lists.xensource.com
Subject: Re: R: [Xen-users] Xen 4.0 Feature Requests
A tool that permit to configure virtual bridge like real switch (e.g.
control VLAN, port status etc.)
On Wed, Apr 22, 2009 at 4:51 PM, Kashif Ali <kashif_quaidian@hotmail.com> wrote:
> If there is any way to monitor,limit and control network traffic coming at
> domUs with xen. I would like xen to have this feature as well.
>
> Thanks,
> Kashif
>
> ________________________________
> From: cluster@xinet.it
> To: stephen.spector@citrix.com; xen-users@lists.xensource.com;
> xen-devel@lists.xensource.com
> Subject: R: [Xen-users] Xen 4.0 Feature Requests
> Date: Tue, 21 Apr 2009 16:53:04 +0200
> CC:
>
> I would like to have dynamic memory mangement for overcommitting RAM (like
> vmware...).
>
>
>
> Thanks and regards,
>
> Francesco Gallo
>
>
>
> Da: xen-users-bounces@lists.xensource.com
> [mailto:xen-users-bounces@lists.xensource.com] Per conto di Stephen Spector
> Inviato: martedì 21 aprile 2009 16.17
> A: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com'
> Oggetto: [Xen-users] Xen 4.0 Feature Requests
>
>
>
> With Xen 3.4 in test for final release shortly, it is time to submit your
> feature requests for the next release, Xen 4.0. The current product roadmap
> is at http://www.xen.org/download/roadmap.html and will be updated with the
> new features you submit once Xen 3.4 is released.
>
>
>
> Please send me your features. Thanks.
>
>
>
> Stephen Spector
>
> Community Manager, Xen.org
>
> stephen.spector@xen.org
>
> (772) 621-5062
>
> Blog: http://blog.xen.org
>
> Twitter: http://www.twitter.com/xen_com_mgr
>
>
>
> ________________________________
> Rediscover Hotmail®: Now available on your iPhone or BlackBerry Check it
> out.
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
--
Alessandro R.
NOTICE
This message is for the named person's use only and it's confidential.
If you receive this message in error, please immediately delete it and
and notify the sender. Thank you.
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
The SAQ Group
Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ
SAQ is the trading name of SEMTEC Limited. Registered in England & Wales
Company Number: 06481952
http://www.saqnet.co.uk AS29219
SAQ Group Delivers high quality, honestly priced communication and I.T. services to UK Business.
Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : Backups : Managed Networks : Remote Support.
ISPA Member
Find us in http://www.thebestof.co.uk/petersfield
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: R: Xen 4.0 Feature Requests
2009-04-23 7:27 ` Robert Dunkley
@ 2009-04-23 13:38 ` Thiago Camargo Martins Cordeiro
2009-04-23 14:34 ` R: [Xen-users] " Robert Dunkley
0 siblings, 1 reply; 36+ messages in thread
From: Thiago Camargo Martins Cordeiro @ 2009-04-23 13:38 UTC (permalink / raw)
To: Robert Dunkley
Cc: xen-devel, Kashif Ali, Alessandro R.,
xen-users, cluster, stephen.spector
[-- Attachment #1.1: Type: text/plain, Size: 3788 bytes --]
What about integrating Xen with a Virtual Ethernet Switch (like VDE2)?
You can create a switch per client...
2009/4/23 Robert Dunkley <Robert@saq.co.uk>
> I second this request, just an easy way of VLan tagging per NIC in the VM
> config file would be good.
>
> Rob
>
> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com [mailto:
> xen-users-bounces@lists.xensource.com] On Behalf Of Alessandro R.
> Sent: 22 April 2009 20:50
> To: Kashif Ali
> Cc: cluster@xinet.it; xen-devel@lists.xensource.com;
> stephen.spector@citrix.com; xen-users@lists.xensource.com
> Subject: Re: R: [Xen-users] Xen 4.0 Feature Requests
>
> A tool that permit to configure virtual bridge like real switch (e.g.
> control VLAN, port status etc.)
>
> On Wed, Apr 22, 2009 at 4:51 PM, Kashif Ali <kashif_quaidian@hotmail.com>
> wrote:
> > If there is any way to monitor,limit and control network traffic coming
> at
> > domUs with xen. I would like xen to have this feature as well.
> >
> > Thanks,
> > Kashif
> >
> > ________________________________
> > From: cluster@xinet.it
> > To: stephen.spector@citrix.com; xen-users@lists.xensource.com;
> > xen-devel@lists.xensource.com
> > Subject: R: [Xen-users] Xen 4.0 Feature Requests
> > Date: Tue, 21 Apr 2009 16:53:04 +0200
> > CC:
> >
> > I would like to have dynamic memory mangement for overcommitting RAM
> (like
> > vmware...).
> >
> >
> >
> > Thanks and regards,
> >
> > Francesco Gallo
> >
> >
> >
> > Da: xen-users-bounces@lists.xensource.com
> > [mailto:xen-users-bounces@lists.xensource.com] Per conto di Stephen
> Spector
> > Inviato: martedì 21 aprile 2009 16.17
> > A: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com'
> > Oggetto: [Xen-users] Xen 4.0 Feature Requests
> >
> >
> >
> > With Xen 3.4 in test for final release shortly, it is time to submit your
> > feature requests for the next release, Xen 4.0. The current product
> roadmap
> > is at http://www.xen.org/download/roadmap.html and will be updated with
> the
> > new features you submit once Xen 3.4 is released.
> >
> >
> >
> > Please send me your features. Thanks.
> >
> >
> >
> > Stephen Spector
> >
> > Community Manager, Xen.org
> >
> > stephen.spector@xen.org
> >
> > (772) 621-5062
> >
> > Blog: http://blog.xen.org
> >
> > Twitter: http://www.twitter.com/xen_com_mgr
> >
> >
> >
> > ________________________________
> > Rediscover Hotmail®: Now available on your iPhone or BlackBerry Check it
> > out.
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users
> >
>
>
>
> --
> Alessandro R.
>
> NOTICE
> This message is for the named person's use only and it's confidential.
> If you receive this message in error, please immediately delete it and
> and notify the sender. Thank you.
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
> The SAQ Group
>
> Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ
> SAQ is the trading name of SEMTEC Limited. Registered in England & Wales
> Company Number: 06481952
>
> http://www.saqnet.co.uk AS29219
>
> SAQ Group Delivers high quality, honestly priced communication and I.T.
> services to UK Business.
>
> Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit :
> Backups : Managed Networks : Remote Support.
>
> ISPA Member
>
> Find us in http://www.thebestof.co.uk/petersfield
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
[-- Attachment #1.2: Type: text/html, Size: 6048 bytes --]
[-- Attachment #2: Type: text/plain, Size: 137 bytes --]
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: TSC virtualization across different host frequency platform migration
2009-04-23 6:15 ` Tian, Kevin
@ 2009-04-23 13:58 ` Dan Magenheimer
0 siblings, 0 replies; 36+ messages in thread
From: Dan Magenheimer @ 2009-04-23 13:58 UTC (permalink / raw)
To: Tian, Kevin, Dong, Eddie, xen-devel
Cc: Yang, Xiaowei, Keir Fraser, Zhang, Xiantao
> that's always the case even w/o migration, since VM can be
> preempted at any time.
Not if it the vcpu is pinned, and that may often
be the case for database apps.
> That's really application specific, depending on the frequency
> of gettimeofday, e.g. in some database transation to stamp
> each record fastly. I had no exact data though. One of my
> colleagues (Xiaowei Yang) once solved one severe performance
> downgrade issue (orders of magnitude, >10%), when guest
> is observed falling back to use vHPET instead of TSC. The
> reason for fallback is not important here, but that actually inspires
> us to pay more attention here.
I'm suggesting that you measure and compare the cycle
cost of a TSC read and a vTSC read (and maybe also
a vHPET read), and also look at the code to see what
the bottleneck is for a vTSC read and if it can be made
faster. And since your solution doesn't solve PV time,
maybe also measure a vTSC read in a PV guest.
I also agree with Keir that a tsc scaler might be a
good enhancement to request for future VT-x designs.
> -----Original Message-----
> From: Tian, Kevin [mailto:kevin.tian@intel.com]
> Sent: Thursday, April 23, 2009 12:15 AM
> To: Dan Magenheimer; Dong, Eddie; xen-devel@lists.xensource.com
> Cc: Keir Fraser; Zhang, Xiantao; Yang, Xiaowei
> Subject: RE: [Xen-devel] TSC virtualization across different
> host frequency platform migration
>
>
> >From: Dan Magenheimer [mailto:dan.magenheimer@oracle.com]
> >Sent: 2009年4月23日 11:40
> >
> >OK, I think I understand, but I think you are
> >solving a very limited problem ("make sure that
> >a user/program that requests time-of-day gets
> >an answer which is close to accurate") but
> >not solving the broader class of time problems,
> >and you may be making them worse. If your solution
> >is implemented and the OS or an application reads tsc,
> >the values obtained will be monotonically increasing
> >but will have large gaps, correct?
>
> that's always the case even w/o migration, since VM can be
> preempted at any time.
>
> >
> >If software-emulated tsc reads is really 10% loss
> >in system performance, I agree that this might be
> >the lesser of two evils. But I don't believe the
> >10%.
>
> That's really application specific, depending on the frequency
> of gettimeofday, e.g. in some database transation to stamp
> each record fastly. I had no exact data though. One of my
> colleagues (Xiaowei Yang) once solved one severe performance
> downgrade issue (orders of magnitude, >10%), when guest
> is observed falling back to use vHPET instead of TSC. The
> reason for fallback is not important here, but that actually inspires
> us to pay more attention here.
>
> Thanks,
> Kevin
>
> >
> >> -----Original Message-----
> >> From: Tian, Kevin [mailto:kevin.tian@intel.com]
> >> Sent: Wednesday, April 22, 2009 9:21 PM
> >> To: Dong, Eddie; Dan Magenheimer; xen-devel@lists.xensource.com
> >> Cc: Keir Fraser; Zhang, Xiantao
> >> Subject: RE: [Xen-devel] TSC virtualization across different
> >> host frequency platform migration
> >>
> >>
> >> >From: Dong, Eddie
> >> >Sent: 2009年4月23日 9:29
> >> >
> >> >Dan Magenheimer wrote:
> >> >> Hi Eddie/Kevin --
> >> >>
> >> >> I'm sorry to be dense, but I don't understand the
> >> >> details of your solution. I'm also not sure I
> >> >> understand the problem you are trying to solve.
> >> >> The problem description doesn't describe a problem,
> >> >> just an event.
> >> >>
> >> >> I'm guessing the problem is: When a guest chooses
> >> >> TSC as its primary clocksource AND a migration later
> >> >> occurs to a host with a different TSC frequency
> >> >> THEN wallclock time (e.g. the "date" command)
> >> >> becomes incorrect.
> >> >
> >> >Mostly yes though don't know if guest wall clock depends on
> >> >TSC heavily.
> >> >
> >> >>
> >> >> I'm also guessing that you are NOT trying to solve
> >> >> the problem: An application that uses TSC
> >> >> heavily to measure the passage of time AND
> >> >> calibrates TSC on host A AND invisibly
> >> >> migrates to host B with a different TSC
> >> >> frequency THEN will NOT be able to accurately
> >> >> measure the passage of time. However, it will
> >> >> continue to be monotonically increasing.
> >> >
> >> >Yes, if we don't scale the TSC.
> >> >The proposal tries to solve the problem.
> >> >
> >> >We can use software trap and emulate to scale the TSC so
> >> >that guest TSC after migration is same with that before migration.
> >> >
> >> >But this is not optimial since the overhead may be too high. So we
> >> >propose to use smart scaling, which continuously use TSC_OFFSET,
> >> >but adjust the TSC_OFFSET value time to time (today it is fixed),
> >> >so that an application that uses TSC heavily to measure the
> >> >passage of time
> >> >can get correct time.
> >> >
> >>
> >> So we're really not trying to solve the micro-level accuracy if app
> >> tries to use TSC for that purpose, which always bias from bare
> >> metal as long as running in a VM. Here we're trying to ensure
> >> macro-level accuracy and thus ToD in guest after migration, with
> >> performance optimized if app in VM uses gettimeofday frequently.
> >> In that way, gap between trap vs. notrap would be orders of
> >> magnitude.
> >>
> >> Thanks
> >> Kevin
> >
^ permalink raw reply [flat|nested] 36+ messages in thread
* RE: R: [Xen-users] Xen 4.0 Feature Requests
2009-04-23 13:38 ` Thiago Camargo Martins Cordeiro
@ 2009-04-23 14:34 ` Robert Dunkley
2009-04-23 15:01 ` R: " Thiago Camargo Martins Cordeiro
2009-04-24 8:50 ` RE: R: [Xen-users] " Kieran Mansley
0 siblings, 2 replies; 36+ messages in thread
From: Robert Dunkley @ 2009-04-23 14:34 UTC (permalink / raw)
To: Thiago Camargo Martins Cordeiro
Cc: xen-devel, Kashif Ali, Alessandro R.,
xen-users, cluster, stephen.spector
[-- Attachment #1.1: Type: text/plain, Size: 4240 bytes --]
VDE2 looks good, Fast Spanning tree could be useful but any idea what sort of performance hit would be taken by using VDE2? Lets see if there is any developer feedback, personally I think Vlan tagging needs addressing at some point since current VLan implementations with Xen are quite complex (Eg. Creating multiple bridges) and still have limitations.
Rob
From: Thiago Camargo Martins Cordeiro [mailto:thiagocmartinsc@gmail.com]
Sent: 23 April 2009 14:38
To: Robert Dunkley
Cc: Alessandro R.; Kashif Ali; cluster@xinet.it; xen-devel@lists.xensource.com; stephen.spector@citrix.com; xen-users@lists.xensource.com
Subject: Re: R: [Xen-users] Xen 4.0 Feature Requests
What about integrating Xen with a Virtual Ethernet Switch (like VDE2)?
You can create a switch per client...
2009/4/23 Robert Dunkley <Robert@saq.co.uk>
I second this request, just an easy way of VLan tagging per NIC in the VM config file would be good.
Rob
-----Original Message-----
From: xen-users-bounces@lists.xensource.com [mailto:xen-users-bounces@lists.xensource.com] On Behalf Of Alessandro R.
Sent: 22 April 2009 20:50
To: Kashif Ali
Cc: cluster@xinet.it; xen-devel@lists.xensource.com; stephen.spector@citrix.com; xen-users@lists.xensource.com
Subject: Re: R: [Xen-users] Xen 4.0 Feature Requests
A tool that permit to configure virtual bridge like real switch (e.g.
control VLAN, port status etc.)
On Wed, Apr 22, 2009 at 4:51 PM, Kashif Ali <kashif_quaidian@hotmail.com> wrote:
> If there is any way to monitor,limit and control network traffic coming at
> domUs with xen. I would like xen to have this feature as well.
>
> Thanks,
> Kashif
>
> ________________________________
> From: cluster@xinet.it
> To: stephen.spector@citrix.com; xen-users@lists.xensource.com;
> xen-devel@lists.xensource.com
> Subject: R: [Xen-users] Xen 4.0 Feature Requests
> Date: Tue, 21 Apr 2009 16:53:04 +0200
> CC:
>
> I would like to have dynamic memory mangement for overcommitting RAM (like
> vmware...).
>
>
>
> Thanks and regards,
>
> Francesco Gallo
>
>
>
> Da: xen-users-bounces@lists.xensource.com
> [mailto:xen-users-bounces@lists.xensource.com] Per conto di Stephen Spector
> Inviato: martedì 21 aprile 2009 16.17
> A: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com'
> Oggetto: [Xen-users] Xen 4.0 Feature Requests
>
>
>
> With Xen 3.4 in test for final release shortly, it is time to submit your
> feature requests for the next release, Xen 4.0. The current product roadmap
> is at http://www.xen.org/download/roadmap.html and will be updated with the
> new features you submit once Xen 3.4 is released.
>
>
>
> Please send me your features. Thanks.
>
>
>
> Stephen Spector
>
> Community Manager, Xen.org
>
> stephen.spector@xen.org
>
> (772) 621-5062
>
> Blog: http://blog.xen.org
>
> Twitter: http://www.twitter.com/xen_com_mgr
>
>
>
> ________________________________
> Rediscover Hotmail®: Now available on your iPhone or BlackBerry Check it
> out.
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
--
Alessandro R.
NOTICE
This message is for the named person's use only and it's confidential.
If you receive this message in error, please immediately delete it and
and notify the sender. Thank you.
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
The SAQ Group
Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ
SAQ is the trading name of SEMTEC Limited. Registered in England & Wales
Company Number: 06481952
http://www.saqnet.co.uk AS29219
SAQ Group Delivers high quality, honestly priced communication and I.T. services to UK Business.
Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit : Backups : Managed Networks : Remote Support.
ISPA Member
Find us in http://www.thebestof.co.uk/petersfield
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
[-- Attachment #1.2: Type: text/html, Size: 15038 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: R: Xen 4.0 Feature Requests
2009-04-23 14:34 ` R: [Xen-users] " Robert Dunkley
@ 2009-04-23 15:01 ` Thiago Camargo Martins Cordeiro
2009-04-24 8:50 ` RE: R: [Xen-users] " Kieran Mansley
1 sibling, 0 replies; 36+ messages in thread
From: Thiago Camargo Martins Cordeiro @ 2009-04-23 15:01 UTC (permalink / raw)
To: Robert Dunkley
Cc: xen-devel, Kashif Ali, Alessandro R.,
xen-users, cluster, stephen.spector
[-- Attachment #1.1: Type: text/plain, Size: 5343 bytes --]
I have done some benchmarks with VDE2 with KVM and it is really fast! No one
notes VDE2...
2009/4/23 Robert Dunkley <Robert@saq.co.uk>
> VDE2 looks good, Fast Spanning tree could be useful but any idea what
> sort of performance hit would be taken by using VDE2? Lets see if there is
> any developer feedback, personally I think Vlan tagging needs addressing at
> some point since current VLan implementations with Xen are quite complex
> (Eg. Creating multiple bridges) and still have limitations.
>
>
>
> Rob
>
>
>
> *From:* Thiago Camargo Martins Cordeiro [mailto:thiagocmartinsc@gmail.com]
>
> *Sent:* 23 April 2009 14:38
> *To:* Robert Dunkley
> *Cc:* Alessandro R.; Kashif Ali; cluster@xinet.it;
> xen-devel@lists.xensource.com; stephen.spector@citrix.com;
> xen-users@lists.xensource.com
>
> *Subject:* Re: R: [Xen-users] Xen 4.0 Feature Requests
>
>
>
> What about integrating Xen with a Virtual Ethernet Switch (like VDE2)?
> You can create a switch per client...
>
> 2009/4/23 Robert Dunkley <Robert@saq.co.uk>
>
> I second this request, just an easy way of VLan tagging per NIC in the VM
> config file would be good.
>
> Rob
>
>
> -----Original Message-----
> From: xen-users-bounces@lists.xensource.com [mailto:
> xen-users-bounces@lists.xensource.com] On Behalf Of Alessandro R.
> Sent: 22 April 2009 20:50
> To: Kashif Ali
> Cc: cluster@xinet.it; xen-devel@lists.xensource.com;
> stephen.spector@citrix.com; xen-users@lists.xensource.com
> Subject: Re: R: [Xen-users] Xen 4.0 Feature Requests
>
> A tool that permit to configure virtual bridge like real switch (e.g.
> control VLAN, port status etc.)
>
> On Wed, Apr 22, 2009 at 4:51 PM, Kashif Ali <kashif_quaidian@hotmail.com>
> wrote:
> > If there is any way to monitor,limit and control network traffic coming
> at
> > domUs with xen. I would like xen to have this feature as well.
> >
> > Thanks,
> > Kashif
> >
> > ________________________________
> > From: cluster@xinet.it
> > To: stephen.spector@citrix.com; xen-users@lists.xensource.com;
> > xen-devel@lists.xensource.com
> > Subject: R: [Xen-users] Xen 4.0 Feature Requests
> > Date: Tue, 21 Apr 2009 16:53:04 +0200
> > CC:
> >
> > I would like to have dynamic memory mangement for overcommitting RAM
> (like
> > vmware...).
> >
> >
> >
> > Thanks and regards,
> >
> > Francesco Gallo
> >
> >
> >
> > Da: xen-users-bounces@lists.xensource.com
> > [mailto:xen-users-bounces@lists.xensource.com] Per conto di Stephen
> Spector
> > Inviato: martedì 21 aprile 2009 16.17
> > A: xen-users@lists.xensource.com; 'xen-devel@lists.xensource.com'
> > Oggetto: [Xen-users] Xen 4.0 Feature Requests
> >
> >
> >
> > With Xen 3.4 in test for final release shortly, it is time to submit your
> > feature requests for the next release, Xen 4.0. The current product
> roadmap
> > is at http://www.xen.org/download/roadmap.html and will be updated with
> the
> > new features you submit once Xen 3.4 is released.
> >
> >
> >
> > Please send me your features. Thanks.
> >
> >
> >
> > Stephen Spector
> >
> > Community Manager, Xen.org
> >
> > stephen.spector@xen.org
> >
> > (772) 621-5062
> >
> > Blog: http://blog.xen.org
> >
> > Twitter: http://www.twitter.com/xen_com_mgr
> >
> >
> >
> > ________________________________
> > Rediscover Hotmail®: Now available on your iPhone or BlackBerry Check it
> > out.
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@lists.xensource.com
> > http://lists.xensource.com/xen-users
> >
>
>
>
> --
> Alessandro R.
>
> NOTICE
> This message is for the named person's use only and it's confidential.
> If you receive this message in error, please immediately delete it and
> and notify the sender. Thank you.
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
> The SAQ Group
>
> Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ
> SAQ is the trading name of SEMTEC Limited. Registered in England & Wales
> Company Number: 06481952
>
> http://www.saqnet.co.uk AS29219
>
> SAQ Group Delivers high quality, honestly priced communication and I.T.
> services to UK Business.
>
> Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit :
> Backups : Managed Networks : Remote Support.
>
> ISPA Member
>
> Find us in http://www.thebestof.co.uk/petersfield
>
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>
>
>
> **
>
> ** *The SAQ Group*
>
> *Registered Office: 18 Chapel Street, Petersfield, Hampshire GU32 3DZ*
> SAQ is the trading name of SEMTEC Limited. Registered in England & Wales
> Company Number: 06481952
>
>
>
> http://www.saqnet.co.uk AS29219
>
> SAQ Group Delivers high quality, honestly priced communication and I.T.
> services to UK Business.
>
> Broadband : Domains : Email : Hosting : CoLo : Servers : Racks : Transit :
> Backups : Managed Networks : Remote Support.
>
>
>
> [image: SAQ Group]
>
>
>
> *ISPA Member*
>
>
>
> <http://www.saq.co.uk>
>
> Find us in http://www.thebestof.co.uk/petersfield
>
[-- Attachment #1.2: Type: text/html, Size: 10639 bytes --]
[-- Attachment #2: Type: text/plain, Size: 137 bytes --]
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: RE: R: [Xen-users] Xen 4.0 Feature Requests
2009-04-23 14:34 ` R: [Xen-users] " Robert Dunkley
2009-04-23 15:01 ` R: " Thiago Camargo Martins Cordeiro
@ 2009-04-24 8:50 ` Kieran Mansley
1 sibling, 0 replies; 36+ messages in thread
From: Kieran Mansley @ 2009-04-24 8:50 UTC (permalink / raw)
To: xen-users, xen-devel
On Thu, 2009-04-23 at 15:34 +0100, Robert Dunkley wrote:
> VDE2 looks good, Fast Spanning tree could be useful but any idea what
> sort of performance hit would be taken by using VDE2? Lets see if
> there is any developer feedback, personally I think Vlan tagging needs
> addressing at some point since current VLan implementations with Xen
> are quite complex (Eg. Creating multiple bridges) and still have
> limitations.
This sort of thing interests Solarflare, but in a more general way.
With Xen (and other virtualisation technologies) users often end up with
a set of bridges, v-switches, hardware switches, and now switches
(albeit limited in capabilities) in virtualisation-aware NICs. It would
be very useful to develop a control plane over all these devices to
allow them to be sensibly configured from a single point. I know there
are some people working on bits of this problem but bringing it all
together to work on Xen, using open APIs and protocols so that other
technologies could be easily integrated, would help a lot.
I'll add this to the list on the wiki, but would be happy to hear from
others if they have ideas on this topic.
Thanks
Kieran
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests
2009-04-21 14:17 Xen 4.0 Feature Requests Stephen Spector
` (4 preceding siblings ...)
2009-04-22 16:14 ` [Xen-devel] " Thiago Camargo Martins Cordeiro
@ 2009-05-03 18:27 ` Sander Eikelenboom
2009-05-03 20:12 ` Paul Schulze
5 siblings, 1 reply; 36+ messages in thread
From: Sander Eikelenboom @ 2009-05-03 18:27 UTC (permalink / raw)
To: Stephen Spector; +Cc: xen-devel
The features i'm looking for are:
- as many others .. VGA (pci-e/pci) passthrough
- complete USB passthrough, (also working for webcams/videograbbers etc)
i'm currently working with "USB over IP" from the
http://usbip.sourceforge.net/ project. It is working fine for
printers/scanners, and almost perfect for webcam (some little distortion
left). But functionality within XEN would be better.
Keep up the good work, still loving xen , and always happy to test :-)
--
Sander
Tuesday, April 21, 2009, 4:17:04 PM, you wrote:
> With Xen 3.4 in test for final release shortly, it is time to submit
> your feature requests for the next release, Xen 4.0. The current product
> roadmap is at http://www.xen.org/download/roadmap.html and will be
> updated with the new features you submit once Xen 3.4 is released.
> Please send me your features. Thanks.
> Stephen Spector
> Community Manager, Xen.org
> stephen.spector@xen.org
> (772) 621-5062
> Blog: http://blog.xen.org
> Twitter: http://www.twitter.com/xen_com_mgr
--
Best regards,
Sander mailto:linux@eikelenboom.it
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Xen 4.0 Feature Requests
2009-05-03 18:27 ` Sander Eikelenboom
@ 2009-05-03 20:12 ` Paul Schulze
2009-05-04 5:54 ` Re[2]: " Sander Eikelenboom
0 siblings, 1 reply; 36+ messages in thread
From: Paul Schulze @ 2009-05-03 20:12 UTC (permalink / raw)
To: Sander Eikelenboom; +Cc: xen-devel, Stephen Spector
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On 3 May 2009, at 20:27, Sander Eikelenboom wrote:
> The features i'm looking for are:
>
> - as many others .. VGA (pci-e/pci) passthrough
> - complete USB passthrough, (also working for webcams/videograbbers
> etc)
Fully functional USB passthrough would be really nice to have, but to
be useful, I would also like to also request some sort of device
management, that allows automatically assigning devices to a DomU
whenever it is connected and a way to have unknown devices assigned to
a default DomU. Otherwise, interaction on the Dom0 will be needed for
each and every time, a device is connected.
Paul.
- --
Paul Schulze
Mail: avlex82@gmail.com
Why can't a programmer tell the difference between Halloween and
Christmas?
Because OCT31 = DEC25.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (Darwin)
iEYEARECAAYFAkn9+psACgkQj2zIQLJNnKN8qwCfUqKhF7bHRdjyp/r4G9PJjY3u
YTQAn37ah5y0bul1FaeT4WrFlGt7ePg7
=BMlM
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re[2]: Xen 4.0 Feature Requests
2009-05-03 20:12 ` Paul Schulze
@ 2009-05-04 5:54 ` Sander Eikelenboom
2009-05-05 14:24 ` Ian Jackson
0 siblings, 1 reply; 36+ messages in thread
From: Sander Eikelenboom @ 2009-05-04 5:54 UTC (permalink / raw)
To: Paul Schulze; +Cc: xen-devel, Stephen Spector
Good point, some good and flexible management would be nice to have too.
USBIP at the moment can handle:
- remove binding to currently loaded modules
- binding to usbip at plugin time
In some quite simple userspace management tools.
For xen it think xend would be the place for normal rules, and xm for
hotplug ?
It would be nice if you could make the rules for usb passthrough match with
both usb port numbers as well as device id's, perhaps even with wildcards.
Sunday, May 3, 2009, 10:12:05 PM, you wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Hi,
> On 3 May 2009, at 20:27, Sander Eikelenboom wrote:
>> The features i'm looking for are:
>>
>> - as many others .. VGA (pci-e/pci) passthrough
>> - complete USB passthrough, (also working for webcams/videograbbers
>> etc)
> Fully functional USB passthrough would be really nice to have, but to
> be useful, I would also like to also request some sort of device
> management, that allows automatically assigning devices to a DomU
> whenever it is connected and a way to have unknown devices assigned to
> a default DomU. Otherwise, interaction on the Dom0 will be needed for
> each and every time, a device is connected.
> Paul.
--
Best regards,
Sander mailto:linux@eikelenboom.it
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Re[2]: Xen 4.0 Feature Requests
2009-05-04 5:54 ` Re[2]: " Sander Eikelenboom
@ 2009-05-05 14:24 ` Ian Jackson
0 siblings, 0 replies; 36+ messages in thread
From: Ian Jackson @ 2009-05-05 14:24 UTC (permalink / raw)
To: Sander Eikelenboom; +Cc: xen-devel, Stephen Spector, Paul Schulze
Sander Eikelenboom writes ("Re[2]: [Xen-devel] Xen 4.0 Feature Requests"):
> Good point, some good and flexible management would be nice to have too.
>
> USBIP at the moment can handle:
Yes, the usbip management tools are much better than the pvusb setup
we have right now. Sadly I didn't find the usbip code worked very
well for me (at least, the version I found in upstream 2.6-staging).
It would be sensible in the longer term to try to unify usbip with our
pvusb support.
> It would be nice if you could make the rules for usb passthrough match with
> both usb port numbers as well as device id's, perhaps even with wildcards.
Yes.
Patches will be very welcome, after the 3.4 release :-).
Thanks,
Ian.
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2009-05-05 14:24 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-21 14:17 Xen 4.0 Feature Requests Stephen Spector
2009-04-21 14:53 ` R: " Francesco Gallo
2009-04-22 14:51 ` Kashif Ali
2009-04-22 19:49 ` Alessandro R.
2009-04-23 7:27 ` Robert Dunkley
2009-04-23 13:38 ` Thiago Camargo Martins Cordeiro
2009-04-23 14:34 ` R: [Xen-users] " Robert Dunkley
2009-04-23 15:01 ` R: " Thiago Camargo Martins Cordeiro
2009-04-24 8:50 ` RE: R: [Xen-users] " Kieran Mansley
2009-04-21 16:48 ` Tim Moore
2009-04-21 17:37 ` Paul Schulze
2009-04-21 19:13 ` Jean Guyader
2009-04-22 1:08 ` Dirk Utterback
2009-04-22 1:14 ` Samuel Thibault
2009-04-22 8:08 ` Dirk Utterback
2009-04-22 8:11 ` Samuel Thibault
2009-04-21 18:43 ` Pasi Kärkkäinen
2009-04-21 20:03 ` Andy Burns
2009-04-21 20:10 ` Maximilian Wilhelm
2009-04-22 0:31 ` Philipp Schmid
2009-04-22 1:24 ` Akio Takebe
2009-04-22 1:32 ` TSC virtualization across different host frequency platform migration Dong, Eddie
2009-04-22 8:13 ` Keir Fraser
2009-04-22 8:49 ` Dong, Eddie
2009-04-22 15:47 ` Dan Magenheimer
2009-04-23 1:28 ` Dong, Eddie
2009-04-23 3:20 ` Tian, Kevin
2009-04-23 3:39 ` Dan Magenheimer
2009-04-23 6:15 ` Tian, Kevin
2009-04-23 13:58 ` Dan Magenheimer
2009-04-22 1:57 ` Xen 4.0 Feature Requests Ryo Tsuruta
2009-04-22 16:14 ` [Xen-devel] " Thiago Camargo Martins Cordeiro
2009-05-03 18:27 ` Sander Eikelenboom
2009-05-03 20:12 ` Paul Schulze
2009-05-04 5:54 ` Re[2]: " Sander Eikelenboom
2009-05-05 14:24 ` Ian Jackson
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.