Re: [libvirt] [PATCH resend V10 03/12] Resctrl: Add new xml element to support cache tune

On Wed, Mar 15, 2017 at 08:49:57PM +0100, Martin Kletzander wrote: > On Wed, Mar 15, 2017 at 02:11:23PM -0300, Marcelo Tosatti wrote: > >On Wed, Mar 15, 2017 at 03:59:31PM +0100, Martin Kletzander wrote: > >>On Wed, Mar 15, 2017 at 02:23:26PM +, Daniel P. Berrange wrote: &

Re: [libvirt] [PATCH resend V10 03/12] Resctrl: Add new xml element to support cache tune

On Wed, Mar 15, 2017 at 03:59:31PM +0100, Martin Kletzander wrote: > On Wed, Mar 15, 2017 at 02:23:26PM +, Daniel P. Berrange wrote: > >On Wed, Mar 15, 2017 at 03:11:26PM +0100, Martin Kletzander wrote: > >>On Mon, Mar 06, 2017 at 06:06:32PM +0800, Eli Qiao wrote: > >>> This patch adds new xml

Re: [libvirt] [PATH V10 12/12] Resctrl: Add nodecachestats

On Mon, Mar 06, 2017 at 05:50:43PM +0800, Eli Qiao wrote: > Add new virsh command line `nodecachestats` to expose the cache usage > on a node. > > Signed-off-by: Eli Qiao > --- > src/libvirt_private.syms | 3 ++- > src/qemu/qemu_driver.c | 12 ++ >

Re: [libvirt] [PATH v9 12/12] Resctrl: Add nodecachestats

On Thu, Mar 02, 2017 at 11:24:00PM -0300, Marcelo Tosatti wrote: > On Mon, Feb 27, 2017 at 03:22:56PM +0800, Eli Qiao wrote: > > Add new virsh command line `nodecachestats` to expose the cache usage > > on a node. > > Testing: > > Setup: one guest with 3072 bytes r

Re: [libvirt] [PATH v9 12/12] Resctrl: Add nodecachestats

On Mon, Feb 27, 2017 at 03:22:56PM +0800, Eli Qiao wrote: > Add new virsh command line `nodecachestats` to expose the cache usage > on a node. Testing: Setup: one guest with 3072 bytes reserved for it. Test-1: start libvirt with free cache. resctrlfs default: L3:0=f;1=f #

Re: [libvirt] [PATH v9 12/12] Resctrl: Add nodecachestats

On Thu, Mar 02, 2017 at 11:24:00PM -0300, Marcelo Tosatti wrote: > On Mon, Feb 27, 2017 at 03:22:56PM +0800, Eli Qiao wrote: > > Add new virsh command line `nodecachestats` to expose the cache usage > > on a node. > > Testing: > > Setup: one guest with 3072 bytes r

Re: [libvirt] [v7 00/10] Support cache tune in libvirt

On Tue, Feb 21, 2017 at 10:25:13AM +0800, Eli Qiao wrote: > > > -- > Best regards > Eli > > 天涯无处不重逢 > a leaf duckweed belongs to the sea, where not to meet in life > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > On Tuesday, 21 Fe

Re: [libvirt] [v7 00/10] Support cache tune in libvirt

On Mon, Feb 20, 2017 at 04:32:19PM +0800, Eli Qiao wrote: > > > -- > Best regards > Eli > > 天涯无处不重逢 > a leaf duckweed belongs to the sea, where not to meet in life > > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > On Sunday, 19 Feb

Re: [libvirt] [v7 00/10] Support cache tune in libvirt

On Sun, Feb 19, 2017 at 12:01:57PM -0300, Marcelo Tosatti wrote: > > How does the management software query the amount of allocatable cache > again? > > Section from another discussion: > > > The second case is necessary to get updated free space information. > &g

Re: [libvirt] [v7 00/10] Support cache tune in libvirt

