public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Avi Kivity <avi@redhat.com>
Cc: kvm@vger.kernel.org, kraxel@redhat.com, anthony@codemonkey.ws,
	Sander.Vanleeuwen@sun.com, zach@vmware.com, brogers@novell.com
Subject: Re: [PATCH] Activate Virtualization On Demand v2
Date: Wed, 05 Nov 2008 12:23:12 +0100	[thread overview]
Message-ID: <49118220.4070403@suse.de> (raw)
In-Reply-To: <4911795A.6020807@redhat.com>

Avi Kivity wrote:
> Alexander Graf wrote:

[snip]

>>>>  static int kvm_resume(struct sys_device *dev)
>>>>  {
>>>> -    hardware_enable(NULL);
>>>> +    if (atomic_read(&kvm_usage_count))
>>>> +        hardware_enable(NULL);
>>>>      return 0;
>>>>  }
>>>>         
>>> Move the test to hardware_enable()?  It's repeated too often.
>>>     
>>
>> What do we do about the on_each_cpu(hardware_enable) cases? We couldn't
>> tell when to activate/deactive virtualization then, as that's
>> semantically bound to "amount of VMs".
>>   
>
> I don't understand.  Moving the test to within the IPI shouldn't
> affect anything.
>

Actually it's there already. Since we have the cpu_isset if here, we
won't get disabling when it's disabled or enabling when it's enabled on
a per-cpu basis. That code would've just saved us the IPIs :-).

So I'll add  hardware_{en,dis}able_all functions that do the locking and
increase / decrease the counter. Disable is used twice, while enable
only once. But for the sake of code readability, I think it might be a
good idea to have both of them be functions.

Also the locking isn't really needed in most cases (CPU hotplug,
suspend, resume, reboot, exit), since we don't schedule there.

Alex

  parent reply	other threads:[~2008-11-05 11:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-05  8:48 [PATCH] Activate Virtualization On Demand v2 Alexander Graf
2008-11-05 10:06 ` Avi Kivity
2008-11-05 10:28   ` Alexander Graf
2008-11-05 10:45     ` Avi Kivity
2008-11-05 10:53       ` Alexander Graf
2008-11-05 11:23       ` Alexander Graf [this message]
2008-11-05 10:45 ` Zhang, Xiantao
2008-11-05 10:54   ` Alexander Graf
2008-11-05 10:58 ` Daniel P. Berrange
2008-11-05 11:01   ` Alexander Graf
2008-11-05 13:06 ` Christian Borntraeger
2008-11-05 13:12   ` Avi Kivity
  -- strict thread matches above, loose matches on Subject: below --
2009-06-15 11:30 Alexander Graf
2009-06-15 12:17 ` Christoph Hellwig
2009-06-15 12:25   ` Alexander Graf
2009-06-15 12:27     ` Christoph Hellwig
2009-06-16 14:02   ` Avi Kivity
2009-06-16 14:01 ` Avi Kivity
2009-06-16 14:08   ` Alexander Graf
2009-06-16 15:13     ` Avi Kivity
2009-06-17 21:56       ` Alexander Graf
2009-06-18  8:35         ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49118220.4070403@suse.de \
    --to=agraf@suse.de \
    --cc=Sander.Vanleeuwen@sun.com \
    --cc=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=brogers@novell.com \
    --cc=kraxel@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=zach@vmware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox