Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
On Sat, Mar 29, 2008 at 01:09:30AM +, Jamie Lokier wrote: > Marcelo Tosatti wrote: > > I don't think the first qemu_aio_flush() is necessary because the fsync > > request will be enqueued after pending ones: > > > >aio_fsync() function does a sync on all outstanding > >asynchronous I/O operations associated with > >aiocbp->aio_fildes. > > > >More precisely, if op is O_SYNC, then all currently queued > >I/O operations shall be completed as if by a call of > >fsync(2), and if op is O_DSYNC, this call is the asynchronous > >analog of fdatasync(2). Note that this is a request only — > >this call does not wait for I/O completion. > > > > glibc sets the priority for fsync as 0, which is the same priority AIO > > reads and writes are submitted by QEMU. > > Do AIO operations always get executed in the order they are submitted? With glibc AIO on the same file descriptor, yes. See sysdeps/pthreads/aio_misc.c. The kernel AIO implementation (used for DIRECT IO) does not implement aio_fsync. > I was under the impression this is not guaranteed, as relaxed ordering > permits better I/O scheduling (e.g. to reduce disk seeks) - which is > one of the most useful points of AIO. (Otherwise you might as well > just have one worker thread doing synchronous IO in order). > > And because of that, I was under the impression the only way to > implement a write barrier+flush in AIO was (1) wait for pending writes > to complete, then (2) aio_fsync, then (3) wait for the aio_fsync. > > I could be wrong, but I haven't seen any documentation which says > otherwise, and it's what I'd expect of an implementation. I.e. it's > just an asynchronous version of fsync(). All documentation (and source code) I can find indicates that aio_fsync() will wait for pending AIO requests to finish before doing the fsync/fdatasync system call. I find it hard to see much purpose in such an interface otherwise. http://www.opengroup.org/onlinepubs/009695399/functions/aio_fsync.html http://docs.hp.com/en/B9106-90012/aio.5.html "Synchronizing Permanent Storage" http://www.gnu.org/software/libtool/manual/libc/Synchronizing-AIO-Operations.html#Synchronizing-AIO-Operations "When dealing with asynchronous operations it is sometimes necessary to get into a consistent state. This would mean for AIO that one wants to know whether a certain request or a group of request were processed. This could be done by waiting for the notification sent by the system after the operation terminated, but this sometimes would mean wasting resources (mainly computation time). Instead POSIX.1b defines two functions which will help with most kinds of consistency." http://www.governmentsecurity.org/articles/articles2/B2355-90693.pdf_fl/B2355-90693-29.html This is the HPUX man page, much better than the Linux one. > The quoted man page doesn't convince me. It says "all currently > queued I/O operations shall be completed" which _could_ mean that > aio_fsync is an AIO barrier too. > > But then "if by a call of fsync(2)" implies that aio_fsync+aio_suspend > could just be replaced by fsync() with no change of semantics. So > "queued I/O operations" means what fsync() handles: dirty file data, > not in-flight AIO writes. > > And you already noticed that fsync() is _not_ guaranteed to flush > in-flight AIO writes. Being the asynchronous analog, aio_fsync() > would not either. That seems to be the whole point of aio_fsync(). - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [01/17]PATCH Add API for allocating dynamic TR resouce. V7
From 1028321e00b0f3a60fc414484754f489a70f2400 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Sat, 29 Mar 2008 09:23:37 +0800
Subject: [PATCH] Add API for allocating Dynamic TR resouce.
Dynamic TR resouce should be managed in an uniform way.
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
Signed-off-by: Anthony Xu<[EMAIL PROTECTED]>
---
arch/ia64/kernel/mca.c | 49 +++
arch/ia64/kernel/mca_asm.S |5 +
arch/ia64/mm/tlb.c | 196
include/asm-ia64/kregs.h |3 +
include/asm-ia64/tlb.h | 14 +++
5 files changed, 267 insertions(+), 0 deletions(-)
diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
index 6c18221..ee6924b 100644
--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -97,6 +97,7 @@
#include
#include
+#include
#include "mca_drv.h"
#include "entry.h"
@@ -112,6 +113,7 @@ DEFINE_PER_CPU(u64, ia64_mca_data); /* ==
__per_cpu_mca[smp_processor_id()] */
DEFINE_PER_CPU(u64, ia64_mca_per_cpu_pte); /* PTE to map per-CPU area
*/
DEFINE_PER_CPU(u64, ia64_mca_pal_pte); /* PTE to map PAL code */
DEFINE_PER_CPU(u64, ia64_mca_pal_base);/* vaddr PAL code granule */
+DEFINE_PER_CPU(u64, ia64_mca_tr_reload); /* Flag for TR reload */
unsigned long __per_cpu_mca[NR_CPUS];
@@ -1182,6 +1184,49 @@ all_in:
return;
}
+/* mca_insert_tr
+ *
+ * Switch rid when TR reload and needed!
+ * iord: 1: itr, 2: itr;
+ *
+*/
+static void mca_insert_tr(u64 iord)
+{
+
+ int i;
+ u64 old_rr;
+ struct ia64_tr_entry *p;
+ unsigned long psr;
+ int cpu = smp_processor_id();
+
+ psr = ia64_clear_ic();
+ for (i = IA64_TR_ALLOC_BASE; i < IA64_TR_ALLOC_MAX; i++) {
+ p = &__per_cpu_idtrs[cpu][iord-1][i];
+ if (p->pte&0x1) {
+ old_rr = ia64_get_rr(p->ifa);
+ if (old_rr != p->rr) {
+ ia64_set_rr(p->ifa, p->rr);
+ ia64_srlz_d();
+ }
+ ia64_ptr(iord, p->ifa, p->itir >> 2);
+ ia64_srlz_i();
+ if (iord & 0x1) {
+ ia64_itr(0x1, i, p->ifa, p->pte, p->itir
>> 2);
+ ia64_srlz_i();
+ }
+ if (iord & 0x2) {
+ ia64_itr(0x2, i, p->ifa, p->pte, p->itir
>> 2);
+ ia64_srlz_i();
+ }
+ if (old_rr != p->rr) {
+ ia64_set_rr(p->ifa, old_rr);
+ ia64_srlz_d();
+ }
+ }
+ }
+ ia64_set_psr(psr);
+}
+
/*
* ia64_mca_handler
*
@@ -1271,6 +1316,10 @@ ia64_mca_handler(struct pt_regs *regs, struct
switch_stack *sw,
monarch_cpu = -1;
#endif
}
+ if (__get_cpu_var(ia64_mca_tr_reload)) {
+ mca_insert_tr(0x1); /*Reload dynamic itrs*/
+ mca_insert_tr(0x2); /*Reload dynamic itrs*/
+ }
if (notify_die(DIE_MCA_MONARCH_LEAVE, "MCA", regs, (long)&nd, 0,
recover)
== NOTIFY_STOP)
ia64_mca_spin(__func__);
diff --git a/arch/ia64/kernel/mca_asm.S b/arch/ia64/kernel/mca_asm.S
index 8bc7d25..a06d465 100644
--- a/arch/ia64/kernel/mca_asm.S
+++ b/arch/ia64/kernel/mca_asm.S
@@ -219,8 +219,13 @@ ia64_reload_tr:
mov r20=IA64_TR_CURRENT_STACK
;;
itr.d dtr[r20]=r16
+ GET_THIS_PADDR(r2, ia64_mca_tr_reload)
+ mov r18 = 1
;;
srlz.d
+ ;;
+ st8 [r2] =r18
+ ;;
done_tlb_purge_and_reload:
diff --git a/arch/ia64/mm/tlb.c b/arch/ia64/mm/tlb.c
index 655da24..0b418cc 100644
--- a/arch/ia64/mm/tlb.c
+++ b/arch/ia64/mm/tlb.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include
static struct {
unsigned long mask; /* mask of supported purge page-sizes */
@@ -39,6 +41,10 @@ struct ia64_ctx ia64_ctx = {
};
DEFINE_PER_CPU(u8, ia64_need_tlb_flush);
+DEFINE_PER_CPU(u8, ia64_tr_num); /*Number of TR slots in current
processor*/
+DEFINE_PER_CPU(u8, ia64_tr_used); /*Max Slot number used by kernel*/
+
+struct ia64_tr_entry __per_cpu_idtrs[NR_CPUS][2][IA64_TR_ALLOC_MAX];
/*
* Initializes the ia64_ctx.bitmap array based on max_ctx+1.
@@ -190,6 +196,9 @@ ia64_tlb_init (void)
ia64_ptce_info_t uninitialized_var(ptce_info); /* GCC be quiet
*/
unsigned long tr_pgbits;
long status;
+ pal_vm_info_1_u_t vm_info_1;
+ pal_vm_info_2_u_t vm_info_2;
+ int cpu = smp_processor_id();
if ((status = ia64_pal_vm_page_size(&tr_pgbits, &purge.mask)) !=
0) {
printk(KERN_ERR "PAL_VM_PAGE_SIZE failed with
status=%ld; "
@@ -206,4 +215,191 @@ ia64_tlb_init (void)
local_cpu_data->ptce_stride[1] = ptce_info.stride[1];
Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
On Saturday 29 March 2008, Jamie Lokier wrote: > Paul Brook wrote: > > > That'll depend on what kind of device is emulated. Does the SCSI > > > emulation handle multiple in-flight commands with any guarantee on > > > order? > > > > SCSI definitely allows (and we emulate) multiple in flight commands. > > I can't find any requirement that writes must complete before a > > subsequent SYNCHRONISE_CACHE. However I don't claim to know the spec > > that well, > > Aren't there SCSI tagged barrier commands or something like that, > which allow a host to request ordering between commands? Ah, yes. Ordering is defined as part of the task management model, not part of the commands themselves. For parallel scsi barrier tasks are created using the ORDERED message (The implementation for this in the LSI HBA is currently absent). So in theory we don't care about this for SCSI because ordering will already have been enforced by upper levels. Paul - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [17/17][PATCH] kvm/ia64: How to boot up guests on kvm/ia64 V7
>From 454e8a4473ed13ce313b2ba3b654feb926a891b7 Mon Sep 17 00:00:00 2001 From: Xiantao Zhang <[EMAIL PROTECTED]> Date: Wed, 12 Mar 2008 13:57:33 +0800 Subject: [PATCH] kvm/ia64: How to boot up guests on kvm/ia64 Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]> --- Documentation/ia64/kvm-howto.txt | 74 ++ 1 files changed, 74 insertions(+), 0 deletions(-) create mode 100644 Documentation/ia64/kvm-howto.txt diff --git a/Documentation/ia64/kvm-howto.txt b/Documentation/ia64/kvm-howto.txt new file mode 100644 index 000..5a8049c --- /dev/null +++ b/Documentation/ia64/kvm-howto.txt @@ -0,0 +1,74 @@ + Guide: How to boot up guests on kvm/ia64 + +1. Get the kvm source from git.kernel.org. + Userspace source: + git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-userspace.git + Kernel Source: + git clone git://git.kernel.org/pub/scm/linux/kernel/git/xiantao/kvm-ia64.git + +2. Compile the source code. + 2.1 Compile userspace code: + (1)cd ./kvm-userspace + (2)./configure + (3)cd kernel + (4)make sync LINUX= $kernel_dir (kernel_dir is the directory of kernel source.) + (5)cd .. + (6)make qemu + (7)cd qemu; make install + + 2.2 Compile kernel source code: + (1) cd ./$kernel_dir + (2) Make menuconfig + (3) Enter into virtualization option, and choose kvm. + (4) make + (5) Once (4) done, make modules_install + (6) Make initrd, and use new kernel to reboot up host machine. + (7) Once (6) done, cd $kernel_dir/arch/ia64/kvm + (8) insmod kvm.ko; insmod kvm-intel.ko + +Note: For step 2, please make sure that host page size == TARGET_PAGE_SIZE of qemu, otherwise, may fail. + +3. Get Guest Firmware named as Flash.fd, and put it under right place: + (1) If you have the guest firmware (binary)released by Intel Corp for Xen, you can use it directly. + (2) If you want to build a guest firmware form source code. Please download the source from + hg clone http://xenbits.xensource.com/ext/efi-vfirmware.hg + Use the Guide of the source to build open Guest Firmware. + (3) Rename it to Flash.fd, and copy it to /usr/local/share/qemu +Note: For step 3, kvm use the guest firmware which complies with the one Xen uses. + +4. Boot up Linux or Windows guests: + 4.1 Create or install a image for guest boot. If you have xen experience, it should be easy. + + 4.2 Boot up guests use the following command. + /usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda $your_image + (xx is the number of virtual processors for the guest, now the maximum value is 4) + +5. Known possibile issue on some platforms with old Firmware + +If meet strange host crashes, you may try to solve it through either of the following methods. +(1): Upgrade your Firmware to the latest one. + +(2): Applying the below patch to kernel source. +diff --git a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S +index 0b53344..f02b0f7 100644 +--- a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S +@@ -84,7 +84,8 @@ GLOBAL_ENTRY(ia64_pal_call_static) + mov ar.pfs = loc1 + mov rp = loc0 + ;; +- srlz.d // serialize restoration of psr.l ++ srlz.i // serialize restoration of psr.l ++ ;; + br.ret.sptk.many b0 + END(ia64_pal_call_static) + +6. Bug report: + If you found any issues when use kvm/ia64, Please post the bug info to kvm-ia64-devel mailing list. + https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel/ + +Thanks for your interest! Let's work together, and make kvm/ia64 stronger and stronger! + + + Xiantao Zhang <[EMAIL PROTECTED]> + 2008.3.10 -- 1.5.2 0017-kvm-ia64-How-to-boot-up-guests-on-kvm-ia64.patch Description: 0017-kvm-ia64-How-to-boot-up-guests-on-kvm-ia64.patch - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [Patch][00/17] kvm-ia64 for kernel V7
Compared with V6, 1. Updated the PATCH 01 according to Tony's comments. 2. Updated the PATCH 14 according to Akio's comments. 3. Updated the PATCH 17 according to Akio's comments. The latest patchset is located at git://git.kernel.org/pub/scm/linux/kernel/git/xiantao/kvm-ia64.git kvm-ia64-mc7. Pelase have a review! Xiantao - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [17/17][PATCH] kvm/ia64: How to boot up guests on kvm/ia64
Akio Takebe wrote: > Hi, > > I found 3 typos. > >> +3. Get Guest Firmware named as Flash.fd, and put it under right >> place: + (1) If you have the guest firmware (binary)released by Intel >> Corp for Xen, you can use it directly. >> +(2) If you want to build a guest firmware form souce code. souce >> ---> source > >> +5. Known possbile issue on some platforms with old Firmware >> + > possbile ---> possible > >> +(2): Applying the below patch to kernel source. >> +diff --git a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S >> +index 0b53344..f02b0f7 100644 >> +--- a/arch/ia64/kernel/pal.S >> b/arch/ia64/kernel/pal.S >> +@@ -84,7 +84,8 @@ GLOBAL_ENTRY(ia64_pal_call_static) + mov ar.pfs >> = loc1 + mov rp = loc0 >> +;; >> +- srlz.d // seralize restoration of psr.l >> ++ srlz.i // seralize restoration of psr.l seralize ---> serialize Good finding. The last one is copied from kernel, maybe need a patch to fix it :) Xiantao - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [11/17][PATCH] kvm/ia64: add processor virtulization support.
Akio Takebe wrote:
> Hi, Xiantao and Anthony
>
>> +void getfpreg(unsigned long regnum, struct ia64_fpreg *fpval,
>> +struct kvm_pt_regs *regs)
>> +{
>> +/* Take floating register rotation into consideration*/
>> +if (regnum >= IA64_FIRST_ROTATING_FR)
>> +regnum = IA64_FIRST_ROTATING_FR + fph_index(regs,
>> regnum);
>> +#define CASE_FIXED_FP(reg) \
>> +case (reg) : \
>> +ia64_stf_spill(fpval, reg); \
>> +break
>> +
>> +switch (regnum) {
>> +CASE_FIXED_FP(0);
>> +CASE_FIXED_FP(1);
>> +CASE_FIXED_FP(2);
>> +CASE_FIXED_FP(3);
>> +CASE_FIXED_FP(4);
>> +CASE_FIXED_FP(5);
>> +
>> +CASE_FIXED_FP(6);
>> +CASE_FIXED_FP(7);
>> +CASE_FIXED_FP(8);
>> +CASE_FIXED_FP(9);
>> +CASE_FIXED_FP(10);
>> +CASE_FIXED_FP(11);
>> +
> Is this correct ? Though I don't know why xen do so.
> In the case of Xen, the above parts are;
>
> #define CASE_SAVED_FP(reg) \
> case reg: \
> fpval->u.bits[0] = regs->f##reg.u.bits[0]; \
> fpval->u.bits[1] = regs->f##reg.u.bits[1]; \
> break
>
> CASE_SAVED_FP(6);
> CASE_SAVED_FP(7);
> CASE_SAVED_FP(8);
>
Hi, Akio
Current should be correct, because for every host<-> guest
switch, we switched FPU accordingly. So the fpu register file is
dedicated for current vm, getting it from physical register should be
right. But for xen's code, due to lazy fpu save/restore, current fpu
register file maybe not belong to current vcpu, so need to load it from
stack. Thanks
Xiantao
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [14/17][PATCH] kvm/ia64: Add guest interruptioninjection support.
INITIAL_PSR_VALUE_AT_INTERRUPTION 0x001808028034 >> + > Xen also use this value, you had better use macros of PSR bits. > Or you can add the same comments as Xen. Hi, Akio. The comment is where it is used. Anyway, using macro is better. Changed. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
Paul Brook wrote: > > That'll depend on what kind of device is emulated. Does the SCSI > > emulation handle multiple in-flight commands with any guarantee on > > order? > > SCSI definitely allows (and we emulate) multiple in flight commands. > I can't find any requirement that writes must complete before a > subsequent SYNCHRONISE_CACHE. However I don't claim to know the spec > that well, Aren't there SCSI tagged barrier commands or something like that, which allow a host to request ordering between commands? > it's probably not a bad idea have them complete anyway. Preferably > this would be a completely asynchronous operation. i.e. the sync > command returns immediately, but only completes when all preceding > writes have completed and been flushed to disk. I agree, that seems the optimal implementation. -- Jamie - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [08/17][PATCH] kvm/ia64: Add interruption vector table for vmm.
Akio Takebe wrote: > Hi, Xiantao > > a comments is below. > > >> +// 0x3000 Entry 12 (size 64 bundles) External Interrupt (4) >> +ENTRY(kvm_interrupt) +mov r31=pr// prepare to save predicates >> +mov r19=12 >> +mov r29=cr.ipsr >> +;; >> +tbit.z p6,p7=r29,IA64_PSR_VM_BIT >> +tbit.z p0,p15=r29,IA64_PSR_I_BIT >> +;; >> +(p7) br.sptk kvm_dispatch_interrupt >> +;; >> +mov r27=ar.rsc /* M */ >> +mov r20=r1 /* A */ >> +mov r25=ar.unat /* M */ >> +mov r26=ar.pfs /* I */ >> +mov r28=cr.iip /* M */ >> +cover /* B (or nothing) */ >> +;; >> +mov r1=sp >> +;; >> +invala /* M */ >> +mov r30=cr.ifs >> +;; >> +addl r1=-VMM_PT_REGS_SIZE,r1 >> +;; >> +adds r17=2*L1_CACHE_BYTES,r1/* really: biggest cache-line size >> */ +adds r16=PT(CR_IPSR),r1 >> +;; >> +lfetch.fault.excl.nt1 [r17],L1_CACHE_BYTES >> +st8 [r16]=r29 /* save cr.ipsr */ >> +;; >> +lfetch.fault.excl.nt1 [r17] >> +mov r29=b0 >> +;; >> +adds r16=PT(R8),r1 /* initialize first base pointer */ >> +adds r17=PT(R9),r1 /* initialize second base pointer */ >> +mov r18=r0 /* make sure r18 isn't NaT */ + ;; >> +.mem.offset 0,0; st8.spill [r16]=r8,16 >> +.mem.offset 8,0; st8.spill [r17]=r9,16 >> +;; >> +.mem.offset 0,0; st8.spill [r16]=r10,24 >> +.mem.offset 8,0; st8.spill [r17]=r11,24 >> +;; >> +st8 [r16]=r28,16/* save cr.iip */ >> +st8 [r17]=r30,16/* save cr.ifs */ >> +mov r8=ar.fpsr /* M */ >> +mov r9=ar.csd >> +mov r10=ar.ssd >> +movl r11=FPSR_DEFAULT /* L-unit */ >> +;; >> +st8 [r16]=r25,16/* save ar.unat */ >> +st8 [r17]=r26,16/* save ar.pfs */ >> +shl r18=r18,16 /* compute ar.rsc to be used for "loadrs" */ >> +;; >> +st8 [r16]=r27,16/* save ar.rsc */ >> +adds r17=16,r17 /* skip over ar_rnat field */ +;; >> +st8 [r17]=r31,16/* save predicates */ >> +adds r16=16,r16 /* skip over ar_bspstore field */ + ;; >> +st8 [r16]=r29,16/* save b0 */ >> +st8 [r17]=r18,16/* save ar.rsc value for "loadrs" */ +;; >> +.mem.offset 0,0; st8.spill [r16]=r20,16/* save original r1 */ >> +.mem.offset 8,0; st8.spill [r17]=r12,16 >> +adds r12=-16,r1 >> +/* switch to kernel memory stack (with 16 bytes of scratch) */ >> +;; +.mem.offset 0,0; st8.spill [r16]=r13,16 >> +.mem.offset 8,0; st8.spill [r17]=r8,16 /* save ar.fpsr */ +;; >> +.mem.offset 0,0; st8.spill [r16]=r15,16 >> +.mem.offset 8,0; st8.spill [r17]=r14,16 >> +dep r14=-1,r0,60,4 >> +;; >> +.mem.offset 0,0; st8.spill [r16]=r2,16 >> +.mem.offset 8,0; st8.spill [r17]=r3,16 >> +adds r2=VMM_PT_REGS_R16_OFFSET,r1 >> +adds r14 = VMM_VCPU_GP_OFFSET,r13 >> +;; >> +mov r8=ar.ccv >> +ld8 r14 = [r14] >> +;; >> +mov r1=r14 /* establish kernel global pointer */ >> +;; \ >> +bsw.1 >> +;; >> +alloc r14=ar.pfs,0,0,1,0// must be first in an insn group + >> mov out0=r13 +;; >> +ssm psr.ic >> +;; >> +srlz.i >> +;; >> +//(p15) ssm psr.i > Why do you comments out some ssm psr.i? >> +adds r3=8,r2// set up second base pointer for >> SAVE_REST >> +srlz.i // ensure everybody knows psr.ic is back >> on > Hmm, if the above ssm is not necessary, this srlz.i is also necessary. Currently, we didn't enable psr.i in GVMM, since all external interrupts should back to host. But for next step, we want to add the psr.i = 1 support in GVMM. The final decision should be based on performance evaluation, and to see whether it has impact on the performance of host and guest side. Now I want to keep it there as a tag. Xiantao - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
> That'll depend on what kind of device is emulated. Does the SCSI > emulation handle multiple in-flight commands with any guarantee on > order? SCSI definitely allows (and we emulate) multiple in flight commands. I can't find any requirement that writes must complete before a subsequent SYNCHRONISE_CACHE. However I don't claim to know the spec that well, and it's probably not a bad idea have them complete anyway. Preferably this would be a completely asynchronous operation. i.e. the sync command returns immediately, but only completes when all preceding writes have completed and been flushed to disk. Paul - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
Marcelo Tosatti wrote:
> static void raw_flush(BlockDriverState *bs)
> {
> BDRVRawState *s = bs->opaque;
> -fsync(s->fd);
> +raw_aio_flush(bs);
> +
> +/* We rely on the fact that no other AIO will be submitted
> + * in parallel, but this should be fixed by per-device
> + * AIO queues when allowing multiple CPU's to process IO
> + * in QEMU.
> + */
> +qemu_aio_flush();
> }
It depends what raw_flush() is used for.
If you want to be sure this flushes AIO writes in-flight at the time
of the call, I still reckon you need an extra qemu_aio_flush() before
raw_aio_flush() - on at least some POSIX AIO implementations. (I'd be
very interested to find out otherwise, if you know better).
But if, as Ian Jackson suggests, raw_flush() is _only_ used when the
guest driver issues a CACHE FLUSH command _and_ the guest driver
either cannot overlap operations, or cannot depend on overlapping
operations occuring in order, then you don't need it.
That'll depend on what kind of device is emulated. Does the SCSI
emulation handle multiple in-flight commands with any guarantee on
order? To be on the safe side, I'd include the extra qemu_aio_flush,
as I expect it's very unlikely to harm performance and might save
someone's data.
-- Jamie
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
Marcelo Tosatti wrote: > I don't think the first qemu_aio_flush() is necessary because the fsync > request will be enqueued after pending ones: > >aio_fsync() function does a sync on all outstanding >asynchronous I/O operations associated with >aiocbp->aio_fildes. > >More precisely, if op is O_SYNC, then all currently queued >I/O operations shall be completed as if by a call of >fsync(2), and if op is O_DSYNC, this call is the asynchronous >analog of fdatasync(2). Note that this is a request only — >this call does not wait for I/O completion. > > glibc sets the priority for fsync as 0, which is the same priority AIO > reads and writes are submitted by QEMU. Do AIO operations always get executed in the order they are submitted? I was under the impression this is not guaranteed, as relaxed ordering permits better I/O scheduling (e.g. to reduce disk seeks) - which is one of the most useful points of AIO. (Otherwise you might as well just have one worker thread doing synchronous IO in order). And because of that, I was under the impression the only way to implement a write barrier+flush in AIO was (1) wait for pending writes to complete, then (2) aio_fsync, then (3) wait for the aio_fsync. I could be wrong, but I haven't seen any documentation which says otherwise, and it's what I'd expect of an implementation. I.e. it's just an asynchronous version of fsync(). The quoted man page doesn't convince me. It says "all currently queued I/O operations shall be completed" which _could_ mean that aio_fsync is an AIO barrier too. But then "if by a call of fsync(2)" implies that aio_fsync+aio_suspend could just be replaced by fsync() with no change of semantics. So "queued I/O operations" means what fsync() handles: dirty file data, not in-flight AIO writes. And you already noticed that fsync() is _not_ guaranteed to flush in-flight AIO writes. Being the asynchronous analog, aio_fsync() would not either. -- Jamie - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] idle load
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi,
Guests seem to be doing a lot of timer related polling, is there any way
to reduce that (which would reduce load on the host):
select(0, [], NULL, NULL, {0, 0}) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {1046993, 598906624}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 598955741}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 599002421}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 599048737}) = 0
timer_gettime(0x2, {it_interval={0, 0}, it_value={0, 0}}) = 0
timer_settime(0x2, 0, {it_interval={0, 0}, it_value={0, 1100}},
NULL) = 0
select(4, [0 3], [], [], {0, 0})= 0 (Timeout)
select(0, [], NULL, NULL, {0, 0}) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {1046993, 599305034}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 599352080}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 599442433}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 599490141}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 599536708}) = 0
timer_gettime(0x2, {it_interval={0, 0}, it_value={0, 10572102}}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 599650500}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 599697967}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 599744129}) = 0
timer_gettime(0x2, {it_interval={0, 0}, it_value={0, 10364877}}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 599850495}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 599898120}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 599944263}) = 0
timer_gettime(0x2, {it_interval={0, 0}, it_value={0, 10164841}}) = 0
timer_settime(0x2, 0, {it_interval={0, 0}, it_value={0, 558000}}, NULL) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 600340673}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 600389516}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 600436196}) = 0
timer_gettime(0x2, {it_interval={0, 0}, it_value={0, 126861}}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 600542537}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 600590172}) = 0
- --- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 600727594}) = 0
timer_gettime(0x2, {it_interval={0, 0}, it_value={0, 0}}) = 0
timer_settime(0x2, 0, {it_interval={0, 0}, it_value={0, 1000}},
NULL) = 0
select(4, [0 3], [], [], {0, 0})= 0 (Timeout)
select(0, [], NULL, NULL, {0, 0}) = 0 (Timeout)
clock_gettime(CLOCK_MONOTONIC, {1046993, 600978104}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 601024560}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 601070676}) = 0
clock_gettime(CLOCK_MONOTONIC, {1046993, 601117316}) = 0
timer_gettime(0x2, {it_interval={0, 0}, it_value={0, 9665212}}) = 0
timer_settime(0x2, 0, {it_interval={0, 0}, it_value={0, 900}}, NULL) = 0
select(4, [0 3], [], [], {0, 1})= 0 (Timeout)
select(0, [], NULL, NULL, {0, 0}) = 0 (Timeout)
Cheers
Antoine
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREKAAYFAkftgjgACgkQGK2zHPGK1rt2XwCeJa8Z2dt/D8jxQCpTeRZRXfOU
fqEAn25oLryZoMbZxli2RepgoC9pSK9M
=5StJ
-END PGP SIGNATURE-
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] virtio-net working on PowerPC KVM
I'm pleased to report that we now have working network support in the guest, via the virtio-net driver. In fact, we can use NFS for the guest's root filesystem. :) Boot log attached. The bad news is that it's very slow, but the good news is that it's nice to be improving performance rather than debugging mysterious crashes... ;) With this milestone reached, in the near future I intend to start sending patches to Avi and linuxppc-dev for review, hopefully for inclusion in 2.6.26. However, I do want to see if we can improve the performance a little bit first... -- Hollis Blanchard IBM Linux Technology Center bash-3.00# ./qemu-system-ppcemb -M bamboo -nographic -kernel ../../uImage.bamboo -L ../pc-bios/ -append "ip=dhcp nfsroot=9.XX.XX.XX:/netroot/ppc_4xx root=/dev/nfs rw debug" -net nic,model=virtio -net tap bamboo_init: START Ram size passed is: 144 MB Calling function ppc440_init setup mmio setup universal controller trying to setup sdram controller sdram_unmap_bcr: Unmap RAM area 0040 sdram_unmap_bcr: Unmap RAM area 0040 sdram_set_bcr: Map RAM area 0800 sdram_set_bcr: Map RAM area 0100 Initializing first serial port ppc405_serial_init: offset 0300 Done calling ppc440_init bamboo_init: load kernel kernel is at guest address: 0x0 bamboo_init: load device tree file device tree address is at guest address: 0x2b2100 bamboo_init: loading kvm registers bamboo_init: DONE Using Bamboo machine description Linux version 2.6.25-rc3-hg1858cec8eb87-dirty ([EMAIL PROTECTED]) (gcc version 3.4.2) #150 Wed Mar 19 12:51:20 CDT 2008 Found legacy serial port 0 for /plb/opb/[EMAIL PROTECTED] mem=ef600300, taddr=ef600300, irq=0, clk=11059200, speed=115200 Found legacy serial port 1 for /plb/opb/[EMAIL PROTECTED] mem=ef600400, taddr=ef600400, irq=0, clk=11059200, speed=0 console [udbg0] enabled Entering add_active_range(0, 0, 36864) 0 entries of 256 used setup_arch: bootmem arch: exit Top of RAM: 0x900, Total RAM: 0x900 Memory hole size: 0MB Zone PFN ranges: DMA 0 ->36864 Normal 36864 ->36864 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 ->36864 On node 0 totalpages: 36864 DMA zone: 288 pages used for memmap DMA zone: 0 pages reserved DMA zone: 36576 pages, LIFO batch:7 Normal zone: 0 pages used for memmap Movable zone: 0 pages used for memmap Built 1 zonelists in Zone order, mobility grouping on. Total pages: 36576 Kernel command line: ip=dhcp nfsroot=9.XX.XX.XX:/netroot/ppc_4xx root=/dev/nfs rw debug irq: Allocated host of type 2 @0xc03f3900 UIC0 (32 IRQ sources) at DCR 0xc0 irq: Default host set to @0xc03f3900 PID hash table entries: 1024 (order: 10, 4096 bytes) time_init: decrementer frequency = 666.60 MHz time_init: processor frequency = 666.60 MHz clocksource: timebase mult[60] shift[22] registered clockevent: decrementer mult[] shift[16] cpu[0] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 143060k/147456k available (2632k kernel code, 4252k reserved, 100k data, 125k bss, 132k init) SLUB: Genslabs=10, HWalign=32, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 Calibrating delay loop... 2490.36 BogoMIPS (lpj=4980736) Mount-cache hash table entries: 512 net_namespace: 156 bytes NET: Registered protocol family 16 PCI host bridge /plb/[EMAIL PROTECTED] (primary) ranges: MEM 0xa000..0xbfff -> 0xa000 IO 0xe800..0xe800 -> 0x 4xx PCI DMA offset set to 0x PCI: Probing PCI hardware PCI: Hiding 4xx host bridge resources :00:00.0 irq: irq_create_mapping(0xc03f3900, 0x1c) irq: -> using host @c03f3900 irq: -> obtained virq 28 Time: timebase clocksource has been installed. NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered irq: irq_create_mapping(0xc03f3900, 0x0) irq: -> using host @c03f3900 irq: -> obtained virq 16 irq: irq_create_mapping(0xc03f3900, 0x1) irq: -> using host @c03f3900 irq: -> obtained virq 17 io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250.0: ttyS0 at MMIO 0xef600300 (irq = 16) is a 16450 console handover: boot [udbg0] -> real [ttyS0] irq: irq_create_mapping(0xc03f3900, 0x0) irq: -> using host @c03f3900 irq: -> existing mapping on virq 16 ef600300.serial: ttyS0 at MMIO 0xef600300 (irq = 16) is a 16450 irq: irq_create_mapping(0xc03f3900, 0x1) irq: -> using host @c03f3900 irq: -> existing mapping on virq 17 b
Re: [kvm-devel] [ANNOUNCE] kvm-guest-drivers-windows-1
Avi Kivity wrote: > No plans at this point. SCSI emulation should provide decent performance. Are there plans for addressing QEMU's issues w/ the SCSI emulation for Windows guests? https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1895893&group_id=180599 [posting this in part as a warning, lest others go through the process of setting Windows up on a guest using SCSI and end up needing to throw out the install -- XP doesn't seem to take well to its SCSI drive becoming IDE without a reinstall]. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] [mq]: add_kvm_guest_wait_handlers
# HG changeset patch # User Jerone Young <[EMAIL PROTECTED]> # Date 1206732207 18000 # Node ID 82daf2163e7a8eb26b446550937e517be86c297c # Parent e48cf2ad6c85c457ff64c04b83960fc305420842 [mq]: add_kvm_guest_wait_handlers - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
On Fri, Mar 28, 2008 at 03:01:13PM +0100, Andrea Arcangeli wrote:
> @@ -271,8 +292,12 @@ int __kvm_set_memory_region(struct kvm *kvm,
>
> r = -EINVAL;
> /* General sanity checks */
> + if (mem->userspace_addr & (PAGE_SIZE - 1))
> + goto out;
> if (mem->memory_size & (PAGE_SIZE - 1))
> goto out;
> + if (mem->userspace_addr + mem->memory_size < mem->userspace_addr)
> + goto out;
Those above (I suppose they're needed even if not strictly related to
the VM_LOCKED) broke vmx (only my laptop is vmx so I noticed it after
submission sorry!, the testing I did on svm test system before
submission worked fine and kvm was oom killed w/o swapping as
expected). I figured out the above likely broke older userland for the
same reason it broke vmx, so a new patch follows that should works for
vmx and should allow older userspace to still work and in VM_LOCKED
safe mode.
I'll try to make a new mmu notifier patch soon that will allow munmap
on a guest live gphys address space for the first time so ballooning
will be safe. Swapping is already safe and allowed with the current
kvm-swapping patch using the mmu notifiers, thanks to the mmu_lock
taken by invalidate_page that serializes the VM against
"spin_lock(mmu_lock); rmap_remove; tlbflush; spin_unlock(mmu_lock)".
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 30bf832..8ece406 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -250,6 +250,24 @@ static int kvm_vm_release(struct inode *inode, struct file
*filp)
return 0;
}
+#ifndef CONFIG_MMU_NOTIFIER
+static void memslot_mlock(unsigned long start, unsigned long len)
+{
+ struct vm_area_struct * vma;
+ unsigned long end = start+len;
+
+ vma = find_vma(current->mm, start);
+ if (!vma || vma->vm_start > start)
+ return;
+
+ /* go simple and don't split vmas */
+ for (;vma && vma->vm_start < end; vma = vma->vm_next) {
+ vma->vm_flags |= VM_LOCKED;
+ start = vma->vm_end;
+ }
+}
+#endif
+
/*
* Allocate some memory and give it an address in the guest physical address
* space.
@@ -273,6 +291,10 @@ int __kvm_set_memory_region(struct kvm *kvm,
/* General sanity checks */
if (mem->memory_size & (PAGE_SIZE - 1))
goto out;
+ if (user_alloc &&
+ ((mem->userspace_addr & (PAGE_SIZE - 1)) ||
+(mem->userspace_addr + mem->memory_size < mem->userspace_addr)))
+ goto out;
if (mem->guest_phys_addr & (PAGE_SIZE - 1))
goto out;
if (mem->slot >= KVM_MEMORY_SLOTS + KVM_PRIVATE_MEM_SLOTS)
@@ -366,6 +388,10 @@ int __kvm_set_memory_region(struct kvm *kvm,
goto out_free;
}
+#ifndef CONFIG_MMU_NOTIFIER
+ memslot_mlock(mem->userspace_addr, mem->memory_size);
+#endif
+
kvm_free_physmem_slot(&old, &new);
return 0;
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] regression breaks lowmem reserved RAM
This is crashing at boot my lowmem reserved RAM patch. This is causing GFP_DMA allocations at boot for no good reason. It crashes in my case because there's no ram below 16M available to linux. Are you sure this is needed at all, for sure if there's any bug this isn't the right fix. Please reverse, thanks! changeset: 87150:1f7afb388483 user:Yang Shi <[EMAIL PROTECTED]> date:Tue Mar 04 11:20:51 2008 +0100 summary: Fix DMA access of block device in 64-bit kernel on some non-x86 systems with 4GB or upper 4GB memory diff --git a/block/blk-settings.c b/block/blk-settings.c --- a/block/blk-settings.c +++ b/block/blk-settings.c @@ -140,7 +140,7 @@ void blk_queue_bounce_limit(struct reque /* Assume anything <= 4GB can be handled by IOMMU. Actually some IOMMUs can handle everything, but I don't know of a way to test this here. */ - if (b_pfn < (min_t(u64, 0x, BLK_BOUNCE_HIGH) >> PAGE_SHIFT)) + if (b_pfn <= (min_t(u64, 0x, BLK_BOUNCE_HIGH) >> PAGE_SHIFT)) dma = 1; q->bounce_pfn = max_low_pfn; #else - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
On Fri, Mar 28, 2008 at 06:03:25PM +, Jamie Lokier wrote:
> Marcelo Tosatti wrote:
> > On Fri, Mar 28, 2008 at 03:07:03PM +, Jamie Lokier wrote:
> > > Marcelo Tosatti wrote:
> > > > Its necessary to guarantee that pending AIO writes have reached stable
> > > > storage when the flush request returns.
> > > >
> > > > Also change fsync() to fdatasync(), since the modification time is not
> > > > critical data.
> > > > +if (aio_fsync(O_DSYNC, &acb->aiocb) < 0) {
> > >
> > > > BDRVRawState *s = bs->opaque;
> > > > -fsync(s->fd);
> > > > +raw_aio_flush(bs);
> > > > +fdatasync(s->fd);
> > > > +
> > > > +/* We rely on the fact that no other AIO will be submitted
> > > > + * in parallel, but this should be fixed by per-device
> > > > + * AIO queues when allowing multiple CPU's to process IO
> > > > + * in QEMU.
> > > > + */
> > > > +qemu_aio_flush();
> > >
> > > I'm a bit confused by this. Why do you need aio_fsync(O_DSYNC) _and_
> > > synchronous fdatasync() calls? Aren't they equivalent?
> >
> > fdatasync() will write and wait for completion of dirty file data
> > present in memory.
> >
> > aio_write() only queues data for submission:
> >
> >The "asynchronous" means that this call returns as soon as the
> > request
> >has been enqueued; the write may or may not have completed when
> > the
> >call returns. One tests for completion using aio_error(3).
> >
>
> > So fdatasync() is not enough because data written via AIO may not
> > have been reflected as "dirty file data" through write() by the time
> > raw_flush() is called.
>
> Sure. But why isn't the aio_fsync(O_DSYNC) enough by itself?
It is enough, fdatasync() becomes redundant.
> It seems to me you should have something like this:
>
> /* Flush pending aio_writes until they are dirty data,
>and wait before the aio_fsync. */
> qemu_aio_flush();
>
> /* Call aio_fsync(O_DSYNC). */
> raw_aio_flush(bs);
>
> /* Wait for the aio_fsync to complete. */
> qemu_aio_flush();
>
> What am I missing?
I don't think the first qemu_aio_flush() is necessary because the fsync
request will be enqueued after pending ones:
aio_fsync() function does a sync on all outstanding asynchronous
I/O operations associated with aiocbp->aio_fildes.
More precisely, if op is O_SYNC, then all currently queued I/O opera-
tions shall be completed as if by a call of fsync(2), and if op is
O_DSYNC, this call is the asynchronous analog of fdatasync(2). Note
that this is a request only — this call does not wait for I/O comple-
tion.
glibc sets the priority for fsync as 0, which is the same priority AIO
reads and writes are submitted by QEMU.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
On Fri, Mar 28, 2008 at 05:00:39PM +, Paul Brook wrote:
> > > Surely you should be using the normal aio notification to wait for the
> > > aio_fsync to complete before reporting success to the device.
> >
> > qemu_aio_flush() will wait for all pending AIO requests (including
> > aio_fsync) to complete.
>
> Then why do you need to separate fdatasync?
Oh, I see what Jamie means now: fdatasync() is redundant with
aio_fsync(O_DSYNC).
How's this?
Index: kvm-userspace.io/qemu/block-raw-posix.c
===
--- kvm-userspace.io.orig/qemu/block-raw-posix.c
+++ kvm-userspace.io/qemu/block-raw-posix.c
@@ -557,10 +557,39 @@ static int raw_create(const char *filena
return 0;
}
+static void raw_aio_flush_complete(void *opaque, int ret)
+{
+if (ret)
+printf("WARNING: aio_fsync failed (completion)\n");
+}
+
+static void raw_aio_flush(BlockDriverState *bs)
+{
+RawAIOCB *acb;
+
+acb = raw_aio_setup(bs, 0, NULL, 0, raw_aio_flush_complete, NULL);
+if (!acb)
+return;
+
+if (aio_fsync(O_DSYNC, &acb->aiocb) < 0) {
+qemu_aio_release(acb);
+perror("aio_fsync");
+printf("WARNING: aio_fsync failed\n");
+return;
+}
+}
+
static void raw_flush(BlockDriverState *bs)
{
BDRVRawState *s = bs->opaque;
-fsync(s->fd);
+raw_aio_flush(bs);
+
+/* We rely on the fact that no other AIO will be submitted
+ * in parallel, but this should be fixed by per-device
+ * AIO queues when allowing multiple CPU's to process IO
+ * in QEMU.
+ */
+qemu_aio_flush();
}
BlockDriver bdrv_raw = {
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
Marcelo Tosatti wrote:
> On Fri, Mar 28, 2008 at 03:07:03PM +, Jamie Lokier wrote:
> > Marcelo Tosatti wrote:
> > > Its necessary to guarantee that pending AIO writes have reached stable
> > > storage when the flush request returns.
> > >
> > > Also change fsync() to fdatasync(), since the modification time is not
> > > critical data.
> > > +if (aio_fsync(O_DSYNC, &acb->aiocb) < 0) {
> >
> > > BDRVRawState *s = bs->opaque;
> > > -fsync(s->fd);
> > > +raw_aio_flush(bs);
> > > +fdatasync(s->fd);
> > > +
> > > +/* We rely on the fact that no other AIO will be submitted
> > > + * in parallel, but this should be fixed by per-device
> > > + * AIO queues when allowing multiple CPU's to process IO
> > > + * in QEMU.
> > > + */
> > > +qemu_aio_flush();
> >
> > I'm a bit confused by this. Why do you need aio_fsync(O_DSYNC) _and_
> > synchronous fdatasync() calls? Aren't they equivalent?
>
> fdatasync() will write and wait for completion of dirty file data
> present in memory.
>
> aio_write() only queues data for submission:
>
>The "asynchronous" means that this call returns as soon as the request
>has been enqueued; the write may or may not have completed when the
>call returns. One tests for completion using aio_error(3).
>
> So fdatasync() is not enough because data written via AIO may not
> have been reflected as "dirty file data" through write() by the time
> raw_flush() is called.
Sure. But why isn't the aio_fsync(O_DSYNC) enough by itself?
It seems to me you should have something like this:
/* Flush pending aio_writes until they are dirty data,
and wait before the aio_fsync. */
qemu_aio_flush();
/* Call aio_fsync(O_DSYNC). */
raw_aio_flush(bs);
/* Wait for the aio_fsync to complete. */
qemu_aio_flush();
What am I missing?
-- Jamie
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
Marcelo Tosatti writes ("[Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush
request "):
> Its necessary to guarantee that pending AIO writes have reached stable
> storage when the flush request returns.
Surely it isn't necessary to call qemu_aio_flush ? Because those
pending AIO writes have not yet been returned to the guest as
complete, the guest is not entitled to assume that a FLUSH CACHE
command (issued before those writes have completed) completing
successfully means that those interleaved writes have reached stable
storage.
Also, this patch does a synchronous flush (which is bad because it
stalls the guest while the flush takes place) and it ignores any error
return (which is quite bad - see my other messages about bdrv_flush,
caches, etc.)
So I think it would be better to apply
- my bdrv_flush patch from February which I've reposted today
and then
- the asynchronous FLUSH CACHE patch which I've posted today
I think we concluded last time that the change of fsync to fdatasync
is correct but I think we should wait for the dust to settle before
introducing another change on top of all this ...
Ian.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
> > Surely you should be using the normal aio notification to wait for the > > aio_fsync to complete before reporting success to the device. > > qemu_aio_flush() will wait for all pending AIO requests (including > aio_fsync) to complete. Then why do you need to separate fdatasync? Paul - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
On Fri, Mar 28, 2008 at 04:40:54PM +, Paul Brook wrote:
> On Friday 28 March 2008, Marcelo Tosatti wrote:
> > On Fri, Mar 28, 2008 at 03:07:03PM +, Jamie Lokier wrote:
> > > Marcelo Tosatti wrote:
> > > > Its necessary to guarantee that pending AIO writes have reached stable
> > > > storage when the flush request returns.
> > > >
> > > > Also change fsync() to fdatasync(), since the modification time is not
> > > > critical data.
> > > > +if (aio_fsync(O_DSYNC, &acb->aiocb) < 0) {
> > > >
> > > > BDRVRawState *s = bs->opaque;
> > > > -fsync(s->fd);
> > > > +raw_aio_flush(bs);
> > > > +fdatasync(s->fd);
> > > > +
> > > > +/* We rely on the fact that no other AIO will be submitted
> > > > + * in parallel, but this should be fixed by per-device
> > > > + * AIO queues when allowing multiple CPU's to process IO
> > > > + * in QEMU.
> > > > + */
> > > > +qemu_aio_flush();
> > >
> > > I'm a bit confused by this. Why do you need aio_fsync(O_DSYNC) _and_
> > > synchronous fdatasync() calls? Aren't they equivalent?
> >
> > fdatasync() will write and wait for completion of dirty file data
> > present in memory.
> >
> > aio_write() only queues data for submission:
> >
> >The "asynchronous" means that this call returns as soon as the
> > request has been enqueued; the write may or may not have completed when
> > the call returns. One tests for completion using aio_error(3).
>
> Surely you should be using the normal aio notification to wait for the
> aio_fsync to complete before reporting success to the device.
qemu_aio_flush() will wait for all pending AIO requests (including
aio_fsync) to complete.
Or do you mean something else?
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Sicoob Executivo - Seguro Mulher
Title: Sicoob Executivo Caso não consiga visualizar esta mensagem corretamente, clique aqui. Caso você não queira receber mais informações de nossa Cooperativa, responda está mensagem solicitando a exclusão de seu e-mail - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
On Friday 28 March 2008, Marcelo Tosatti wrote:
> On Fri, Mar 28, 2008 at 03:07:03PM +, Jamie Lokier wrote:
> > Marcelo Tosatti wrote:
> > > Its necessary to guarantee that pending AIO writes have reached stable
> > > storage when the flush request returns.
> > >
> > > Also change fsync() to fdatasync(), since the modification time is not
> > > critical data.
> > > +if (aio_fsync(O_DSYNC, &acb->aiocb) < 0) {
> > >
> > > BDRVRawState *s = bs->opaque;
> > > -fsync(s->fd);
> > > +raw_aio_flush(bs);
> > > +fdatasync(s->fd);
> > > +
> > > +/* We rely on the fact that no other AIO will be submitted
> > > + * in parallel, but this should be fixed by per-device
> > > + * AIO queues when allowing multiple CPU's to process IO
> > > + * in QEMU.
> > > + */
> > > +qemu_aio_flush();
> >
> > I'm a bit confused by this. Why do you need aio_fsync(O_DSYNC) _and_
> > synchronous fdatasync() calls? Aren't they equivalent?
>
> fdatasync() will write and wait for completion of dirty file data
> present in memory.
>
> aio_write() only queues data for submission:
>
>The "asynchronous" means that this call returns as soon as the
> request has been enqueued; the write may or may not have completed when
> the call returns. One tests for completion using aio_error(3).
Surely you should be using the normal aio notification to wait for the
aio_fsync to complete before reporting success to the device.
Paul
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
On Fri, Mar 28, 2008 at 03:07:03PM +, Jamie Lokier wrote:
> Marcelo Tosatti wrote:
> > Its necessary to guarantee that pending AIO writes have reached stable
> > storage when the flush request returns.
> >
> > Also change fsync() to fdatasync(), since the modification time is not
> > critical data.
> > +if (aio_fsync(O_DSYNC, &acb->aiocb) < 0) {
>
> > BDRVRawState *s = bs->opaque;
> > -fsync(s->fd);
> > +raw_aio_flush(bs);
> > +fdatasync(s->fd);
> > +
> > +/* We rely on the fact that no other AIO will be submitted
> > + * in parallel, but this should be fixed by per-device
> > + * AIO queues when allowing multiple CPU's to process IO
> > + * in QEMU.
> > + */
> > +qemu_aio_flush();
>
> I'm a bit confused by this. Why do you need aio_fsync(O_DSYNC) _and_
> synchronous fdatasync() calls? Aren't they equivalent?
fdatasync() will write and wait for completion of dirty file data
present in memory.
aio_write() only queues data for submission:
The "asynchronous" means that this call returns as soon as the request
has been enqueued; the write may or may not have completed when the
call returns. One tests for completion using aio_error(3).
So fdatasync() is not enough because data written via AIO may not
have been reflected as "dirty file data" through write() by the time
raw_flush() is called.
The SCSI and IDE drivers use flush() in response to a "flush cache"
request, which is used by the guest OS to implement barriers, for
example.
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH] QEMU: fsync AIO writes on flush request
Marcelo Tosatti wrote:
> Its necessary to guarantee that pending AIO writes have reached stable
> storage when the flush request returns.
>
> Also change fsync() to fdatasync(), since the modification time is not
> critical data.
> +if (aio_fsync(O_DSYNC, &acb->aiocb) < 0) {
> BDRVRawState *s = bs->opaque;
> -fsync(s->fd);
> +raw_aio_flush(bs);
> +fdatasync(s->fd);
> +
> +/* We rely on the fact that no other AIO will be submitted
> + * in parallel, but this should be fixed by per-device
> + * AIO queues when allowing multiple CPU's to process IO
> + * in QEMU.
> + */
> +qemu_aio_flush();
I'm a bit confused by this. Why do you need aio_fsync(O_DSYNC) _and_
synchronous fdatasync() calls? Aren't they equivalent?
-- Jamie
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] QEMU: fsync AIO writes on flush request
Its necessary to guarantee that pending AIO writes have reached stable
storage when the flush request returns.
Also change fsync() to fdatasync(), since the modification time is not
critical data.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm-userspace.io/qemu/block-raw-posix.c
===
--- kvm-userspace.io.orig/qemu/block-raw-posix.c
+++ kvm-userspace.io/qemu/block-raw-posix.c
@@ -557,10 +557,40 @@ static int raw_create(const char *filena
return 0;
}
+static void raw_aio_flush_complete(void *opaque, int ret)
+{
+if (ret)
+printf("WARNING: aio_fsync failed (completion)\n");
+}
+
+static void raw_aio_flush(BlockDriverState *bs)
+{
+RawAIOCB *acb;
+
+acb = raw_aio_setup(bs, 0, NULL, 0, raw_aio_flush_complete, NULL);
+if (!acb)
+return;
+
+if (aio_fsync(O_DSYNC, &acb->aiocb) < 0) {
+qemu_aio_release(acb);
+perror("aio_fsync");
+printf("WARNING: aio_fsync failed\n");
+return;
+}
+}
+
static void raw_flush(BlockDriverState *bs)
{
BDRVRawState *s = bs->opaque;
-fsync(s->fd);
+raw_aio_flush(bs);
+fdatasync(s->fd);
+
+/* We rely on the fact that no other AIO will be submitted
+ * in parallel, but this should be fixed by per-device
+ * AIO queues when allowing multiple CPU's to process IO
+ * in QEMU.
+ */
+qemu_aio_flush();
}
BlockDriver bdrv_raw = {
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] We can offer any medical products you need
The best shop Today you can buy medical goods sitting at home *Most popular medications *Great choice *The cheapest cost you have ever seen http://www.lakerub.com - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [17/17][PATCH] kvm/ia64: How to boot up guests on kvm/ia64
Hi, I found 3 typos. >+3. Get Guest Firmware named as Flash.fd, and put it under right place: >+ (1) If you have the guest firmware (binary)released by Intel >Corp for Xen, you can use it directly. >+ (2) If you want to build a guest firmware form souce code. souce ---> source >+5. Known possbile issue on some platforms with old Firmware >+ possbile ---> possible >+(2): Applying the below patch to kernel source. >+diff --git a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S >+index 0b53344..f02b0f7 100644 >+--- a/arch/ia64/kernel/pal.S > b/arch/ia64/kernel/pal.S >+@@ -84,7 +84,8 @@ GLOBAL_ENTRY(ia64_pal_call_static) >+ mov ar.pfs = loc1 >+ mov rp = loc0 >+ ;; >+- srlz.d // seralize restoration of psr.l >++ srlz.i // seralize restoration of psr.l seralize ---> serialize Best Regards, Akio Takebe - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [12/17][PATCH] kvm/ia64: add optimization for some virtulization faults
Hi, >>From 2dbf7c93ff5e36a221761c690ff12e7be48a6bb2 Mon Sep 17 00:00:00 2001 >From: Xiantao Zhang <[EMAIL PROTECTED]> >Date: Wed, 12 Mar 2008 13:49:38 +0800 >Subject: [PATCH] kvm/ia64: add optimization for some virtulization >faults > >optvfault.S adds optimization for some performance-critical >virtualization >faults. >Signed-off-by: Anthony Xu <[EMAIL PROTECTED]> >Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]> It looks good. Best Regards, Akio Takebe - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] kvm-63: Windows Server 2003 randomly hangs with 100% CPU
Hello list, I encountered two Windows Server 2003 Std SP1 guests which would randomly hang with 100% CPU after several hours of normal operation. The guest would not respond at all, not even to ping requests. Its process on the host uses 100% CPU. The Host: Dual-Core AMD Opteron(tm) Processor 2212 10GB DDRII RAM Linux 2.6.24.3 KVM-63 userspace Other KVM guests (Linux and Windows Vista) are rock-solid The two problematic guests: Imaged from VMWare ESX 2.5 with reinstall of the ACPI Uniprocessor HAL and drivers. Switching to the Standard PC HAL and using -no-acpi does not help. Tried with the new virtio NIC first and changed to ne2k_pci later but no effect. One guest uses a raw hard disk image the other qcow2. The guests are launched with this command-line: kvm -hda bonus-system.qcow2 -m 1024 -net nic,model=ne2k_pci,macaddr=52:54:00:74:A1:0C -net tap,ifname=vm-bonus -vnc 10.73.250.1:2 -k de -monitor tcp:10.73.250.1:5952,server,nowait -localtime Currently I'm testing with a fresh install of Win2003 STD SP1 to rule out the imaged-from-ESX factor. Also I'm running one of the machines with -no-kvm now and will report back how that works out. Any idea how to go about debugging this? Also I see interesting syslog entries. But they don't seem directly related to the hangs, as the times do not match. Mar 27 14:30:26 [EMAIL PROTECTED] kvm: 1363: cpu0 kvm_set_msr_common: MSR_IA32_MC0_STATUS 0x0, nop Mar 27 15:46:52 [EMAIL PROTECTED] Ignoring de-assert INIT to vcpu 0 Mar 27 17:20:45 [EMAIL PROTECTED] Ignoring de-assert INIT to vcpu 0 Mar 27 17:37:30 [EMAIL PROTECTED] apic write: bad size=1 fee00030 Mar 27 17:37:30 [EMAIL PROTECTED] Ignoring de-assert INIT to vcpu 0 Mar 27 17:42:19 [EMAIL PROTECTED] apic write: bad size=1 fee00030 Mar 27 17:42:19 [EMAIL PROTECTED] Ignoring de-assert INIT to vcpu 0 Mar 27 17:55:34 [EMAIL PROTECTED] apic write: bad size=1 fee00030 Mar 27 17:55:34 [EMAIL PROTECTED] Ignoring de-assert INIT to vcpu 0 Mar 27 20:13:14 [EMAIL PROTECTED] apic write: bad size=1 fee00030 Mar 27 20:13:14 [EMAIL PROTECTED] Ignoring de-assert INIT to vcpu 0 Cheers, FL - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [11/17][PATCH] kvm/ia64: add processor virtulization support.
Hi, Xiantao and Anthony
>+void getfpreg(unsigned long regnum, struct ia64_fpreg *fpval,
>+ struct kvm_pt_regs *regs)
>+{
>+ /* Take floating register rotation into consideration*/
>+ if (regnum >= IA64_FIRST_ROTATING_FR)
>+ regnum = IA64_FIRST_ROTATING_FR + fph_index(regs,
>regnum);
>+#define CASE_FIXED_FP(reg)\
>+ case (reg) : \
>+ ia64_stf_spill(fpval, reg); \
>+ break
>+
>+ switch (regnum) {
>+ CASE_FIXED_FP(0);
>+ CASE_FIXED_FP(1);
>+ CASE_FIXED_FP(2);
>+ CASE_FIXED_FP(3);
>+ CASE_FIXED_FP(4);
>+ CASE_FIXED_FP(5);
>+
>+ CASE_FIXED_FP(6);
>+ CASE_FIXED_FP(7);
>+ CASE_FIXED_FP(8);
>+ CASE_FIXED_FP(9);
>+ CASE_FIXED_FP(10);
>+ CASE_FIXED_FP(11);
>+
Is this correct ? Though I don't know why xen do so.
In the case of Xen, the above parts are;
#define CASE_SAVED_FP(reg) \
case reg: \
fpval->u.bits[0] = regs->f##reg.u.bits[0]; \
fpval->u.bits[1] = regs->f##reg.u.bits[1]; \
break
CASE_SAVED_FP(6);
CASE_SAVED_FP(7);
CASE_SAVED_FP(8);
CASE_SAVED_FP(9);
CASE_SAVED_FP(10);
CASE_SAVED_FP(11);
>+void setfpreg(unsigned long regnum, struct ia64_fpreg *fpval,
>+ struct kvm_pt_regs *regs)
>+{
>+ /* Take floating register rotation into consideration*/
>+ if (regnum >= IA64_FIRST_ROTATING_FR)
>+ regnum = IA64_FIRST_ROTATING_FR + fph_index(regs,
>regnum);
>+
>+#define CASE_FIXED_FP(reg)\
>+ case (reg) :\
>+ ia64_ldf_fill(reg, fpval); \
>+ break
>+
>+ switch (regnum) {
>+ CASE_FIXED_FP(2);
>+ CASE_FIXED_FP(3);
>+ CASE_FIXED_FP(4);
>+ CASE_FIXED_FP(5);
>+
>+ CASE_FIXED_FP(6);
>+ CASE_FIXED_FP(7);
>+ CASE_FIXED_FP(8);
>+ CASE_FIXED_FP(9);
>+ CASE_FIXED_FP(10);
>+ CASE_FIXED_FP(11);
>+
ditto.
#define CASE_RESTORED_FP(reg) \
case reg: \
regs->f##reg.u.bits[0] = fpval->u.bits[0]; \
regs->f##reg.u.bits[1] = fpval->u.bits[1] ; \
break
CASE_RESTORED_FP(6);
CASE_RESTORED_FP(7);
CASE_RESTORED_FP(8);
CASE_RESTORED_FP(9);
CASE_RESTORED_FP(10);
CASE_RESTORED_FP(11);
Best Regards,
Akio Takebe
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] KVM: MMU: Fix rmap_remove() race
I thought some more about this.
BTW, for completeness: normally (with exception of vm_destroy) the
put_page run by rmap_remove won't be the last one, but still the page
can go in the freelist a moment after put_page runs (leading to the
same problem). The VM is prevented to free the page while it's pinned,
but the VM can do the final free on the page before rmap_remove
returns. And w/o mmu notifiers there's no serialization that makes the
core VM stop on the mmu_lock to wait the tlb flush to run, before the
VM finally executes the last free of the page. mmu notifiers fixes
this race for regular swapping as the core VM will block on the
mmu_lock waiting the tlb flush (for this to work the tlb flush must
always happen inside the mmu_lock unless the order is exactly "spte =
nonpresent; tlbflush; put_page"). A VM_LOCKED on the vmas backing the
anonymous memory will fix this for regolar swapping too (I did
something like this in a patch at the end as a band-aid).
But thinking more the moment we pretend to allow anybody to randomly
__munmap__ any part of the guest physical address space like for
ballooning while the guest runs (think unprivileged user owning
/dev/kvm and running munmap at will), not even VM_LOCKED (ignored by
munmap) and not even the mmu notifiers, can prevent the page to be
queued in the kernel freelists immediately after rmap_remove returns,
this is because rmap_remove may run in a different host-cpu in between
unmap_vmas and invalidate_range_end.
Running the ioctl before munmap won't help to prevent the race as the
guest can still re-instantiate the sptes with page faults between the
ioctl and munmap.
However we've invalidate_range_begin. If we invalidate all sptes in
invalidate_range_begin and we hold off the page faults in between
_begin/_end, then we can fix this with the mmu notifiers.
So I think I can allow munmap safely (to unprivileged user too) by
using _range_begin somehow. For this to work any relevant tlb flush
must happen inside the _same_ mmu_lock critical section where
spte=nonpresent and rmap_remove run too (thanks to the mmu_lock the
ordering of those operations won't matter anymore, and no queue will
be needed).
---
Temporary band-aid to prevent the VM to do the final free on the page
immediately after put_page run inside rmap_remove, and before the tlb
flush (mmu_lock shall be released always after the tlb flush for
future appraoches to be safe). This still can't allow safe (safe as
guest not able to memory corrupt the host) munmap in the middle of the
guest physical memory. Only a combination of both _range_begin and
_range_end mmu notifier will allow that, unless rmap_remove callers
are all changed to do safe "spte=nonpresent; tlbflush; put_page"
ordering, then it'll always be safe, but it'll be slower as there will
be more tlb flushes than needed.
Signed-off-by: Andrea Arcangeli <[EMAIL PROTECTED]>
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index caa9f94..5343216 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3887,8 +3887,11 @@ int kvm_arch_set_memory_region(struct kvm *kvm,
memslot->userspace_addr = do_mmap(NULL, 0,
npages * PAGE_SIZE,
PROT_READ | PROT_WRITE,
-MAP_SHARED | MAP_ANONYMOUS,
-0);
+MAP_SHARED | MAP_ANONYMOUS
+#ifndef CONFIG_MMU_NOTIFIER
+|MAP_LOCKED
+#endif
+, 0);
up_write(¤t->mm->mmap_sem);
if (IS_ERR((void *)memslot->userspace_addr))
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 30bf832..ed65e29 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -250,6 +250,27 @@ static int kvm_vm_release(struct inode *inode, struct file
*filp)
return 0;
}
+#ifndef CONFIG_MMU_NOTIFIER
+static int memslot_mlock(unsigned long start, unsigned long len)
+{
+ struct vm_area_struct * vma;
+ unsigned long end = start+len;
+
+ vma = find_vma(current->mm, start);
+ if (!vma || vma->vm_start > start)
+ return -ENOMEM;
+
+ /* go simple and don't split vmas */
+ for (;vma && vma->vm_start < end; vma = vma->vm_next) {
+ vma->vm_flags |= VM_LOCKED;
+ start = vma->vm_end;
+ }
+ if (start < end)
+ return -ENOMEM;
+ return 0;
+}
+#endif
+
/*
* Allocate some memory and give it an address in the guest physical address
* space.
@@ -271,8 +292,12 @@ int __kvm_set_memory_region(struct kvm *kvm,
r = -EINVAL;
/* General sanity checks */
+ if (mem->userspace_addr & (PAGE_SIZE - 1))
+ goto out;
if (mem->memory_size & (PAGE_SIZE - 1))
Re: [kvm-devel] [Qemu-devel] [PATCH] ignore reads to the EOI register.
Aurelien Jarno wrote: > On Wed, Mar 26, 2008 at 09:57:16PM -0300, Glauber Costa wrote: >> They seem legal in real hardware, even though the EOI >> is a write-only register. By "legal" I mean they are completely >> ignored, but at least, don't cause any bits to be set at ESR. >> >> Without this patch, some (very recent) linux git trees will fail >> to boot in i386. >> >> This is generated from kvm-userspace, but should apply well to >> plain qemu too. >> >> Signed-off-by: Glauber Costa <[EMAIL PROTECTED]> >> --- >> qemu/hw/apic.c |2 ++ >> 1 files changed, 2 insertions(+), 0 deletions(-) >> >> diff --git a/qemu/hw/apic.c b/qemu/hw/apic.c >> index 92248dd..4102493 100644 >> --- a/qemu/hw/apic.c >> +++ b/qemu/hw/apic.c >> @@ -615,6 +615,8 @@ static uint32_t apic_mem_readl(void *opaque, >> target_phys_addr_t addr) >> /* ppr */ >> val = apic_get_ppr(s); >> break; >> +case 0x0b: >> +break; > > While I agree the guest should not care of the value (it should actually > not read it), wouldn't it be safer to return a default value (0 ?) > instead of an initialized value? > I don't think it would really make any difference, but is not opposed to this solution either. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [08/17][PATCH] kvm/ia64: Add interruption vector table for vmm.
Hi, Xiantao a comments is below. >+// 0x3000 Entry 12 (size 64 bundles) External Interrupt (4) >+ENTRY(kvm_interrupt) >+mov r31=pr// prepare to save predicates >+mov r19=12 >+mov r29=cr.ipsr >+;; >+tbit.z p6,p7=r29,IA64_PSR_VM_BIT >+tbit.z p0,p15=r29,IA64_PSR_I_BIT >+;; >+(p7) br.sptk kvm_dispatch_interrupt >+;; >+mov r27=ar.rsc/* M */ >+mov r20=r1/* A */ >+mov r25=ar.unat /* M */ >+mov r26=ar.pfs/* I */ >+mov r28=cr.iip/* M */ >+cover /* B (or nothing) */ >+;; >+mov r1=sp >+;; >+invala/* M */ >+mov r30=cr.ifs >+;; >+addl r1=-VMM_PT_REGS_SIZE,r1 >+;; >+adds r17=2*L1_CACHE_BYTES,r1 /* really: biggest cache-line >size */ >+adds r16=PT(CR_IPSR),r1 >+;; >+lfetch.fault.excl.nt1 [r17],L1_CACHE_BYTES >+st8 [r16]=r29 /* save cr.ipsr */ >+;; >+lfetch.fault.excl.nt1 [r17] >+mov r29=b0 >+;; >+adds r16=PT(R8),r1/* initialize first base pointer */ >+adds r17=PT(R9),r1/* initialize second base pointer */ >+mov r18=r0/* make sure r18 isn't NaT */ >+;; >+.mem.offset 0,0; st8.spill [r16]=r8,16 >+.mem.offset 8,0; st8.spill [r17]=r9,16 >+;; >+.mem.offset 0,0; st8.spill [r16]=r10,24 >+.mem.offset 8,0; st8.spill [r17]=r11,24 >+;; >+st8 [r16]=r28,16 /* save cr.iip */ >+st8 [r17]=r30,16 /* save cr.ifs */ >+mov r8=ar.fpsr/* M */ >+mov r9=ar.csd >+mov r10=ar.ssd >+movl r11=FPSR_DEFAULT /* L-unit */ >+;; >+st8 [r16]=r25,16 /* save ar.unat */ >+st8 [r17]=r26,16 /* save ar.pfs */ >+shl r18=r18,16/* compute ar.rsc to be used for >"loadrs" */ >+;; >+st8 [r16]=r27,16 /* save ar.rsc */ >+adds r17=16,r17 /* skip over ar_rnat field */ >+;; >+st8 [r17]=r31,16 /* save predicates */ >+adds r16=16,r16 /* skip over ar_bspstore field */ >+;; >+st8 [r16]=r29,16 /* save b0 */ >+st8 [r17]=r18,16 /* save ar.rsc value for "loadrs" */ >+;; >+.mem.offset 0,0; st8.spill [r16]=r20,16/* save original r1 */ >+.mem.offset 8,0; st8.spill [r17]=r12,16 >+adds r12=-16,r1 >+/* switch to kernel memory stack (with 16 bytes of scratch) */ >+;; >+.mem.offset 0,0; st8.spill [r16]=r13,16 >+.mem.offset 8,0; st8.spill [r17]=r8,16 /* save ar.fpsr */ >+;; >+.mem.offset 0,0; st8.spill [r16]=r15,16 >+.mem.offset 8,0; st8.spill [r17]=r14,16 >+dep r14=-1,r0,60,4 >+;; >+.mem.offset 0,0; st8.spill [r16]=r2,16 >+.mem.offset 8,0; st8.spill [r17]=r3,16 >+adds r2=VMM_PT_REGS_R16_OFFSET,r1 >+adds r14 = VMM_VCPU_GP_OFFSET,r13 >+;; >+mov r8=ar.ccv >+ld8 r14 = [r14] >+;; >+mov r1=r14 /* establish kernel global pointer */ >+;; \ >+bsw.1 >+;; >+alloc r14=ar.pfs,0,0,1,0 // must be first in an insn group >+mov out0=r13 >+;; >+ssm psr.ic >+;; >+srlz.i >+;; >+//(p15) ssm psr.i Why do you comments out some ssm psr.i? >+adds r3=8,r2 // set up second base pointer for >SAVE_REST >+srlz.i// ensure everybody knows psr.ic is back >on Hmm, if the above ssm is not necessary, this srlz.i is also necessary. Best Regards, Akio Takebe - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [14/17][PATCH] kvm/ia64: Add guest interruption injection support.
Hi, Xiantao
It's good, I have some small comments.
>+
>+/* SDM vol2 5.5 - IVA based interruption handling */
>+#define INITIAL_PSR_VALUE_AT_INTERRUPTION 0x001808028034
>+
Xen also use this value, you had better use macros of PSR bits.
Or you can add the same comments as Xen.
>+
>+/*
>+ * Handle floating-point assist faults and traps for domain.
>+ */
>+unsigned long vmm_handle_fpu_swa(int fp_fault, REGS *regs, unsigned
>long isr)
>+{
>+ struct kvm_vcpu *v = current_vcpu;
>+ IA64_BUNDLE bundle;
>+ unsigned long fault_ip;
>+ fpswa_ret_t ret;
>+
>+ fault_ip = regs->cr_iip;
>+ /*
>+ * When the FP trap occurs, the trapping instruction is
>completed.
>+ * If ipsr.ri == 0, there is the trapping instruction in
>previous
>+ * bundle.
>+ */
>+ if (!fp_fault && (ia64_psr(regs)->ri == 0))
>+ fault_ip -= 16;
>+
>+ if (fetch_code(v, fault_ip, &bundle))
>+ return -EAGAIN;
>+
>+ if (!bundle.i64[0] && !bundle.i64[1]) {
>+ return -EACCES;
>+ }
>+
>+ ret = vmm_fp_emulate(fp_fault, &bundle, ®s->cr_ipsr,
>®s->ar_fpsr,
>+ &isr, ®s->pr, ®s->cr_ifs, regs);
>+ return ret.status;
>+}
>+
>+void reflect_interruption(u64 ifa, u64 isr, u64 iim,
>+ u64 vec, REGS *regs)
>+{
>+ u64 vector;
>+ int status ;
>+ VCPU *vcpu = current_vcpu;
>+ u64 vpsr = VCPU(vcpu, vpsr);
>+
>+ vector = vec2off[vec];
>+
>+ if (!(vpsr & IA64_PSR_IC) && (vector !=
>IA64_DATA_NESTED_TLB_VECTOR)) {
>+ panic_vm(vcpu);
>+ return;
>+ }
>+
>+ switch (vec) {
>+ case 32:
I want to add a comment of IA64_FP_FAULT_VECTOR.
>+ status = vmm_handle_fpu_swa(1, regs, isr);
>+ if (!status) {
>+ vcpu_increment_iip(vcpu);
>+ return;
>+ } else if (-EAGAIN == status)
>+ return;
>+ break;
>+ case 33:
ditto, I want to add a comments of IA64_FP_TRAP_VECTOR.
>+ status = vmm_handle_fpu_swa(0, regs, isr);
>+ if (!status)
>+ return ;
>+ else if (-EAGAIN == status) {
>+ vcpu_decrement_iip(vcpu);
>+ return ;
>+ }
>+ break;
>+ }
>+
>+ VCPU(vcpu, isr) = isr;
>+ VCPU(vcpu, iipa) = regs->cr_iip;
>+ if (vector == IA64_BREAK_VECTOR || vector ==
>IA64_SPECULATION_VECTOR)
>+ VCPU(vcpu, iim) = iim;
>+ else {
>+ set_ifa_itir_iha(vcpu, ifa, 1, 1, 1);
>+ }
>+ inject_guest_interruption(vcpu, vector);
>+}
>+
>
Best Regards,
Akio Takebe
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] EFI BIOS and kvm
Thomas Mueller wrote: > hi there > > is the EFI BIOS (http://fabrice.bellard.free.fr/qemu/download.html -> > efi-bios.tar.bz2) supposed to work with kvm? I wan't to try installing > Mac OS X. > There is a guy called Alexander Graf that have succeeded this, see. http://alex.csgraf.de/self/?part/projects&folder/Qemu%20OSX&type/&project/projects¶meters/id=Qemu%20OSX/qemu regards //Peter -- bitrunner - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] EFI BIOS and kvm
hi there is the EFI BIOS (http://fabrice.bellard.free.fr/qemu/download.html -> efi-bios.tar.bz2) supposed to work with kvm? I wan't to try installing Mac OS X. README of efi-bios tells "You must use the CVS version of QEMU to use the BIOS (the version 0.9.0 won't work)" so, which qemu version is kvm based on? i'm using kvm-63 module and utilities. Or maybe this doesn't work at all with kvm? KVM says now: #> kvm -hda efi.disk -vnc :1 qemu: could not load PC bios '/usr/share/kvm/bios.bin' (where bios.bin is replaced by efi bios.bin) - Thomas - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] windows guest shows 15 virtual CPU´s in device manager
Hi all, I am running on kernel 2.6.24, KVM 63 trying windows guests working quite well. but why tells the device manager that I have 15 CPU`s (QEMU Virtual CPU version 0.9.1)? The windows task manager is just showing one as expected. I got this issue on winxp sp2 and on vista sp1 (others not tested yet.) Best Regards, Martin - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [12/17][PATCH] kvm/ia64: add optimization for some virtulization faults
>From 2dbf7c93ff5e36a221761c690ff12e7be48a6bb2 Mon Sep 17 00:00:00 2001 From: Xiantao Zhang <[EMAIL PROTECTED]> Date: Wed, 12 Mar 2008 13:49:38 +0800 Subject: [PATCH] kvm/ia64: add optimization for some virtulization faults optvfault.S adds optimization for some performance-critical virtualization faults. Signed-off-by: Anthony Xu <[EMAIL PROTECTED]> Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]> --- arch/ia64/kvm/optvfault.S | 918 + 1 files changed, 918 insertions(+), 0 deletions(-) create mode 100644 arch/ia64/kvm/optvfault.S diff --git a/arch/ia64/kvm/optvfault.S b/arch/ia64/kvm/optvfault.S new file mode 100644 index 000..5de210e --- /dev/null +++ b/arch/ia64/kvm/optvfault.S @@ -0,0 +1,918 @@ +/* + * arch/ia64/vmx/optvfault.S + * optimize virtualization fault handler + * + * Copyright (C) 2006 Intel Co + * Xuefei Xu (Anthony Xu) <[EMAIL PROTECTED]> + */ + +#include +#include + +#include "vti.h" +#include "asm-offsets.h" + +#define ACCE_MOV_FROM_AR +#define ACCE_MOV_FROM_RR +#define ACCE_MOV_TO_RR +#define ACCE_RSM +#define ACCE_SSM +#define ACCE_MOV_TO_PSR +#define ACCE_THASH + +//mov r1=ar3 +GLOBAL_ENTRY(kvm_asm_mov_from_ar) +#ifndef ACCE_MOV_FROM_AR +br.many kvm_virtualization_fault_back +#endif +add r18=VMM_VCPU_ITC_OFS_OFFSET, r21 +add r16=VMM_VCPU_LAST_ITC_OFFSET,r21 +extr.u r17=r25,6,7 +;; +ld8 r18=[r18] +mov r19=ar.itc +mov r24=b0 +;; +add r19=r19,r18 +addl [EMAIL PROTECTED](asm_mov_to_reg),gp +;; +st8 [r16] = r19 +adds r30=kvm_resume_to_guest-asm_mov_to_reg,r20 +shladd r17=r17,4,r20 +;; +mov b0=r17 +br.sptk.few b0 +;; +END(kvm_asm_mov_from_ar) + + +// mov r1=rr[r3] +GLOBAL_ENTRY(kvm_asm_mov_from_rr) +#ifndef ACCE_MOV_FROM_RR +br.many kvm_virtualization_fault_back +#endif +extr.u r16=r25,20,7 +extr.u r17=r25,6,7 +addl [EMAIL PROTECTED](asm_mov_from_reg),gp +;; +adds r30=kvm_asm_mov_from_rr_back_1-asm_mov_from_reg,r20 +shladd r16=r16,4,r20 +mov r24=b0 +;; +add r27=VMM_VCPU_VRR0_OFFSET,r21 +mov b0=r16 +br.many b0 +;; +kvm_asm_mov_from_rr_back_1: +adds r30=kvm_resume_to_guest-asm_mov_from_reg,r20 +adds r22=asm_mov_to_reg-asm_mov_from_reg,r20 +shr.u r26=r19,61 +;; +shladd r17=r17,4,r22 +shladd r27=r26,3,r27 +;; +ld8 r19=[r27] +mov b0=r17 +br.many b0 +END(kvm_asm_mov_from_rr) + + +// mov rr[r3]=r2 +GLOBAL_ENTRY(kvm_asm_mov_to_rr) +#ifndef ACCE_MOV_TO_RR +br.many kvm_virtualization_fault_back +#endif +extr.u r16=r25,20,7 +extr.u r17=r25,13,7 +addl [EMAIL PROTECTED](asm_mov_from_reg),gp +;; +adds r30=kvm_asm_mov_to_rr_back_1-asm_mov_from_reg,r20 +shladd r16=r16,4,r20 +mov r22=b0 +;; +add r27=VMM_VCPU_VRR0_OFFSET,r21 +mov b0=r16 +br.many b0 +;; +kvm_asm_mov_to_rr_back_1: +adds r30=kvm_asm_mov_to_rr_back_2-asm_mov_from_reg,r20 +shr.u r23=r19,61 +shladd r17=r17,4,r20 +;; +//if rr6, go back +cmp.eq p6,p0=6,r23 +mov b0=r22 +(p6) br.cond.dpnt.many kvm_virtualization_fault_back +;; +mov r28=r19 +mov b0=r17 +br.many b0 +kvm_asm_mov_to_rr_back_2: +adds r30=kvm_resume_to_guest-asm_mov_from_reg,r20 +shladd r27=r23,3,r27 +;; // vrr.rid<<4 |0xe +st8 [r27]=r19 +mov b0=r30 +;; +extr.u r16=r19,8,26 +extr.u r18 =r19,2,6 +mov r17 =0xe +;; +shladd r16 = r16, 4, r17 +extr.u r19 =r19,0,8 +;; +shl r16 = r16,8 +;; +add r19 = r19, r16 +;; //set ve 1 +dep r19=-1,r19,0,1 +cmp.lt p6,p0=14,r18 +;; +(p6) mov r18=14 +;; +(p6) dep r19=r18,r19,2,6 +;; +cmp.eq p6,p0=0,r23 +;; +cmp.eq.or p6,p0=4,r23 +;; +adds r16=VMM_VCPU_MODE_FLAGS_OFFSET,r21 +(p6) adds r17=VMM_VCPU_META_SAVED_RR0_OFFSET,r21 +;; +ld4 r16=[r16] +cmp.eq p7,p0=r0,r0 +(p6) shladd r17=r23,1,r17 +;; +(p6) st8 [r17]=r19 +(p6) tbit.nz p6,p7=r16,0 +;; +(p7) mov rr[r28]=r19 +mov r24=r22 +br.many b0 +END(kvm_asm_mov_to_rr) + + +//rsm +GLOBAL_ENTRY(kvm_asm_rsm) +#ifndef ACCE_RSM +br.many kvm_virtualization_fault_back +#endif +add r16=VMM_VPD_BASE_OFFSET,r21 +extr.u r26=r25,6,21 +extr.u r27=r25,31,2 +;; +ld8 r16=[r16] +extr.u r28=r25,36,1 +dep r26=r27,r26,21,2 +;; +add r17=VPD_VPSR_START_OFFSET,r16 +add r22=VMM_VCPU_MODE_FLAGS_OFFSET,r21 +//r26 is imm24 +dep r26=r28,r26,23,1 +;; +ld8 r18=[r17] +movl r28=IA64_PSR_IC+IA64_PSR_I+IA64_PSR_DT+IA64_PSR_SI +ld4 r23=[r22] +sub r27=-1,r26 +mov r24=b0 +;; +mov r20=cr.ipsr +or r28=r27,r28 +and r19=r18,r27 +;; +st8 [r17]=r19 +and r20=r20,r28 +/* Comment it out due to short of fp lazy alorgithm support +adds r27=IA64_VCPU_FP_PSR_OFFSET,r21 +;; +ld8 r27=[r27] +;; +tbit.nz p8,p0= r27,IA64_PSR_DFH_BIT +;; +(p8) dep r20=-1,r20,IA6
[kvm-devel] [13/17][PATCH] kvm/ia64: Generate offset values for assembly code use.
>From f21b39650592fff4d07c94730b0f4e9aa093b9a8 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Wed, 12 Mar 2008 13:50:13 +0800
Subject: [PATCH] kvm/ia64: Generate offset values for assembly code use.
asm-offsets.c will generate offset values used for assembly code
for some fileds of special structures.
Signed-off-by: Anthony Xu <[EMAIL PROTECTED]>
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
arch/ia64/kvm/asm-offsets.c | 251
+++
1 files changed, 251 insertions(+), 0 deletions(-)
create mode 100644 arch/ia64/kvm/asm-offsets.c
diff --git a/arch/ia64/kvm/asm-offsets.c b/arch/ia64/kvm/asm-offsets.c
new file mode 100644
index 000..fc2ac82
--- /dev/null
+++ b/arch/ia64/kvm/asm-offsets.c
@@ -0,0 +1,251 @@
+/*
+ * asm-offsets.c Generate definitions needed by assembly language
modules.
+ * This code generates raw asm output which is post-processed
+ * to extract and format the required data.
+ *
+ * Anthony Xu<[EMAIL PROTECTED]>
+ * Xiantao Zhang <[EMAIL PROTECTED]>
+ * Copyright (c) 2007 Intel Corporation KVM support.
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ */
+
+#include
+#include
+
+#include "vcpu.h"
+
+#define task_struct kvm_vcpu
+
+#define DEFINE(sym, val) \
+ asm volatile("\n->" #sym " (%0) " #val : : "i" (val))
+
+#define BLANK() asm volatile("\n->" : :)
+
+#define OFFSET(_sym, _str, _mem) \
+DEFINE(_sym, offsetof(_str, _mem));
+
+void foo(void)
+{
+ DEFINE(VMM_TASK_SIZE, sizeof(struct kvm_vcpu));
+ DEFINE(VMM_PT_REGS_SIZE, sizeof(struct kvm_pt_regs));
+
+ BLANK();
+
+ DEFINE(VMM_VCPU_META_RR0_OFFSET,
+ offsetof(struct kvm_vcpu,
arch.metaphysical_rr0));
+ DEFINE(VMM_VCPU_META_SAVED_RR0_OFFSET,
+ offsetof(struct kvm_vcpu,
+ arch.metaphysical_saved_rr0));
+ DEFINE(VMM_VCPU_VRR0_OFFSET,
+ offsetof(struct kvm_vcpu, arch.vrr[0]));
+ DEFINE(VMM_VPD_IRR0_OFFSET,
+ offsetof(struct vpd, irr[0]));
+ DEFINE(VMM_VCPU_ITC_CHECK_OFFSET,
+ offsetof(struct kvm_vcpu, arch.itc_check));
+ DEFINE(VMM_VCPU_IRQ_CHECK_OFFSET,
+ offsetof(struct kvm_vcpu, arch.irq_check));
+ DEFINE(VMM_VPD_VHPI_OFFSET,
+ offsetof(struct vpd, vhpi));
+ DEFINE(VMM_VCPU_VSA_BASE_OFFSET,
+ offsetof(struct kvm_vcpu, arch.vsa_base));
+ DEFINE(VMM_VCPU_VPD_OFFSET,
+ offsetof(struct kvm_vcpu, arch.vpd));
+ DEFINE(VMM_VCPU_IRQ_CHECK,
+ offsetof(struct kvm_vcpu, arch.irq_check));
+ DEFINE(VMM_VCPU_TIMER_PENDING,
+ offsetof(struct kvm_vcpu, arch.timer_pending));
+ DEFINE(VMM_VCPU_META_SAVED_RR0_OFFSET,
+ offsetof(struct kvm_vcpu,
arch.metaphysical_saved_rr0));
+ DEFINE(VMM_VCPU_MODE_FLAGS_OFFSET,
+ offsetof(struct kvm_vcpu, arch.mode_flags));
+ DEFINE(VMM_VCPU_ITC_OFS_OFFSET,
+ offsetof(struct kvm_vcpu, arch.itc_offset));
+ DEFINE(VMM_VCPU_LAST_ITC_OFFSET,
+ offsetof(struct kvm_vcpu, arch.last_itc));
+ DEFINE(VMM_VCPU_SAVED_GP_OFFSET,
+ offsetof(struct kvm_vcpu, arch.saved_gp));
+
+ BLANK();
+
+ DEFINE(VMM_PT_REGS_B6_OFFSET,
+ offsetof(struct kvm_pt_regs, b6));
+ DEFINE(VMM_PT_REGS_B7_OFFSET,
+ offsetof(struct kvm_pt_regs, b7));
+ DEFINE(VMM_PT_REGS_AR_CSD_OFFSET,
+ offsetof(struct kvm_pt_regs, ar_csd));
+ DEFINE(VMM_PT_REGS_AR_SSD_OFFSET,
+ offsetof(struct kvm_pt_regs, ar_ssd));
+ DEFINE(VMM_PT_REGS_R8_OFFSET,
+ offsetof(struct kvm_pt_regs, r8));
+ DEFINE(VMM_PT_REGS_R9_OFFSET,
+ offsetof(struct kvm_pt_regs, r9));
+ DEFINE(VMM_PT_REGS_R10_OFFSET,
+ offsetof(struct kvm_pt_regs, r10));
+ DEFINE(VMM_PT_REGS_R11_OFFSET,
+ offsetof(struct kvm_pt_regs, r11));
+ DEFINE(VMM_PT_REGS_CR_IPSR_OFFSET,
+ offsetof(struct kvm_pt_regs, c
[kvm-devel] [02/17][PATCH] Implement smp_call_function_mask for ia64
>From 9118d25b4e98bef3a62429f8c150e8d429396c40 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Wed, 12 Mar 2008 12:58:02 +0800
Subject: [PATCH] Implement smp_call_function_mask for ia64
This function provides more flexible interface for smp
infrastructure.
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
arch/ia64/kernel/smp.c | 84
+--
include/linux/smp.h|3 ++
2 files changed, 69 insertions(+), 18 deletions(-)
diff --git a/arch/ia64/kernel/smp.c b/arch/ia64/kernel/smp.c
index 4e446aa..5bb241f 100644
--- a/arch/ia64/kernel/smp.c
+++ b/arch/ia64/kernel/smp.c
@@ -213,6 +213,19 @@ send_IPI_allbutself (int op)
* Called with preemption disabled.
*/
static inline void
+send_IPI_mask(cpumask_t mask, int op)
+{
+ unsigned int cpu;
+
+ for_each_cpu_mask(cpu, mask) {
+ send_IPI_single(cpu, op);
+ }
+}
+
+/*
+ * Called with preemption disabled.
+ */
+static inline void
send_IPI_all (int op)
{
int i;
@@ -401,33 +414,36 @@ smp_call_function_single (int cpuid, void (*func)
(void *info), void *info, int
}
EXPORT_SYMBOL(smp_call_function_single);
-/*
- * this function sends a 'generic call function' IPI to all other CPUs
- * in the system.
- */
-
-/*
- * [SUMMARY] Run a function on all other CPUs.
- * The function to run. This must be fast and non-blocking.
- * An arbitrary pointer to pass to the function.
- * currently unused.
- * If true, wait (atomically) until function has completed
on other CPUs.
- * [RETURNS] 0 on success, else a negative status code.
+/**
+ * smp_call_function_mask(): Run a function on a set of other CPUs.
+ * The set of cpus to run on. Must not include the current
cpu.
+ * The function to run. This must be fast and non-blocking.
+ * An arbitrary pointer to pass to the function.
+ * If true, wait (atomically) until function
+ * has completed on other CPUs.
*
- * Does not return until remote CPUs are nearly ready to execute
or are or have
- * executed.
+ * Returns 0 on success, else a negative status code.
+ *
+ * If @wait is true, then returns once @func has returned; otherwise
+ * it returns just before the target cpu calls @func.
*
* You must not call this function with disabled interrupts or from a
* hardware interrupt handler or from a bottom half handler.
*/
-int
-smp_call_function (void (*func) (void *info), void *info, int
nonatomic, int wait)
+int smp_call_function_mask(cpumask_t mask,
+ void (*func)(void *), void *info,
+ int wait)
{
struct call_data_struct data;
+ cpumask_t allbutself;
int cpus;
spin_lock(&call_lock);
- cpus = num_online_cpus() - 1;
+ allbutself = cpu_online_map;
+ cpu_clear(smp_processor_id(), allbutself);
+
+ cpus_and(mask, mask, allbutself);
+ cpus = cpus_weight(mask);
if (!cpus) {
spin_unlock(&call_lock);
return 0;
@@ -445,7 +461,12 @@ smp_call_function (void (*func) (void *info), void
*info, int nonatomic, int wai
call_data = &data;
mb(); /* ensure store to call_data precedes setting of
IPI_CALL_FUNC */
- send_IPI_allbutself(IPI_CALL_FUNC);
+
+ /* Send a message to other CPUs */
+ if (cpus_equal(mask, allbutself))
+ send_IPI_allbutself(IPI_CALL_FUNC);
+ else
+ send_IPI_mask(mask, IPI_CALL_FUNC);
/* Wait for response */
while (atomic_read(&data.started) != cpus)
@@ -458,6 +479,33 @@ smp_call_function (void (*func) (void *info), void
*info, int nonatomic, int wai
spin_unlock(&call_lock);
return 0;
+
+}
+EXPORT_SYMBOL(smp_call_function_mask);
+
+/*
+ * this function sends a 'generic call function' IPI to all other CPUs
+ * in the system.
+ */
+
+/*
+ * [SUMMARY] Run a function on all other CPUs.
+ * The function to run. This must be fast and non-blocking.
+ * An arbitrary pointer to pass to the function.
+ * currently unused.
+ * If true, wait (atomically) until function has completed
on other CPUs.
+ * [RETURNS] 0 on success, else a negative status code.
+ *
+ * Does not return until remote CPUs are nearly ready to execute
or are or have
+ * executed.
+ *
+ * You must not call this function with disabled interrupts or from a
+ * hardware interrupt handler or from a bottom half handler.
+ */
+int
+smp_call_function (void (*func) (void *info), void *info, int
nonatomic, int wait)
+{
+ return smp_call_function_mask(cpu_online_map, func, info, wait);
}
EXPORT_SYMBOL(smp_call_function);
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 55232cc..b71820b 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -56,6 +56,9 @@ int smp_call_function(void(*func)(void *info), void
*info, int retry, int wait);
int smp_call_function_single(int cp
[kvm-devel] [07/17][PATCH] kvm/ia64: Add TLB virtulization support.
>From 56d3f7acf8d45d2491646be77ced344dcc516cd7 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Wed, 12 Mar 2008 13:45:40 +0800
Subject: [PATCH] kvm/ia64: Add TLB virtulization support.
vtlb.c includes tlb/VHPT virtulization.
Signed-off-by: Anthony Xu <[EMAIL PROTECTED]>
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
arch/ia64/kvm/vtlb.c | 631
++
1 files changed, 631 insertions(+), 0 deletions(-)
create mode 100644 arch/ia64/kvm/vtlb.c
diff --git a/arch/ia64/kvm/vtlb.c b/arch/ia64/kvm/vtlb.c
new file mode 100644
index 000..6e6ed25
--- /dev/null
+++ b/arch/ia64/kvm/vtlb.c
@@ -0,0 +1,631 @@
+/*
+ * vtlb.c: guest virtual tlb handling module.
+ * Copyright (c) 2004, Intel Corporation.
+ * Yaozu Dong (Eddie Dong) <[EMAIL PROTECTED]>
+ * Xuefei Xu (Anthony Xu) <[EMAIL PROTECTED]>
+ *
+ * Copyright (c) 2007, Intel Corporation.
+ * Xuefei Xu (Anthony Xu) <[EMAIL PROTECTED]>
+ * Xiantao Zhang <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ */
+
+#include "vcpu.h"
+
+#include
+/*
+ * Check to see if the address rid:va is translated by the TLB
+ */
+
+static int __is_tr_translated(thash_data_t *trp, u64 rid, u64 va)
+{
+ return ((trp->p) && (trp->rid == rid)
+ && ((va-trp->vadr) < PSIZE(trp->ps)));
+}
+
+/*
+ * Only for GUEST TR format.
+ */
+static int __is_tr_overlap(thash_data_t *trp, u64 rid, u64 sva, u64
eva)
+{
+ u64 sa1, ea1;
+
+ if (!trp->p || trp->rid != rid)
+ return 0;
+
+ sa1 = trp->vadr;
+ ea1 = sa1 + PSIZE(trp->ps) - 1;
+ eva -= 1;
+ if ((sva > ea1) || (sa1 > eva))
+ return 0;
+ else
+ return 1;
+
+}
+
+void machine_tlb_purge(u64 va, u64 ps)
+{
+ ia64_ptcl(va, ps << 2);
+}
+
+void local_flush_tlb_all(void)
+{
+ int i, j;
+ unsigned long flags, count0, count1;
+ unsigned long stride0, stride1, addr;
+
+ addr= current_vcpu->arch.ptce_base;
+ count0 = current_vcpu->arch.ptce_count[0];
+ count1 = current_vcpu->arch.ptce_count[1];
+ stride0 = current_vcpu->arch.ptce_stride[0];
+ stride1 = current_vcpu->arch.ptce_stride[1];
+
+ local_irq_save(flags);
+ for (i = 0; i < count0; ++i) {
+ for (j = 0; j < count1; ++j) {
+ ia64_ptce(addr);
+ addr += stride1;
+ }
+ addr += stride0;
+ }
+ local_irq_restore(flags);
+ ia64_srlz_i(); /* srlz.i implies srlz.d */
+}
+
+int vhpt_enabled(VCPU *vcpu, u64 vadr, vhpt_ref_t ref)
+{
+ ia64_rrvrr;
+ ia64_pta vpta;
+ ia64_psr vpsr;
+
+ vpsr.val = VCPU(vcpu, vpsr);
+ vrr.val = vcpu_get_rr(vcpu, vadr);
+ vpta.val = vcpu_get_pta(vcpu);
+
+ if (vrr.ve & vpta.ve) {
+ switch (ref) {
+ case DATA_REF:
+ case NA_REF:
+ return vpsr.dt;
+ case INST_REF:
+ return vpsr.dt && vpsr.it && vpsr.ic;
+ case RSE_REF:
+ return vpsr.dt && vpsr.rt;
+
+ }
+ }
+ return 0;
+}
+
+thash_data_t *vsa_thash(ia64_pta vpta, u64 va, u64 vrr, u64 *tag)
+{
+ u64 index, pfn, rid, pfn_bits;
+
+ pfn_bits = vpta.size - 5 - 8;
+ pfn = REGION_OFFSET(va) >> _REGION_PAGE_SIZE(vrr);
+ rid = _REGION_ID(vrr);
+ index = ((rid & 0xff) << pfn_bits)|(pfn & ((1UL << pfn_bits) -
1));
+ *tag = ((rid >> 8) & 0x) | ((pfn >> pfn_bits) << 16);
+
+ return (thash_data_t *)((vpta.base << PTA_BASE_SHIFT) + (index
<< 5));
+}
+
+thash_data_t *__vtr_lookup(VCPU *vcpu, u64 va, int type)
+{
+
+ thash_data_t *trp;
+ int i;
+ u64 rid;
+
+ rid = vcpu_get_rr(vcpu, va);
+ rid = rid & RR_RID_MASK;;
+ if (type == D_TLB) {
+ if (vcpu_quick_region_check(vcpu->arch.dtr_regions, va))
{
+ for (trp = (thash_data_t *)&vcpu->arch.dtrs, i =
0;
+ i < NDTRS; i++, trp++) {
+ if (__is_tr_translated(trp, rid, va))
+ return trp;
+ }
+ }
+ } else {
+
[kvm-devel] [09/17] [PATCH] kvm/ia64: Add mmio decoder for kvm/ia64.
>From 5f82ea88c095cf89cbae920944c05e578f35365f Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Wed, 12 Mar 2008 14:48:09 +0800
Subject: [PATCH] kvm/ia64: Add mmio decoder for kvm/ia64.
mmio.c includes mmio decoder routines.
Signed-off-by: Anthony Xu <[EMAIL PROTECTED]>
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
arch/ia64/kvm/mmio.c | 349
++
1 files changed, 349 insertions(+), 0 deletions(-)
create mode 100644 arch/ia64/kvm/mmio.c
diff --git a/arch/ia64/kvm/mmio.c b/arch/ia64/kvm/mmio.c
new file mode 100644
index 000..3f8027a
--- /dev/null
+++ b/arch/ia64/kvm/mmio.c
@@ -0,0 +1,349 @@
+/*
+ * mmio.c: MMIO emulation components.
+ * Copyright (c) 2004, Intel Corporation.
+ * Yaozu Dong (Eddie Dong) ([EMAIL PROTECTED])
+ * Kun Tian (Kevin Tian) ([EMAIL PROTECTED])
+ *
+ * Copyright (c) 2007 Intel Corporation KVM support.
+ * Xuefei Xu (Anthony Xu) ([EMAIL PROTECTED])
+ * Xiantao Zhang ([EMAIL PROTECTED])
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ */
+
+#include
+
+#include "vcpu.h"
+
+static void vlsapic_write_xtp(VCPU *v, uint8_t val)
+{
+ VLSAPIC_XTP(v) = val;
+}
+
+/*
+ * LSAPIC OFFSET
+ */
+#define PIB_LOW_HALF(ofst) !(ofst & (1 << 20))
+#define PIB_OFST_INTA 0x1E
+#define PIB_OFST_XTP 0x1E0008
+
+/*
+ * execute write IPI op.
+ */
+static void vlsapic_write_ipi(VCPU *vcpu, uint64_t addr, uint64_t data)
+{
+ struct exit_ctl_data *p = ¤t_vcpu->arch.exit_data;
+ unsigned long psr;
+
+ local_irq_save(psr);
+
+ p->exit_reason = EXIT_REASON_IPI;
+ p->u.ipi_data.addr.val = addr;
+ p->u.ipi_data.data.val = data;
+ vmm_transition(current_vcpu);
+
+ local_irq_restore(psr);
+
+}
+
+void lsapic_write(VCPU *v, unsigned long addr, unsigned long length,
+ unsigned long val)
+{
+ addr &= (PIB_SIZE - 1);
+
+ switch (addr) {
+ case PIB_OFST_INTA:
+ /*panic_domain(NULL, "Undefined write on PIB INTA\n");*/
+ panic_vm(v);
+ break;
+ case PIB_OFST_XTP:
+ if (length == 1) {
+ vlsapic_write_xtp(v, val);
+ } else {
+ /*panic_domain(NULL,
+ "Undefined write on PIB XTP\n");*/
+ panic_vm(v);
+ }
+ break;
+ default:
+ if (PIB_LOW_HALF(addr)) {
+ /*lower half */
+ if (length != 8)
+ /*panic_domain(NULL,
+ "Can't LHF write with size %ld!\n",
+ length);*/
+ panic_vm(v);
+ else
+ vlsapic_write_ipi(v, addr, val);
+ } else { /* upper half
+ printk("IPI-UHF write %lx\n",addr);*/
+ panic_vm(v);
+ }
+ break;
+ }
+}
+
+unsigned long lsapic_read(VCPU *v, unsigned long addr,
+ unsigned long length)
+{
+ uint64_t result = 0;
+
+ addr &= (PIB_SIZE - 1);
+
+ switch (addr) {
+ case PIB_OFST_INTA:
+ if (length == 1) /* 1 byte load */
+ ; /* There is no i8259, there is no INTA
access*/
+ else
+ /*panic_domain(NULL,"Undefined read on PIB
INTA\n"); */
+ panic_vm(v);
+
+ break;
+ case PIB_OFST_XTP:
+ if (length == 1) {
+ result = VLSAPIC_XTP(v);
+ /* printk("read xtp %lx\n", result); */
+ } else {
+ /*panic_domain(NULL,
+ "Undefined read on PIB XTP\n");*/
+ panic_vm(v);
+ }
+ break;
+ default:
+ panic_vm(v);
+ break;
+ }
+ return result;
+}
+
+static void mmio_access(VCPU *vcpu, u64 src_pa, u64 *dest,
+ u16 s, int ma, int dir)
+{
+ unsigned long iot;
+ struct exit_ctl_data *p = &vcpu->arch.exit_data;
+ unsigned long psr;
+
+ iot = __gpfn_is_io(src_pa >> PAGE_SHIFT);
+
+ local_irq
[kvm-devel] [01/17]PATCH Add API for allocating dynamic TR resouce.
Refined according to Tony's comments.
>From 837f0508a617ea0386808de9fd0f42ef4aefe5e0 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Thu, 27 Mar 2008 10:18:29 +0800
Subject: [PATCH] Add API for allocating TR resouce.
Dynamic TR resouce should be managed in an uniform way.
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
Signed-off-by: Anthony Xu<[EMAIL PROTECTED]>
---
arch/ia64/kernel/mca.c | 50 +
arch/ia64/kernel/mca_asm.S |5 ++
arch/ia64/mm/tlb.c | 170
include/asm-ia64/kregs.h |3 +
include/asm-ia64/tlb.h | 12 +++
5 files changed, 240 insertions(+), 0 deletions(-)
diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
index 6c18221..51d0c26 100644
--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -97,6 +97,7 @@
#include
#include
+#include
#include "mca_drv.h"
#include "entry.h"
@@ -112,8 +113,10 @@ DEFINE_PER_CPU(u64, ia64_mca_data); /* ==
__per_cpu_mca[smp_processor_id()] */
DEFINE_PER_CPU(u64, ia64_mca_per_cpu_pte); /* PTE to map per-CPU area
*/
DEFINE_PER_CPU(u64, ia64_mca_pal_pte); /* PTE to map PAL code */
DEFINE_PER_CPU(u64, ia64_mca_pal_base);/* vaddr PAL code granule */
+DEFINE_PER_CPU(u64, ia64_mca_tr_reload); /* Flag for TR reload */
unsigned long __per_cpu_mca[NR_CPUS];
+extern struct ia64_tr_entry
__per_cpu_idtrs[NR_CPUS][2][IA64_TR_ALLOC_MAX];
/* In mca_asm.S */
extern voidia64_os_init_dispatch_monarch (void);
@@ -1182,6 +1185,49 @@ all_in:
return;
}
+/* mca_insert_tr
+ *
+ * Switch rid when TR reload and needed!
+ * iord: 1: itr, 2: itr;
+ *
+*/
+static void mca_insert_tr(u64 iord)
+{
+
+ int i;
+ u64 old_rr;
+ struct ia64_tr_entry *p;
+ unsigned long psr;
+ int cpu = smp_processor_id();
+
+ psr = ia64_clear_ic();
+ for (i = IA64_TR_ALLOC_BASE; i < IA64_TR_ALLOC_MAX; i++) {
+ p = &__per_cpu_idtrs[cpu][iord-1][i];
+ if (p->pte&0x1) {
+ old_rr = ia64_get_rr(p->ifa);
+ if (old_rr != p->rr) {
+ ia64_set_rr(p->ifa, p->rr);
+ ia64_srlz_d();
+ }
+ ia64_ptr(iord, p->ifa, p->itir >> 2);
+ ia64_srlz_i();
+ if (iord & 0x1) {
+ ia64_itr(0x1, i, p->ifa, p->pte, p->itir
>> 2);
+ ia64_srlz_i();
+ }
+ if (iord & 0x2) {
+ ia64_itr(0x2, i, p->ifa, p->pte, p->itir
>> 2);
+ ia64_srlz_i();
+ }
+ if (old_rr != p->rr) {
+ ia64_set_rr(p->ifa, old_rr);
+ ia64_srlz_d();
+ }
+ }
+ }
+ ia64_set_psr(psr);
+}
+
/*
* ia64_mca_handler
*
@@ -1271,6 +1317,10 @@ ia64_mca_handler(struct pt_regs *regs, struct
switch_stack *sw,
monarch_cpu = -1;
#endif
}
+ if (__get_cpu_var(ia64_mca_tr_reload)) {
+ mca_insert_tr(0x1); /*Reload dynamic itrs*/
+ mca_insert_tr(0x2); /*Reload dynamic itrs*/
+ }
if (notify_die(DIE_MCA_MONARCH_LEAVE, "MCA", regs, (long)&nd, 0,
recover)
== NOTIFY_STOP)
ia64_mca_spin(__func__);
diff --git a/arch/ia64/kernel/mca_asm.S b/arch/ia64/kernel/mca_asm.S
index 8bc7d25..a06d465 100644
--- a/arch/ia64/kernel/mca_asm.S
+++ b/arch/ia64/kernel/mca_asm.S
@@ -219,8 +219,13 @@ ia64_reload_tr:
mov r20=IA64_TR_CURRENT_STACK
;;
itr.d dtr[r20]=r16
+ GET_THIS_PADDR(r2, ia64_mca_tr_reload)
+ mov r18 = 1
;;
srlz.d
+ ;;
+ st8 [r2] =r18
+ ;;
done_tlb_purge_and_reload:
diff --git a/arch/ia64/mm/tlb.c b/arch/ia64/mm/tlb.c
index 655da24..d7f8206 100644
--- a/arch/ia64/mm/tlb.c
+++ b/arch/ia64/mm/tlb.c
@@ -26,6 +26,8 @@
#include
#include
#include
+#include
+#include
static struct {
unsigned long mask; /* mask of supported purge page-sizes */
@@ -39,6 +41,10 @@ struct ia64_ctx ia64_ctx = {
};
DEFINE_PER_CPU(u8, ia64_need_tlb_flush);
+DEFINE_PER_CPU(u8, ia64_tr_num); /*Number of TR slots in current
processor*/
+DEFINE_PER_CPU(u8, ia64_tr_used); /*Max Slot number used by kernel*/
+
+struct ia64_tr_entry __per_cpu_idtrs[NR_CPUS][2][IA64_TR_ALLOC_MAX];
/*
* Initializes the ia64_ctx.bitmap array based on max_ctx+1.
@@ -190,6 +196,9 @@ ia64_tlb_init (void)
ia64_ptce_info_t uninitialized_var(ptce_info); /* GCC be quiet
*/
unsigned long tr_pgbits;
long status;
+ pal_vm_info_1_u_t vm_info_1;
+ pal_vm_info_2_u_t vm_info_2;
+ int cpu = smp_processor_id();
if ((status = ia64_pal_vm_page_size(&tr_pgbits, &pu
[kvm-devel] [03/15][PATCH] kvm/ia64: Add header files for kvm/ia64.
>From cf64ba3c5464b7da6c6fb2871b8424a08ade3ab2 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Fri, 28 Mar 2008 09:48:10 +0800
Subject: [PATCH] kvm/ia64: Add header files for kvm/ia64.
Three header files are added:
asm-ia64/kvm.h
asm-ia64/kvm_host.h
asm-ia64/kvm_para.h
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
include/asm-ia64/kvm.h | 205 +
include/asm-ia64/kvm_host.h | 530
+++
include/asm-ia64/kvm_para.h | 29 +++
3 files changed, 764 insertions(+), 0 deletions(-)
create mode 100644 include/asm-ia64/kvm.h
create mode 100644 include/asm-ia64/kvm_host.h
create mode 100644 include/asm-ia64/kvm_para.h
diff --git a/include/asm-ia64/kvm.h b/include/asm-ia64/kvm.h
new file mode 100644
index 000..8c70dd6
--- /dev/null
+++ b/include/asm-ia64/kvm.h
@@ -0,0 +1,205 @@
+#ifndef __ASM_KVM_IA64_H
+#define __ASM_KVM_IA64_H
+
+/*
+ * asm-ia64/kvm.h: kvm structure definitions for ia64
+ *
+ * Copyright (C) 2007 Xiantao Zhang <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ *
+ */
+
+#include
+#include
+
+#include
+
+/* Architectural interrupt line count. */
+#define KVM_NR_INTERRUPTS 256
+
+#define KVM_IOAPIC_NUM_PINS 24
+
+struct kvm_ioapic_state {
+ __u64 base_address;
+ __u32 ioregsel;
+ __u32 id;
+ __u32 irr;
+ __u32 pad;
+ union {
+ __u64 bits;
+ struct {
+ __u8 vector;
+ __u8 delivery_mode:3;
+ __u8 dest_mode:1;
+ __u8 delivery_status:1;
+ __u8 polarity:1;
+ __u8 remote_irr:1;
+ __u8 trig_mode:1;
+ __u8 mask:1;
+ __u8 reserve:7;
+ __u8 reserved[4];
+ __u8 dest_id;
+ } fields;
+ } redirtbl[KVM_IOAPIC_NUM_PINS];
+};
+
+#define KVM_IRQCHIP_PIC_MASTER 0
+#define KVM_IRQCHIP_PIC_SLAVE1
+#define KVM_IRQCHIP_IOAPIC 2
+
+#define KVM_CONTEXT_SIZE 8*1024
+
+typedef union context {
+ /* 8K size */
+ chardummy[KVM_CONTEXT_SIZE];
+ struct {
+ unsigned long psr;
+ unsigned long pr;
+ unsigned long caller_unat;
+ unsigned long pad;
+ unsigned long gr[32];
+ unsigned long ar[128];
+ unsigned long br[8];
+ unsigned long cr[128];
+ unsigned long rr[8];
+ unsigned long ibr[8];
+ unsigned long dbr[8];
+ unsigned long pkr[8];
+ struct ia64_fpreg fr[128];
+ };
+} context_t;
+
+typedef struct thash_data {
+ union {
+ struct {
+ unsigned long p: 1; /* 0 */
+ unsigned long rv1 : 1; /* 1 */
+ unsigned long ma : 3; /* 2-4 */
+ unsigned long a: 1; /* 5 */
+ unsigned long d: 1; /* 6 */
+ unsigned long pl : 2; /* 7-8 */
+ unsigned long ar : 3; /* 9-11 */
+ unsigned long ppn : 38; /* 12-49 */
+ unsigned long rv2 : 2; /* 50-51 */
+ unsigned long ed : 1; /* 52 */
+ unsigned long ig1 : 11; /* 53-63 */
+ };
+ struct {
+ unsigned long __rv1 : 53; /* 0-52 */
+ unsigned long contiguous : 1; /*53 */
+ unsigned long tc : 1; /* 54 TR or TC */
+ unsigned long cl : 1;
+ /* 55 I side or D side cache line */
+ unsigned long len : 4; /* 56-59 */
+ unsigned long io : 1; /* 60 entry is for io or
not */
+ unsigned long nomap : 1;
+ /* 61 entry cann't be inserted into machine
TLB.*/
+ unsigned long checked : 1;
+ /* 62 for VTLB/VHPT sanity check */
+ unsigned long invalid : 1;
+ /*
[kvm-devel] [16/17] [PATCH] kvm:ia64 Enable kvm build for ia64
>From 0639faa4a3347771e793e33652667272cc140240 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Fri, 28 Mar 2008 14:58:47 +0800
Subject: [PATCH] kvm:ia64 Enable kvm build for ia64
Update the related Makefile and KConfig for kvm build
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
arch/ia64/Kconfig |3 ++
arch/ia64/Makefile |1 +
arch/ia64/kvm/Kconfig | 46
arch/ia64/kvm/Makefile | 61
4 files changed, 111 insertions(+), 0 deletions(-)
create mode 100644 arch/ia64/kvm/Kconfig
create mode 100644 arch/ia64/kvm/Makefile
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 8fa3faf..a7bb62e 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -19,6 +19,7 @@ config IA64
select HAVE_OPROFILE
select HAVE_KPROBES
select HAVE_KRETPROBES
+ select HAVE_KVM
default y
help
The Itanium Processor Family is Intel's 64-bit successor to
@@ -589,6 +590,8 @@ config MSPEC
source "fs/Kconfig"
+source "arch/ia64/kvm/Kconfig"
+
source "lib/Kconfig"
#
diff --git a/arch/ia64/Makefile b/arch/ia64/Makefile
index f1645c4..ec4cca4 100644
--- a/arch/ia64/Makefile
+++ b/arch/ia64/Makefile
@@ -57,6 +57,7 @@ core-$(CONFIG_IA64_GENERIC) += arch/ia64/dig/
core-$(CONFIG_IA64_HP_ZX1) += arch/ia64/dig/
core-$(CONFIG_IA64_HP_ZX1_SWIOTLB) += arch/ia64/dig/
core-$(CONFIG_IA64_SGI_SN2)+= arch/ia64/sn/
+core-$(CONFIG_KVM) += arch/ia64/kvm/
drivers-$(CONFIG_PCI) += arch/ia64/pci/
drivers-$(CONFIG_IA64_HP_SIM) += arch/ia64/hp/sim/
diff --git a/arch/ia64/kvm/Kconfig b/arch/ia64/kvm/Kconfig
new file mode 100644
index 000..d2e54b9
--- /dev/null
+++ b/arch/ia64/kvm/Kconfig
@@ -0,0 +1,46 @@
+#
+# KVM configuration
+#
+config HAVE_KVM
+ bool
+
+menuconfig VIRTUALIZATION
+ bool "Virtualization"
+ depends on HAVE_KVM || IA64
+ default y
+ ---help---
+ Say Y here to get to see options for using your Linux host to
run other
+ operating systems inside virtual machines (guests).
+ This option alone does not add any kernel code.
+
+ If you say N, all options in this submenu will be skipped and
disabled.
+
+if VIRTUALIZATION
+
+config KVM
+ tristate "Kernel-based Virtual Machine (KVM) support"
+ depends on HAVE_KVM && EXPERIMENTAL
+ select PREEMPT_NOTIFIERS
+ select ANON_INODES
+ ---help---
+ Support hosting fully virtualized guest machines using
hardware
+ virtualization extensions. You will need a fairly recent
+ processor equipped with virtualization extensions. You will
also
+ need to select one or more of the processor modules below.
+
+ This module provides access to the hardware capabilities
through
+ a character device node named /dev/kvm.
+
+ To compile this as a module, choose M here: the module
+ will be called kvm.
+
+ If unsure, say N.
+
+config KVM_INTEL
+ tristate "KVM for Intel Itanium 2 processors support"
+ depends on KVM && m
+ ---help---
+ Provides support for KVM on Itanium 2 processors equipped with
the VT
+ extensions.
+
+endif # VIRTUALIZATION
diff --git a/arch/ia64/kvm/Makefile b/arch/ia64/kvm/Makefile
new file mode 100644
index 000..cde7d8e
--- /dev/null
+++ b/arch/ia64/kvm/Makefile
@@ -0,0 +1,61 @@
+#This Make file is to generate asm-offsets.h and build source.
+#
+
+#Generate asm-offsets.h for vmm module build
+offsets-file := asm-offsets.h
+
+always := $(offsets-file)
+targets := $(offsets-file)
+targets += arch/ia64/kvm/asm-offsets.s
+clean-files := $(addprefix $(objtree)/,$(targets) $(obj)/memcpy.S
$(obj)/memset.S)
+
+# Default sed regexp - multiline due to syntax constraints
+define sed-y
+ "/^->/{s:^->\([^ ]*\) [\$$#]*\([^ ]*\) \(.*\):#define \1 \2 /*
\3 */:; s:->::; p;}"
+endef
+
+quiet_cmd_offsets = GEN $@
+define cmd_offsets
+ (set -e; \
+echo "#ifndef __ASM_KVM_OFFSETS_H__"; \
+echo "#define __ASM_KVM_OFFSETS_H__"; \
+echo "/*"; \
+echo " * DO NOT MODIFY."; \
+echo " *"; \
+echo " * This file was generated by Makefile"; \
+echo " *"; \
+echo " */"; \
+echo ""; \
+sed -ne $(sed-y) $<; \
+echo ""; \
+echo "#endif" ) > $@
+endef
+# We use internal rules to avoid the "is up to date" message from make
+arch/ia64/kvm/asm-offsets.s: arch/ia64/kvm/asm-offsets.c
+ $(call if_changed_dep,cc_s_c)
+
+$(obj)/$(offsets-file): arch/ia64/kvm/asm-offsets.s
+ $(call cmd,offsets)
+
+#
+# Makefile for Kernel-based Virtual Machine module
+#
+
+EXTRA_CFLAGS += -Ivirt/kvm -Iarch/ia64/kvm/
+
+$(addprefix $(objtree)/,$(obj)/memcpy.S $(obj)/memset.S):
+ $(shell ln -snf ../lib/memcpy.S $(src)/memcpy.S)
+ $(shell ln -snf ../lib/memset.S $(src)/memset.
[kvm-devel] [06/17][PATCH] kvm/ia64: VMM module interfaces.
>From 6af8b4d7ca1d4ec40cc634cf8b0d5ae8d2dc53ce Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Wed, 12 Mar 2008 13:44:37 +0800
Subject: [PATCH] kvm/ia64: VMM module interfaces.
vmm.c adds the interfaces with kvm/module, and initialize global data
area.
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
arch/ia64/kvm/vmm.c | 66
+++
1 files changed, 66 insertions(+), 0 deletions(-)
create mode 100644 arch/ia64/kvm/vmm.c
diff --git a/arch/ia64/kvm/vmm.c b/arch/ia64/kvm/vmm.c
new file mode 100644
index 000..2275bf4
--- /dev/null
+++ b/arch/ia64/kvm/vmm.c
@@ -0,0 +1,66 @@
+/*
+ * vmm.c: vmm module interface with kvm module
+ *
+ * Copyright (c) 2007, Intel Corporation.
+ *
+ * Xiantao Zhang ([EMAIL PROTECTED])
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+
+#include
+#include
+
+#include "vcpu.h"
+
+MODULE_AUTHOR("Intel");
+MODULE_LICENSE("GPL");
+
+extern char kvm_ia64_ivt;
+extern fpswa_interface_t *vmm_fpswa_interface;
+
+struct kvm_vmm_info vmm_info = {
+ .module = THIS_MODULE,
+ .vmm_entry = vmm_entry,
+ .tramp_entry = vmm_trampoline,
+ .vmm_ivt = (unsigned long)&kvm_ia64_ivt,
+};
+
+static int __init kvm_vmm_init(void)
+{
+
+ vmm_fpswa_interface = fpswa_interface;
+
+ /*Register vmm data to kvm side*/
+ return kvm_init(&vmm_info, 1024, THIS_MODULE);
+}
+
+static void __exit kvm_vmm_exit(void)
+{
+ kvm_exit();
+ return ;
+}
+
+void vmm_spin_lock(spinlock_t *lock)
+{
+ _vmm_raw_spin_lock(lock);
+}
+
+void vmm_spin_unlock(spinlock_t *lock)
+{
+ _vmm_raw_spin_unlock(lock);
+}
+module_init(kvm_vmm_init)
+module_exit(kvm_vmm_exit)
--
1.5.2
0006-kvm-ia64-VMM-module-interfaces.patch
Description: 0006-kvm-ia64-VMM-module-interfaces.patch
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [17/17][PATCH] kvm/ia64: How to boot up guests on kvm/ia64
>From 517a89fd248193f6a7049832e2c1b811afe98f96 Mon Sep 17 00:00:00 2001 From: Xiantao Zhang <[EMAIL PROTECTED]> Date: Wed, 12 Mar 2008 13:57:33 +0800 Subject: [PATCH] kvm/ia64: How to boot up guests on kvm/ia64 Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]> --- Documentation/ia64/kvm-howto.txt | 74 ++ 1 files changed, 74 insertions(+), 0 deletions(-) create mode 100644 Documentation/ia64/kvm-howto.txt diff --git a/Documentation/ia64/kvm-howto.txt b/Documentation/ia64/kvm-howto.txt new file mode 100644 index 000..ad853b9 --- /dev/null +++ b/Documentation/ia64/kvm-howto.txt @@ -0,0 +1,74 @@ + Guide: How to boot up guests on kvm/ia64 + +1. Get the kvm source from git.kernel.org. + Userspace source: + git clone git://git.kernel.org/pub/scm/virt/kvm/kvm-userspace.git + Kernel Source: + git clone git://git.kernel.org/pub/scm/linux/kernel/git/xiantao/kvm-ia64.git + +2. Compile the source code. + 2.1 Compile userspace code: + (1)cd ./kvm-userspace + (2)./configure + (3)cd kernel + (4)make sync LINUX= $kernel_dir (kernel_dir is the directory of kernel source.) + (5)cd .. + (6)make qemu + (7)cd qemu; make install + + 2.2 Compile kernel source code: + (1) cd ./$kernel_dir + (2) Make menuconfig + (3) Enter into virtualization option, and choose kvm. + (4) make + (5) Once (4) done, make modules_install + (6) Make initrd, and use new kernel to reboot up host machine. + (7) Once (6) done, cd $kernel_dir/arch/ia64/kvm + (8) insmod kvm.ko; insmod kvm-intel.ko + +Note: For step 2, please make sure that host page size == TARGET_PAGE_SIZE of qemu, otherwise, may fail. + +3. Get Guest Firmware named as Flash.fd, and put it under right place: + (1) If you have the guest firmware (binary)released by Intel Corp for Xen, you can use it directly. + (2) If you want to build a guest firmware form souce code. Please download the source from + hg clone http://xenbits.xensource.com/ext/efi-vfirmware.hg + Use the Guide of the source to build open Guest Firmware. + (3) Rename it to Flash.fd, and copy it to /usr/local/share/qemu +Note: For step 3, kvm use the guest firmware which complies with the one Xen uses. + +4. Boot up Linux or Windows guests: + 4.1 Create or install a image for guest boot. If you have xen experience, it should be easy. + + 4.2 Boot up guests use the following command. + /usr/local/bin/qemu-system-ia64 -smp xx -m 512 -hda $your_image + (xx is the number of virtual processors for the guest, now the maximum value is 4) + +5. Known possbile issue on some platforms with old Firmware + +If meet strange host crashes, you may try to solve it through either of the following methods. +(1): Upgrade your Firmware to the latest one. + +(2): Applying the below patch to kernel source. +diff --git a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S +index 0b53344..f02b0f7 100644 +--- a/arch/ia64/kernel/pal.S b/arch/ia64/kernel/pal.S +@@ -84,7 +84,8 @@ GLOBAL_ENTRY(ia64_pal_call_static) + mov ar.pfs = loc1 + mov rp = loc0 + ;; +- srlz.d // seralize restoration of psr.l ++ srlz.i // seralize restoration of psr.l ++ ;; + br.ret.sptk.many b0 + END(ia64_pal_call_static) + +6. Bug report: + If you found any issues when use kvm/ia64, Please post the bug info to kvm-ia64-devel mailing list. + https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel/ + +Thanks for your interest! Let's work together, and make kvm/ia64 stronger and stronger! + + + Xiantao Zhang <[EMAIL PROTECTED]> + 2008.3.10 -- 1.5.2 0017-kvm-ia64-How-to-boot-up-guests-on-kvm-ia64.patch Description: 0017-kvm-ia64-How-to-boot-up-guests-on-kvm-ia64.patch - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [15/17][PATCH] kvm/ia64: Add kvm sal/pal virtulization support.
>From ba064fc79c5d8577543ae6e4a201f622f0c4b777 Mon Sep 17 00:00:00 2001
From: Xiantao Zhang <[EMAIL PROTECTED]>
Date: Wed, 12 Mar 2008 13:42:18 +0800
Subject: [PATCH] kvm/ia64: Add kvm sal/pal virtulization support.
Some sal/pal calls would be traped to kvm for virtulization
from guest firmware.
Signed-off-by: Xiantao Zhang <[EMAIL PROTECTED]>
---
arch/ia64/kvm/kvm_fw.c | 500
1 files changed, 500 insertions(+), 0 deletions(-)
create mode 100644 arch/ia64/kvm/kvm_fw.c
diff --git a/arch/ia64/kvm/kvm_fw.c b/arch/ia64/kvm/kvm_fw.c
new file mode 100644
index 000..077d6e7
--- /dev/null
+++ b/arch/ia64/kvm/kvm_fw.c
@@ -0,0 +1,500 @@
+/*
+ * PAL/SAL call delegation
+ *
+ * Copyright (c) 2004 Li Susie <[EMAIL PROTECTED]>
+ * Copyright (c) 2005 Yu Ke <[EMAIL PROTECTED]>
+ * Copyright (c) 2007 Xiantao Zhang <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but
WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
59 Temple
+ * Place - Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include
+#include
+
+#include "vti.h"
+#include "misc.h"
+
+#include
+#include
+#include
+
+/*
+ * Handy macros to make sure that the PAL return values start out
+ * as something meaningful.
+ */
+#define INIT_PAL_STATUS_UNIMPLEMENTED(x) \
+ { \
+ x.status = PAL_STATUS_UNIMPLEMENTED;\
+ x.v0 = 0; \
+ x.v1 = 0; \
+ x.v2 = 0; \
+ }
+
+#define INIT_PAL_STATUS_SUCCESS(x) \
+ { \
+ x.status = PAL_STATUS_SUCCESS; \
+ x.v0 = 0; \
+ x.v1 = 0; \
+ x.v2 = 0; \
+}
+
+static void kvm_get_pal_call_data(struct kvm_vcpu *vcpu,
+ u64 *gr28, u64 *gr29, u64 *gr30, u64 *gr31) {
+ struct exit_ctl_data *p;
+
+ if (vcpu) {
+ p = &vcpu->arch.exit_data;
+ if (p->exit_reason == EXIT_REASON_PAL_CALL) {
+ *gr28 = p->u.pal_data.gr28;
+ *gr29 = p->u.pal_data.gr29;
+ *gr30 = p->u.pal_data.gr30;
+ *gr31 = p->u.pal_data.gr31;
+ return ;
+ }
+ }
+ printk(KERN_DEBUG"Error occurs in kvm_get_pal_call_data!!\n");
+}
+
+static void set_pal_result(struct kvm_vcpu *vcpu,
+ struct ia64_pal_retval result) {
+
+ struct exit_ctl_data *p;
+
+ p = kvm_get_exit_data(vcpu);
+ if (p && p->exit_reason == EXIT_REASON_PAL_CALL) {
+ p->u.pal_data.ret = result;
+ return ;
+ }
+ INIT_PAL_STATUS_UNIMPLEMENTED(p->u.pal_data.ret);
+}
+
+static void set_sal_result(struct kvm_vcpu *vcpu,
+ struct sal_ret_values result) {
+ struct exit_ctl_data *p;
+
+ p = kvm_get_exit_data(vcpu);
+ if (p && p->exit_reason == EXIT_REASON_SAL_CALL) {
+ p->u.sal_data.ret = result;
+ return ;
+ }
+ printk(KERN_WARNING"Error occurs!!!\n");
+}
+
+struct cache_flush_args {
+ u64 cache_type;
+ u64 operation;
+ u64 progress;
+ long status;
+};
+
+cpumask_t cpu_cache_coherent_map;
+
+static void remote_pal_cache_flush(void *data)
+{
+ struct cache_flush_args *args = data;
+ long status;
+ u64 progress = args->progress;
+
+ status = ia64_pal_cache_flush(args->cache_type, args->operation,
+ &progress, NULL);
+ if (status != 0)
+ args->status = status;
+}
+
+static struct ia64_pal_retval pal_cache_flush(struct kvm_vcpu *vcpu)
+{
+ u64 gr28, gr29, gr30, gr31;
+ struct ia64_pal_retval result = {0, 0, 0, 0};
+ struct cache_flush_args args = {0, 0, 0, 0};
+ long psr;
+
+ gr28 = gr29 = gr30 = gr31 = 0;
+ kvm_get_pal_call_data(vcpu, &gr28, &gr29, &gr30, &gr31);
+
+ if (gr31 != 0)
+ printk(KERN_ERR"vcpu:%p called cache_flush error!\n",
vcpu);
+
+ /* Always call Host Pal in int=1 */
+ gr30 &= ~PAL_CACHE_FLUSH_CHK_INTRS;
+ args.cache_type = gr29;
+ args.operation = gr30;
+ smp_call_function(remote_pal_cac
[kvm-devel] [Patch][00/17] kvm-ia64 for kernel V6
Hi This patchset enables kvm on ia64 platform. And it targets for Avi's pull to mainline. Please review. If you don't have concerns, I will ask Avi's pull for kvm.git. Thanks! Also, you can get it from git://git.kernel.org/pub/scm/linux/kernel/git/xiantao/kvm-ia64.git kvm-ia64-mc6 Tony, The first two patches touches kernel code, please have a review again, and ensure it is good for kernel. Thanks:) Xiantao Documentation/ia64/kvm-howto.txt | 71 + arch/ia64/Kconfig|6 arch/ia64/Makefile |1 arch/ia64/kernel/mca.c | 50 arch/ia64/kernel/mca_asm.S |5 arch/ia64/kernel/smp.c | 84 + arch/ia64/kvm/Kconfig| 43 arch/ia64/kvm/Makefile | 61 + arch/ia64/kvm/asm-offsets.c | 251 arch/ia64/kvm/ia64_regs.h| 234 arch/ia64/kvm/kvm_fw.c | 500 + arch/ia64/kvm/kvm_ia64.c | 1789 arch/ia64/kvm/kvm_minstate.h | 273 arch/ia64/kvm/lapic.h| 27 arch/ia64/kvm/misc.h | 93 + arch/ia64/kvm/mmio.c | 349 ++ arch/ia64/kvm/optvfault.S| 918 arch/ia64/kvm/process.c | 979 + arch/ia64/kvm/trampoline.S | 1040 ++ arch/ia64/kvm/vcpu.c | 2145 +++ arch/ia64/kvm/vcpu.h | 749 + arch/ia64/kvm/vmm.c | 66 + arch/ia64/kvm/vmm_ivt.S | 1425 + arch/ia64/kvm/vti.h | 290 + arch/ia64/kvm/vtlb.c | 631 +++ arch/ia64/mm/tlb.c | 170 +++ include/asm-ia64/kregs.h |3 include/asm-ia64/kvm.h | 205 +++ include/asm-ia64/kvm_host.h | 530 + include/asm-ia64/kvm_para.h | 29 include/asm-ia64/tlb.h | 12 include/linux/smp.h |3 32 files changed, 13014 insertions(+), 18 deletions(-) - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] qemu: remove conflicting dependency to
remove dependency to the pci linux headers added since c10bf6159ff24501852c91a342c3077d5388b184 and that was generating the following conflict : qemu/hw/cirrus_vga.c:193:1: warning: "PCI_COMMAND_SERR" redefined In file included from /usr/include/linux/pci.h:21, from qemu/hw/pci.h:6, from qemu/hw/cirrus_vga.c:31: /usr/include/linux/pci_regs.h:40:1: warning: this is the location of the previous definition Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> --- qemu/hw/pci.h |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/qemu/hw/pci.h b/qemu/hw/pci.h index 036e914..60e4094 100644 --- a/qemu/hw/pci.h +++ b/qemu/hw/pci.h @@ -3,10 +3,12 @@ /* PCI includes legacy ISA access. */ #include "isa.h" -#include -/* PCI bus */ +/* imported from */ +#define PCI_SLOT(devfn) (((devfn) >> 3) & 0x1f) +#define PCI_FUNC(devfn) ((devfn) & 0x07) +/* PCI bus */ extern target_phys_addr_t pci_mem_base; typedef void PCIConfigWriteFunc(PCIDevice *pci_dev, -- 1.5.3.7 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] KVM Test result, kernel 2d38988.., userspace 64173d0.. -- One Issue fixed
Hi, all, This is today's KVM test result against kvm.git 2d3898859c4eafc8e67f805f38acae8f31bd24a4 and kvm-userspace.git 64173d009c1f4d163c425b14aa650df5b982428a. One issue fixed: 1. slab error in kmem_cache_destroy(): cache `kvm_vcpu': https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1925889&group_id=180599 Issue list 1. Booting four guests likely fails https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1919354&group_id=180599 2. booting smp windows guests has 30% chance of hang https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1910923&group_id=180599 Test environment PlatformWoodcrest CPU 4 Memory size 8G' Details IA32-pae: 1. boot guest with 256M memory PASS 2. boot two windows xp guest PASS 3. boot 4 same guest in parallelPASS 4. boot linux and windows guest in parallel PASS 5. boot guest with 1500M memory PASS 6. boot windows 2003 with ACPI enabled PASS 7. boot Windows xp with ACPI enabled PASS 8. boot Windows 2000 without ACPI PASS 9. kernel build on SMP linux guestPASS 10. LTP on SMP linux guest PASS 11. boot base kernel linux PASS 12. save/restore 32-bit HVM guests PASS 13. live migration 32-bit HVM guests PASS 14. boot SMP Windows xp with ACPI enabledPASS 15. boot SMP Windows 2003 with ACPI enabled PASS 16. boot SMP Windows 2000 with ACPI enabled PASS IA32e: 1. boot four 32-bit guest in parallel PASS 2. boot four 64-bit guest in parallel PASS 3. boot 4G 64-bit guest PASS 4. boot 4G pae guest PASS 5. boot 32-bit linux and 32 bit windows guest in parallelPASS 6. boot 32-bit guest with 1500M memory PASS 7. boot 64-bit guest with 1500M memory PASS 8. boot 32-bit guest with 256M memory PASS 9. boot 64-bit guest with 256M memory PASS 10. boot two 32-bit windows xp in parallelPASS 11. boot four 32-bit different guest in paraPASS 12. save/restore 64-bit linux guests PASS 13. save/restore 32-bit linux guests PASS 14. boot 32-bit SMP windows 2003 with ACPI enabled PASS 15. boot 32-bit SMP Windows 2000 with ACPI enabledPASS 16. boot 32-bit SMP Windows xp with ACPI enabledPASS 17. boot 32-bit Windows 2000 without ACPIPASS 18. boot 64-bit Windows xp with ACPI enabledPASS 19. boot 32-bit Windows xp without ACPIPASS 20. boot 64-bit UP vista PASS 21. boot 64-bit SMP vista PASS 22. kernel build in 32-bit linux guest OS PASS 23. kernel build in 64-bit linux guest OS PASS 24. LTP on SMP 32-bit linux guest OSPASS 25. LTP on SMP 64-bit linux guest OSPASS 26. boot 64-bit guests with ACPI enabled PASS 27. boot 32-bit x-server PASS 28. boot 64-bit SMP windows XP with ACPI enabled PASS 29. boot 64-bit SMP windows 2003 with ACPI enabled PASS 30. live migration 64bit linux guests PASS 31. live migration 32bit linux guests PASS 32. reboot 32bit windows xp guestPASS 33. reboot 32bit windows xp guest PASS Report Summary on IA32-pae Summary Test Report of Last Session = Total PassFailNoResult Crash = control_panel 7 7 0 00 Restart 2 2 0 00 gtest 15 14 1 00 ==
[kvm-devel] [PATCH] qemu: use ARRAY_SIZE macro as provided by osdep.h
included through "qemu-kvm.h" -> "cpu.h" -> "cpu-defs.h" for all architectures and resulting otherwise in : qemu/qemu-kvm-x86.c:23:1: warning: "ARRAY_SIZE" redefined In file included from ../cpu-defs.h:30, from qemu/target-i386/cpu.h:45, from ../qemu-common.h:62, from qemu/hw/hw.h:5, from qemu/qemu-kvm-x86.c:13: ../osdep.h:30:1: warning: this is the location of the previous definition Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> --- qemu/qemu-kvm-x86.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/qemu/qemu-kvm-x86.c b/qemu/qemu-kvm-x86.c index 78490c5..35fb535 100644 --- a/qemu/qemu-kvm-x86.c +++ b/qemu/qemu-kvm-x86.c @@ -20,8 +20,6 @@ #define MSR_IA32_TSC 0x10 -#define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0])) - static struct kvm_msr_list *kvm_msr_list; extern unsigned int kvm_shadow_memory; extern kvm_context_t kvm_context; -- 1.5.3.7 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 5/5] qemu: ARRAY_SIZE redefined
On Fri, Mar 28, 2008 at 10:04:21AM +0300, Avi Kivity wrote: > Carlo Marcelo Arenas Belon wrote: > >qemu/qemu-kvm-x86.c:23:1: warning: "ARRAY_SIZE" redefined > >In file included from ../cpu-defs.h:30, > > from > > > > /var/tmp/portage/app-emulation/kvm-64/work/kvm-64/qemu/target-i386/cpu.h:45, > > from ../qemu-common.h:62, > > from > > > > /var/tmp/portage/app-emulation/kvm-64/work/kvm-64/qemu/hw/hw.h:5, > > from > > > > /var/tmp/portage/app-emulation/kvm-64/work/kvm-64/qemu/qemu-kvm-x86.c:13: > >../osdep.h:30:1: warning: this is the location of the previous definition > > > >Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> > >--- > > qemu/qemu-kvm-x86.c |2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > >diff --git a/qemu/qemu-kvm-x86.c b/qemu/qemu-kvm-x86.c > >index 78490c5..ab91ff2 100644 > >--- a/qemu/qemu-kvm-x86.c > >+++ b/qemu/qemu-kvm-x86.c > >@@ -20,7 +20,9 @@ > > > > #define MSR_IA32_TSC0x10 > > > >+#ifndef ARRAY_SIZE > > #define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0])) > >+#endif > > > > static struct kvm_msr_list *kvm_msr_list; > > extern unsigned int kvm_shadow_memory; > > Why note remove the definition completely, and #include osdep.h instead? that was my first choice as there is not even a need to include osdep.h as it is already included and the source for this conflict. but ARRAY_SIZE is also defined in qemu in a mips file (mips-dis.c) and therefore assumed its current state was transitional and having it redefined as a fallback was safer until consolidated correctly upstream. Carlo - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
