[Xen-ia64-devel] [PATCH 0/2] ia64/pv_ops documentation and pv checker
Here is .S paravirtualization checker and the draft of the ia64/pv_ops documentation. These patches doesn't change kernel binary. [PATCH 1/2] ia64/pv_ops: paravirtualized istruction checker. [PATCH 2/2] ia64/pv_ops: documentation on ia64/pv_ops The pv checker patch is to show my idea. CPP trick doesn't work because some instructions includes .(dot) which CPP doesn't handle well. So I resorted to use sed in Makefile. Presumably the sed script should be moved into a separated file. Although the pv checker doesn't cover all the cases, I expect it can detect most cases. thanks, ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH 2/2] ia64/pv_ops: documentation on ia64/pv_ops
Documentation on ia64/pv_ops which describes its strategy and implementation. Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] --- Documentation/ia64/paravirt_ops.txt | 136 +++ 1 files changed, 136 insertions(+), 0 deletions(-) create mode 100644 Documentation/ia64/paravirt_ops.txt diff --git a/Documentation/ia64/paravirt_ops.txt b/Documentation/ia64/paravirt_ops.txt new file mode 100644 index 000..e835d6f --- /dev/null +++ b/Documentation/ia64/paravirt_ops.txt @@ -0,0 +1,136 @@ +Paravirt_ops on IA64 + + 21 May 2008, Isaku Yamahata [EMAIL PROTECTED] + + +Introduction + +The aim of this documentation is to help with maintainability and/or to +encourage people to use paravirt_ops/IA64. + +paravirt_ops (pv_ops in short) is a way for virtualization support of +Linux kernel on x86. Several ways for virtualization support were +proposed, paravirt_ops is the winner. +On the other hand there are several IA64 virtualization technologies like +kvm/IA64, xen/IA64 and many other academic IA64 hypervisors so that it is +good to add virtualization support on Linux/IA64. + + +What is paravirt_ops? +- +It has been developed on x86 as virtualization support via API, not ABI. +It allows each hypervisors to override operations which is important for +hypervisors at API level. And it allows single kernel binary to run on +all supported execution environments including native machine. +Essentially paravirt_ops is the set of table of function pointers and +operations correspond to from low level sensitive instructions to high +level functionalities in various area. But one significant difference +from usual function pointer table is that it allows optimization with +binary patch. It is because some operations corresponds to very low +level so that indirect call overhead isn't neglectable. +With binary patch, indirect C function call can be transformed into +direct C function call or in-place execution to eliminate the overhead. + +Thus, operations of paravirt_ops are classified into three categories. +- simple indirect call + The operations correspond to high level functionality so that the + overhead of indirect call isn't very important. + +- indirect call which allows optimization with binary patch + Usually the operations correspond to low level instructions so that + they are called so frequent and performance critical. So the + overhead is very important. + +- a set of macros for hand written assembly code + Hand written assembly codes (.S files) also need paravirtualization + because they include sensitive instructions or some of code paths in + them are very performance critical. + + +The relation to the IA64 machine vector +--- +Linux/IA64 has the IA64 machine vector functionality which allows the +kernel to switch implementations (e.g. initialization, ipi, dma api...) +depending on executing platform. +We can replace some implementations very easily defining new machine +vector. Thus another approach for virtualization support would be +enhancing the machine vector functionality. +But paravirt_ops approach was taken because +- virtualization support needs wider support then machine vector does. + e.g. low level instruction paravirtualization. It must be + initialized very early before platform detection. + +- virtualization support needs more functionality like binary patch. + Probably the calling overhead might not very large compared to the + emulation overhead of virtualization. However on native case, the + overhead should be eliminated completely. + Single kernel binary should run on each environment including native, + and the overhead of paravirt_ops on native environment should be as + small as possible. + +- for full virtualization technology, e.g. KVM/IA64 or + Xen/IA64 HVM domain, the result would be + (the emulated platform machine vector. probably dig) + (pv_ops). + This means that the virtualization support layer should be under + the machine vector layer. + +Possibly it might be better to move some function pointers from +paravirt_ops to machine vector. In fact xen domU case both pv_ops and +machine vector are utilized. + + +IA64 paravirt_ops +- +In this section, the concrete paravirt_ops will be discussed. +Because of the architecture difference between ia64 and x86, the +resulted set of functions is very different from x86 pv_ops. + +- C function pointer tables +They are not very performance critical part so that simple C indirect +function call is accepted. The following structures are defined at +this moment. For details see linux/include/asm-ia64/paravirt.h + - struct pv_info +A structure describes the execution environment. + - struct pv_init_ops +A structure describes the various initialization hooks. + - struct pv_iosapic_ops +A structure describes hooks to iosapic operations. + -
[Xen-ia64-devel] [RFC][PATCH] fix zero extending for mmio ld1/2/4 emulation
Recently Jes Soresen found a bug in kvm/ia64 mmio emulator. I believe xen/ia64 needs same bug fix, but I haven't confirmed the bug and the fix. Can anyone confirm this patch? # HG changeset patch # User Isaku Yamahata [EMAIL PROTECTED] # Date 1211356962 -32400 # Node ID 9b9a503239d60b3595c772d9337c4a217960a93e # Parent f04ce41dab843b275ccb6636290e51c591ac2a06 [IA64] fix zero extending for mmio ld1/2/4 emulation This bug was found by Jes Soresen with kvm/ia64 as follows. This patch is xen/ia64 counterpart. Only copy in the data actually requested by the instruction emulation and zero pad the destination register first. This avoids the problem where emulated mmio access got garbled data from ld2.acq instructions in the vga console driver. Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] diff --git a/xen/arch/ia64/vmx/mmio.c b/xen/arch/ia64/vmx/mmio.c --- a/xen/arch/ia64/vmx/mmio.c +++ b/xen/arch/ia64/vmx/mmio.c @@ -170,8 +170,9 @@ } vmx_send_assist_req(v); -if (dir == IOREQ_READ) -*val = p-data; +if (dir == IOREQ_READ) +/* it's necessary to ensure zero extending */ +*val = p-data (~0UL (64 - (s * 8))); return; } -- yamahata # HG changeset patch # User Isaku Yamahata [EMAIL PROTECTED] # Date 1211356962 -32400 # Node ID 9b9a503239d60b3595c772d9337c4a217960a93e # Parent f04ce41dab843b275ccb6636290e51c591ac2a06 [IA64] fix zero extending for mmio ld1/2/4 emulation This bug was found by Jes Soresen with kvm/ia64 as follows. This patch is xen/ia64 counterpart. Only copy in the data actually requested by the instruction emulation and zero pad the destination register first. This avoids the problem where emulated mmio access got garbled data from ld2.acq instructions in the vga console driver. Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] diff --git a/xen/arch/ia64/vmx/mmio.c b/xen/arch/ia64/vmx/mmio.c --- a/xen/arch/ia64/vmx/mmio.c +++ b/xen/arch/ia64/vmx/mmio.c @@ -170,8 +170,9 @@ } vmx_send_assist_req(v); -if (dir == IOREQ_READ) -*val = p-data; +if (dir == IOREQ_READ) +/* it's necessary to ensure zero extending */ +*val = p-data (~0UL (64 - (s * 8))); return; } ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [RFC][DRAFT] linux-2.6/Documentation/ia64/pv_ops.txt
Hi, Isaku and all
Thank you.
I could bootup paravirtualized domU with your dot config.
And some of /dev files are not copied properly.
/dev/console, /dev/null...
I re-made these by mknod, I could boot it.
I updated my recipe.
Isaku already has posted pv_ops.txt,
Do I had better add this recipe into other(xensource wiki
or xen-ia64 tree)?
Best Regards,
Akio Takebe
---
Recipe for getting/building/running Xen/ia64 with pv_ops
This recipe discribes how to get xen-ia64 source and build it,
and run domU with pv_ops.
===
Requirement
===
- python
- mercurial
it (aka hg) is a open-source source code
management software. See the below.
http://www.selenic.com/mercurial/wiki/
- git
- bridge-utils
=
Getting and Building Xen and Dom0
=
My enviroment is;
Machine : Tiger4
Domain0 OS : RHEL5
DomainU OS : RHEL5
1. Download source
# hg clone http://xenbits.xensource.com/ext/ia64/xen-unstable.hg
# cd xen-unstable.hg
# hg clone http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg
2. # make world
3. # make install-tools
4. copy kernels and xen
# cp xen/xen.gz /boot/efi/efi/redhat/
# cp build-linux-2.6.18-xen_ia64/vmlinux.gz \
/boot/efi/efi/redhat/vmlinuz-2.6.18.8-xen
5. make initrd for Dom0/DomU
# make -C linux-2.6.18-xen.hg ARCH=ia64 modules_install \
O=$(/bin/pwd)/build-linux-2.6.18-xen_ia64
# mkinitrd -f /boot/efi/efi/redhat/initrd-2.6.18.8-xen.img \
2.6.18.8-xen --builtin mptspi --builtin mptbase \
--builtin mptscsih --builtin uhci-hcd --builtin ohci-hcd \
--builtin ehci-hcd
Making a disk image for guest OS
1. make file
# dd if=/dev/zero of=/root/rhel5.img bs=1M seek=4096 count=0
# mke2fs -F -j /root/rhel5.img
# mount -o loop /root/rhel5.img /mnt
# cp -ax /{dev,var,etc,usr,bin,sbin,lib} /mnt
# mkdir /mnt/{root,proc,sys,home,tmp}
NOTE:Some device files may not be copied properly.
In the case of that, you should make these manually with mknod.
2. modify DomU's fstab
# vi /mnt/etc/fstab
/dev/xvda1 /ext3defaults1 1
none/dev/pts devpts gid=5,mode=620 0 0
none/dev/shm tmpfs defaults0 0
none/procprocdefaults0 0
none/sys sysfs defaults0 0
3. modify inittab
set runlevel to 3 to avoid X trying to start
# vi /mnt/etc/inittab
id:3:initdefault:
Start a getty on the hvc0 console
X0:2345:respawn:/sbin/mingetty hvc0
tty1-6 mingetty can be commented out
4. add hvc0 into /etc/securetty
# vi /mnt/etc/securetty (add hvc0)
5. umount
# umount /mnt
FYI, virt-manager can also make a disk image for guest OS.
It's GUI tools and easy to make it.
==
Boot Xen Domain0
==
1. replace elilo
elilo of RHEL5 can boot Xen and Dom0.
If you use old elilo (e.g RHEL4), please download from the below
http://elilo.sourceforge.net/cgi-bin/blosxom
and copy into /boot/efi/efi/redhat/
# cp elilo-3.6-ia64.efi /boot/efi/efi/redhat/elilo.efi
2. modify elilo.conf (like the below)
# vi /boot/efi/efi/redhat/elilo.conf
prompt
timeout=20
default=xen
relocatable
image=vmlinuz-2.6.18.8-xen
label=xen
vmm=xen.gz
initrd=initrd-2.6.18.8-xen.img
read-only
append= -- rhgb root=/dev/sda2
The append options before -- are for xen hypervisor,
the options after -- are for dom0.
FYI, your machine may need console options like
com1=19200,8n1 console=vga,com1. For example,
append=com1=19200,8n1 console=vga,com1 -- rhgb console=tty0 \
console=ttyS0 root=/dev/sda2
=
Getting and Building domU with pv_ops
=
1. get pv_ops tree
# git clone
http://people.valinux.co.jp/~yamahata/xen-ia64/linux-2.6-xen-ia64.git/
2. git branch (if necessary)
# cd linux-2.6-xen-ia64/
# git checkout -b your_branch origin/xen-ia64-domu-minimal-2008may19
(you can see git branch -r to get the branch lists.)
3. copy .config for pv_ops of domU
# cp arch/ia64/configs/xen_domu_wip_defconfig .config
4. make kernel with pv_ops
# make oldconfig
# make
5. install the kernel and initrd
# cp vmlinux.gz /boot/efi/efi/redhat/vmlinuz-2.6-pv_ops-xenU
# make modules_install
# mkinitrd -f /boot/efi/efi/redhat/initrd-2.6-pv_ops-xenU.img \
2.6.26-rc3xen-ia64-08941-g1b12161 --builtin mptspi --builtin
mptbase \
--builtin mptscsih --builtin uhci-hcd --builtin ohci-hcd \
--builtin ehci-hcd
Boot DomainU with pv_ops
1. make
Re: [Xen-ia64-devel] [RFC][DRAFT] linux-2.6/Documentation/ia64/pv_ops.txt
On Wed, May 21, 2008 at 05:45:55PM +0900, Akio Takebe wrote: Isaku already has posted pv_ops.txt, Do I had better add this recipe into other(xensource wiki or xen-ia64 tree)? My document describes about pv_op itself, on the other hand your document describes how to boot xen domU. So I suppose that it should be Documentation/ia64/xen.txt or something like that. -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [RFC][DRAFT] linux-2.6/Documentation/ia64/pv_ops.txt
Some inlined comment.
On Wed, May 21, 2008 at 05:45:55PM +0900, Akio Takebe wrote:
Hi, Isaku and all
Thank you.
I could bootup paravirtualized domU with your dot config.
And some of /dev files are not copied properly.
/dev/console, /dev/null...
I re-made these by mknod, I could boot it.
I updated my recipe.
Isaku already has posted pv_ops.txt,
Do I had better add this recipe into other(xensource wiki
or xen-ia64 tree)?
Best Regards,
Akio Takebe
---
Recipe for getting/building/running Xen/ia64 with pv_ops
This recipe discribes how to get xen-ia64 source and build it,
and run domU with pv_ops.
===
Requirement
===
- python
- mercurial
it (aka hg) is a open-source source code
management software. See the below.
http://www.selenic.com/mercurial/wiki/
- git
- bridge-utils
=
Getting and Building Xen and Dom0
=
My enviroment is;
Machine : Tiger4
Domain0 OS : RHEL5
DomainU OS : RHEL5
1. Download source
# hg clone http://xenbits.xensource.com/ext/ia64/xen-unstable.hg
# cd xen-unstable.hg
# hg clone http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg
2. # make world
3. # make install-tools
4. copy kernels and xen
# cp xen/xen.gz /boot/efi/efi/redhat/
# cp build-linux-2.6.18-xen_ia64/vmlinux.gz \
/boot/efi/efi/redhat/vmlinuz-2.6.18.8-xen
5. make initrd for Dom0/DomU
# make -C linux-2.6.18-xen.hg ARCH=ia64 modules_install \
O=$(/bin/pwd)/build-linux-2.6.18-xen_ia64
# mkinitrd -f /boot/efi/efi/redhat/initrd-2.6.18.8-xen.img \
2.6.18.8-xen --builtin mptspi --builtin mptbase \
--builtin mptscsih --builtin uhci-hcd --builtin ohci-hcd \
--builtin ehci-hcd
Making a disk image for guest OS
1. make file
# dd if=/dev/zero of=/root/rhel5.img bs=1M seek=4096 count=0
# mke2fs -F -j /root/rhel5.img
# mount -o loop /root/rhel5.img /mnt
# cp -ax /{dev,var,etc,usr,bin,sbin,lib} /mnt
# mkdir /mnt/{root,proc,sys,home,tmp}
NOTE:Some device files may not be copied properly.
In the case of that, you should make these manually with mknod.
How about using tar instead of cp?
2. modify DomU's fstab
# vi /mnt/etc/fstab
/dev/xvda1 /ext3defaults1 1
none/dev/pts devpts gid=5,mode=620 0 0
none/dev/shm tmpfs defaults0 0
none/procprocdefaults0 0
none/sys sysfs defaults0 0
3. modify inittab
set runlevel to 3 to avoid X trying to start
# vi /mnt/etc/inittab
id:3:initdefault:
Start a getty on the hvc0 console
X0:2345:respawn:/sbin/mingetty hvc0
tty1-6 mingetty can be commented out
4. add hvc0 into /etc/securetty
# vi /mnt/etc/securetty (add hvc0)
5. umount
# umount /mnt
FYI, virt-manager can also make a disk image for guest OS.
It's GUI tools and easy to make it.
==
Boot Xen Domain0
==
1. replace elilo
elilo of RHEL5 can boot Xen and Dom0.
If you use old elilo (e.g RHEL4), please download from the below
http://elilo.sourceforge.net/cgi-bin/blosxom
and copy into /boot/efi/efi/redhat/
# cp elilo-3.6-ia64.efi /boot/efi/efi/redhat/elilo.efi
2. modify elilo.conf (like the below)
# vi /boot/efi/efi/redhat/elilo.conf
prompt
timeout=20
default=xen
relocatable
image=vmlinuz-2.6.18.8-xen
label=xen
vmm=xen.gz
initrd=initrd-2.6.18.8-xen.img
read-only
append= -- rhgb root=/dev/sda2
The append options before -- are for xen hypervisor,
the options after -- are for dom0.
FYI, your machine may need console options like
com1=19200,8n1 console=vga,com1. For example,
append=com1=19200,8n1 console=vga,com1 -- rhgb console=tty0 \
console=ttyS0 root=/dev/sda2
=
Getting and Building domU with pv_ops
=
1. get pv_ops tree
# git clone
http://people.valinux.co.jp/~yamahata/xen-ia64/linux-2.6-xen-ia64.git/
2. git branch (if necessary)
# cd linux-2.6-xen-ia64/
# git checkout -b your_branch origin/xen-ia64-domu-minimal-2008may19
(you can see git branch -r to get the branch lists.)
The current branch is surely xen-ia64-domu-minimal-2008may19.
But in future the new branch would be created. So please warn it here.
3. copy .config for pv_ops of domU
# cp arch/ia64/configs/xen_domu_wip_defconfig .config
4. make kernel with pv_ops
# make oldconfig
# make
5. install the kernel and initrd
RE: [Xen-ia64-devel] [RFC][PATCH] fix zero extending for mmio ld1/2/4emulation
Hi Isaku,
Before copying value ( *val=p-data),
The code sets p-data to 0,( p-data=0)
I think this can avoid the issue Jes found in KVM/IA64.
Anthony
if (dir == IOREQ_WRITE)
p-data = *val;
else
p-data = 0;
p-data_is_ptr = 0;
p-dir = dir;
p-df = 0;
p-type = 1;
p-io_count++;
if (hvm_buffered_io_intercept(p)) {
p-state = STATE_IORESP_READY;
vmx_io_assist(v);
if (dir != IOREQ_READ)
return;
}
vmx_send_assist_req(v);
if (dir == IOREQ_READ)
*val = p-data;
Isaku Yamahata wrote:
Recently Jes Soresen found a bug in kvm/ia64 mmio emulator.
I believe xen/ia64 needs same bug fix, but I haven't confirmed
the bug and the fix.
Can anyone confirm this patch?
# HG changeset patch
# User Isaku Yamahata [EMAIL PROTECTED]
# Date 1211356962 -32400
# Node ID 9b9a503239d60b3595c772d9337c4a217960a93e
# Parent f04ce41dab843b275ccb6636290e51c591ac2a06
[IA64] fix zero extending for mmio ld1/2/4 emulation
This bug was found by Jes Soresen with kvm/ia64 as follows.
This patch is xen/ia64 counterpart.
Only copy in the data actually requested by the instruction emulation
and zero pad the destination register first. This avoids the problem
where emulated mmio access got garbled data from ld2.acq instructions
in the vga console driver.
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff --git a/xen/arch/ia64/vmx/mmio.c b/xen/arch/ia64/vmx/mmio.c
--- a/xen/arch/ia64/vmx/mmio.c
+++ b/xen/arch/ia64/vmx/mmio.c
@@ -170,8 +170,9 @@
}
vmx_send_assist_req(v);
-if (dir == IOREQ_READ)
-*val = p-data;
+if (dir == IOREQ_READ)
+/* it's necessary to ensure zero extending */
+*val = p-data (~0UL (64 - (s * 8)));
return;
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] zero extend I/O reads
Jes Sorensen debugged an issue recently on KVM that a ld2.acq was
getting sign extended in the I/O emulation path[1][2]. This was exposed
by the VGA console hanging due to some benign looking changes to the VGA
console structure several kernel revisions back. I remember seeing this
on Xen, but I've lost the recipe to reproduce it. I believe the
following patch adds the same logic that is being incorporated for KVM,
but I'm unable to prove we're hitting the same issue since I can no
longer reproduce it. Please review and apply if it looks right.
Thanks,
Alex
[1] http://marc.info/?t=12111893401
[2] http://marc.info/?t=12112784858
[IA64] zero pad emulated I/O instructions
Fixes issue seen on KVM with more recent upstream changes to the VGA
console structure.
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
--
diff -r f04ce41dab84 xen/arch/ia64/vmx/mmio.c
--- a/xen/arch/ia64/vmx/mmio.c Tue May 20 18:54:09 2008 +0900
+++ b/xen/arch/ia64/vmx/mmio.c Wed May 21 13:02:27 2008 -0600
@@ -171,7 +171,7 @@ static void low_mmio_access(VCPU *vcpu,
vmx_send_assist_req(v);
if (dir == IOREQ_READ)
-*val = p-data;
+*val = p-data (~0UL (BITS_PER_LONG - (s * 8)));
return;
}
@@ -340,7 +340,7 @@ static void legacy_io_access(VCPU *vcpu,
vmx_send_assist_req(v);
if (dir == IOREQ_READ) { // read
-*val=p-data;
+*val = p-data (~0UL (BITS_PER_LONG - (s * 8)));
}
#ifdef DEBUG_PCI
if (dir == IOREQ_WRITE)
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH 2/2] ia64/pv_ops: documentation on ia64/pv_ops
On Wed, May 21, 2008 at 03:28:57PM +0200, Gerald Pfeifer wrote: On Wed, 21 May 2008, Isaku Yamahata wrote: Documentation on ia64/pv_ops which describes its strategy and implementation. I hope you do not mind if I make some minor suggestions on how to improve this nice documentation? Thank you very much for fixing my bad english. Here is the updated one. From 549c9ed78e671432bc084e7c8829c0400c42518a Mon Sep 17 00:00:00 2001 From: Isaku Yamahata [EMAIL PROTECTED] Date: Wed, 21 May 2008 16:05:24 +0900 Subject: [PATCH] ia64/pv_ops: documentation on ia64/pv_ops Documentation on ia64/pv_ops which describes its strategy and implementation. Signed-off-by: Isaku Yamahata [EMAIL PROTECTED] Cc: Gerald Pfeifer [EMAIL PROTECTED] --- Documentation/ia64/paravirt_ops.txt | 137 +++ 1 files changed, 137 insertions(+), 0 deletions(-) create mode 100644 Documentation/ia64/paravirt_ops.txt diff --git a/Documentation/ia64/paravirt_ops.txt b/Documentation/ia64/paravirt_ops.txt new file mode 100644 index 000..39ded02 --- /dev/null +++ b/Documentation/ia64/paravirt_ops.txt @@ -0,0 +1,137 @@ +Paravirt_ops on IA64 + + 21 May 2008, Isaku Yamahata [EMAIL PROTECTED] + + +Introduction + +The aim of this documentation is to help with maintainability and/or to +encourage people to use paravirt_ops/IA64. + +paravirt_ops (pv_ops in short) is a way for virtualization support of +Linux kernel on x86. Several ways for virtualization support were +proposed, paravirt_ops is the winner. +On the other hand, now there are also several IA64 virtualization +technologies like kvm/IA64, xen/IA64 and many other academic IA64 +hypervisors so that it is good to add generic virtualization +infrastructure on Linux/IA64. + + +What is paravirt_ops? +- +It has been developed on x86 as virtualization support via API, not ABI. +It allows each hypervisor to override operations which are important for +hypervisors at API level. And it allows a single kernel binary to run on +all supported execution environments including native machine. +Essentially paravirt_ops is a set of function pointers which represent +operations corresponding to low level sensitive instructions and high +level functionalities in various area. But one significant difference +from usual function pointer table is that it allows optimization with +binary patch. It is because some of these operations are very +performance sensitive and indirect call overhead is not negligible. +With binary patch, indirect C function call can be transformed into +direct C function call or in-place execution to eliminate the overhead. + +Thus, operations of paravirt_ops are classified into three categories. +- simple indirect call + These operations correspond to high level functionality so that the + overhead of indirect call isn't very important. + +- indirect call which allows optimization with binary patch + Usually these operations correspond to low level instructions. They + are called frequently and performance critical. So the overhead is + very important. + +- a set of macros for hand written assembly code + Hand written assembly codes (.S files) also need paravirtualization + because they include sensitive instructions or some of code paths in + them are very performance critical. + + +The relation to the IA64 machine vector +--- +Linux/IA64 has the IA64 machine vector functionality which allows the +kernel to switch implementations (e.g. initialization, ipi, dma api...) +depending on executing platform. +We can replace some implementations very easily defining a new machine +vector. Thus another approach for virtualization support would be +enhancing the machine vector functionality. +But paravirt_ops approach was taken because +- virtualization support needs wider support than machine vector does. + e.g. low level instruction paravirtualization. It must be + initialized very early before platform detection. + +- virtualization support needs more functionality like binary patch. + Probably the calling overhead might not be very large compared to the + emulation overhead of virtualization. However in the native case, the + overhead should be eliminated completely. + A single kernel binary should run on each environment including native, + and the overhead of paravirt_ops on native environment should be as + small as possible. + +- for full virtualization technology, e.g. KVM/IA64 or + Xen/IA64 HVM domain, the result would be + (the emulated platform machine vector. probably dig) + (pv_ops). + This means that the virtualization support layer should be under + the machine vector layer. + +Possibly it might be better to move some function pointers from +paravirt_ops to machine vector. In fact, Xen domU case utilizes both +pv_ops and machine vector. + + +IA64 paravirt_ops +- +In this section, the
[Xen-ia64-devel] Re: [patch] fix zero extending for mmio ld1/2/4 emulation in KVM
Hi Jes.
Good catch.
I thought similar fix is necessary for xen/ia64 and checked the code.
It was fixed differently. I think the unnecessary divergence is undesirable.
What do you think the following fix according?
Only copy in the data actually requested by the instruction emulation
and zero pad the destination register first. This avoids the problem
where emulated mmio access got garbled data from ld2.acq instructions
in the vga console driver.
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
Cc: Jes Sorensen [EMAIL PROTECTED]
diff --git a/arch/ia64/kvm/mmio.c b/arch/ia64/kvm/mmio.c
index 351bf70..e6f194a 100644
--- a/arch/ia64/kvm/mmio.c
+++ b/arch/ia64/kvm/mmio.c
@@ -154,6 +154,9 @@ static void mmio_access(struct kvm_vcpu *vcpu, u64 src_pa,
u64 *dest,
p-u.ioreq.dir = dir;
if (dir == IOREQ_WRITE)
p-u.ioreq.data = *dest;
+ else
+ /* it's necessary to ensure zero extending */
+ p-u.ioreq.data = 0;
p-u.ioreq.state = STATE_IOREQ_READY;
vmm_transition(vcpu);
On Tue, May 20, 2008 at 01:13:50PM +0200, Jes Sorensen wrote:
Matthew Chapman wrote:
Jes,
Glad you tracked it down. Can I suggest rather than using memcpy, a
more efficient way might be something like...
#define ZERO_EXTEND(x,bits) ((x) (~0UL (64-(bits
*dest = ZERO_EXTEND(p-u.ioreq.data, 8*s);
Much nicer indeed!
Here's a pretty version - Tony will you apply this one instead.
Cheers,
Jes
Only copy in the data actually requested by the instruction emulation
and zero pad the destination register first. This avoids the problem
where emulated mmio access got garbled data from ld2.acq instructions
in the vga console driver.
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
---
arch/ia64/kvm/mmio.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6.git/arch/ia64/kvm/mmio.c
===
--- linux-2.6.git.orig/arch/ia64/kvm/mmio.c
+++ linux-2.6.git/arch/ia64/kvm/mmio.c
@@ -159,7 +159,8 @@
if (p-u.ioreq.state == STATE_IORESP_READY) {
if (dir == IOREQ_READ)
- *dest = p-u.ioreq.data;
+ /* it's necessary to ensure zero extending */
+ *dest = p-u.ioreq.data (~0UL (64-(s*8)));
} else
panic_vm(vcpu);
out:
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] zero extend I/O reads
Hi Alex. I digged into log and found the two commits as below. I think they fixed the issue. So I guess you encountered the issue before committing the c/s 16180:62a7a2f4d9c7. They are several mounths before, so memory might be vague... changeset: 16284:7eb68d995aa7 user:Keir Fraser [EMAIL PROTECTED] date:Tue Oct 30 16:25:58 2007 + files: xen/arch/ia64/vmx/mmio.c description: ia64: Fix after stdvga performance changes to bufioreq struct. Signed-off-by: Alex Williamson [EMAIL PROTECTED] -- changeset: 16180:62a7a2f4d9c7 user:Alex Williamson [EMAIL PROTECTED] date:Mon Oct 22 12:30:17 2007 -0600 files: xen/arch/ia64/vmx/mmio.c description: [IA64] Fix MMIO readb operation We should do clean before read operation. Otherwise, read one byte data may get garbage data sometimes. Signed-off-by: Zhang Xin [EMAIL PROTECTED] diff -r ecbda3783c85 -r 62a7a2f4d9c7 xen/arch/ia64/vmx/mmio.c --- a/xen/arch/ia64/vmx/mmio.c Mon Oct 22 12:26:53 2007 -0600 +++ b/xen/arch/ia64/vmx/mmio.c Mon Oct 22 12:30:17 2007 -0600 @@ -120,6 +120,8 @@ p-dir = dir; if (dir==IOREQ_WRITE) // write; p-data = *val; +else if (dir == IOREQ_READ) +p-data = 0; // clear all bits p-data_is_ptr = 0; p-type = 1; p-df = 0; On Wed, May 21, 2008 at 01:17:24PM -0600, Alex Williamson wrote: Jes Sorensen debugged an issue recently on KVM that a ld2.acq was getting sign extended in the I/O emulation path[1][2]. This was exposed by the VGA console hanging due to some benign looking changes to the VGA console structure several kernel revisions back. I remember seeing this on Xen, but I've lost the recipe to reproduce it. I believe the following patch adds the same logic that is being incorporated for KVM, but I'm unable to prove we're hitting the same issue since I can no longer reproduce it. Please review and apply if it looks right. Thanks, Alex [1] http://marc.info/?t=12111893401 [2] http://marc.info/?t=12112784858 [IA64] zero pad emulated I/O instructions Fixes issue seen on KVM with more recent upstream changes to the VGA console structure. Signed-off-by: Alex Williamson [EMAIL PROTECTED] -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] zero extend I/O reads
On Thu, 2008-05-22 at 12:51 +0900, Isaku Yamahata wrote: Hi Alex. I digged into log and found the two commits as below. I think they fixed the issue. So I guess you encountered the issue before committing the c/s 16180:62a7a2f4d9c7. They are several mounths before, so memory might be vague... Hi Isaku, Good, thanks for tracking down the mystery of why it got fixed. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
