On Fri, 2010-12-31 at 17:10 +0800, Jan Kiszka wrote:
> Am 31.12.2010 06:22, Huang Ying wrote:
> > In Linux kernel HWPoison processing implementation, the virtual
> > address in processes mapping the error physical memory page is marked
> > as HWPoison. So that, the further accessing to the virtual
On Tue, 2011-01-04 at 16:32 +0800, Jan Kiszka wrote:
> From: Jan Kiszka
>
> There is no need to restrict writing back MCE MSRs to reset or full
> state updates as setting their values has no side effects.
Sorry for late.
The MCE MSRs contents is sticky for warm reset except MCG_STATUS, so
their
On 01/04/2011 05:36 AM, Marcelo Tosatti wrote:
On Tue, Dec 28, 2010 at 07:38:18PM -1000, Zachary Amsden wrote:
During a host suspend, TSC may go backwards, which KVM interprets
as an unstable TSC. Technically, KVM should not be marking the
TSC unstable, which causes the TSC clocksource to g
> NAK NAK NAK, yield_to is utter crap, and the only reason kvm 'needs' it
> is because its wants to be utter crap (run unmodified guests).
>
> There is plenty of sane serialization primitives for userspace, fix your
> locking mess instead of pushing crap.
>
> The only reason I'm maybe half-way co
> On 01/04/2011 08:14 AM, KOSAKI Motohiro wrote:
> > Also, If pthread_cond_signal() call sys_yield_to imlicitly, we can
> > avoid almost Nehalem (and other P2P cache arch) lock unfairness
> > problem. (probaby creating pthread_condattr_setautoyield_np or similar
> > knob is good one)
>
> Often, th
Il 05/01/2011 00:38, Tommaso Cucinotta ha scritto:
Of course, don't misunderstand me: this is a necessary condition for a
stable performance of KVM VMs, I'm not saying it is sufficient for
... it.
Please, comment on this (reply to all, please, I'm not following LKML).
Thanks,
Tommaso
--
Il 04/01/2011 19:15, Dario Faggioli ha scritto:
Forwarded Message
From: Peter Zijlstra
To: Rik van Riel
Cc: Hillf Danton,kvm@vger.kernel.org,
linux-ker...@vger.kernel.org, Avi Kiviti, Srivatsa
Vaddagiri, Mike Galbraith,
Chris Wright
Subject: Re: [RFC -v3 PATCH 2/3] sched: add y
On Tue, Jan 04, 2011 at 08:17:26AM -0600, Anthony Liguori wrote:
> On 01/03/2011 04:01 AM, Avi Kivity wrote:
> >On 01/03/2011 11:46 AM, Jan Kiszka wrote:
> >>Hi,
> >>
> >>at least in kvm mode, the qemu_fair_mutex seems to have lost its
> >>function of balancing qemu_global_mutex access between the
On Sun, Jan 02, 2011 at 08:33:13PM +0100, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Obviously a merge artifact.
>
> Signed-off-by: Jan Kiszka
> ---
> target-i386/kvm.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
Applied, thanks.
--
To unsubscribe from this list: send the line
On 01/04/2011 08:20 AM, Marcelo Tosatti wrote:
On Tue, Dec 28, 2010 at 07:38:20PM -1000, Zachary Amsden wrote:
On systems with synchronized TSCs, we still have VCPU individual
KVM clocks, each with their own computed offset. As this all happens
at different times, the computed KVM clock off
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 29.12.2010, at 20:51, Peter Tyser wrote:
> Previously SPRGs 4-7 were improperly read and written in
> kvm_arch_vcpu_ioctl_get_regs() and kvm_arch_vcpu_ioctl_set_regs();
>
> Signed-off-by: Peter Tyser
Thanks a lot for the catch. At least for Boo
From: Jan Kiszka
Make sure to re-register the IRQ of an assigned device as INTx when the
guest disables MSI[X] mode again.
Signed-off-by: Jan Kiszka
---
hw/device-assignment.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/hw/device-assignment.c b/hw/device-assig
On Wed, Dec 29, 2010 at 07:53:39PM +0100, Jan Kiszka wrote:
> From: Jan Kiszka
>
> kvm_arch_reset_vcpu includes the same logic (minus the obsolete feature
> check), and every caller of kvm_reset_mpstate also calls that function.
>
> Signed-off-by: Jan Kiszka
> ---
> qemu-kvm-x86.c | 16 -
On Fri, Dec 31, 2010 at 01:22:34PM +0800, Huang Ying wrote:
> qemu_ram_remap() unmaps the specified RAM pages, then re-maps these
> pages again. This is used by KVM HWPoison support to clear HWPoisoned
> page tables across guest rebooting, so that a new page may be
> allocated later to recover the
On Tue, 2011-01-04 at 19:04 +0100, Peter Zijlstra wrote:
> > + p_cfs_rq = cfs_rq_of(pse);
> > + yield = 1;
> > + }
> > +#endif
> > +
> > + if (yield)
> > + clear_buddies(cfs_rq, se);
> > + else if (preempt)
> > + clear_buddies(p_cfs_rq, curr);
> > +
>
The PCI sysfs rom file is exposed read-only by default, but we need
to write to it to enable and disable the ROM around the read. When
running as root, the code works fine as is, but when running
de-privileged via libvirt, the fopen("r+") will fail if the file
doesn't have owner write permissions.
On Tue, 2011-01-04 at 10:30 -0800, Chris Wright wrote:
> * Alex Williamson (alex.william...@redhat.com) wrote:
> > The PCI sysfs rom file is exposed read-only by default, but we need
> > to write to it to enable and disable the ROM around the read. When
> > running as root, the code works fine as
* Alex Williamson (alex.william...@redhat.com) wrote:
> The PCI sysfs rom file is exposed read-only by default, but we need
> to write to it to enable and disable the ROM around the read. When
> running as root, the code works fine as is, but when running
> de-privileged via libvirt, the fopen("r+
On Tue, Dec 28, 2010 at 07:38:18PM -1000, Zachary Amsden wrote:
> During a host suspend, TSC may go backwards, which KVM interprets
> as an unstable TSC. Technically, KVM should not be marking the
> TSC unstable, which causes the TSC clocksource to go bad, but
> should be adjusting the TSC offsets
On Tue, Dec 28, 2010 at 07:38:20PM -1000, Zachary Amsden wrote:
> On systems with synchronized TSCs, we still have VCPU individual
> KVM clocks, each with their own computed offset. As this all happens
> at different times, the computed KVM clock offset can vary, causing a
> globally visible backw
On Mon, Dec 27, 2010 at 12:08:45PM +0200, Avi Kivity wrote:
> Instead, drop large mappings, which were the reason we dropped shadow.
>
> Signed-off-by: Avi Kivity
> ---
>
> v2: maintain largepage stats
>
> arch/x86/kvm/mmu.c | 12
> virt/kvm/kvm_main.c |7 +--
> 2 files
The PCI sysfs rom file is exposed read-only by default, but we need
to write to it to enable and disable the ROM around the read. When
running as root, the code works fine as is, but when running
de-privileged via libvirt, the fopen("r+") will fail if the file
doesn't have owner write permissions.
On Tue, 2011-01-04 at 12:53 -0500, Rik van Riel wrote:
> One host can have a few RT guests, say a host with 8 CPUs
> can have up to 6 or 7 RT VCPUs. Those guests get top
> priority.
RT guests don't make sense, there's nowhere near enough infrastructure
for that to work well.
I'd argue that KVM
On Mon, 2011-01-03 at 16:29 -0500, Rik van Riel wrote:
> From: Mike Galbraith
>
> Add a yield_to function to the scheduler code, allowing us to
> give enough of our timeslice to another thread to allow it to
> run and release whatever resource we need it to release.
>
> We may want to use this t
On 01/04/2011 12:08 PM, Peter Zijlstra wrote:
On Wed, 2011-01-05 at 00:51 +0800, Hillf Danton wrote:
Where is the yield_to callback in the patch for RT schedule class?
If @p is RT, what could you do?
RT guests are a pipe dream, you first need to get the hypervisor (kvm in
this case) to be RT,
On Wed, 2011-01-05 at 01:12 +0800, Hillf Danton wrote:
> On Wed, Jan 5, 2011 at 1:08 AM, Peter Zijlstra wrote:
> > On Wed, 2011-01-05 at 00:51 +0800, Hillf Danton wrote:
> >> Where is the yield_to callback in the patch for RT schedule class?
> >> If @p is RT, what could you do?
> >
> > RT guests a
On Tue, 2011-01-04 at 11:26 +0100, Mike Galbraith wrote:
> On Tue, 2011-01-04 at 11:14 +0200, Avi Kivity wrote:
>
> > Assuming there are no objections, Mike, can you get 2/3 into a
> > fast-forward-only branch of tip.git? I'll then merge it into kvm.git
> > and apply 1/3 and 2/3.
>
> Wrong guy
On Tue, 2011-01-04 at 15:14 +0900, KOSAKI Motohiro wrote:
> > From: Mike Galbraith
> >
> > Add a yield_to function to the scheduler code, allowing us to
> > give enough of our timeslice to another thread to allow it to
> > run and release whatever resource we need it to release.
> >
> > We may w
On Wed, Jan 5, 2011 at 1:08 AM, Peter Zijlstra wrote:
> On Wed, 2011-01-05 at 00:51 +0800, Hillf Danton wrote:
>> Where is the yield_to callback in the patch for RT schedule class?
>> If @p is RT, what could you do?
>
> RT guests are a pipe dream, you first need to get the hypervisor (kvm in
> thi
On Wed, 2011-01-05 at 00:51 +0800, Hillf Danton wrote:
> Where is the yield_to callback in the patch for RT schedule class?
> If @p is RT, what could you do?
RT guests are a pipe dream, you first need to get the hypervisor (kvm in
this case) to be RT, which it isn't. Then you either need to very
On Wed, Jan 5, 2011 at 12:54 AM, Rik van Riel wrote:
> On 01/04/2011 11:51 AM, Hillf Danton wrote:
>
>>> Wouldn't that break for FIFO and RR tasks?
>>>
>>> There's a reason all the scheduler folks wanted a
>>> per-class yield_to_task function :)
>>>
>>
>> Where is the yield_to callback in the patc
On 01/04/2011 11:51 AM, Hillf Danton wrote:
Wouldn't that break for FIFO and RR tasks?
There's a reason all the scheduler folks wanted a
per-class yield_to_task function :)
Where is the yield_to callback in the patch for RT schedule class?
If @p is RT, what could you do?
If the user choose
On Wed, Jan 5, 2011 at 12:44 AM, Rik van Riel wrote:
> On 01/04/2011 11:41 AM, Hillf Danton wrote:
>
>> /* !curr->sched_class->yield_to_task || */
>>
>>> + curr->sched_class != p->sched_class) {
>>> + goto out;
>>> + }
>>> +
>>
On 01/04/2011 11:41 AM, Hillf Danton wrote:
/* !curr->sched_class->yield_to_task ||*/
+ curr->sched_class != p->sched_class) {
+ goto out;
+ }
+
/*
* ask scheduler to compute the next for successfully ki
On Tue, Jan 4, 2011 at 5:29 AM, Rik van Riel wrote:
> From: Mike Galbraith
>
> Add a yield_to function to the scheduler code, allowing us to
> give enough of our timeslice to another thread to allow it to
> run and release whatever resource we need it to release.
>
> We may want to use this to pr
Hi Stefan,
Thanks for replying! I was able to figure it out - it was not the fault of
KVM. One of the guests was running ganglia gmetad which was updating 30,000+
rrd files every 15 seconds (thus generating load via disk I/O), I didn't spot
that until shutting down the VMs one by one until I
On 01/04/2011 09:12 AM, Avi Kivity wrote:
On 01/04/2011 04:55 PM, Anthony Liguori wrote:
When the TCG thread, it needs to let the IO thread run for at least
one iteration. Coordinating the execution of the IO thread such
that it's guaranteed to run at least once and then having it drop
th
On Tue, Jan 04, 2011 at 12:56:16AM +0200, Michael Goldish wrote:
> I think that's risky:
>
> try:
> vm.create() # context aware, raises an exception
> except:
> try:
> vm.destroy() # context aware, raises an exception
> except:
> pass
> raise
Heh, did you try th
On 01/04/2011 04:55 PM, Anthony Liguori wrote:
When the TCG thread, it needs to let the IO thread run for at least
one iteration. Coordinating the execution of the IO thread such
that it's guaranteed to run at least once and then having it drop
the qemu mutex long enough for the TCG thread
On Tue, Jan 04, 2011 at 12:56:16AM +0200, Michael Goldish wrote:
> On 01/04/2011 12:06 AM, Eduardo Habkost wrote:
> > On Mon, Jan 03, 2011 at 07:22:17PM -0200, Eduardo Habkost wrote:
[...]
> > If you want to be extra careful, you can keep an index of contexts for
> > each exception ever seen, and c
On 01/04/2011 08:27 AM, Avi Kivity wrote:
On 01/04/2011 04:17 PM, Anthony Liguori wrote:
On 01/03/2011 04:01 AM, Avi Kivity wrote:
On 01/03/2011 11:46 AM, Jan Kiszka wrote:
Hi,
at least in kvm mode, the qemu_fair_mutex seems to have lost its
function of balancing qemu_global_mutex access betw
On 01/04/11 15:33, Anthony Liguori wrote:
> On 01/04/2011 08:31 AM, Jes Sorensen wrote:
>> On 01/03/11 11:57, Juan Quintela wrote:
>>
>>> Please send any agenda items you are interested in covering.
>>>
>>> thanks, Juan.
>>>
>>>
>> Do we have anything for the agenda yet?
>>
>
> I coul
On Tue, Jan 04, 2011 at 10:45:13PM +0900, Yoshiaki Tamura wrote:
> 2011/1/4 Michael S. Tsirkin :
> > On Tue, Jan 04, 2011 at 09:20:53PM +0900, Yoshiaki Tamura wrote:
> >> 2011/1/4 Michael S. Tsirkin :
> >> > On Tue, Jan 04, 2011 at 08:02:54PM +0900, Yoshiaki Tamura wrote:
> >> >> 2010/11/29 Stefan
Avi Kivity wrote:
On 01/04/2011 04:18 PM, Rik van Riel wrote:
So should I resend the patch with the ple_gap default
changed to 128, or are you willing to ack the current
patch?
I think 128 is safer given than 41 was too low. We have to take into
account newer cpus and slower spin
Juan Quintela wrote:
> Please send any agenda items you are interested in covering.
By popular request, this call got cancelled O:-)
Later, Juan.
>
> thanks, Juan.
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majord...@vger.kernel.org
> Mor
On 01/04/2011 08:31 AM, Jes Sorensen wrote:
On 01/03/11 11:57, Juan Quintela wrote:
Please send any agenda items you are interested in covering.
thanks, Juan.
Do we have anything for the agenda yet?
I could use the extra hour to catch up from the Holiday (as I assume a
lot of
On 01/03/11 11:57, Juan Quintela wrote:
>
> Please send any agenda items you are interested in covering.
>
> thanks, Juan.
>
Do we have anything for the agenda yet?
Jes
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More
On Tue, Jan 4, 2011 at 5:29 AM, Rik van Riel wrote:
> From: Mike Galbraith
>
> Add a yield_to function to the scheduler code, allowing us to
> give enough of our timeslice to another thread to allow it to
> run and release whatever resource we need it to release.
>
> We may want to use this to pr
On 01/04/2011 04:18 PM, Rik van Riel wrote:
On 01/03/2011 10:21 PM, Zhai, Edwin wrote:
Riel,
Thanks for your patch. I have changed the ple_gap to 128 on xen side,
but forget the patch for KVM:(
A little bit big is no harm, but more perf data is better.
So should I resend the patch with the pl
On 01/04/2011 04:17 PM, Anthony Liguori wrote:
On 01/03/2011 04:01 AM, Avi Kivity wrote:
On 01/03/2011 11:46 AM, Jan Kiszka wrote:
Hi,
at least in kvm mode, the qemu_fair_mutex seems to have lost its
function of balancing qemu_global_mutex access between the io-thread
and
vcpus. It's now onl
On 01/03/2011 10:21 PM, Zhai, Edwin wrote:
Riel,
Thanks for your patch. I have changed the ple_gap to 128 on xen side,
but forget the patch for KVM:(
A little bit big is no harm, but more perf data is better.
So should I resend the patch with the ple_gap default
changed to 128, or are you will
On 01/03/2011 04:01 AM, Avi Kivity wrote:
On 01/03/2011 11:46 AM, Jan Kiszka wrote:
Hi,
at least in kvm mode, the qemu_fair_mutex seems to have lost its
function of balancing qemu_global_mutex access between the io-thread and
vcpus. It's now only taken by the latter, isn't it?
This and the fac
2011/1/4 Michael S. Tsirkin :
> On Tue, Jan 04, 2011 at 09:20:53PM +0900, Yoshiaki Tamura wrote:
>> 2011/1/4 Michael S. Tsirkin :
>> > On Tue, Jan 04, 2011 at 08:02:54PM +0900, Yoshiaki Tamura wrote:
>> >> 2010/11/29 Stefan Hajnoczi :
>> >> > On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura
>> >> >
Mark some instructions as vendor specific, and allow the caller to request
emulation only of vendor specific instructions. This is useful in some
circumstances (responding to a #UD fault).
Signed-off-by: Avi Kivity
---
arch/x86/include/asm/kvm_emulate.h |1 +
arch/x86/kvm/emulate.c
Use the new support in the emulator, and drop the ad-hoc code in x86.c.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/x86.c | 31 +++
1 files changed, 3 insertions(+), 28 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b085ac3..8652643 100644
-
x86_decode_insn() doesn't return X86EMUL_* values, it returns
EMULATION_* codes. Adjust the check.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/x86.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fa708c9..b20499d 100644
---
'goto done' leads to a maze of checks and actions, all pointless. Bail
out immediately if we can't decode.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/x86.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index b20499d..b085ac3 10
Currently we have some ad-hoc code in x86.c to restrict #UD emulation to
expected instructions (that is, vendor specific instructions). This patchset
replaces the ad-hoc code with proper emulator support using decode tables.
Avi Kivity (4):
KVM: Fix x86_decode_insn() return code check
KVM: Si
On Tue, Jan 04, 2011 at 09:20:53PM +0900, Yoshiaki Tamura wrote:
> 2011/1/4 Michael S. Tsirkin :
> > On Tue, Jan 04, 2011 at 08:02:54PM +0900, Yoshiaki Tamura wrote:
> >> 2010/11/29 Stefan Hajnoczi :
> >> > On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura
> >> > wrote:
> >> >> event-tap controls w
2011/1/4 Michael S. Tsirkin :
> On Tue, Jan 04, 2011 at 08:02:54PM +0900, Yoshiaki Tamura wrote:
>> 2010/11/29 Stefan Hajnoczi :
>> > On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura
>> > wrote:
>> >> event-tap controls when to start FT transaction, and provides proxy
>> >> functions to called fro
On 01/04/2011 08:14 AM, KOSAKI Motohiro wrote:
Also, If pthread_cond_signal() call sys_yield_to imlicitly, we can
avoid almost Nehalem (and other P2P cache arch) lock unfairness
problem. (probaby creating pthread_condattr_setautoyield_np or similar
knob is good one)
Often, the thread calling pt
On Tue, 2011-01-04 at 12:45 +0100, Jan Kiszka wrote:
> Am 04.01.2011 12:43, Glauber Costa wrote:
> > On Tue, 2011-01-04 at 12:34 +0100, Jan Kiszka wrote:
> >> Am 04.01.2011 12:08, Glauber Costa wrote:
> >>> On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
> From: Jan Kiszka
>
>
Am 04.01.2011 12:43, Glauber Costa wrote:
> On Tue, 2011-01-04 at 12:34 +0100, Jan Kiszka wrote:
>> Am 04.01.2011 12:08, Glauber Costa wrote:
>>> On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
From: Jan Kiszka
If kvmclock is used, which implies the kernel supports it, register
On Tue, 2011-01-04 at 12:34 +0100, Jan Kiszka wrote:
> Am 04.01.2011 12:08, Glauber Costa wrote:
> > On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
> >> From: Jan Kiszka
> >>
> >> If kvmclock is used, which implies the kernel supports it, register a
> >> kvmclock device with the sysbus. Its
Am 04.01.2011 12:08, Glauber Costa wrote:
> On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
>> From: Jan Kiszka
>>
>> If kvmclock is used, which implies the kernel supports it, register a
>> kvmclock device with the sysbus. Its main purpose is to save and restore
>> the kernel state on migrat
On Tue, Jan 04, 2011 at 08:02:54PM +0900, Yoshiaki Tamura wrote:
> 2010/11/29 Stefan Hajnoczi :
> > On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura
> > wrote:
> >> event-tap controls when to start FT transaction, and provides proxy
> >> functions to called from net/block devices. While FT transa
On Tue, Jan 4, 2011 at 11:02 AM, Yoshiaki Tamura
wrote:
> After doing some heavy load tests, I realized that we have to
> take a hybrid approach to replay for now. This is because when a
> device moves to the next state (e.g. virtio decreases inuse) is
> different between net and block. For exam
On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
> From: Jan Kiszka
>
> If kvmclock is used, which implies the kernel supports it, register a
> kvmclock device with the sysbus. Its main purpose is to save and restore
> the kernel state on migration, but this will also allow to visualize it
>
On Tue, 2011-01-04 at 09:32 +0100, Jan Kiszka wrote:
> From: Jan Kiszka
>
> Make sure to write the cleared MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
> and MSR_KVM_ASYNC_PF_EN to the kernel state so that a freshly booted
> guest cannot be disturbed by old values.
>
> Signed-off-by: Jan Kiszka
> C
2010/11/29 Stefan Hajnoczi :
> On Thu, Nov 25, 2010 at 6:06 AM, Yoshiaki Tamura
> wrote:
>> event-tap controls when to start FT transaction, and provides proxy
>> functions to called from net/block devices. While FT transaction, it
>> queues up net/block requests, and flush them when the transact
On Thu, Dec 30, 2010 at 11:25 PM, Erich Weiler wrote:
> I've got this issue that I've been banging my head against a wall for a
> while over and I think another pair of eyes may help, if anyone have a
> moment. We have this new-ish KVM VM server (with the latest CentOS 5.5
> updates, kmod-kvm-83-
Am 10.12.2010 19:44, Chris Wright wrote:
> * Jan Kiszka (jan.kis...@siemens.com) wrote:
> --- a/drivers/pci/intel-iommu.c
> +++ b/drivers/pci/intel-iommu.c
> @@ -3627,9 +3627,9 @@ static int intel_iommu_attach_device(struct
> iommu_domain *domain,
>
> pte = dmar_do
On 01/04/2011 12:32 PM, Mike Galbraith wrote:
On Tue, 2011-01-04 at 11:09 +0200, Avi Kivity wrote:
> On 01/04/2011 08:42 AM, Mike Galbraith wrote:
> > If I were to, say, run a 256 CPU VM on my quad, would this help me get
> > more hackbench or whatever oomph from my (256X80386/20:) box?
>
>
On Tue, 2011-01-04 at 11:09 +0200, Avi Kivity wrote:
> On 01/04/2011 08:42 AM, Mike Galbraith wrote:
> > If I were to, say, run a 256 CPU VM on my quad, would this help me get
> > more hackbench or whatever oomph from my (256X80386/20:) box?
>
> First of all, you can't run 256 guests on x86 kvm.
On Tue, 2011-01-04 at 11:14 +0200, Avi Kivity wrote:
> Assuming there are no objections, Mike, can you get 2/3 into a
> fast-forward-only branch of tip.git? I'll then merge it into kvm.git
> and apply 1/3 and 2/3.
Wrong guy. Fast-forward is Peter's department.
-Mike
--
To unsubscrib
On 01/03/2011 11:26 PM, Rik van Riel wrote:
When running SMP virtual machines, it is possible for one VCPU to be
spinning on a spinlock, while the VCPU that holds the spinlock is not
currently running, because the host scheduler preempted it to run
something else.
Both Intel and AMD CPUs have a
On 01/04/2011 08:42 AM, Mike Galbraith wrote:
A couple questions.
On Mon, 2011-01-03 at 16:26 -0500, Rik van Riel wrote:
> When running SMP virtual machines, it is possible for one VCPU to be
> spinning on a spinlock, while the VCPU that holds the spinlock is not
> currently running, because
On 01/04/2011 10:42 AM, Jan Kiszka wrote:
>
> Sounds really frightening... this glue code is a real breeding ground
> for subtle bugs and merge problems.
...and that's why we are more than late with unifying it into a single
code base.
After that upcoming cleanup round we will have three majo
Am 03.01.2011 17:09, Avi Kivity wrote:
> On 01/03/2011 10:32 AM, Jan Kiszka wrote:
>> All previously sent patches against current uq combined, some smaller
>> tweaks applied, and 4 new patches added. Major news is support for
>> using up to 16M BIOSes and optional code dump for cpu_dump_state. Thos
From: Jan Kiszka
The ordering doesn't matter in this case, but better keep it consistent.
Signed-off-by: Jan Kiszka
---
target-i386/kvm.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index d4f253e..684430f 100644
--- a/targ
From: Jan Kiszka
Report KVM_EXIT_UNKNOWN, KVM_EXIT_FAIL_ENTRY, and KVM_EXIT_EXCEPTION
with more details to stderr. The latter two are so far x86-only, so move
them into the arch-specific handler. Integrate the Intel real mode
warning on KVM_EXIT_FAIL_ENTRY that qemu-kvm carries, but actually
rest
From: Jan Kiszka
kvm_arch_reset_vcpu initializes mp_state, and that function is invoked
right after kvm_arch_init_vcpu.
Signed-off-by: Jan Kiszka
---
target-i386/kvm.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 30aa51c.
From: Jan Kiszka
Introduce the cpu_dump_state flag CPU_DUMP_CODE and implement it for
x86. This writes out the code bytes around the current instruction
pointer. Make use of this feature in KVM to help debugging fatal vm
exits.
Signed-off-by: Jan Kiszka
---
cpu-all.h|2 ++
kvm-
From: Jan Kiszka
This code path will not yet be taken as we still lack in-kernel irqchip
support. But qemu-kvm can already make use of it and drop its own
mp_state access services.
Signed-off-by: Jan Kiszka
---
target-i386/kvm.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
dif
Next round, addressing review comments and new findings:
- new: Flush coalesced mmio buffer on IO window exits
- new: Do not use qemu_fair_mutex in kvm mode
- new: Implicitly clear nmi_injected/pending on reset
- new: Fix !CONFIG_KVM_PARA build
- reworked: Read kvmclock only once per stopped p
From: Jan Kiszka
For unknown reasons, xcr0 reset ended up in kvm_arch_update_guest_debug
on upstream merge. Fix this and also remove the misleading comment (1 is
THE reset value).
Signed-off-by: Jan Kiszka
---
target-i386/kvm.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff
From: Jan Kiszka
Ensure that we stop the guest whenever we face a fatal or unknown exit
reason. If we stop, we also have to enforce a cpu loop exit.
Signed-off-by: Jan Kiszka
---
kvm-all.c | 15 +++
target-i386/kvm.c |4
target-ppc/kvm.c |4
3 files cha
From: Jan Kiszka
Make sure to write the cleared MSR_KVM_SYSTEM_TIME, MSR_KVM_WALL_CLOCK,
and MSR_KVM_ASYNC_PF_EN to the kernel state so that a freshly booted
guest cannot be disturbed by old values.
Signed-off-by: Jan Kiszka
CC: Glauber Costa
---
target-i386/kvm.c |7 +++
1 files chan
From: Jan Kiszka
There is no need to restrict writing back MCE MSRs to reset or full
state updates as setting their values has no side effects.
Signed-off-by: Jan Kiszka
CC: Huang Ying
---
target-i386/kvm.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/ta
From: Jan Kiszka
QEMU supports only one VM, so there is only one kvm_state per process,
and we gain nothing passing a reference to it around. Eliminate any need
to refer to it outside of kvm-all.c.
Signed-off-by: Jan Kiszka
CC: Alexander Graf
---
cpu-defs.h|2 -
kvm-all.c
From: Jan Kiszka
If we lack kvm_para.h, MSR_KVM_ASYNC_PF_EN is not defined. The change in
kvm_arch_init_vcpu is just for consistency reasons.
Signed-off-by: Jan Kiszka
---
target-i386/kvm.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/target-i386/kvm.c b/targ
From: Jan Kiszka
No longer used.
Signed-off-by: Jan Kiszka
---
kvm-all.c |4 ++--
kvm-stub.c |2 +-
kvm.h |4 ++--
target-i386/kvm.c |2 +-
target-ppc/kvm.c |2 +-
target-s390x/kvm.c |2 +-
vl.c |2 +-
7 files changed,
From: Jan Kiszka
If kvmclock is used, which implies the kernel supports it, register a
kvmclock device with the sysbus. Its main purpose is to save and restore
the kernel state on migration, but this will also allow to visualize it
one day.
Signed-off-by: Jan Kiszka
CC: Glauber Costa
---
targ
From: Jan Kiszka
All CPUX86State variables before CPU_COMMON are automatically cleared on
reset. Reorder nmi_injected and nmi_pending to avoid having to touch
them explicitly.
Signed-off-by: Jan Kiszka
---
target-i386/cpu.h |6 --
target-i386/kvm.c |2 --
2 files changed, 4 inserti
From: Jan Kiszka
We must flush pending mmio writes if we leave kvm_cpu_exec for an IO
window. Otherwise we risk to loose those requests when migrating to a
different host during that window.
Signed-off-by: Jan Kiszka
---
kvm-all.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
From: Jan Kiszka
Instead of splattering the code with #ifdefs and runtime checks for
capabilities we cannot work without anyway, provide central test
infrastructure for verifying their availability both at build and
runtime.
Signed-off-by: Jan Kiszka
---
configure | 39 +
From: Jan Kiszka
In order to support loading BIOSes > 256K, reorder the code, adjusting
the base if the kernel supports moving the identity map.
Signed-off-by: Jan Kiszka
---
target-i386/kvm.c | 63 +---
1 files changed, 30 insertions(+), 33 de
From: Jan Kiszka
The imbalance in the hold time of qemu_global_mutex only exists in TCG
mode. In contrast to TCG VCPUs, KVM drops the global lock during guest
execution. We already avoid touching the fairness lock from the
IO-thread in KVM mode, so also stop using it from the VCPU threads.
Signe
From: Jan Kiszka
It is not used, it is not needed, so let's remove it.
Signed-off-by: Jan Kiszka
---
kvm-all.c |6 ++
kvm-stub.c |4 ++--
kvm.h |2 +-
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 2538283..7518f2c 100644
--- a/
From: Jan Kiszka
No functional changes.
Signed-off-by: Jan Kiszka
---
kvm-all.c | 139 ++--
1 files changed, 79 insertions(+), 60 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 35fc73c..2538283 100644
--- a/kvm-all.c
+++ b/kvm-al
1 - 100 of 101 matches
Mail list logo
