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
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 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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
-----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----- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 > > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
2009/4/21 Pasi Kärkkäinen <pasik@iki.fi>:> Online resizing of domU disks.+1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Anno domini 2009 Andy Burns scripsit:> 2009/4/21 Pasi Kärkkäinen <pasik@iki.fi>: > > > Online resizing of domU disks.> +1Add me ;) Ciao Max -- Follow the white penguin. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Stephen Spector pisze:> > 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-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-usersHello, I have a question a when xen 3.4-rc2 becomes officially stable version? How long will take the time to test this version became the official stable version? For@ll _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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
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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dong, Eddie
2009-Apr-22 01:32 UTC
[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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Apr-22 08:13 UTC
[Xen-devel] Re: TSC virtualization across different host frequency platform migration
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._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dong, Eddie
2009-Apr-22 08:49 UTC
[Xen-devel] RE: TSC virtualization across different host frequency platform migration
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-secondThat is what I am interested too. Is there any report from real deployment which utilize migration frequently? thx, eddie _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Dan Magenheimer
2009-Apr-22 15:47 UTC
RE: [Xen-devel] TSC virtualization across different host frequency platform migration
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thiago Camargo Martins Cordeiro
2009-Apr-22 16:14 UTC
[Xen-users] Re: [Xen-devel] Xen 4.0 Feature Requests
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 > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/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. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
stable support for passing through usb-controllers/devices and pci-devices for paravirtualized guests would be really great. greetings franz ----- Ursprüngliche Mail ---- Von: Alessandro R. <lord2y@gmail.com> An: Kashif Ali <kashif_quaidian@hotmail.com> CC: cluster@xinet.it; xen-devel@lists.xensource.com; stephen.spector@citrix.com; xen-users@lists.xensource.com Gesendet: Mittwoch, den 22. April 2009, 21:49:33 Uhr Betreff: 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 _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Dong, Eddie
2009-Apr-23 01:28 UTC
RE: [Xen-devel] TSC virtualization across different host frequency platform migration
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tian, Kevin
2009-Apr-23 03:20 UTC
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Dan Magenheimer
2009-Apr-23 03:39 UTC
RE: [Xen-devel] TSC virtualization across different host frequency platform migration
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Tian, Kevin
2009-Apr-23 06:15 UTC
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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
Thiago Camargo Martins Cordeiro
2009-Apr-23 13:38 UTC
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 >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Dan Magenheimer
2009-Apr-23 13:58 UTC
RE: [Xen-devel] TSC virtualization across different host frequency platform migration
> 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 > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Robert Dunkley
2009-Apr-23 14:34 UTC
[Xen-devel] RE: R: [Xen-users] Xen 4.0 Feature Requests
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thiago Camargo Martins Cordeiro
2009-Apr-23 15:01 UTC
Re: R: [Xen-users] Xen 4.0 Feature Requests
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 >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Kieran Mansley
2009-Apr-24 08:50 UTC
Re: [Xen-devel] RE: R: [Xen-users] Xen 4.0 Feature Requests
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
-----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----- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel