On 06/14/2010 08:45 PM, Balbir Singh wrote:
There are two decisions that need to be made:
- how much memory a guest should be given
- given some guest memory, what's the best use for it
The first question can perhaps be answered by looking at guest I/O
rates and giving more memory to more
On 06/14/2010 08:58 PM, Dave Hansen wrote:
On Mon, 2010-06-14 at 19:34 +0300, Avi Kivity wrote:
Again, this is useless when ballooning is being used. But, I'm thinking
of a more general mechanism to force the system to both have MemFree
_and_ be acting as if it is under memory pressure.
On 06/14/2010 08:40 PM, Balbir Singh wrote:
* Avi Kivitya...@redhat.com [2010-06-14 18:34:58]:
On 06/14/2010 06:12 PM, Dave Hansen wrote:
On Mon, 2010-06-14 at 14:18 +0530, Balbir Singh wrote:
1. A slab page will not be freed until the entire page is free (all
slabs have
On 06/14/2010 08:16 PM, Balbir Singh wrote:
* Dave Hansend...@linux.vnet.ibm.com [2010-06-14 10:09:31]:
On Mon, 2010-06-14 at 22:28 +0530, Balbir Singh wrote:
If you've got duplicate pages and you know
that they are duplicated and can be retrieved at a lower cost, why
wouldn't we
This is an attempt to cleanup and plug some of the many existing holes
with TSC and as a direct result, kvmclock. It is not a perfect attempt;
no trap and emulate is yet done for TSC in cases in which it can not be
perfectly virtualized. In particular, on platforms with unstable /
buggy TSCs, it
Move duplicated timer related code into arch_vcpu_load rather
than vendor callouts. Should be an isomorphic transformation.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
arch/x86/kvm/svm.c |2 --
arch/x86/kvm/vmx.c |3 +--
arch/x86/kvm/x86.c |4
3 files changed, 5
Move the TSC control logic from the vendor backends into x86.c
by adding adjust_tsc_offset to x86 ops. Now all TSC decisions
can be done in one place.
Also, rename some variable in the VCPU structure to more accurately
reflect their actual content.
VMX backend would record last observed TSC
When CPUs with unstable TSCs enter deep C-state, TSC may stop
running. This causes us to require resynchronization. Since
we can't tell when this may potentially happen, we assume the
worst by forcing re-compensation for it at every point the VCPU
task is descheduled.
Signed-off-by: Zachary
This bit will be used to track all clock synchronization events,
so rename it KVM_REQ_CLOCK_SYNC. Also it makes some spacing better.
As prep for using it for all synchronization, we can't skip
setting the bit in the event there is no vcpu time page.
Signed-off-by: Zachary Amsden
The CPU_STARTING callback was added upstream with the intention
of being used for KVM, specifically for the hardware enablement
that must be done before we can run in hardware virt. It had
bugs on the x86_64 architecture at the time, where it was called
after CPU_ONLINE. The arches have since
The scale_delta function for shift / multiply with 31-bit
precision moves to a common header so it can be used by both
kernel and kvm module.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
arch/x86/include/asm/pvclock.h | 38 ++
If there are active VCPUs which are marked as belonging to
a particular hardware CPU, request a clock sync for them when
enabling hardware; the TSC could be desynchronized on a newly
arriving CPU, and we need to recompute guests system time
relative to boot after a suspend event.
This covers both
Add a helper function for the multiple places this is used. Note that it
must not be called in preemptible context, as that would mean the kernel
could enter software suspend state, which would cause non-atomic operation
of the monotonic_to_bootbased computation.
Open question: should the
Kernel time, which advances in discrete steps may progress much slower
than TSC. As a result, when kvmclock is adjusted to a new base, the
apparent time to the guest, which runs at a much higher, nsec scaled
rate based on the current TSC, may have already been observed to have
a larger value
On reset, VMCB TSC should be set to zero. Instead, code was setting
tsc_offset to zero, which passes through the underlying TSC.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
arch/x86/kvm/svm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/svm.c
Attempt to synchronize TSCs which are reset to the same value. In the
case of a reliable hardware TSC, we can just re-use the same offset, but
on non-reliable hardware, we can get closer by adjusting the offset to
match the elapsed time.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
Basic informational document about x86 timekeeping and how KVM
is affected.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
Documentation/kvm/timekeeping.txt | 599 +
1 files changed, 599 insertions(+), 0 deletions(-)
create mode 100644
Some AMD based machines can have TSC drift when in C1 HLT state because
despite attempting to scale the TSC increment when dividing down the
P-state, the processor may return to full P-state to service cache
probes. The TSC of halted CPUs can advance faster than that of running
CPUs as a result,
Track the last TSC offset set for each VM and ensure that the storing of
the offset and the reading of the TSC are never preempted by taking a
spinlock.
Signed-off-by: Zachary Amsden zams...@redhat.com
---
arch/x86/include/asm/kvm_host.h |6 +-
arch/x86/kvm/svm.c | 30
The math in kvm_get_time_scale relies on the fact that
NSEC_PER_SEC 2^32. To use the same function to compute
arbitrary time scales, we must extend the first reduction
step to shrink the base rate to a 32-bit value, and
possibly reduce the scaled rate into a 32-bit as well.
Note we must take
SMP VMs on machines with unstable TSC have their TSC offset adjusted by the
local offset delta from last measurement. This does not take into account how
long it has been since the measurement, leading to drift. Minimize the drift
by accounting for any time difference the kernel has observed.
This simplifies much of the init code; we can now simply always
call tsc_khz_changed, optionally passing it a new value, or letting
it figure out the existing value (while interrupts are disabled, and
thus, by inference from the rule, not raceful against CPU hotplug or
frequency updates, which
* Avi Kivity a...@redhat.com [2010-06-15 09:58:33]:
On 06/14/2010 08:45 PM, Balbir Singh wrote:
There are two decisions that need to be made:
- how much memory a guest should be given
- given some guest memory, what's the best use for it
The first question can perhaps be answered by
* Avi Kivity a...@redhat.com [2010-06-15 10:12:44]:
On 06/14/2010 08:16 PM, Balbir Singh wrote:
* Dave Hansend...@linux.vnet.ibm.com [2010-06-14 10:09:31]:
On Mon, 2010-06-14 at 22:28 +0530, Balbir Singh wrote:
If you've got duplicate pages and you know
that they are duplicated and can be
On 06/15/2010 10:34 AM, Zachary Amsden wrote:
This simplifies much of the init code; we can now simply always
call tsc_khz_changed, optionally passing it a new value, or letting
it figure out the existing value (while interrupts are disabled, and
thus, by inference from the rule, not raceful
On 06/15/2010 10:34 AM, Zachary Amsden wrote:
When CPUs with unstable TSCs enter deep C-state, TSC may stop
running. This causes us to require resynchronization. Since
we can't tell when this may potentially happen, we assume the
worst by forcing re-compensation for it at every point the VCPU
On 06/15/2010 10:34 AM, Zachary Amsden wrote:
SMP VMs on machines with unstable TSC have their TSC offset adjusted by the
local offset delta from last measurement. This does not take into account how
long it has been since the measurement, leading to drift. Minimize the drift
by accounting for
On 06/14/2010 10:09 PM, Avi Kivity wrote:
On 06/15/2010 10:34 AM, Zachary Amsden wrote:
When CPUs with unstable TSCs enter deep C-state, TSC may stop
running. This causes us to require resynchronization. Since
we can't tell when this may potentially happen, we assume the
worst by forcing
Am 14.06.2010 21:48, schrieb MORITA Kazutaka:
3) qemu-io aio_read/write doesn't seem to work well with it. I only get
the result of the AIO request when I exit qemu-io. This may be a qemu-io
problem or a Sheepdog one. We need to look into this, qemu-io is
important for testing and debugging
On 06/15/2010 10:34 AM, Zachary Amsden wrote:
If there are active VCPUs which are marked as belonging to
a particular hardware CPU, request a clock sync for them when
enabling hardware; the TSC could be desynchronized on a newly
arriving CPU, and we need to recompute guests system time
relative
On 06/15/2010 10:34 AM, Zachary Amsden wrote:
Kernel time, which advances in discrete steps may progress much slower
than TSC. As a result, when kvmclock is adjusted to a new base, the
apparent time to the guest, which runs at a much higher, nsec scaled
rate based on the current TSC, may have
On 06/15/2010 10:34 AM, Zachary Amsden wrote:
Add a helper function for the multiple places this is used. Note that it
must not be called in preemptible context, as that would mean the kernel
could enter software suspend state, which would cause non-atomic operation
of the
On 06/15/2010 10:34 AM, Zachary Amsden wrote:
Track the last TSC offset set for each VM and ensure that the storing of
the offset and the reading of the TSC are never preempted by taking a
spinlock.
Totally missing the point - tsc is per vcpu, why do we need per-vm tracking?
--
error
On 06/15/2010 10:34 AM, Zachary Amsden wrote:
Some AMD based machines can have TSC drift when in C1 HLT state because
despite attempting to scale the TSC increment when dividing down the
P-state, the processor may return to full P-state to service cache
probes. The TSC of halted CPUs can
On 06/15/2010 10:34 AM, Zachary Amsden wrote:
Attempt to synchronize TSCs which are reset to the same value. In the
case of a reliable hardware TSC, we can just re-use the same offset, but
on non-reliable hardware, we can get closer by adjusting the offset to
match the elapsed time.
On 06/15/2010 10:34 AM, Zachary Amsden wrote:
Basic informational document about x86 timekeeping and how KVM
is affected.
Excellent.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
Alex Williamson alex.william...@redhat.com writes:
On Mon, 2010-06-14 at 09:02 +0200, Gerd Hoffmann wrote:
Hi,
My premise with this attempt is that we walk the hierarchy and use the
names to create the base of the path. As we get to the device,
particularly to the parent bus of the
ISA: serial/parallel = iobase, others??
ne2k_isa has iobase too.
I think all remaining isa devices (timer, kbd, vga, ...) have a fixed
i/o base and can be only once in the system.
ide-drive: unit
I2C: address
virtio-serial doesn't seem to make a DeviceState per port, so I think it
can be
On 06/14/2010 10:47 PM, Avi Kivity wrote:
On 06/15/2010 10:34 AM, Zachary Amsden wrote:
Some AMD based machines can have TSC drift when in C1 HLT state because
despite attempting to scale the TSC increment when dividing down the
P-state, the processor may return to full P-state to service cache
Markus Armbruster wrote:
Paul Brook p...@codesourcery.com writes:
Alex Williamson alex.william...@redhat.com writes:
On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
Could you explain why you add identified properties of the immediate
parent bus and device? They make the result
On 06/15/2010 10:49 AM, Balbir Singh wrote:
All we need is to select the right page to drop.
Do we need to drop to the granularity of the page to drop? I think
figuring out the class of pages and making sure that we don't write
our own reclaim logic, but work with what we have to
On 06/15/2010 10:52 AM, Balbir Singh wrote:
That is why the policy (in the next set) will come from the host. As
to whether the data is truly duplicated, my experiments show up to 60%
of the page cache is duplicated.
Isn't that incredibly workload dependent?
We can't expect the host
On 06/14/2010 04:03 PM, Nadav Har'El wrote:
Let's try to get this merged quickly.
I'll start fixing the individual patches and resending them individually, and
when I've fixed everything I'll resubmit the whole lot. I hope that this time
I can do it in a matter of days, not months.
* Avi Kivity a...@redhat.com [2010-06-15 12:44:31]:
On 06/15/2010 10:49 AM, Balbir Singh wrote:
All we need is to select the right page to drop.
Do we need to drop to the granularity of the page to drop? I think
figuring out the class of pages and making sure that we don't write
our own
On 06/15/2010 04:03 AM, Wei Yongjun wrote:
emulate pusha instruction only writeback the last
EDI register, but the other registers which need
to be writeback is ignored. This patch fixed it.
Ouch.
-static void emulate_pusha(struct x86_emulate_ctxt *ctxt,
+static int
On Sun, Jun 13, 2010 at 03:24:37PM +0300, Nadav Har'El wrote:
This patch allows the guest to enable the VMXE bit in CR4, which is a
prerequisite to running VMXON.
Signed-off-by: Nadav Har'El n...@il.ibm.com
---
--- .before/arch/x86/kvm/x86.c2010-06-13 15:01:28.0 +0300
+++
On 06/15/2010 05:46 AM, Xiao Guangrong wrote:
Introduce gfn_to_page_atomic() and gfn_to_pfn_atomic(), those
functions is fast path and can used in atomic context, the later
patch will use those
@@ -942,6 +942,41 @@ unsigned long gfn_to_hva(struct kvm *kvm, gfn_t gfn)
}
In fact what you really want to do is transfer the device tree
(including properties), and create the machine from scratch, not load
state into a pre-supplied device tree.
Well, I agree, but that's a lot more of an overhaul, and once again
we're changing the problem.
I think it's you
Alex proposed to disambiguate by adding identified properties of the
immediate parent bus and device to the path component. For PCI, these
are dev.fn. Likewise for any other bus where devices have unambigous
bus address. The driver name carries no information!
From user POV, driver
Hi all,,
I have installed KVM by enabling KVM during Fedora core 8 OS installation.
I can able to create guest OS with qemu-system-x86_64.
Also I have configured guest OS with different subnet and I can reach
the guest OS from the host machine which is having different subnet
Now the problem is
On 06/15/2010 05:47 AM, Xiao Guangrong wrote:
Support prefetch ptes when intercept guest #PF, avoid to #PF by later
access
If we meet any failure in the prefetch path, we will exit it and
not try other ptes to avoid become heavy path
+#define PTE_PREFETCH_NUM 16
+
#define
Jan Kiszka jan.kis...@siemens.com writes:
Markus Armbruster wrote:
Paul Brook p...@codesourcery.com writes:
Alex Williamson alex.william...@redhat.com writes:
On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
Could you explain why you add identified properties of the immediate
On 06/15/2010 05:46 AM, Xiao Guangrong wrote:
Hi Avi, Marcelo,
This patchset support pte prefetch when intercepted guest #PF,
the aim is to reduce guest #PF which can be intercepted by VMM.
If we meet any failure in the prefetch path, we will exit it
and not try other ptes to avoid become
Paul Brook wrote:
Alex proposed to disambiguate by adding identified properties of the
immediate parent bus and device to the path component. For PCI, these
are dev.fn. Likewise for any other bus where devices have unambigous
bus address. The driver name carries no information!
From user
Markus Armbruster wrote:
Jan Kiszka jan.kis...@siemens.com writes:
Markus Armbruster wrote:
Paul Brook p...@codesourcery.com writes:
Alex Williamson alex.william...@redhat.com writes:
On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
Could you explain why you add identified
From user POV, driver names are very handly to address a device
intuitively - except for the case you have tones of devices on the same
bus that are handled by the same driver. For that case we need to
augment the device name with a useful per-bus ID, derived from the bus
address where
On 06/15/2010 02:40 PM, Rajiv Rajaian wrote:
Hi all,,
I have installed KVM by enabling KVM during Fedora core 8 OS installation.
I can able to create guest OS with qemu-system-x86_64.
Also I have configured guest OS with different subnet and I can reach
the guest OS from the host machine which
On 06/15/2010 05:47 AM, Xiao Guangrong wrote:
Trace pte prefetch to see what trouble we meet, if can help us to
improve the prefetch
Signed-off-by: Xiao Guangrongxiaoguangr...@cn.fujitsu.com
---
arch/x86/kvm/mmu.c | 12 +++-
arch/x86/kvm/mmutrace.h| 26
On Sun, Jun 13, 2010 at 03:26:09PM +0300, Nadav Har'El wrote:
This patch includes a couple of utility functions for extracting pointer
operands of VMX instructions issued by L1 (a guest hypervisor), and
translating guest-given vmcs12 virtual addresses to guest-physical addresses.
Paul Brook wrote:
From user POV, driver names are very handly to address a device
intuitively - except for the case you have tones of devices on the same
bus that are handled by the same driver. For that case we need to
augment the device name with a useful per-bus ID, derived from the bus
At Tue, 15 Jun 2010 10:24:14 +0200,
Kevin Wolf wrote:
Am 14.06.2010 21:48, schrieb MORITA Kazutaka:
3) qemu-io aio_read/write doesn't seem to work well with it. I only get
the result of the AIO request when I exit qemu-io. This may be a qemu-io
problem or a Sheepdog one. We need to look
Paul Brook wrote:
From user POV, driver names are very handly to address a device
intuitively - except for the case you have tones of devices on the
same bus that are handled by the same driver. For that case we need
to augment the device name with a useful per-bus ID, derived from the
If we want to support barriers with the cache=writethrough mode in qemu
we need to tell the block layer that we only need queue drains to
implement a barrier. Follow the model set by SCSI and IDE and assume
that there is no volatile write cache if the host doesn't advertize it.
While this might
* Avi Kivity a...@redhat.com [2010-06-15 12:54:31]:
On 06/15/2010 10:52 AM, Balbir Singh wrote:
That is why the policy (in the next set) will come from the host. As
to whether the data is truly duplicated, my experiments show up to 60%
of the page cache is duplicated.
Isn't that incredibly
Paul Brook wrote:
Paul Brook wrote:
From user POV, driver names are very handly to address a device
intuitively - except for the case you have tones of devices on the
same bus that are handled by the same driver. For that case we need
to augment the device name with a useful per-bus ID,
On 06/15/2010 12:48 AM, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
- Page cache controls (Balbir/Dave)
Regards,
Anthony Liguori
If we have a lack of agenda items I'll cancel the week's call.
thanks,
-chris
--
To unsubscribe from this list: send
On Mon, Jun 14, 2010 at 01:11:20PM -0400, Chris Lalancette wrote:
We really want to kvm_set_irq during the hrtimer callback,
but that is risky because that is during interrupt context.
Instead, offload the work to a workqueue, which is a bit safer
and should provide most of the same
Jan Kiszka jan.kis...@siemens.com writes:
Markus Armbruster wrote:
Jan Kiszka jan.kis...@siemens.com writes:
Markus Armbruster wrote:
Paul Brook p...@codesourcery.com writes:
Alex Williamson alex.william...@redhat.com writes:
On Mon, 2010-06-14 at 08:39 +0200, Markus Armbruster wrote:
Works for serial, but fails for ISA devices not occupying an address.
An ISA device without an IO/MMIO capabilities seems extremely unlikely.
What exactly would such a device do?
Inject interrupts via that bus (while exposing registers in some other
way). The m48t59 seems to fall in
Jan Kiszka jan.kis...@siemens.com writes:
Paul Brook wrote:
Alex proposed to disambiguate by adding identified properties of the
immediate parent bus and device to the path component. For PCI, these
are dev.fn. Likewise for any other bus where devices have unambigous
bus address. The
Every hotplug-capable bus must have a proper addressing scheme, I think
this is a reasonable and achievable requirement. Then we don't need
instance numbers for those buses.
What about USB?
USB has useful device addresses (physical ports).
These aren't used by most of the higher-level
Every hotplug-capable bus must have a proper addressing scheme, I think
this is a reasonable and achievable requirement. Then we don't need
instance numbers for those buses.
What about USB?
USB has useful device addresses (physical ports).
These aren't used by most of the
Markus Armbruster wrote:
That way, we gain a useful feature, and avoid having an savevm-specific
device path that isn't recognized anywhere else.
Agreed, we should find one solution for all use cases.
I wasn't aware that there was any suggestion of a separate savevm-specific
path. The whole
Anthony Liguori anth...@codemonkey.ws wrote:
On 06/15/2010 12:48 AM, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
- Page cache controls (Balbir/Dave)
- Migration Subsections
Just sent a possible implementation code to the list (too late for a big
Bugs item #2933400, was opened at 2010-01-16 15:35
Message generated for change (Comment added) made by masc82
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=2933400group_id=180599
Please note that this message will contain a full copy of the comment
On Sun, Jun 13, 2010 at 03:27:10PM +0300, Nadav Har'El wrote:
This patch implements the VMCLEAR instruction.
Signed-off-by: Nadav Har'El n...@il.ibm.com
---
--- .before/arch/x86/kvm/vmx.c2010-06-13 15:01:29.0 +0300
+++ .after/arch/x86/kvm/vmx.c 2010-06-13 15:01:29.0
Thanks, applied! Got back from holiday today and am catching up on
tracing emails.
http://repo.or.cz/w/qemu/stefanha.git/commitdiff/3e59a5f51675d377a0fda88d4b83138a6b872962
Stefan
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
On 06/15/2010 04:47 PM, Gleb Natapov wrote:
On Sun, Jun 13, 2010 at 03:27:10PM +0300, Nadav Har'El wrote:
This patch implements the VMCLEAR instruction.
Signed-off-by: Nadav Har'Eln...@il.ibm.com
---
--- .before/arch/x86/kvm/vmx.c 2010-06-13 15:01:29.0 +0300
+++
On Tue, Jun 15, 2010 at 04:50:35PM +0300, Avi Kivity wrote:
On 06/15/2010 04:47 PM, Gleb Natapov wrote:
On Sun, Jun 13, 2010 at 03:27:10PM +0300, Nadav Har'El wrote:
This patch implements the VMCLEAR instruction.
Signed-off-by: Nadav Har'Eln...@il.ibm.com
---
--- .before/arch/x86/kvm/vmx.c
This is a big RFC for the moment. These need a bunch more
runtime testing.
--
We've seen contention in the mmu_shrink() function. This patch
set reworks it to hopefully be more scalable to large numbers
of CPUs, as well as large numbers of running VMs.
The patches are ordered with increasing
This basically takes the loop contents and sticks it in
its own function for readability. Don't pay too much
attention to the use of nr_scanned in here. It's a bit
wonky but it'll change in a minute anyway.
Signed-off-by: Dave Hansen d...@linux.vnet.ibm.com
---
First of all, I think free is a poor name for this value. In
this context, it means, the number of mmu pages which this kvm
instance should be able to allocate. To me, free implies
much more that the objects are there and ready for use. I think
available is a much better description,
Again, I think this is a poor choice of names. This value truly
means, the number of pages which _may_ be allocated. But,
reading the value, n_alloc_mmu_pages, I'm unable to think of
anything it should mean other than the number of allocated mmu
pages, which is dead wrong.
It's really the high
I think doing this makes the code much more readable. That's
borne out by the fact that this patch removes code. used
also happens to be the number that we need to return back to
the slab code when our shrinker gets called. Keeping this
value as opposed to free makes the next patch simpler.
Note: this is the real meat of the patch set. It can be applied up
to this point, and everything will probably be improved, at least
a bit.
Of slab shrinkers, the VM code says:
* Note that 'shrink' will be passed nr_to_scan == 0 when the VM is
* querying the cache size, so a fastpath for
In a previous patch, we removed the 'nr_to_scan' tracking.
It was not being used to track the number of objects
scanned, so we stopped using it entirely. Here, we
strart using it again.
The theory here is simple; if we already have the refcount
and the kvm-mmu_lock, then we should do as much
The comment tells most of the story here. This patch guarantees
that once a user decrements kvm-users_count to 0 that no one
will increment it again.
We'll need this in a moment because we are going to use
kvm-users_count as a more generic refcount.
Signed-off-by: Dave Hansen
In mmu_shrink(), we walk the vm_list to try and free some
of the mmu objects. If we did this over and over again, we
would unfairly bias the shrinking at the beginning of the
list. So, if a KVM instance gets successfully shrunk, then
we move it to the end of the vm_list. This keeps things
On Mon, Jun 14, 2010 at 07:19:17PM -0400, David Woodhouse wrote:
Why not just jump straight to the 'DMA proxy' device, and use that
_only_?
Not sure about Intel chipsets, but on AMD chipset a legacy device can be
seen by the IOMMU with both device-ids, its own and the bridge device.
So the
On 06/15/2010 08:33 AM, Juan Quintela wrote:
Anthony Liguorianth...@codemonkey.ws wrote:
On 06/15/2010 12:48 AM, Chris Wright wrote:
Please send in any agenda items you are interested in covering.
- Page cache controls (Balbir/Dave)
- Migration Subsections
Just
On Mon, Jun 14, 2010, Avi Kivity wrote about Re: [PATCH 1/24] Move nested
option from svm.c to x86.c:
A global variable names 'nested' is not a good idea. I recommend having
a kvm-intel scope module parameter instead, that also avoids the 0/1/2
values.
The rationale behind having a nested
On Mon, Jun 14, 2010, Avi Kivity wrote about Re: [PATCH 2/24] Add VMX and SVM
to list of supported cpuid features:
const u32 kvm_supported_word4_x86_features =
F(XMM3) | 0 /* Reserved, DTES64, MONITOR */ |
-0 /* DS-CPL, VMX, SMX, EST */ |
+0 /* DS-CPL
On Tue, Jun 15, 2010, Gleb Natapov wrote about Re: [PATCH 4/24] Allow setting
the VMXE bit in CR4:
On Sun, Jun 13, 2010 at 03:24:37PM +0300, Nadav Har'El wrote:
This patch allows the guest to enable the VMXE bit in CR4, which is a
prerequisite to running VMXON.
..
---
On Tue, Jun 15, 2010 at 05:21:11AM -0400, Zachary Amsden wrote:
On 06/14/2010 10:47 PM, Avi Kivity wrote:
On 06/15/2010 10:34 AM, Zachary Amsden wrote:
+/*
+ * AMD processors can de-synchronize TSC on halt in C1 state,
because
+ * processors in lower P state will have TSC
On Tue, 2010-06-15 at 10:07 +0300, Avi Kivity wrote:
On 06/14/2010 08:58 PM, Dave Hansen wrote:
On Mon, 2010-06-14 at 19:34 +0300, Avi Kivity wrote:
Again, this is useless when ballooning is being used. But, I'm thinking
of a more general mechanism to force the system to both have
On Tue, 2010-06-15 at 16:10 +0200, Joerg Roedel wrote:
On Mon, Jun 14, 2010 at 07:19:17PM -0400, David Woodhouse wrote:
Why not just jump straight to the 'DMA proxy' device, and use that
_only_?
Not sure about Intel chipsets, but on AMD chipset a legacy device can be
seen by the IOMMU
Bugs item #1945129, was opened at 2008-04-17 19:36
Message generated for change (Comment added) made by jessorensen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=893831aid=1945129group_id=180599
Please note that this message will contain a full copy of the comment
Markus Armbruster wrote:
Jan Kiszka jan.kis...@siemens.com writes:
Markus Armbruster wrote:
Jan Kiszka jan.kis...@siemens.com writes:
Markus Armbruster wrote:
Paul Brook p...@codesourcery.com writes:
Alex Williamson alex.william...@redhat.com writes:
On Mon, 2010-06-14 at 08:39 +0200,
Page cache controls
- cache is 60% duplicated between host and guest (when not using cache=none)
- Balbir posted 2 patches to eliminate this
- boot parameter for preferred reclaim
- not always have balloon driver
- need a boot parameter
- perhaps add a balloon cmd to give a hint before a
On Tue, Jun 15, 2010 at 08:18:12AM -0700, Chris Wright wrote:
KVM/qemu patches
- patch rate is high, documentation is low, review is low
- patches need to include better descriptions and documentation
- will slow down patch writers
- will make it easier for patch reviewers
What is the
1 - 100 of 142 matches
Mail list logo