How does the management software query the amount of allocatable cache again? Section from another discussion: > The second case is necessary to get updated free space information. > Just VM initialization time could be enough as virConnectGetCapabilities would just know the total and free

Re: [libvirt] [v7 00/10] Support cache tune in libvirt

Hi Eli Qiao, Question about removing resctrlfs directories with empty "tasks" file. /* This domain is not created by libvirt, so we don't care * about the tasks, add a fake one to prevent * virResCtrlRefresh * remove it from sysfs */

Re: [libvirt] [v6 09/10] Resctrl: concurrence support

On Wed, Feb 15, 2017 at 01:41:52PM +0800, Eli Qiao wrote: > The internal struct list domainall is a list which are resctral domain > status shared by all VMs, especiall the default domain, each VM should > access it concomitantly. Ues a mutex to control it. > > Each bank's cache_left field is

Re: [libvirt] [v5 0/9] Support cache tune in libvirt

On Mon, Feb 13, 2017 at 03:46:38PM +0800, Eli Qiao wrote: > Addressed comment from v4 -> v5: > > Marcelo: >* Several typos >* Use flock instead of virFileLock > > Addressed comment from v3 -> v4: > > Daniel & Marcelo: >* Added concurrence support > > Addressed comment

Re: [libvirt] [v4 0/9] Support cache tune in libvirt

On Tue, Feb 14, 2017 at 09:37:02AM +0100, Martin Kletzander wrote: > On Mon, Feb 13, 2017 at 04:09:13PM -0200, Marcelo Tosatti wrote: > >On Mon, Feb 13, 2017 at 03:42:04PM +0800, Eli Qiao wrote: > >>> > L3data:0=0xff00;... > >>> > L3code:0=0xff00;... > >

Re: [libvirt] [v4 0/9] Support cache tune in libvirt

On Tue, Feb 14, 2017 at 04:59:52PM +0800, Eli Qiao wrote: > > > -- > Eli Qiao > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > On Tuesday, 14 February 2017 at 4:37 PM, Martin Kletzander wrote: > > > On Mon, Feb 13, 2017 at 04:09:13PM -0200, Ma

Re: [libvirt] [v4 0/9] Support cache tune in libvirt

On Mon, Feb 13, 2017 at 03:42:04PM +0800, Eli Qiao wrote: > > > L3data:0=0xff00;... > > > L3code:0=0xff00;... > > > > > > * Would you please help to test if the functions work. > > > > Setting up CDP machine. > > > > Unrelated: > > > > Found a bug: > > > > The code should scan for all

Re: [libvirt] [RFC v3 1/8] Resctrl: Add some utils functions

On Thu, Feb 09, 2017 at 03:43:02PM +0800, Eli Qiao wrote: > This patch adds some utils struct and functions to expose resctrl > information. > > virResCtrlAvailable: If resctrl interface exist on host > virResCtrlGet: get specify type resource contral information > virResCtrlInit: initialize

Re: [libvirt] [RFC v3 0/8] Support cache tune in libvirt

On Fri, Feb 10, 2017 at 09:58:19AM +0800, Eli Qiao wrote: > > > -- > Eli Qiao > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > On Thursday, 9 February 2017 at 10:25 PM, Marcelo Tosatti wrote: > > > On Thu, Feb 09, 2017 at 03:43:01PM +0800

Re: [libvirt] [RFC v3 3/8] Resctrl: Add new xml element to support cache tune

On Thu, Feb 09, 2017 at 03:43:04PM +0800, Eli Qiao wrote: > This patch adds new xml element to support cache tune as: > > > ... > vcpus='1,2'/> > ... > > > id: any non-minus number > host_id: reference of the host's cache banks id, it's from capabilities > type: cache bank type >

Re: [libvirt] [v4 0/9] Support cache tune in libvirt

On Fri, Feb 10, 2017 at 02:42:04PM +0800, Eli Qiao wrote: > Addressed comment from v3 -> v4: > > Daniel & Marcelo: >* Added concurrence support > > Addressed comment from v2 -> v3: > > Daniel: > * Fixed coding style, passed `make check` and `make syntax-check` > > *

Re: [libvirt] [RFC v3 0/8] Support cache tune in libvirt

On Thu, Feb 09, 2017 at 03:43:01PM +0800, Eli Qiao wrote: > Addressed comment from v2 -> v3: > > Daniel: > * Fixed coding style, passed `make check` and `make syntax-check` > > * Variables renaming and move from header file to c file. > > * For locking/mutex support, no

Re: [libvirt] [resend v2 0/7] Support cache tune in libvirt

On Wed, Feb 08, 2017 at 10:19:07AM +0800, Eli Qiao wrote: > > > -- > Eli Qiao > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > On Tuesday, 7 February 2017 at 7:56 PM, Marcelo Tosatti wrote: > > > On Tue, Feb 07, 2017 at

Re: [libvirt] [resend v2 0/7] Support cache tune in libvirt

On Tue, Feb 07, 2017 at 10:17:37AM +, Daniel P. Berrange wrote: > On Tue, Feb 07, 2017 at 02:43:13PM +0800, Eli Qiao wrote: > > > 3) CDP / non-CDP convertion. > > > > > > In case the size determination has been performed with non-CDP, > > > to emulate such allocation on a CDP host, > > > it

Re: [libvirt] [resend v2 0/7] Support cache tune in libvirt

On Tue, Feb 07, 2017 at 02:43:13PM +0800, Eli Qiao wrote: > > > -- > Eli Qiao > Sent with Sparrow (http://www.sparrowmailapp.com/?sig) > > > On Tuesday, 7 February 2017 at 3:03 AM, Marcelo Tosatti wrote: > > > On Mon, Feb 06, 2017 at 01:33:09PM -0200, Ma

Re: [libvirt] [resend v2 0/7] Support cache tune in libvirt

On Mon, Feb 06, 2017 at 01:33:09PM -0200, Marcelo Tosatti wrote: > On Mon, Feb 06, 2017 at 10:23:35AM +0800, Eli Qiao wrote: > > This series patches are for supportting CAT featues, which also > > called cache tune in libvirt. > > > > First to expose cache infor

Re: [libvirt] [resend v2 0/7] Support cache tune in libvirt

On Mon, Feb 06, 2017 at 10:23:35AM +0800, Eli Qiao wrote: > This series patches are for supportting CAT featues, which also > called cache tune in libvirt. > > First to expose cache information which could be tuned in capabilites XML. > Then add new domain xml element support to add cacahe bank

Re: [libvirt] [PATCH 1/2] Resctrl: Add some utils functions

Hi Eli Qiao, On Wed, Jan 18, 2017 at 03:26:19PM +0800, Eli Qiao wrote: > This patch adds some utils struct and functions to expose resctrl > information. > > virResCtrlAvailable: If resctrl interface exist on host > virResCtrlGet: get specify type resource contral information > virResCtrlInit:

Re: [libvirt] [V4] RFC for support cache tune(CAT) in libvirt

On Fri, Jan 13, 2017 at 09:41:22AM +, Daniel P. Berrange wrote: > On Fri, Jan 13, 2017 at 09:38:44AM +0800, 乔立勇(Eli Qiao) wrote: > > > > virsh capabilities > > > > > > > > > > > > > > <- level 3 cache is per socket, so group them by > > socket id > > > >

Re: [libvirt] [PATCH v3 0/2] Allow migration with invtsc if TSC frequency is explicitly set

C frequency is not > specified explicitly. It will be a bit more complex because it > requires either letting the destination abort the migration, or > sending TSC frequency/scaling information from destination to > source. > > --- > Cc: Marcelo Tosatti <mtosa...@redhat.com>

Re: [libvirt] TSC frequency configuration & invtsc migration (was Re: [PATCH 4/4] kvm: Allow migration with invtsc)

On Tue, Jan 10, 2017 at 05:36:48PM +0100, Paolo Bonzini wrote: > > > On 05/01/2017 11:48, Marcelo Tosatti wrote: > >> Host A has TSC scaling, host B doesn't have TSC scaling. We want > >> to be able to start the VM on host A, and migrate to B. In this > >&

Re: [libvirt] "[V3] RFC for support cache tune in libvirt"

On Thu, Jan 12, 2017 at 11:06:06AM +, Daniel P. Berrange wrote: > On Thu, Jan 12, 2017 at 08:48:01AM -0200, Marcelo Tosatti wrote: > > On Thu, Jan 12, 2017 at 09:44:36AM +0800, 乔立勇(Eli Qiao) wrote: > > > hi, It's really good to have you get involved to support CAT in >

Re: [libvirt] "[V3] RFC for support cache tune in libvirt"

On Thu, Jan 12, 2017 at 09:44:36AM +0800, 乔立勇(Eli Qiao) wrote: > hi, It's really good to have you get involved to support CAT in > libvirt/OpenStack. > replied inlines. > > 2017-01-11 20:19 GMT+08:00 Marcelo Tosatti <mtosa...@redhat.com>: > > > > > Hi

Re: [libvirt] "[V3] RFC for support cache tune in libvirt"

On Thu, Jan 12, 2017 at 08:47:58AM -0200, Marcelo Tosatti wrote: > On Thu, Jan 12, 2017 at 09:44:36AM +0800, 乔立勇(Eli Qiao) wrote: > > hi, It's really good to have you get involved to support CAT in > > libvirt/OpenStack. > > replied inlines. > > > > 2017-01-1

Re: [libvirt] "[V3] RFC for support cache tune in libvirt"

On Wed, Jan 11, 2017 at 10:34:00AM -0200, Marcelo Tosatti wrote: > On Wed, Jan 11, 2017 at 10:19:10AM -0200, Marcelo Tosatti wrote: > > > > Hi, > > > > Comments/questions related to: > > https://www.redhat.com/archives/libvir-list/2017-January/msg00354.html

Re: [libvirt] OpenStack/libvirt CAT interface

On Wed, Jan 11, 2017 at 10:18:11AM +, Daniel P. Berrange wrote: > On Tue, Jan 10, 2017 at 02:18:43PM -0200, Marcelo Tosatti wrote: > > > > There have been queries about the OpenStack interface > > for CAT: > > FYI, there's another mail discussing libvir

Re: [libvirt] "[V3] RFC for support cache tune in libvirt"

On Wed, Jan 11, 2017 at 10:19:10AM -0200, Marcelo Tosatti wrote: > > Hi, > > Comments/questions related to: > https://www.redhat.com/archives/libvir-list/2017-January/msg00354.html > > 1) root s2600wt:~/linux# virsh cachetune kvm02 --l3.count 2 > > How does alloca

Re: [libvirt] "[V3] RFC for support cache tune in libvirt"

Hi, Comments/questions related to: https://www.redhat.com/archives/libvir-list/2017-January/msg00354.html 1) root s2600wt:~/linux# virsh cachetune kvm02 --l3.count 2 How does allocation of code/data look like? 2) 'nodecachestats' command: 3. Add new virsh command 'nodecachestats':

Re: [libvirt] OpenStack/libvirt CAT interface

On Tue, Jan 10, 2017 at 02:18:41PM -0200, Marcelo Tosatti wrote: > > There have been queries about the OpenStack interface > for CAT: > > http://bugzilla.redhat.com/show_bug.cgi?id=1299678 > > Comment 2 says: > Sahid Ferdjaoui 2016-01-19 10:58:48 EST > A spec will

[libvirt] OpenStack/libvirt CAT interface

There have been queries about the OpenStack interface for CAT: http://bugzilla.redhat.com/show_bug.cgi?id=1299678 Comment 2 says: Sahid Ferdjaoui 2016-01-19 10:58:48 EST A spec will have to be addressed, after a first look this feature needs some work in several components of Nova to

Re: [libvirt] TSC frequency configuration & invtsc migration (was Re: [PATCH 4/4] kvm: Allow migration with invtsc)

On Thu, Jan 05, 2017 at 10:19:50AM -0200, Eduardo Habkost wrote: > On Thu, Jan 05, 2017 at 08:48:32AM -0200, Marcelo Tosatti wrote: > > On Wed, Jan 04, 2017 at 11:36:31PM -0200, Eduardo Habkost wrote: > > > On Wed, Jan 04, 2017 at 08:26:27PM -0200, Marcelo Tosatti wrote: >

Re: [libvirt] TSC frequency configuration & invtsc migration (was Re: [PATCH 4/4] kvm: Allow migration with invtsc)

On Thu, Jan 05, 2017 at 08:48:32AM -0200, Marcelo Tosatti wrote: > > Note that even if we follow your suggestion and implement an > > alternative version of patch 4/4 to cover your use case, I will > > strongly recommend libvirt developers to support configuring TSC > >

Re: [libvirt] TSC frequency configuration & invtsc migration (was Re: [PATCH 4/4] kvm: Allow migration with invtsc)

On Wed, Jan 04, 2017 at 11:36:31PM -0200, Eduardo Habkost wrote: > On Wed, Jan 04, 2017 at 08:26:27PM -0200, Marcelo Tosatti wrote: > > On Wed, Jan 04, 2017 at 05:59:17PM -0200, Eduardo Habkost wrote: > > > On Wed, Jan 04, 2017 at 11:39:16AM -0200, Eduardo Habkost wrote: >

Re: [libvirt] TSC frequency configuration & invtsc migration (was Re: [PATCH 4/4] kvm: Allow migration with invtsc)

On Wed, Jan 04, 2017 at 05:59:17PM -0200, Eduardo Habkost wrote: > On Wed, Jan 04, 2017 at 11:39:16AM -0200, Eduardo Habkost wrote: > > On Wed, Jan 04, 2017 at 09:56:56AM -0200, Marcelo Tosatti wrote: > > > On Tue, Dec 27, 2016 at 05:21:20PM -0200, Eduardo Habkost wrot

Re: [libvirt] [PATCHv2 libvirt] qemu: Issue rtc-reset-reinjection command after guest-set-time

On Mon, Aug 18, 2014 at 06:29:42PM +0200, Michal Privoznik wrote: On 18.08.2014 17:28, Eric Blake wrote: On 08/14/2014 02:24 AM, Michal Privoznik wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1103245 An advice appeared there on the qemu-devel list [1]. When a domain is suspended and

Re: [libvirt] [PATCHv2 libvirt] qemu: Issue rtc-reset-reinjection command after guest-set-time

On Tue, Aug 19, 2014 at 11:00:26AM -0600, Eric Blake wrote: On 08/19/2014 10:57 AM, Marcelo Tosatti wrote: rtc-reset-reinjection has been introduced because certain Windows versions will advance the guest system time (via rtc interrupt reinjection). So if libvirt adjusts the guest

Re: [libvirt] [Qemu-devel] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for clock offset='variable' basis='utc'/

On Fri, May 23, 2014 at 11:36:56PM +0200, Paolo Bonzini wrote: You can get the current time via the qom-get command, and then follow the same algorithm as QEMU: time_t seconds; if (rtc_date_offset == -1) { if (rtc_utc) { seconds = mktimegm(tm); } else

Re: [libvirt] [PATCHv2 1/4] util: new function virTimeLocalOffsetFromUTC

On Fri, May 23, 2014 at 02:43:08PM +0300, Laine Stump wrote: On 05/22/2014 09:49 PM, Marcelo Tosatti wrote: On Thu, May 22, 2014 at 02:07:27PM +0300, Laine Stump wrote: Since there isn't a single libc API to get this value, this patch supplies one which gets the value by grabbing current

Re: [libvirt] [Qemu-devel] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for clock offset='variable' basis='utc'/

On Fri, May 23, 2014 at 03:35:19PM +0200, Markus Armbruster wrote: Luiz Capitulino lcapitul...@redhat.com writes: On Fri, 23 May 2014 00:50:38 -0300 Marcelo Tosatti mtosa...@redhat.com wrote: Then the guest triggers an RTC update, so qemu sends an event, but the event is lost

Re: [libvirt] [Qemu-devel] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for clock offset='variable' basis='utc'/

On Fri, May 23, 2014 at 10:48:18AM -0300, Marcelo Tosatti wrote: On Fri, May 23, 2014 at 03:35:19PM +0200, Markus Armbruster wrote: Luiz Capitulino lcapitul...@redhat.com writes: On Fri, 23 May 2014 00:50:38 -0300 Marcelo Tosatti mtosa...@redhat.com wrote: Then the guest

Re: [libvirt] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for clock offset='variable' basis='utc'/

On Fri, May 23, 2014 at 08:54:54AM -0600, Eric Blake wrote: On 05/23/2014 04:19 AM, Laine Stump wrote: On 05/23/2014 12:17 PM, Laine Stump wrote: *However*, this discussion forced me to investigate some of the basic assumptions that I'd been making when coming in to fix this bug. In

Re: [libvirt] [PATCHv2 1/4] util: new function virTimeLocalOffsetFromUTC

On Thu, May 22, 2014 at 02:07:27PM +0300, Laine Stump wrote: Since there isn't a single libc API to get this value, this patch supplies one which gets the value by grabbing current UTC, then converting that into a struct tm with localtime_r(), then back to a time_t using mktime; it again does

Re: [libvirt] [PATCHv2 3/4] qemu: fix RTC_CHANGE event for clock offset='variable' basis='utc'/

On Thu, May 22, 2014 at 01:33:14PM -0600, Eric Blake wrote: [Adding qemu] On 05/22/2014 05:07 AM, Laine Stump wrote: commit e31b5cf393857 attempted to fix libvirt's VIR_DOMAIN_EVENT_ID_RTC_CHANGE, which is documentated to always s/documentated/documented/ provide the new offset of

Re: [libvirt] [RFC PATCH] Add support for invtsc timer

On Tue, May 06, 2014 at 03:27:20PM +0200, Ján Tomko wrote: Not yet merged in upstream QEMU: https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg05024.html Add support for invariant TSC timer running at constant rate in all ACPI P-, C- and T-states. It can be enabled by specifying:

Re: [libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

On Mon, Mar 17, 2014 at 09:39:54AM +, Daniel P. Berrange wrote: On Fri, Mar 14, 2014 at 06:52:19PM -0300, Marcelo Tosatti wrote: On Tue, Feb 04, 2014 at 11:54:22AM -0500, Marcelo Tosatti wrote: On Tue, Feb 04, 2014 at 04:42:02PM +, Daniel P. Berrange wrote: On Tue, Feb 04, 2014

Re: [libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

On Tue, Feb 04, 2014 at 11:54:22AM -0500, Marcelo Tosatti wrote: On Tue, Feb 04, 2014 at 04:42:02PM +, Daniel P. Berrange wrote: On Tue, Feb 04, 2014 at 11:32:47AM -0500, Marcelo Tosatti wrote: Add an element named strict-hugepages to control whether to refuse guest

Re: [libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

On Fri, Mar 14, 2014 at 06:52:19PM -0300, Marcelo Tosatti wrote: On Tue, Feb 04, 2014 at 11:54:22AM -0500, Marcelo Tosatti wrote: On Tue, Feb 04, 2014 at 04:42:02PM +, Daniel P. Berrange wrote: On Tue, Feb 04, 2014 at 11:32:47AM -0500, Marcelo Tosatti wrote: Add an element named

Re: [libvirt] [PATCH] qemu driver: sync guest time via qemu-guest-agent when domain is resumed

On Wed, Feb 12, 2014 at 10:22:11AM +, Daniel P. Berrange wrote: I agree that this should be a completely separate command, not merely a flag to the Resume API. The reason is that you cannot do sensible error reporting if you overload this in one API call. ie consider that resuming the

Re: [libvirt] [PATCH] qemu driver: sync guest time via qemu-guest-agent when domain is resumed

On Wed, Feb 12, 2014 at 06:45:28PM -0200, Marcelo Tosatti wrote: On Wed, Feb 12, 2014 at 10:22:11AM +, Daniel P. Berrange wrote: I agree that this should be a completely separate command, not merely a flag to the Resume API. The reason is that you cannot do sensible error reporting

Re: [libvirt] [PATCH] qemu driver: sync guest time via qemu-guest-agent when domain is resumed

On Tue, Feb 11, 2014 at 11:48:58AM +0100, Michal Privoznik wrote: On 11.02.2014 01:04, Marcelo Tosatti wrote: On Mon, Feb 10, 2014 at 03:42:45PM -0700, Eric Blake wrote: On 02/10/2014 03:10 PM, Marcelo Tosatti wrote: Since QEMU commit kvmclock: clock should count only if vm is running (http

Re: [libvirt] [PATCH] qemu driver: sync guest time via qemu-guest-agent when domain is resumed

On Tue, Feb 11, 2014 at 02:45:28PM -0700, Eric Blake wrote: On 02/11/2014 02:37 PM, Marcelo Tosatti wrote: I think we may need both approaches. I too think that resume with syncing guest time is so common use case that is deserves to be exposed as a single operation outside the libvirt

[libvirt] [PATCH] qemu driver: sync guest time via qemu-guest-agent when domain is resumed

Since QEMU commit kvmclock: clock should count only if vm is running (http://lists.gnu.org/archive/html/qemu-devel/2013-06/msg01225.html), guests have their realtime clock stopped during pause. To correct the situation, invoke guest agent to sync time from host time. Signed-off-by: Marcelo

Re: [libvirt] [PATCH] qemu driver: sync guest time via qemu-guest-agent when domain is resumed

On Mon, Feb 10, 2014 at 03:42:45PM -0700, Eric Blake wrote: On 02/10/2014 03:10 PM, Marcelo Tosatti wrote: Since QEMU commit kvmclock: clock should count only if vm is running (http://lists.gnu.org/archive/html/qemu-devel/2013-06/msg01225.html), guests have their realtime clock stopped

[libvirt] [PATCH] add option to enforce minimal pagesize for hugetlbfs backed guests

Require a minimal pagesize for hugetlbfs backed guests. Fail guest initialization if hugetlbfs mount is configured with smaller page size. Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index fd02864..e28d182 100644

Re: [libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

On Wed, Feb 05, 2014 at 09:49:53AM +, Daniel P. Berrange wrote: On Tue, Feb 04, 2014 at 03:04:11PM -0700, Eric Blake wrote: On 02/04/2014 02:57 PM, Marcelo Tosatti wrote: So perhaps we do need some policy attribute on the hugepages/ element to indicate desired behaviour here

[libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

Add an element named strict-hugepages to control whether to refuse guest initialization in case hugepage allocation cannot be performed. Signed-off-by: Marcelo Tosatti mtosa...@redhat.com diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index ff50214..e79f5e6 100644

Re: [libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

On Tue, Feb 04, 2014 at 04:42:02PM +, Daniel P. Berrange wrote: On Tue, Feb 04, 2014 at 11:32:47AM -0500, Marcelo Tosatti wrote: Add an element named strict-hugepages to control whether to refuse guest initialization in case hugepage allocation cannot be performed. Signed-off

Re: [libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

On Tue, Feb 04, 2014 at 04:42:02PM +, Daniel P. Berrange wrote: On Tue, Feb 04, 2014 at 11:32:47AM -0500, Marcelo Tosatti wrote: Add an element named strict-hugepages to control whether to refuse guest initialization in case hugepage allocation cannot be performed. Signed-off

Re: [libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

You're OK with StrictHugePageSize=N element ? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

On Tue, Feb 04, 2014 at 05:10:13PM +, Daniel P. Berrange wrote: Because there is no guarantee with -mem-prealloc. For instance, if the hugepage path is not actually hugetlbfs backed, QEMU falls back to malloc(). Well if you can't fix -mem-prealloc to properly report errors for reasons

Re: [libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

On Tue, Feb 04, 2014 at 05:26:31PM +, Daniel P. Berrange wrote: On Tue, Feb 04, 2014 at 12:22:00PM -0500, Marcelo Tosatti wrote: You're OK with StrictHugePageSize=N element ? I'm not entirely sure what that would do ? Is that for when people want to have a specific size of hugepages

Re: [libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

On Tue, Feb 04, 2014 at 05:26:31PM +, Daniel P. Berrange wrote: On Tue, Feb 04, 2014 at 12:22:00PM -0500, Marcelo Tosatti wrote: You're OK with StrictHugePageSize=N element ? I'm not entirely sure what that would do ? Is that for when people want to have a specific size of hugepages

Re: [libvirt] [PATCH] add flag to enforce hugepage backing of guest RAM

On Tue, Feb 04, 2014 at 03:04:11PM -0700, Eric Blake wrote: On 02/04/2014 02:57 PM, Marcelo Tosatti wrote: So perhaps we do need some policy attribute on the hugepages/ element to indicate desired behaviour here. What about the following new element under hugepages

Re: [libvirt] [PATCH v2] kvm: warn if num cpus is greater than num recommended

On Fri, Aug 23, 2013 at 03:24:37PM +0200, Andrew Jones wrote: The comment in kvm_max_vcpus() states that it's using the recommended procedure from the kernel API documentation to get the max number of vcpus that kvm supports. It is, but by always returning the maximum number supported. The

Re: [libvirt] TSC scaling interface to management

On Tue, Sep 25, 2012 at 11:08:58AM +0100, Daniel P. Berrange wrote: On Wed, Sep 12, 2012 at 12:39:39PM -0300, Marcelo Tosatti wrote: HW TSC scaling is a feature of AMD processors that allows a multiplier to be specified to the TSC frequency exposed to the guest. KVM also contains

Re: [libvirt] TSC scaling interface to management

On Fri, Sep 21, 2012 at 11:30:31PM +0300, Dor Laor wrote: On 09/21/2012 05:51 AM, Marcelo Tosatti wrote: On Fri, Sep 21, 2012 at 12:02:46AM +0300, Dor Laor wrote: On 09/12/2012 06:39 PM, Marcelo Tosatti wrote: HW TSC scaling is a feature of AMD processors that allows a multiplier

Re: [libvirt] TSC scaling interface to management

On Fri, Sep 21, 2012 at 12:02:46AM +0300, Dor Laor wrote: On 09/12/2012 06:39 PM, Marcelo Tosatti wrote: HW TSC scaling is a feature of AMD processors that allows a multiplier to be specified to the TSC frequency exposed to the guest. KVM also contains provision to trap TSC (KVM

[libvirt] TSC scaling interface to management

HW TSC scaling is a feature of AMD processors that allows a multiplier to be specified to the TSC frequency exposed to the guest. KVM also contains provision to trap TSC (KVM: Infrastructure for software and hardware based TSC rate scaling cc578287e3224d0da) or advance TSC frequency. This is