* Asias He asias.he...@gmail.com wrote:
On 10/14/2011 02:22 AM, Pekka Enberg wrote:
On Thu, Oct 13, 2011 at 7:52 PM, Ingo Molnar mi...@elte.hu wrote:
Btw., will 'kvm run' select the last-created rootfs by default?
No, it runs rootfs that's named 'default'. We can change that but
I'm
On Fri, Oct 14, 2011 at 9:08 AM, Ingo Molnar mi...@elte.hu wrote:
The canonical extension of that would be to create .kvmtool/ in $CWD
and to union-mount the files in the current directory on top of the
.kvmtool 'binary environment' - or such.
Union mount is off the table for now because
On 10/14/2011 01:53 PM, Jan Kiszka wrote:
On 2011-10-14 02:53, Lai Jiangshan wrote:
As explained in some other mail, we could then emulate the missing
kernel feature by reading out the current in-kernel APIC state, testing
if LINT1 is unmasked, and then delivering the NMI directly.
Only
On 2011-10-14 08:36, Lai Jiangshan wrote:
On 10/14/2011 01:53 PM, Jan Kiszka wrote:
On 2011-10-14 02:53, Lai Jiangshan wrote:
As explained in some other mail, we could then emulate the missing
kernel feature by reading out the current in-kernel APIC state, testing
if LINT1 is unmasked, and
* Pekka Enberg penb...@cs.helsinki.fi wrote:
On Fri, Oct 14, 2011 at 9:08 AM, Ingo Molnar mi...@elte.hu wrote:
The canonical extension of that would be to create .kvmtool/ in $CWD
and to union-mount the files in the current directory on top of the
.kvmtool 'binary environment' - or such.
Recent kernels check for MSR_IA32_MISC_ENABLE_FAST_STRING in the
MSR_IA32_MISC_ENABLE MSR before enabling reps/movs memcpy.
So far we didn't set it, and got a slower memcpy and a warning:
[0.00] Disabled fast string operations
This patch enables fast string operations.
On 10/14/2011 02:49 PM, Jan Kiszka wrote:
On 2011-10-14 08:36, Lai Jiangshan wrote:
On 10/14/2011 01:53 PM, Jan Kiszka wrote:
On 2011-10-14 02:53, Lai Jiangshan wrote:
As explained in some other mail, we could then emulate the missing
kernel feature by reading out the current in-kernel APIC
On 2011-10-14 09:43, Lai Jiangshan wrote:
On 10/14/2011 02:49 PM, Jan Kiszka wrote:
On 2011-10-14 08:36, Lai Jiangshan wrote:
On 10/14/2011 01:53 PM, Jan Kiszka wrote:
On 2011-10-14 02:53, Lai Jiangshan wrote:
As explained in some other mail, we could then emulate the missing
kernel
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers LINT1. Because of this, NMI is sent to
the processor even when LINT1 is masked in LVT. For example, this
causes the problem that
Synchronize newest kernel headers which have
KVM_CAP_SET_LINT1 and KVM_SET_LINT1 by
./scripts/update-linux-headers.sh
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
---
linux-headers/asm-powerpc/kvm.h | 19 +--
linux-headers/asm-x86/kvm.h |1 +
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers LINT1. Because of this, NMI is sent to
the processor even when LINT1 is masked in LVT. For example, this
causes the problem that
Avi, Marcelo,
below is a patch for the System z (s390x) ballooner (as defined by the
other System z hypervisors). I want to push that patch via Martins tree,
since the tricky part is in architecture specific memory management code.
Can you ack/nack?
Linux on System z uses a ballooner based on
On 2011-10-14 11:03, Lai Jiangshan wrote:
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers LINT1. Because of this, NMI is sent to
the processor even when LINT1 is masked in
On Thu, Oct 13, 2011 at 05:03:53PM +0200, benoit ROUSSELLE wrote:
On Thu, Oct 13, 2011 at 4:27 PM, Stefan Hajnoczi stefa...@gmail.com wrote:
dd performs buffered I/O by default. That means it just writes to the
page cache and the kernel decides when to write out dirty pages.
So your host
On 10/14/2011 05:07 PM, Jan Kiszka wrote:
On 2011-10-14 11:03, Lai Jiangshan wrote:
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers LINT1. Because of this, NMI is sent to
On 2011-10-14 11:03, Lai Jiangshan wrote:
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers LINT1. Because of this, NMI is sent to
the processor even when LINT1 is masked in
On 2011-10-14 11:27, Lai Jiangshan wrote:
On 10/14/2011 05:07 PM, Jan Kiszka wrote:
On 2011-10-14 11:03, Lai Jiangshan wrote:
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers LINT1. Because of this, NMI is sent to
the processor even when LINT1 is masked in LVT. For example, this
causes the problem that
Synchronize newest kernel headers which have
KVM_CAP_SET_LINT1 and KVM_SET_LINT1 by
./scripts/update-linux-headers.sh
Signed-off-by: Lai Jiangshan la...@cn.fujitsu.com
---
linux-headers/asm-powerpc/kvm.h | 19 +--
linux-headers/asm-x86/kvm_para.h | 14
On Fri, 2011-10-14 at 17:51 +0800, Lai Jiangshan wrote:
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers LINT1. Because of this, NMI is sent to
the processor even when LINT1
On 2011-10-14 13:59, Sasha Levin wrote:
On Fri, 2011-10-14 at 17:51 +0800, Lai Jiangshan wrote:
Currently, NMI interrupt is blindly sent to all the vCPUs when NMI
button event happens. This doesn't properly emulate real hardware on
which NMI button event triggers LINT1. Because of this, NMI is
On Fri, Oct 14, 2011 at 9:33 AM, Stefan Hajnoczi stefa...@gmail.com wrote:
The next step is trying QEMU's -drive aio=native, which uses Linux AIO
instead of a custom userspace threadpool for doing I/O. It is usually
faster. The libvirt domain XML is:
disk ...
driver name='qemu'
On Tue, Oct 11, 2011 at 01:01:23PM -0400, Ohad Ben-Cohen wrote:
On Tue, Oct 11, 2011 at 12:38 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
You need to make sure that you don;t pass larger regions then requested
to the low-level driver. Some logic like in the iommu_map function
should do
On Thu, Oct 13, 2011 at 09:44:48AM -0700, Jeremy Fitzhardinge wrote:
On 10/13/2011 03:54 AM, Peter Zijlstra wrote:
On Wed, 2011-10-12 at 17:51 -0700, Jeremy Fitzhardinge wrote:
This is is all unnecessary complication if you're not using PV ticket
locks, it also uses the jump-label machinery
On 2011-10-06 17:48, Jesse Barnes wrote:
On Mon, 12 Sep 2011 18:54:01 +0200
Jan Kiszka jan.kis...@siemens.com wrote:
This series tries to heal the currently broken locking scheme around PCI
config space accesses.
We have an interface lock out access via sysfs, but that service wrongly
On 10/06/2011 10:48 AM, Jesse Barnes wrote:
On Mon, 12 Sep 2011 18:54:01 +0200
Jan Kiszka jan.kis...@siemens.com wrote:
This series tries to heal the currently broken locking scheme around PCI
config space accesses.
We have an interface lock out access via sysfs, but that service wrongly
On 10/14/2011 07:17 AM, Jason Baron wrote:
On Thu, Oct 13, 2011 at 09:44:48AM -0700, Jeremy Fitzhardinge wrote:
pvops is basically a collection of ordinary _ops structures full of
function pointers, but it has a layer of patching to help optimise it.
In the common case, this just replaces an
On Fri, Oct 14, 2011 at 3:35 PM, Roedel, Joerg joerg.roe...@amd.com wrote:
This patch looks good. Please include it in the page-size patch-set.
will do.
Hmm, I'd like to constify the iommu_ops structures in the future. This
wouldn't work then anymore. How about renaming it to io_page_size
On Fri, Oct 14, 2011 at 7:03 PM, Ohad Ben-Cohen o...@wizery.com wrote:
Btw, how have you tested this code?
Of course. Every patch I send is always tested on...
*oops I thought you asked Btw, have you tested this code?. I missed
the how part :)
--
To unsubscribe from this list: send the line
On Fri, Oct 14, 2011 at 10:02:35AM -0700, Jeremy Fitzhardinge wrote:
On 10/14/2011 07:17 AM, Jason Baron wrote:
On Thu, Oct 13, 2011 at 09:44:48AM -0700, Jeremy Fitzhardinge wrote:
pvops is basically a collection of ordinary _ops structures full of
function pointers, but it has a layer of
On 10/14/2011 10:02 AM, Jeremy Fitzhardinge wrote:
Jump labels are essentially binary: you can use path A or path B. pvops
are multiway: there's no limit to the number of potential number of
paravirtualized hypervisor implementations. At the moment we have 4:
native, Xen, KVM and lguest.
On 10/14/2011 11:35 AM, Jason Baron wrote:
A nice featuer of jump labels, is that it allows the various branches
(currently we only support 2), to be written in c code (as opposed to asm),
which means you can write your code as you normally would and access any
parameters as you normally
On 10/14/2011 11:38 AM, H. Peter Anvin wrote:
On 10/14/2011 11:35 AM, Jason Baron wrote:
A nice featuer of jump labels, is that it allows the various branches
(currently we only support 2), to be written in c code (as opposed to asm),
which means you can write your code as you normally would
On 10/14/2011 11:35 AM, Jason Baron wrote:
On Fri, Oct 14, 2011 at 10:02:35AM -0700, Jeremy Fitzhardinge wrote:
On 10/14/2011 07:17 AM, Jason Baron wrote:
On Thu, Oct 13, 2011 at 09:44:48AM -0700, Jeremy Fitzhardinge wrote:
pvops is basically a collection of ordinary _ops structures full of
On 10/14/2011 11:37 AM, H. Peter Anvin wrote:
On 10/14/2011 10:02 AM, Jeremy Fitzhardinge wrote:
Jump labels are essentially binary: you can use path A or path B. pvops
are multiway: there's no limit to the number of potential number of
paravirtualized hypervisor implementations. At the
On 10/14/2011 12:10 PM, Jeremy Fitzhardinge wrote:
We probably don't want all those implementations (near) inline, so they
would end up being plain function calls anyway.
I would not object if the native one was closer, though; especially in
term of source text (the current level of
In order to preseve the original behavior of the KVM
test variants, split base.cfg once again and create
guest-hw.cfg, that contains (mostly) hardware related
variants (and some others that don't quite fit into
a new config file).
This patch was sent as pull request
37 matches
Mail list logo
