Re: [PATCH 00/27] KVM PPC PV framework
On 09.07.2010, at 06:57, MJ embd wrote: On Thu, Jul 1, 2010 at 4:12 PM, Alexander Graf ag...@suse.de wrote: On PPC we run PR=0 (kernel mode) code in PR=1 (user mode) and don't use the hypervisor extensions. While that is all great to show that virtualization is possible, there are quite some cases where the emulation overhead of privileged instructions is killing performance. This patchset tackles exactly that issue. It introduces a paravirtual framework using which KVM and Linux share a page to exchange register state with. That KVM and Linux or KVM and GuestOS ? KVM and GuestOS. The first user is of course Linux. Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netfilter: add CHECKSUM target
On Fri, Jul 09, 2010 at 01:29:13AM +0300, Michael S. Tsirkin wrote: This adds a `CHECKSUM' target, which can be used in the iptables mangle table. You can use this target to compute and fill in the checksum in an IP packet that lacks a checksum. This is particularly useful, if you need to work around old applications such as dhcp clients, that do not work well with checksum offloads, but don't want to disable checksum offload in your device. The problem happens in the field with virtualized applications. For reference, see Red Hat bz 60, as well as http://www.spinics.net/lists/kvm/msg37660.html Typical expected use (helps old dhclient binary running in a VM): iptables -A POSTROUTING -t mangle -p udp --dport 68 -j CHECKSUM --checksum-fill Signed-off-by: Michael S. Tsirkin m...@redhat.com I'd think that this target would be protocol-agnostic, no? Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/24] Nested VMX, v5
Nadav Har'El wrote: Hi Avi, This is a followup of our nested VMX patches that Orit Wasserman posted in December. We've addressed most of the comments and concerns that you and others on the mailing list had with the previous patch set. We hope you'll find these patches easier to understand, and suitable for applying to KVM. The following 24 patches implement nested VMX support. The patches enable a guest to use the VMX APIs in order to run its own nested guests. I.e., it allows running hypervisors (that use VMX) under KVM. We describe the theory behind this work, our implementation, and its performance characteristics, in IBM Research report H-0282, The Turtles Project: Design and Implementation of Nested Virtualization, available at: http://bit.ly/a0o9te The current patches support running Linux under a nested KVM using shadow page table (with bypass_guest_pf disabled). They support multiple nested hypervisors, which can run multiple guests. Only 64-bit nested hypervisors are supported. SMP is supported. Additional patches for running Windows under nested KVM, and Linux under nested VMware server, and support for nested EPT, are currently running in the lab, and will be sent as follow-on patchsets. Nadav All: Thnaks for the posting and in general the patches are well written. I like the concept of VMCSxy and I feel it is pretty clear (better than my previous naming as well), but there are some confusing inside, especially for the term shadow which I feel quit hard. Comments from me: 1: Basically there are 2 diferent type in VMCS, one is defined by hardware, whose layout is unknown to VMM. Another one is defined by VMM (this patch) and used for vmcs12. The former one is using struct vmcs to describe its data instance, but the later one doesn't have a clear definition (or struct vmcs12?). I suggest we can have a distinguish struct for this, for example struct sw_vmcs(software vmcs), or struct vvmcs (virtual vmcs). 2: vmcsxy (vmcs12, vmcs02, vmcs01) are for instances of either struct vmcs, or struct sw_vmcs, but not for struct Clear distinguish between data structure and instance helps IMO. 3: We may use prefix or suffix in addition to vmcsxy to explictly state the format of that instance. For example vmcs02 in current patch is for hardware use, hence it is an instance struct vmcs, but vmcs01 is an instance of struct sw_vmcs. Postfix and prefix helps to make better understand. 4: Rename l2_vmcs to vmcs02, l1_shadow_vmcs to vmcs01, l1_vmcs to vmcs02, with prefix/postfix can strengthen above concept of vmcsxy. 5: guest VMPTRLD emulation. Current patch creates vmcs02 instance each time when guest VMPTRLD, and free the instance at VMCLEAR. The code may fail if the vmcs (un-vmcleared) exceeds certain threshold to avoid denial of service. That is fine, but it brings additional complexity and may pay with a lot of memory. I think we can emulate using concept of cached vmcs here in case L1 VMM doesn't do vmclear in time. L0 VMM can simply flush those vmcs02 to guest memory i.e. vmcs12 per need. For example if the cached vcs02 exceeds 10, we can do automatically flush. Thx, Eddie -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
On Thu, Jul 1, 2010 at 4:13 PM, Alexander Graf ag...@suse.de wrote:
We just introduced a new PV interface that screams for documentation. So here
it is - a shiny new and awesome text file describing the internal works of
the PPC KVM paravirtual interface.
Signed-off-by: Alexander Graf ag...@suse.de
---
v1 - v2:
- clarify guest implementation
- clarify that privileged instructions still work
- explain safe MSR bits
- Fix dsisr patch description
- change hypervisor calls to use new register values
---
Documentation/kvm/ppc-pv.txt | 185
++
1 files changed, 185 insertions(+), 0 deletions(-)
create mode 100644 Documentation/kvm/ppc-pv.txt
diff --git a/Documentation/kvm/ppc-pv.txt b/Documentation/kvm/ppc-pv.txt
new file mode 100644
index 000..82de6c6
--- /dev/null
+++ b/Documentation/kvm/ppc-pv.txt
@@ -0,0 +1,185 @@
+The PPC KVM paravirtual interface
+=
+
+The basic execution principle by which KVM on PowerPC works is to run all
kernel
+space code in PR=1 which is user space. This way we trap all privileged
+instructions and can emulate them accordingly.
+
+Unfortunately that is also the downfall. There are quite some privileged
+instructions that needlessly return us to the hypervisor even though they
+could be handled differently.
+
+This is what the PPC PV interface helps with. It takes privileged
instructions
+and transforms them into unprivileged ones with some help from the
hypervisor.
+This cuts down virtualization costs by about 50% on some of my benchmarks.
+
+The code for that interface can be found in arch/powerpc/kernel/kvm*
+
+Querying for existence
+==
+
+To find out if we're running on KVM or not, we overlay the PVR register.
Usually
+the PVR register contains an id that identifies your CPU type. If, however,
you
+pass KVM_PVR_PARA in the register that you want the PVR result in, the
register
+still contains KVM_PVR_PARA after the mfpvr call.
+
+ LOAD_REG_IMM(r5, KVM_PVR_PARA)
+ mfpvr r5
+ [r5 still contains KVM_PVR_PARA]
+
+Once determined to run under a PV capable KVM, you can now use hypercalls as
+described below.
+
+PPC hypercalls
+==
+
+The only viable ways to reliably get from guest context to host context are:
+
+ 1) Call an invalid instruction
+ 2) Call the sc instruction with a parameter to sc
+ 3) Call the sc instruction with parameters in GPRs
+
+Method 1 is always a bad idea. Invalid instructions can be replaced later on
+by valid instructions, rendering the interface broken.
+
+Method 2 also has downfalls. If the parameter to sc is != 0 the spec is
+rather unclear if the sc is targeted directly for the hypervisor or the
+supervisor. It would also require that we read the syscall issuing
instruction
+every time a syscall is issued, slowing down guest syscalls.
+
+Method 3 is what KVM uses. We pass magic constants (KVM_SC_MAGIC_R0 and
+KVM_SC_MAGIC_R3) in r0 and r3 respectively. If a syscall instruction with
these
+magic values arrives from the guest's kernel mode, we take the syscall as a
+hypercall.
+
+The parameters are as follows:
+
+ r0 KVM_SC_MAGIC_R0
+ r3 KVM_SC_MAGIC_R3 Return code
+ r4 Hypercall number
+ r5 First parameter
+ r6 Second parameter
+ r7 Third parameter
+ r8 Fourth parameter
+
+Hypercall definitions are shared in generic code, so the same hypercall
numbers
+apply for x86 and powerpc alike.
+
+The magic page
+==
+
+To enable communication between the hypervisor and guest there is a new
shared
+page that contains parts of supervisor visible register state. The guest can
+map this shared page using the KVM hypercall KVM_HC_PPC_MAP_MAGIC_PAGE.
+
+With this hypercall issued the guest always gets the magic page mapped at the
+desired location in effective and physical address space. For now, we always
+map the page to -4096. This way we can access it using absolute load and
store
+functions. The following instruction reads the first field of the magic page:
+
+ ld rX, -4096(0)
+
+The interface is designed to be extensible should there be need later to add
+additional registers to the magic page. If you add fields to the magic page,
+also define a new hypercall feature to indicate that the host can give you
more
+registers. Only if the host supports the additional features, make use of
them.
+
+The magic page has the following layout as described in
+arch/powerpc/include/asm/kvm_para.h:
+
+struct kvm_vcpu_arch_shared {
+ __u64 scratch1;
+ __u64 scratch2;
+ __u64 scratch3;
+ __u64 critical; /* Guest may not get interrupts if == r1 */
+ __u64 sprg0;
+ __u64 sprg1;
+
Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
On 09.07.2010, at 11:11, MJ embd wrote: On Thu, Jul 1, 2010 at 4:13 PM, Alexander Graf ag...@suse.de wrote: We just introduced a new PV interface that screams for documentation. So here it is - a shiny new and awesome text file describing the internal works of the PPC KVM paravirtual interface. Signed-off-by: Alexander Graf ag...@suse.de + + +Some instructions require more logic to determine what's going on than a load +or store instruction can deliver. To enable patching of those, we keep some +RAM around where we can live translate instructions to. What happens is the +following: + + 1) copy emulation code to memory + 2) patch that code to fit the emulated instruction + 3) patch that code to return to the original pc + 4 + 4) patch the original instruction to branch to the new code + +That way we can inject an arbitrary amount of code as replacement for a single +instruction. This allows us to check for pending interrupts when setting EE=1 +for example. + Which patch does this mapping ? Can you please point to that. The branch patching is in patch 22/27. For the respective users, see patch 23-26/27. Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netfilter: add CHECKSUM target
On Friday 2010-07-09 00:29, Michael S. Tsirkin wrote:
include/linux/netfilter_ipv4/ipt_CHECKSUM.h | 18 +++
net/ipv4/netfilter/Kconfig | 16 ++
net/ipv4/netfilter/Makefile |1 +
net/ipv4/netfilter/ipt_CHECKSUM.c | 72 +++
New modules should use xt.
+static unsigned int
+checksum_tg(struct sk_buff *skb, const struct xt_action_param *par)
+{
+ if (skb-ip_summed == CHECKSUM_PARTIAL) {
+ skb_checksum_help(skb);
+ }
- {}
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netfilter: add CHECKSUM target
Am 09.07.2010 00:29, schrieb Michael S. Tsirkin: This adds a `CHECKSUM' target, which can be used in the iptables mangle table. You can use this target to compute and fill in the checksum in an IP packet that lacks a checksum. This is particularly useful, if you need to work around old applications such as dhcp clients, that do not work well with checksum offloads, but don't want to disable checksum offload in your device. The problem happens in the field with virtualized applications. For reference, see Red Hat bz 60, as well as http://www.spinics.net/lists/kvm/msg37660.html Typical expected use (helps old dhclient binary running in a VM): iptables -A POSTROUTING -t mangle -p udp --dport 68 -j CHECKSUM --checksum-fill I'm not sure this is something we want to merge upstream and support indefinitely. Dave suggested this as a temporary out-of-tree workaround until the majority of guest dhcp clients are fixed. Has anything changed that makes this course of action impractical? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Alt SeaBIOS SSDT cpu hotplug
On Thu, Jul 08, 2010 at 08:45:06PM -0400, Kevin O'Connor wrote:
On Thu, Jul 08, 2010 at 03:54:10PM +0300, Gleb Natapov wrote:
On Wed, Jul 07, 2010 at 07:26:07PM -0400, Kevin O'Connor wrote:
On Wed, Jul 07, 2010 at 01:22:49PM +0300, Gleb Natapov wrote:
On Wed, Jul 07, 2010 at 12:57:05AM -0400, Kevin O'Connor wrote:
The CPUS package stores references to the Processor objects, and the
CPON package stores the state of which cpus are active. With this
info, hopefully there is no need to update the MADT tables.
The way you wrote it acpi_id is always equal to lapic_id which is not
alway true. By using MADT from memory we remove this dependency from
DSDT code.
The current code always sets the apic-processor_id equal to
apic-local_apic_id in the madt apic table. If this changes, we could
add a dynamically created mapping table to the ssdt. Something like:
Name(CPLA, Package() { 0x00, 0x01, 0x02, 0x03, 0x04 })
Yeah, but if we can avoid it in the first place why not doing so.
There is a cost to reading/writing the MADT tables. The hardcoding of
0x514 has a risk - it's not clear to me that an optionrom wont clobber
that space. It also recently occurred to me that there may be a
problem if a guest expects the MADT address to remain constant across
a hibernate/restore cycle - the malloc_high() function doesn't
guarentee stable addresses across reboots.
That's definitely an issue. HW shouldn't change between hibernate and
resume, so boot process should be the same and address should end up be
the same too, but I wouldn't want to rely on this blindly.
BTW how
do you pass to DSDT what cpus are initially on? Previously this info was
taken from memory copy of MADT too.
The CPON array is dynamically generated with the status of the
processors. (It is then kept up to date by the DSDT code.) The code
for generating CPON is:
// build Name(CPON, Package() { One, One, ..., Zero, Zero, ... })
*(ssdt_ptr++) = 0x08; // NameOp
*(ssdt_ptr++) = 'C';
*(ssdt_ptr++) = 'P';
*(ssdt_ptr++) = 'O';
*(ssdt_ptr++) = 'N';
*(ssdt_ptr++) = 0x12; // PackageOp
ssdt_ptr = encodeLen(ssdt_ptr, 2+1+(1*acpi_cpus), 2);
*(ssdt_ptr++) = acpi_cpus;
for (i=0; iacpi_cpus; i++)
*(ssdt_ptr++) = (i CountCPUs) ? 0x01 : 0x00;
See it now. Thanks.
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] increase MAX_NICS value
Hi all
max number of allowed nics per vm is hardcoded on net.h to 8. This value
it's too low in situation with big network, increase to 24
this should be safe as mentioned on this thread
http://kerneltrap.org/mailarchive/linux-kvm/2009/1/29/4848304/thread
Signed-off-by: Alessandro Bono alessandro.b...@gmail.com
--- net.h.old 2010-07-09 17:30:39.542170103 +0200
+++ net.h 2010-07-09 17:30:48.842166029 +0200
@@ -121,7 +121,7 @@
/* NIC info */
-#define MAX_NICS 8
+#define MAX_NICS 24
struct NICInfo {
uint8_t macaddr[6];
--
Cordiali Saluti
Alessandro Bono
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 08/12] Inject asynchronous page fault into a guest if page is swapped out.
On Thu, Jul 08, 2010 at 08:10:31PM +0200, Peter Zijlstra wrote: On Thu, 2010-07-08 at 20:09 +0200, Peter Zijlstra wrote: On Thu, 2010-07-08 at 21:05 +0300, Gleb Natapov wrote: + /* do alloc atomic since if we are going to sleep anyway we + may as well sleep faulting in page */ + work = kmem_cache_zalloc(async_pf_cache, GFP_ATOMIC); + if (!work) + return 0; GFP_KERNEL is fine for this context. But it can sleep, no? The comment explains why I don't want to sleep here. In that case, use 0, no use wasting __GFP_HIGH on something that doesn't actually need it. Ah, I just saw we have GFP_NOWAIT for that. Indeed. Will use GFP_NOWAIT. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netfilter: add CHECKSUM target
On Friday 2010-07-09 17:17, Patrick McHardy wrote: This adds a `CHECKSUM' target, which can be used in the iptables mangle table. You can use this target to compute and fill in the checksum in an IP packet that lacks a checksum. This is particularly useful, if you need to work around old applications such as dhcp clients, that do not work well with checksum offloads, but don't want to disable checksum offload in your device. I'm not sure this is something we want to merge upstream and support indefinitely. We could put it into Xtables-addons. That would also be consistent with Dave's suggestion. Dave suggested this as a temporary out-of-tree workaround until the majority of guest dhcp clients are fixed. Has anything changed that makes this course of action impractical? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netfilter: add CHECKSUM target
Am 09.07.2010 18:26, schrieb Jan Engelhardt: On Friday 2010-07-09 17:17, Patrick McHardy wrote: This adds a `CHECKSUM' target, which can be used in the iptables mangle table. You can use this target to compute and fill in the checksum in an IP packet that lacks a checksum. This is particularly useful, if you need to work around old applications such as dhcp clients, that do not work well with checksum offloads, but don't want to disable checksum offload in your device. I'm not sure this is something we want to merge upstream and support indefinitely. We could put it into Xtables-addons. That would also be consistent with Dave's suggestion. Sure, that would be fine with me. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Alt SeaBIOS SSDT cpu hotplug
Kevin O'Connor wrote:
On Thu, Jul 08, 2010 at 09:19:13PM +0800, Liu, Jinsong wrote:
Avi Kivity wrote:
Very nice. I thought about doing this but abandoned it as
unmaintainable. Using external functions and the ID variable,
however, reduces the mess to tolerable proportions, and gains us a
lot of flexibility. We can now have any combinations of sockets and
installed cpus.
Agree, only 1 concern
will it bring debugable/ scalable issue by hardcode aml code?
I've updated the patch (see below). This version documents how one
can build a new version of the Processor() ssdt snippet.
I've tested this under linux - there were a few bugs in the previous
patch. I also had to replace the dynamically created CPUS array with
a dynamically created NTFY method - which is a bit more complicated.
-Kevin
Yeah, thanks Kevin.
After you done patch and draft test, our QA may do nightly test.
Thanks,
Jinsong
diff --git a/src/acpi-dsdt.dsl b/src/acpi-dsdt.dsl
index cc31112..24674fc 100644
--- a/src/acpi-dsdt.dsl
+++ b/src/acpi-dsdt.dsl
@@ -648,6 +648,78 @@ DefinitionBlock (
Zero /* reserved */
})
+/* CPU hotplug */
+Scope(\_SB) {
+/* Objects filled in by run-time generated SSDT */
+External(NTFY, MethodObj)
+External(CPON, PkgObj)
+
+/* Methods called by run-time generated SSDT Processor
objects */ +Method (CPMA, 1, NotSerialized) {
+// _MAT method - create an madt apic buffer
+// Local0 = CPON flag for this cpu
+Store(DerefOf(Index(CPON, Arg0)), Local0)
+// Local1 = Buffer (in madt apic form) to return
+Store(Buffer(8) {0x00, 0x08, 0x00, 0x00, 0x00, 0, 0, 0},
Local1) +// Update the processor id, lapic id, and
enable/disable status +Store(Arg0, Index(Local1, 2))
+Store(Arg0, Index(Local1, 3))
+Store(Local0, Index(Local1, 4))
+Return (Local1)
+}
+Method (CPST, 1, NotSerialized) {
+// _STA method - return ON status of cpu
+// Local0 = CPON flag for this cpu
+Store(DerefOf(Index(CPON, Arg0)), Local0)
+If (Local0) { Return(0xF) } Else { Return(0x0) }
+}
+Method (CPEJ, 2, NotSerialized) {
+// _EJ0 method - eject callback
+Sleep (0xC8)
+}
+
+/* CPU hotplug notify method */
+OperationRegion(PRST, SystemIO, 0xaf00, 32)
+Field (PRST, ByteAcc, NoLock, Preserve)
+{
+PRS, 256
+}
+Method(PRSC, 0) {
+// Local5 = active cpu bitmap
+Store (PRS, Local5)
+// Local2 = last read byte from bitmap
+Store (Zero, Local2)
+// Local0 = cpuid iterator
+Store (Zero, Local0)
+While (LLess(Local0, SizeOf(CPON))) {
+// Local1 = CPON flag for this cpu
+Store(DerefOf(Index(CPON, Local0)), Local1)
+If (And(Local0, 0x07)) {
+// Shift down previously read bitmap byte
+ShiftRight(Local2, 1, Local2)
+} Else {
+// Read next byte from cpu bitmap
+Store(DerefOf(Index(Local5, ShiftRight(Local0,
3))), Local2) +}
+// Local3 = active state for this cpu
+Store(And(Local2, 1), Local3)
+
+If (LNotEqual(Local1, Local3)) {
+// State change - update CPON with new state
+Store(Local3, Index(CPON, Local0))
+// Do CPU notify
+If (LEqual(Local3, 1)) {
+NTFY(Local0, 1)
+} Else {
+NTFY(Local0, 3)
+}
+}
+Increment(Local0)
+}
+Return(One)
+}
+}
+
Scope (\_GPE)
{
Name(_HID, ACPI0006)
@@ -701,7 +773,8 @@ DefinitionBlock (
}
Method(_L02) {
-Return(0x01)
+// CPU hotplug event
+Return(\_SB.PRSC())
}
Method(_L03) {
Return(0x01)
diff --git a/src/acpi.c b/src/acpi.c
index 0559443..082ef73 100644
--- a/src/acpi.c
+++ b/src/acpi.c
@@ -406,16 +406,56 @@ build_madt(void)
return madt;
}
+// Encode a hex value
+static inline char getHex(u32 val) {
+val = 0x0f;
+return (val = 9) ? ('0' + val) : ('A' + val - 10);
+}
+
+// Encode a length in an SSDT.
+static u8 *
+encodeLen(u8 *ssdt_ptr, int length, int bytes)
+{
+if (bytes = 1) {
+*ssdt_ptr = length 0x3f;
+return ssdt_ptr+1;
+}
+ssdt_ptr[0] = (((bytes-1) 0x3) 6) | (length 0x0f);
+ssdt_ptr[1] = ((length 4) 0xff);
+ssdt_ptr[2] = ((length 12) 0xff);
+ssdt_ptr[3] = ((length
KVM Forum 2010: schedule and registration reminder
As a reminder...the registration fees will increase on July 15th, so register now to save the fees. KVM Forum registration link is here: http://events.linuxfoundation.org/component/registrationpro/?func=detailsdid=34 Hotel and travel information is here (same hotel and venue as LinuxCon): http://events.linuxfoundation.org/events/linuxcon/hotel Here is the schedule (should be up on the LF site with more details shortly). Monday, August 9th -- 9:009:30Welcome + Keynote 9:3010:15 Desktop virtualization with spice 10:15 10:45 Developing tests for the KVM autotest framework 10:45 11:00 - break - 11:00 11:30 Threading the QEMU Device Model 11:30 12:00 QEMU's new device model qdev 12:00 12:30 KVM on Server Class PowerPC 12:30 13:30 - lunch - 13:30 14:00 Transparent Hugepage Support 14:00 14:30 Migration: how to hop from machine to machine without losing state 14:30 15:00 Sheepdog: distributed storage system for QEMU 15:00 15:30 - break - 15:30 16:00 How to keep time correctly, and avoid SDR-awk cab emit peek problems 16:00 16:30 PV-DMA using IOMMU Emulation 16:30 16:45 Network Virtualization in KVM 16:45 17:00 Ganeti as a KVM cluster management interface 17:00 17:15 Porting virtio to PowerVM Hypervisors 17:15 17:30 lightning talks 17:30 19:00 BoFs Tuesday, August 10th 9:009:15Keynote 9:159:45vhost-net and virtio-net: need for speed 9:4510:15 The QEMU Monitor Protocol (QMP) 10:15 10:45 Integrating KVM with Linux 10:45 11:00 - break - 11:00 11:30 KVM in Embedded: Requirements, Experiences and Open Challenges 11:30 12:00 Kemari: Fault Tolerant Virtual Machine Synchronization based on KVM 12:00 12:30 Managing Resources on Over-committed Virtualization Hosts 12:30 13:30 - lunch - 13:30 14:00 A Walkthrough on some recent KVM performance improvements 14:00 14:30 Examing KVM as Nested Virtualization Friendly Guest 14:30 15:00 PCI direct device assignment: pwned! all your devices are belong to guest 15:00 15:30 - break - 15:30 16:00 Performance and Scalability of Server Consolidation using KVM 16:00 16:15 WinKVM: Windows kernel-based Virtual Machine 16:15 16:30 Nahanni: Inter-VM Shared Memory 16:30 16:45 Asynchronous Page Faults: AIX did it. 16:45 17:00 PCI Express support in QEmu 17:00 17:15 lightning talks 17:15 17:30 Closing comments 17:30 19:00 BoFs We look forward to seeing you there. thanks, -KVM Forum 2010 Program Commitee -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] increase MAX_NICS value
Alessandro Bono alessandro.b...@gmail.com writes: Hi all max number of allowed nics per vm is hardcoded on net.h to 8. This value it's too low in situation with big network, increase to 24 this should be safe as mentioned on this thread http://kerneltrap.org/mailarchive/linux-kvm/2009/1/29/4848304/thread Signed-off-by: Alessandro Bono alessandro.b...@gmail.com 1. Doesn't this belong upstream? qemu-de...@nongnu.org 2. MAX_NICS applies only to -net nic. Use -device instead. See docs/qdev-device-use.txt -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/27] KVM PPC PV framework
On 09.07.2010, at 06:57, MJ embd wrote: On Thu, Jul 1, 2010 at 4:12 PM, Alexander Graf ag...@suse.de wrote: On PPC we run PR=0 (kernel mode) code in PR=1 (user mode) and don't use the hypervisor extensions. While that is all great to show that virtualization is possible, there are quite some cases where the emulation overhead of privileged instructions is killing performance. This patchset tackles exactly that issue. It introduces a paravirtual framework using which KVM and Linux share a page to exchange register state with. That KVM and Linux or KVM and GuestOS ? KVM and GuestOS. The first user is of course Linux. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 27/27] KVM: PPC: Add Documentation about PV interface
On 09.07.2010, at 11:11, MJ embd wrote: On Thu, Jul 1, 2010 at 4:13 PM, Alexander Graf ag...@suse.de wrote: We just introduced a new PV interface that screams for documentation. So here it is - a shiny new and awesome text file describing the internal works of the PPC KVM paravirtual interface. Signed-off-by: Alexander Graf ag...@suse.de + + +Some instructions require more logic to determine what's going on than a load +or store instruction can deliver. To enable patching of those, we keep some +RAM around where we can live translate instructions to. What happens is the +following: + + 1) copy emulation code to memory + 2) patch that code to fit the emulated instruction + 3) patch that code to return to the original pc + 4 + 4) patch the original instruction to branch to the new code + +That way we can inject an arbitrary amount of code as replacement for a single +instruction. This allows us to check for pending interrupts when setting EE=1 +for example. + Which patch does this mapping ? Can you please point to that. The branch patching is in patch 22/27. For the respective users, see patch 23-26/27. Alex -- To unsubscribe from this list: send the line unsubscribe kvm-ppc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
