[Xen-ia64-devel] Re: GFW and startup
Quoting Isaku Yamahata [EMAIL PROTECTED]: Hi. I have a question about GFW startup procedure. Although I don't fully understand tianocore liking mechanism, efi-vfirmware.hg/edk2-sparse/EdkXenPkg/SecMain/Ipf/startup.s is compiled into startup.bin and is symbolic linked as ResetVect.cat. Finally it is placed in ROM area and _start is executed in place. Is the above correct? Yes, this is correct. If so, Is using [_stack_start, _stack_end) as stack correct? Why not! The ROM area is in RAM. We of course need a stack to execute C code. On iron-board, we could use CAR (Cache As Ram). But this is not possible with Xen. However, the ROM area is not write-only. So we could use it. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH][GFW] fix EFI_SAL_SET_VECTORS
Hi Isaku,
this is OK.
Tristan.
Quoting Isaku Yamahata [EMAIL PROTECTED]:
# HG changeset patch
# User Isaku Yamahata [EMAIL PROTECTED]
# Date 1210731778 -32400
# Node ID c7e929cfb87aa4c505eecae2746d61e1226d8a90
# Parent ececa5a5473be16d416cfb675d3a6bf338d7db4c
fix EFI_SAL_SET_VECTORS
While booting recent Linux kernel under VTi domain with the latest
open gfw, it panics as following.
Linux kernel calls sal call of
(EFI_SAL_SET_VECTORS, EFI_SAL_SET_INIT_VECTOR) and the gfw accesses
the invalid address.
The uncached physical addresses are hard coded, but they aren't
relocated when switching to virtual address mode.
And calling xen sal hypercall looks copy and past typo.
Unable to handle kernel paging request at virtual address
8000ff80
swapper[0]: Oops 8804682956800 [1]
Modules linked in:
Pid: 0, CPU 0, comm: swapper
psr : 1010084a2010 ifs : 80001634 ip :
[ef1479e0]Not tainted
(2.6.26-rc1xen-ia64-08245-g59409b5-dirt(XEN) paddr_to_maddr: called
with bad memory address: 0x74138100 - iip=a001000660c0
ip is at 0xef1479e0
unat: pfs : 091a rsc : 0003
rnat: 0005 bsps: pr : 0002aa49
ldrs: ccv : fpsr: 0009804c8a70433f
csd : ssd :
b0 : a0010075e3f0 b6 : a00100052100 b7 : ef147620
f6 : 0 f7 : 0
f8 : 0 f9 : 0
f10 : 0 f11 : 0
r1 : ef152020 r2 : 0001 r3 : 040d
r8 : r9 : 040c r10 : a00100052100
r11 : a00100958708 r12 : a00100943bd0 r13 : a0010093c000
r14 : 8000ff80 r15 : ef152130 r16 : ef152138
r17 : a00100731948 r18 : a00100052100 r19 : a001009b23b8
r20 : a001009ed548 r21 : dead4ead r22 : a00100958704
r23 : r24 : a00100a07518 r25 : ef147620
r26 : a001009ee038 r27 : a00100731948 r28 : a00100052100
r29 : a00100731948 r30 : a00100052100 r31 :
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff --git a/edk2-sparse/EdkXenPkg/Dxe/XenSal/Sal.c
b/edk2-sparse/EdkXenPkg/Dxe/XenSal/Sal.c
--- a/edk2-sparse/EdkXenPkg/Dxe/XenSal/Sal.c
+++ b/edk2-sparse/EdkXenPkg/Dxe/XenSal/Sal.c
@@ -8,8 +8,8 @@
UINT64 Gp;
} SalRendezVector;
-struct Fptr *SalMonarchInitVector = (struct Fptr *)0x8000ff80;
-struct Fptr *SalSlaveInitVector = (struct Fptr *)0x8000ff90 ;
+struct Fptr *SalMonarchInitVector = (struct Fptr *)0xff80;
+struct Fptr *SalSlaveInitVector = (struct Fptr *)0xff90 ;
STATIC
EFI_SAL_STATUS
@@ -136,3 +136,23 @@
}
return (SAL_RETURN_REGS) {status, r9, r10, r11};
}
+
+VOID
+EFIAPI
+SalProcAddressChangeEvent (
+ IN EFI_EVENTEvent,
+ IN VOID *Context
+ )
+/*++
+
+Routine Description:
+
+Arguments:
+
+Returns:
+
+--*/
+{
+ EfiConvertPointer (0x0, (VOID **) SalMonarchInitVector);
+ EfiConvertPointer (0x0, (VOID **) SalSlaveInitVector);
+}
diff --git a/edk2-sparse/EdkXenPkg/Dxe/XenSal/XenSal.msa
b/edk2-sparse/EdkXenPkg/Dxe/XenSal/XenSal.msa
--- a/edk2-sparse/EdkXenPkg/Dxe/XenSal/XenSal.msa
+++ b/edk2-sparse/EdkXenPkg/Dxe/XenSal/XenSal.msa
@@ -65,5 +65,8 @@
Extern
ModuleEntryPointXenSalInitialize/ModuleEntryPoint
/Extern
+Extern
+
SetVirtualAddressMapCallBackSalProcAddressChangeEvent/SetVirtualAddressMapCallBack
+/Extern
/Externs
/ModuleSurfaceArea
\ No newline at end of file
--
yamahata
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH][GFW] allocate xen vram area and tell xen pci chip.
Quoting Isaku Yamahata [EMAIL PROTECTED]:
allocate xen vram area and tell xen pci chip.
This is GFW counter part of xen-unstable 18383:dade7f0bdc8d.
Hi Isaku,
this looks to be slightly over-complex. Why not programming the VGA
inside VgaInit ?
BTW, you don't need to look for the PciIo protocol. Just use one of the
PciIoLib.
Tristan.
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
diff -r 830ed5449dd4
edk2-sparse/EdkQemuPkg/Chipset/PcCompatible/VgaInit/Dxe/VgaInit.c
--- a/edk2-sparse/EdkQemuPkg/Chipset/PcCompatible/VgaInit/Dxe/VgaInit.c
Wed
May 14 11:22:58 2008 +0900
+++ b/edk2-sparse/EdkQemuPkg/Chipset/PcCompatible/VgaInit/Dxe/VgaInit.c
Wed
Sep 10 17:32:02 2008 +0900
@@ -34,7 +34,7 @@
Digital Equipment Corporation
*/
-#include VgaBios.h
+#include VgaBios.h
extern const unsigned char console_font[];
static const unsigned int palette[] = {
diff -r 830ed5449dd4 edk2-sparse/EdkXenPkg/Dxe/Bds/Bds.msa
--- a/edk2-sparse/EdkXenPkg/Dxe/Bds/Bds.msa Wed May 14 11:22:58 2008 +0900
+++ b/edk2-sparse/EdkXenPkg/Dxe/Bds/Bds.msa Wed Sep 10 17:32:02 2008 +0900
@@ -57,6 +57,9 @@
KeywordEdkGenericPlatformBdsLib/Keyword
/LibraryClass
LibraryClass Usage=ALWAYS_CONSUMED
+ KeywordIoLib/Keyword
+/LibraryClass
+LibraryClass Usage=ALWAYS_CONSUMED
KeywordPcdLib/Keyword
/LibraryClass
/LibraryClassDefinitions
@@ -110,5 +113,17 @@
DefaultValue0xF0/DefaultValue
HelpTextDevices for default console. 0x01: com1, 0x02: com2, 0x10:
kbd, 0x20: vga/HelpText
/PcdEntry
+PcdEntry PcdItemType=FEATURE_FLAG Usage=ALWAYS_CONSUMED
+ C_NamePcdVgaInitAtBoot/C_Name
+ TokenSpaceGuidCNamegEfiEdkQemuTokenSpaceGuid/TokenSpaceGuidCName
+ DefaultValueTRUE/DefaultValue
+ HelpTextInitialise in text mode the Vga at module boot/HelpText
+/PcdEntry
+PcdEntry PcdItemType=FEATURE_FLAG Usage=ALWAYS_CONSUMED
+ C_NamePcdVgaInitAtExit/C_Name
+ TokenSpaceGuidCNamegEfiEdkQemuTokenSpaceGuid/TokenSpaceGuidCName
+ DefaultValueFALSE/DefaultValue
+ HelpTextInitialise in text mode the Vga at module exit/HelpText
+/PcdEntry
/PcdCoded
-/ModuleSurfaceArea
\ No newline at end of file
+/ModuleSurfaceArea
diff -r 830ed5449dd4 edk2-sparse/EdkXenPkg/Dxe/Bds/BdsPlatform.c
--- a/edk2-sparse/EdkXenPkg/Dxe/Bds/BdsPlatform.c Wed May 14 11:22:58 2008
+0900
+++ b/edk2-sparse/EdkXenPkg/Dxe/Bds/BdsPlatform.c Wed Sep 10 17:32:02 2008
+0900
@@ -633,6 +633,89 @@
return EFI_SUCCESS;
}
+//
+// PCI Xen device
+//
+#include ../../../EdkQemuPkg/Chipset/PcCompatible/VgaInit/Dxe/VgaInit.c
+#include ../../../EdkQemuPkg/Chipset/PcCompatible/VgaInit/Dxe/Font.c
+
+STATIC VOID
+__InitializeVga (VOID)
+{
+ InitializeVga (NULL, NULL);
+}
+
+#define XEN_PLATFORM_VENDOR_ID 0x5853
+#define XEN_PLATFORM_DEVICE_ID 0x0001
+
+// See if the device is an enabled XEN device.
+#define IS_PCI_XEN_PLATFORM(Pci) \
+ ((Pci)-Hdr.VendorId == XEN_PLATFORM_VENDOR_ID \
+ (Pci)-Hdr.DeviceId == XEN_PLATFORM_DEVICE_ID)
+
+#define XEN_PAGE_SIZE(16 * 1024)
+#define VGA_RAM_SIZE (8192 * 1024)
+// Round up to XEN_PAGE_SIZE
+#define VGA_RAM_PAGES(((VGA_RAM_SIZE + (XEN_PAGE_SIZE - 1)) /
XEN_PAGE_SIZE) * XEN_PAGE_SIZE) / (4 * 1024)
+
+//
+// Use BAR 0
+// Offset 4 bytes
+//
+#define XEN_BAR_INDEX0
+#define XEN_VGA_OFFSET 4
+
+STATIC VOID
+PreparePciXenDevicePath (
+ IN EFI_PCI_IO_PROTOCOL *PciIo
+ )
+{
+ STATIC BOOLEAN Initialized = FALSE;
+ VOID *VgaRam = NULL;
+ UINT64 Data64;
+ UINT32 Data32;
+ EFI_STATUSStatus;
+
+
+ if (Initialized)
+return;
+
+ //
+ // XXX: exclusion. only once.
+ //
+ VgaRam = AllocateAlignedReservedPages (VGA_RAM_PAGES, XEN_PAGE_SIZE);
+ if (VgaRam == NULL) {
+return;
+ }
+ ZeroMem (VgaRam, VGA_RAM_PAGES * 4 * 1024);
+
+ Data64 = (UINT64)VgaRam;
+ Data32 = (UINT32)VgaRam;
+ if (Data64 == Data32) {
+//
+// At this moment, 32bit is only supported by qemu-dm
+//
+Status = PciIo-Io.Write (
+ PciIo,
+ EfiPciIoWidthUint32,
+ XEN_BAR_INDEX,
+ XEN_VGA_OFFSET,
+ 1,
+ Data32
+ );
+ } else {
+Status = EFI_OUT_OF_RESOURCES;
+ }
+
+ if (!EFI_ERROR(Status)) {
+Initialized = TRUE;
+ } else {
+if (VgaRam) {
+ FreeAlignedPages (VgaRam, VGA_RAM_PAGES);
+}
+ }
+}
+
STATIC
EFI_STATUS
DetectAndPreparePlatformPciDevicePath (
@@ -677,6 +760,37 @@
if (EFI_ERROR (Status)) {
return Status;
}
+
+ for (Index = 0; Index HandleCount; Index++) {
+Status = gBS-HandleProtocol
Re: [Xen-ia64-devel] [PATCH][GFW][RFC] fix EFI_SAL_SET_VECTORS
Quoting Isaku Yamahata [EMAIL PROTECTED]: On Tue, May 13, 2008 at 12:24:16PM +0200, [EMAIL PROTECTED] wrote: The uncached physical addresses are hard coded, but they aren't relocated when switching to virtual address mode. I am not sure ConvertPointer is able to deal with uncached addresses. Anyway, using normal addresses should be harmless. I guess that the original auther concerned about a race so that he used uncached addresses. I don't catch your point. Uncached addresses won't prevent races. Anyway the variable size is 16 bytes and are written/read twice so that the access isn't smp safe. Possible choice would be a. don't care assume that such a race won't happen and pray. b. use explicit lock c. use atomic access(cmp8xchg16) d. explicit synchronization betweeen cpus. Probably this would be difficult in gfw. My bet is a. I don't think that SAL has to protect against concurrency. I can't remember if the vector must be set for every processor. I will look. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen Itanium features available in Xen HVM?
Quoting Kayvan Sylvan [EMAIL PROTECTED]: Thanks very much for the replies. We would like to lend some help with trying to implement the protection registers. You're welcome! What is your advice on how to proceed? PKR have been implemented in PV mode. For VTi there is however an issue: we need an extra PK entry for the hypervisor. I don't think we can share the entry with one set by the OS. As there is no extra PKR (argh!), we need to implement an LRU-like arlgorithm. Nothing very hard here. You also need to be sure the PK are correctly handled in itc/itr/... instructions. About the PK ids: one must be reserved for Xen (it would be nice to use the same as the PV one, I think it is 0 - TBC). So only 23 bits remain for the domain. (I think it would be nice to split again in two: use one bit to support VTi virtualization. But that's future work). Feel free to discuss implementation issues here. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen Itanium features available in Xen HVM?
Quoting Kayvan Sylvan [EMAIL PROTECTED]: Hi everyone, We have some questions about the HVM roadmap and features. According to the Wiki, Fujitsu is working on getting other operating systems running as HVM guests. Tristan appears to be working on getting openVMS running and then HP-UX. Right for me. From what I gather from posts here, the major roadblock to HP-UX is protection key support. Not yet. The HP-UX efi loader crashes very early. This is currently blocking. I need either help from HP *or* time to investigate. Does anyone know the big picture of HVM features: - What Itanium architecture features are supported by HVM guests now? Most of them :-) - What Itanium architecture features are not supported now? Protection registers. I think that's almost it. - What features are most likely needed by openVMS? OpenVMS now works on Xen/ia64. There are still a few issues however (e.g. UP only). - What features are most likely needed by HP-UX? Protection registers. Thank you very much, any answers would be much appreciated. You're welcome! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] linux: set memory attribute in inlineasm
Selon Isaku Yamahata [EMAIL PROTECTED]: diff -r bb2f8ba47833 include/asm-ia64/xen/privop.h --- a/include/asm-ia64/xen/privop.h Tue Mar 25 12:37:54 2008 -0600 +++ b/include/asm-ia64/xen/privop.h Sat Apr 05 07:27:30 2008 +0900 @@ -67,7 +67,7 @@ #endif #ifndef __ASSEMBLY__ -#define XEN_HYPER_SSM_I asm(break %0 : : i (HYPERPRIVOP_SSM_I)) +#define XEN_HYPER_SSM_I asm(break %0 : : i (HYPERPRIVOP_SSM_I): memory) #define XEN_HYPER_GET_IVR asm(break %0 : : i (HYPERPRIVOP_GET_IVR)) // Shouldn't those be asm volatile, but asm? IIRC, according to the gcc doc asm without outputs are volatile. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [kvm-ia64-devel] FW: Follow up - IA64 uses Open Guest Firmware
My comments inside.
Quoting Yang, Fred [EMAIL PROTECTED]:
Daniel P. Berrange wrote:
On Fri, Mar 28, 2008 at 10:26:37AM -0700, Yang, Fred wrote:
Dan,
This mail is to follow up with
https://bugzilla.redhat.com/show_bug.cgi?id=420421 FEAT: IA64
RHEL5.2 Xen to use Open Guest Firmware to make it for RHEL5.3.
In BZ, we have updated following information in addressing your 3
concerns,
1. The build process requires tools which are not part of RHEL-5 eg
the XML Beans Java libraries. This means that it is not currently
possible to produce an RPM of the firmware source which will build
[Status] open GFW was originally derived from
https://www.tianocore.org/. The build infrastructure is also derived
from Tiano core, which is a very unique in its own way. Can Red Hat
release binary GFW (similar to the current RHEL5.2 in releasing Intel
proprietary GFW) associated with source code described in item#2 if
no short term tool change is available?
When we ship open source software we need to be able to guarentee that
the binary and source code we ship are matching. ie, if someone gets
the
source code, they will be able to build it and get the same result as
the binary we built. This is neccessary for us to comply with the
terms
of licenses such as the GPL. It is also neccessary for our support and
maintainence procedures - if we patch something to fix a bug we need
to
sure that we are building new updated RPM the same way.
The way we guarentee this is via our RPM build system. Every open
source
package has a source RPM. This is fed into the build system to produce
the binary RPM. As such, we need to be able to build the binary RPM
using
the tools available in RHEL. We cannot simply ship a pre-built
binary
and a collection of source code. It has to go via the RPM build
system.
This is currently a stopper. We are not able to provide a source package
that can be build without Java (+ XMLBeans + ... )
{ Note that tianocore is switching to a python based builder so the future is
open. But we haven't switched to the new infrastructure. }
2. The is no upstream official release. The build instructions are
just telling us to take a HG snapshot of the Xen patches, and a SVN
snapshot of the EDK sources. There really needs to be a properly
versioned, formal release of the firmware - preferably as a
self-contained tar.gz of all the source code [Status] The open GFW
site http://xenbits.xensource.com/ext/efi-vfirmware.hg is now also
building binary as part of it release now. Please see Changeset99
Binary for CS 92
This is not exactly what I meant. In fact, including and distributing
the pre-built binary in the efi-vfirmware.hg would be a violation of
the GPL
because you are not including any of the source from the tiancore.org
Subversion repository that is used to build it.
What we require is a single tar.gz file containing *all* the source
code neccessary to build the firmware image - this will be a
combination
of the source from efi-vfirmeware.hg, and the neccessary bits from the
tianocore Subversion repository in one tar.gz file. This must *not*
include any pre-built binary images - it must be all source code.
This is of course doable. But won't fix point 1.
Do you do this for xen x86 ?
3. The is no clear statement of the licensing of the open source
code. I've picked a random selection of source files and found a
couple of different license headers - some BSD, some public domain,
and some referring to external license files which don't exist. The
source will need auditing to make sure its all consistent in terms
of licensing. [Status] The code checked into
http://xenbits.xensource.com/ext/efi-vfirmware.hg should all have
signed-off by community developers. This would need Red Hat
address/sanitize from legal/license aspect.
The 'signed-off-by' lines indicate that the developer had the right
to submit
the code. They do not, however, specify the license for files. Most
of the
source code files contain a comment at the top of the file describing
what license they are under. A number of source code files do not
have any
comment describing the license. These need to be updated to have
explicit
license information. Second, the complete text of all the license
should
be included in top level directory of the source code. Many of the
files
simply say
All rights reserved. This program and the accompanying materials
are licensed and made available under the terms and conditions of the
BSD License which accompanies this distribution. The full text of
the license may be found at
http://opensource.org/licenses/bsd-license.php
It is not sufficient to point to a website URL since this URL / site
can disappear/change at any time. The actual text of the license
should be
included in the .tar.gz file along with all the source code.
[Xen-ia64-devel] Re: [kvm-ia64-devel] FW: Follow up - IA64 uses Open Guest Firmware
Quoting Daniel P. Berrange [EMAIL PROTECTED]: Can you clarify just what parts involve Java. Is it just the build system which is java based, or is part of the firmware itself coming from java source too ? Only the build system is java based. I'm wondering whether it would be feasible to try building with GCJ instead of the Sun/IBM/BEA JDKs. If only the build system used java this may be a viable option. Not sure. Several java components involved (such as Ant) were known *not* to work with gcj. But now that GCJ is ecj based (maybe not in RHEL5), this may have changed. Do you do this for xen x86 ? For x86, the HVM firmware source code is just part of the regular xen released tar.gz and built as part of the userspace build process of Xen. Right. I missed that. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH][Open GFW]Support ACPI SPCR table
Selon SUZUKI Kazuhiro [EMAIL PROTECTED]: Hi Tristan, The following patch supports ACPI Serial Port Console Redirection(SPCR) table, by which we can use Windows Special Administration Console(SAC). Hi, the issue raised by Alex is serious. I don't know what can we do. One possible solution is to create a small EFI application that just add the SPCR table. What do you think ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: move IO type to ppn [v2]
xen_ulong_t;
#endif
#define INVALID_MFN (~0UL)
-
-#define MEM_G (1UL 30)
-#define MEM_M (1UL 20)
-#define MEM_K (1UL 10)
-
-/* Guest physical address of IO ports space. */
-#define IO_PORTS_PADDR 0x0c00UL
-#define IO_PORTS_SIZE 0x0400UL
-
-#define MMIO_START (3 * MEM_G)
-#define MMIO_SIZE(512 * MEM_M)
-
-#define VGA_IO_START 0xAUL
-#define VGA_IO_SIZE 0x2
-
-#define LEGACY_IO_START (MMIO_START + MMIO_SIZE)
-#define LEGACY_IO_SIZE (64*MEM_M)
-
-#define IO_PAGE_START (LEGACY_IO_START + LEGACY_IO_SIZE)
-#define IO_PAGE_SIZE XEN_PAGE_SIZE
-
-#define STORE_PAGE_START (IO_PAGE_START + IO_PAGE_SIZE)
-#define STORE_PAGE_SIZE XEN_PAGE_SIZE
-
-#define BUFFER_IO_PAGE_START (STORE_PAGE_START + STORE_PAGE_SIZE)
-#define BUFFER_IO_PAGE_SIZE XEN_PAGE_SIZE
-
-#define BUFFER_PIO_PAGE_START (BUFFER_IO_PAGE_START + BUFFER_IO_PAGE_SIZE)
-#define BUFFER_PIO_PAGE_SIZE XEN_PAGE_SIZE
-
-#define IO_SAPIC_START 0xfec0UL
-#define IO_SAPIC_SIZE0x10
-
-#define PIB_START 0xfee0UL
-#define PIB_SIZE 0x20
-
-#define GFW_START(4*MEM_G -16*MEM_M)
-#define GFW_SIZE (16*MEM_M)
-
-/* Nvram belongs to GFW memory space */
-#define NVRAM_SIZE (MEM_K * 64)
-#define NVRAM_START (GFW_START + 10 * MEM_M)
-
-#define NVRAM_VALID_SIG 0x4650494e45584948 // HIXENIPF
-struct nvram_save_addr {
-unsigned long addr;
-unsigned long signature;
-};
struct pt_fpreg {
union {
@@ -503,6 +459,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_conte
/* Internal only: associated with PGC_allocated bit */
#define _ASSIGN_pgc_allocated 3
#define ASSIGN_pgc_allocated(1UL _ASSIGN_pgc_allocated)
+/* Page is an IO page. */
+#define _ASSIGN_io 4
+#define ASSIGN_io (1UL _ASSIGN_io)
/* This structure has the same layout of struct ia64_boot_param, defined in
asm/system.h. It is redefined here to ease use. */
diff -r a88bb92e5790 -r 485a87e89329 xen/include/public/arch-ia64/hvm/memmap.h
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/xen/include/public/arch-ia64/hvm/memmap.h Wed Mar 26 06:57:48 2008 +0100
@@ -0,0 +1,88 @@
+/**
+ * memmap.h
+ *
+ * Copyright (c) 2008 Tristan Gingold tgingold AT free fr
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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
+ *
+ */
+
+#ifndef __XEN_PUBLIC_HVM_MEMMAP_IA64_H__
+#define __XEN_PUBLIC_HVM_MEMMAP_IA64_H__
+
+#define MEM_G (1UL 30)
+#define MEM_M (1UL 20)
+#define MEM_K (1UL 10)
+
+/* Guest physical address of IO ports space. */
+#define MMIO_START (3 * MEM_G)
+#define MMIO_SIZE(512 * MEM_M)
+
+#define VGA_IO_START 0xAUL
+#define VGA_IO_SIZE 0x2
+
+#define LEGACY_IO_START (MMIO_START + MMIO_SIZE)
+#define LEGACY_IO_SIZE (64*MEM_M)
+
+#define IO_PAGE_START (LEGACY_IO_START + LEGACY_IO_SIZE)
+#define IO_PAGE_SIZE XEN_PAGE_SIZE
+
+#define STORE_PAGE_START (IO_PAGE_START + IO_PAGE_SIZE)
+#define STORE_PAGE_SIZE XEN_PAGE_SIZE
+
+#define BUFFER_IO_PAGE_START (STORE_PAGE_START + STORE_PAGE_SIZE)
+#define BUFFER_IO_PAGE_SIZE XEN_PAGE_SIZE
+
+#define BUFFER_PIO_PAGE_START (BUFFER_IO_PAGE_START + BUFFER_IO_PAGE_SIZE)
+#define BUFFER_PIO_PAGE_SIZE XEN_PAGE_SIZE
+
+#define IO_SAPIC_START 0xfec0UL
+#define IO_SAPIC_SIZE0x10
+
+#define PIB_START 0xfee0UL
+#define PIB_SIZE 0x20
+
+#define GFW_START(4*MEM_G -16*MEM_M)
+#define GFW_SIZE (16*MEM_M)
+
+/* domVTI */
+#define GPFN_FRAME_BUFFER 0x1 /* VGA framebuffer */
+#define GPFN_LOW_MMIO 0x2 /* Low MMIO range */
+#define GPFN_PIB 0x3 /* PIB base */
+#define GPFN_IOSAPIC 0x4 /* IOSAPIC base */
+#define GPFN_LEGACY_IO 0x5 /* Legacy I/O base */
+#define GPFN_HIGH_MMIO 0x6 /* High MMIO range */
+
+/* Nvram belongs to GFW memory space */
+#define NVRAM_SIZE (MEM_K * 64)
+#define NVRAM_START (GFW_START + 10 * MEM_M)
+
+#define NVRAM_VALID_SIG 0x4650494e45584948 // HIXENIPF
+struct nvram_save_addr {
+unsigned long addr;
+unsigned long signature;
+};
+
+#endif /* __XEN_PUBLIC_HVM_MEMMAP_IA64_H__ */
+
+/*
+ * Local variables:
+ * mode: C
[Xen-ia64-devel] PATCH: fix compilation warnings
Hi,
this simple patch fixes gcc warnings.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1206342217 -3600
# Node ID a88bb92e579000faadefe911f7571205d280fbab
# Parent e768be7bf56162347c1facf3b71e88d19f639599
Fix warnings.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r e768be7bf561 -r a88bb92e5790 xen/arch/ia64/vmx/vmx_init.c
--- a/xen/arch/ia64/vmx/vmx_init.c Thu Mar 20 14:29:09 2008 -0600
+++ b/xen/arch/ia64/vmx/vmx_init.c Mon Mar 24 08:03:37 2008 +0100
@@ -308,11 +308,9 @@ void
void
vmx_save_state(struct vcpu *v)
{
- u64 status;
-
BUG_ON(v != current);
- ia64_call_vsa(PAL_VPS_SAVE, v-arch.privregs, 0, 0, 0, 0, 0, 0);
+ ia64_call_vsa(PAL_VPS_SAVE, (u64)v-arch.privregs, 0, 0, 0, 0, 0, 0);
/* Need to save KR when domain switch, though HV itself doesn;t
* use them.
@@ -336,7 +334,7 @@ vmx_load_state(struct vcpu *v)
vmx_load_all_rr(v);
/* vmx_load_all_rr() pins down v-arch.privregs with both dtr/itr*/
- ia64_call_vsa(PAL_VPS_RESTORE, v-arch.privregs, 0, 0, 0, 0, 0, 0);
+ ia64_call_vsa(PAL_VPS_RESTORE, (u64)v-arch.privregs, 0, 0, 0, 0, 0, 0);
ia64_set_kr(0, v-arch.arch_vmx.vkr[0]);
ia64_set_kr(1, v-arch.arch_vmx.vkr[1]);
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: move IO type to ppn (VTi)
+ STORE_PAGE_SIZE)
-#define BUFFER_IO_PAGE_SIZE XEN_PAGE_SIZE
-
-#define BUFFER_PIO_PAGE_START (BUFFER_IO_PAGE_START + BUFFER_IO_PAGE_SIZE)
-#define BUFFER_PIO_PAGE_SIZE XEN_PAGE_SIZE
-
-#define IO_SAPIC_START 0xfec0UL
-#define IO_SAPIC_SIZE0x10
-
-#define PIB_START 0xfee0UL
-#define PIB_SIZE 0x20
-
-#define GFW_START(4*MEM_G -16*MEM_M)
-#define GFW_SIZE (16*MEM_M)
-
-/* Nvram belongs to GFW memory space */
-#define NVRAM_SIZE (MEM_K * 64)
-#define NVRAM_START (GFW_START + 10 * MEM_M)
-
-#define NVRAM_VALID_SIG 0x4650494e45584948 // HIXENIPF
-struct nvram_save_addr {
-unsigned long addr;
-unsigned long signature;
-};
struct pt_fpreg {
union {
@@ -503,6 +459,9 @@ DEFINE_XEN_GUEST_HANDLE(vcpu_guest_conte
/* Internal only: associated with PGC_allocated bit */
#define _ASSIGN_pgc_allocated 3
#define ASSIGN_pgc_allocated(1UL _ASSIGN_pgc_allocated)
+/* Page is an IO page. */
+#define _ASSIGN_io 4
+#define ASSIGN_io (1UL _ASSIGN_io)
/* This structure has the same layout of struct ia64_boot_param, defined in
asm/system.h. It is redefined here to ease use. */
diff -r a88bb92e5790 -r c109051a7ba7 xen/include/public/arch-ia64/hvm/memmap.h
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/xen/include/public/arch-ia64/hvm/memmap.h Tue Mar 25 06:12:50 2008 +0100
@@ -0,0 +1,88 @@
+/**
+ * memmap.h
+ *
+ * Copyright (c) 2008 Tristan Gingold tgingold AT free fr
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that 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
+ *
+ */
+
+#ifndef __XEN_PUBLIC_HVM_MEMMAP_IA64_H__
+#define __XEN_PUBLIC_HVM_MEMMAP_IA64_H__
+
+#define MEM_G (1UL 30)
+#define MEM_M (1UL 20)
+#define MEM_K (1UL 10)
+
+/* Guest physical address of IO ports space. */
+#define MMIO_START (3 * MEM_G)
+#define MMIO_SIZE(512 * MEM_M)
+
+#define VGA_IO_START 0xAUL
+#define VGA_IO_SIZE 0x2
+
+#define LEGACY_IO_START (MMIO_START + MMIO_SIZE)
+#define LEGACY_IO_SIZE (64*MEM_M)
+
+#define IO_PAGE_START (LEGACY_IO_START + LEGACY_IO_SIZE)
+#define IO_PAGE_SIZE XEN_PAGE_SIZE
+
+#define STORE_PAGE_START (IO_PAGE_START + IO_PAGE_SIZE)
+#define STORE_PAGE_SIZE XEN_PAGE_SIZE
+
+#define BUFFER_IO_PAGE_START (STORE_PAGE_START + STORE_PAGE_SIZE)
+#define BUFFER_IO_PAGE_SIZE XEN_PAGE_SIZE
+
+#define BUFFER_PIO_PAGE_START (BUFFER_IO_PAGE_START + BUFFER_IO_PAGE_SIZE)
+#define BUFFER_PIO_PAGE_SIZE XEN_PAGE_SIZE
+
+#define IO_SAPIC_START 0xfec0UL
+#define IO_SAPIC_SIZE0x10
+
+#define PIB_START 0xfee0UL
+#define PIB_SIZE 0x20
+
+#define GFW_START(4*MEM_G -16*MEM_M)
+#define GFW_SIZE (16*MEM_M)
+
+/* domVTI */
+#define GPFN_FRAME_BUFFER 0x1 /* VGA framebuffer */
+#define GPFN_LOW_MMIO 0x2 /* Low MMIO range */
+#define GPFN_PIB 0x3 /* PIB base */
+#define GPFN_IOSAPIC 0x4 /* IOSAPIC base */
+#define GPFN_LEGACY_IO 0x5 /* Legacy I/O base */
+#define GPFN_HIGH_MMIO 0x6 /* High MMIO range */
+
+/* Nvram belongs to GFW memory space */
+#define NVRAM_SIZE (MEM_K * 64)
+#define NVRAM_START (GFW_START + 10 * MEM_M)
+
+#define NVRAM_VALID_SIG 0x4650494e45584948 // HIXENIPF
+struct nvram_save_addr {
+unsigned long addr;
+unsigned long signature;
+};
+
+#endif /* __XEN_PUBLIC_HVM_MEMMAP_IA64_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: BSD
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] [2/2] fix wrong emulation: set psr.i
Quoting Akio Takebe [EMAIL PROTECTED]: Hi, we should not set psr.ic at setting psr.i. I think it was not wrong. You can't set psr.i without setting psr.ic. So at least, this was harmless. As this is an hyperprivop, the correct behaviour should be checked with linux sources. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] [1/2] fix wrong emulation: move to psr
Quoting Akio Takebe [EMAIL PROTECTED]: Hi, move_to_psr need to unset the bits. Why not ispr-xxx = newpsr-xxx ? Seems simpler. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] [1/2] fix wrong emulation: move to psr
Quoting Akio Takebe [EMAIL PROTECTED]:
Hi,
I updated it.
Haven't you changed the behaviour of dfh:
From
- if (newpsr.dfh) {
- ipsr-dfh = 1;
- PSCB(vcpu, vpsr_dfh) = 1;
- } else {
- ipsr-dfh = PSCB(vcpu, hpsr_dfh);
- PSCB(vcpu, vpsr_dfh) = 0;
- }
to
+ ipsr-dfh = newpsr.dfh;
+ PSCB(vcpu, vpsr_dfh) = newpsr.dfh;
vpsr_dfh is correct, but ipsr-dfh has changed.
Tristan.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: new SIOEMU interface
Hi,
this patch changes the SIOEMU callback interface. The old method was
flawed: the callback data were lost if occuring during an hypercall.
This new interface is not backward compatible. I think it is not an issue
since sioemu is not widely deployed.
As currently committed, the sioemu fw should work with this new interface
(e1000 is even available).
But I still have one xen patch to submit before generating a binary fw
for sioemu.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1205993255 -3600
# Node ID 1c98957779ee1d8730d48f2c09e9ca35cc77441d
# Parent ac30e3a6b9fccc9d0213dc0eed7c1545c4312b1f
New SIOEmu interface: pass callback data in memory.
This fixes lost data for callback while hypercall case.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r ac30e3a6b9fc -r 1c98957779ee xen/arch/ia64/asm-offsets.c
--- a/xen/arch/ia64/asm-offsets.c Thu Mar 13 05:29:24 2008 +0100
+++ b/xen/arch/ia64/asm-offsets.c Thu Mar 20 07:07:35 2008 +0100
@@ -150,6 +150,8 @@ void foo(void)
DEFINE(IA64_VCPU_OPCODE_OFFSET, offsetof (struct vcpu,
arch.arch_vmx.opcode));
DEFINE(SWITCH_MPTA_OFFSET,offsetof(struct vcpu ,arch.arch_vmx.mpta));
DEFINE(IA64_PT_REGS_R16_SLOT, (((offsetof(struct pt_regs,
r16)-sizeof(struct pt_regs))3)0x3f));
+ DEFINE(IA64_PT_REGS_R2_SLOT, (((offsetof(struct pt_regs,
r16)-sizeof(struct pt_regs))3)0x3f));
+ DEFINE(IA64_PT_REGS_R8_SLOT, (((offsetof(struct pt_regs,
r16)-sizeof(struct pt_regs))3)0x3f));
DEFINE(IA64_VCPU_FLAGS_OFFSET,offsetof(struct vcpu
,arch.arch_vmx.flags));
DEFINE(IA64_VCPU_MMU_MODE_OFFSET,offsetof(struct vcpu,
arch.arch_vmx.mmu_mode));
diff -r ac30e3a6b9fc -r 1c98957779ee xen/arch/ia64/vmx/sioemu.c
--- a/xen/arch/ia64/vmx/sioemu.cThu Mar 13 05:29:24 2008 +0100
+++ b/xen/arch/ia64/vmx/sioemu.cThu Mar 20 07:07:35 2008 +0100
@@ -26,171 +26,137 @@
#include asm/sal.h
#include asm/vlsapic.h
-static void
-sioemu_save_regs (VCPU *vcpu)
-{
-REGS *regs = vcpu_regs(vcpu);
-
-vcpu-arch.arch_vmx.stub_saved[0] = regs-r16;
-vcpu-arch.arch_vmx.stub_saved[1] = regs-r17;
-vcpu-arch.arch_vmx.stub_saved[2] = regs-r18;
-vcpu-arch.arch_vmx.stub_saved[3] = regs-r19;
-vcpu-arch.arch_vmx.stub_saved[4] = regs-r20;
-vcpu-arch.arch_vmx.stub_saved[5] = regs-r21;
-vcpu-arch.arch_vmx.stub_saved[6] = regs-r22;
-vcpu-arch.arch_vmx.stub_saved[7] = regs-r23;
-vcpu-arch.arch_vmx.stub_saved[8] = regs-r24;
-vcpu-arch.arch_vmx.stub_saved[9] = regs-r25;
-vcpu-arch.arch_vmx.stub_saved[10] = regs-r26;
-vcpu-arch.arch_vmx.stub_saved[11] = regs-r27;
-vcpu-arch.arch_vmx.stub_saved[12] = regs-r28;
-vcpu-arch.arch_vmx.stub_saved[13] = regs-r29;
-vcpu-arch.arch_vmx.stub_saved[14] = regs-r30;
-vcpu-arch.arch_vmx.stub_saved[15] = regs-r31;
-vcpu-arch.arch_vmx.stub_nats =
-(regs-eml_unat IA64_PT_REGS_R16_SLOT) 0x;
-}
-
-static void
-sioemu_restore_regs (VCPU *vcpu)
-{
-REGS *regs = vcpu_regs(vcpu);
-
-/* First restore registers. */
-regs-cr_iip = regs-r28;
-regs-cr_ifs = regs-r30;
-vmx_vcpu_set_psr (vcpu, regs-r29);
-
-regs-eml_unat = ~(0xUL IA64_PT_REGS_R16_SLOT);
-regs-eml_unat |= vcpu-arch.arch_vmx.stub_nats IA64_PT_REGS_R16_SLOT;
-
-regs-r16 = vcpu-arch.arch_vmx.stub_saved[0];
-regs-r17 = vcpu-arch.arch_vmx.stub_saved[1];
-regs-r18 = vcpu-arch.arch_vmx.stub_saved[2];
-regs-r19 = vcpu-arch.arch_vmx.stub_saved[3];
-regs-r20 = vcpu-arch.arch_vmx.stub_saved[4];
-regs-r21 = vcpu-arch.arch_vmx.stub_saved[5];
-regs-r22 = vcpu-arch.arch_vmx.stub_saved[6];
-regs-r23 = vcpu-arch.arch_vmx.stub_saved[7];
-regs-r24 = vcpu-arch.arch_vmx.stub_saved[8];
-regs-r25 = vcpu-arch.arch_vmx.stub_saved[9];
-regs-r26 = vcpu-arch.arch_vmx.stub_saved[10];
-regs-r27 = vcpu-arch.arch_vmx.stub_saved[11];
-regs-r28 = vcpu-arch.arch_vmx.stub_saved[12];
-regs-r29 = vcpu-arch.arch_vmx.stub_saved[13];
-regs-r30 = vcpu-arch.arch_vmx.stub_saved[14];
-regs-r31 = vcpu-arch.arch_vmx.stub_saved[15];
-
-}
-
-static REGS *
+struct sioemu_callback_info *
sioemu_deliver (void)
{
VCPU *vcpu = current;
REGS *regs = vcpu_regs(vcpu);
+struct sioemu_callback_info *info = vcpu-arch.arch_vmx.sioemu_info_mva;
unsigned long psr = vmx_vcpu_get_psr(vcpu);
if (vcpu-vcpu_info-evtchn_upcall_mask)
panic_domain (NULL, sioemu_deliver: aleady in stub mode\n);
+if (info == NULL)
+panic_domain (NULL, sioemu_deliver: set_callback not called\n);
/* All cleared, but keep BN. */
vmx_vcpu_set_psr(vcpu, IA64_PSR_MC | (psr IA64_PSR_BN));
-/* Save registers. */
-sioemu_save_regs (vcpu);
-
-/* Context. */
-regs-r28 = regs-cr_iip;
-regs-r29 = psr;
-regs-r30 = regs-cr_ifs;
+/* Set info. */
+info-ip = regs-cr_iip;
+info-psr = psr;
+info-ifs = regs-cr_ifs;
+info-nats = (((regs-eml_unat
[Xen-ia64-devel] Re: [PATCH][RFC] fix DTLB miss behavior with physical mode
Quoting Kouya Shimura [EMAIL PROTECTED]: Hi, A behavior with bad physical address on HVM is unpredictable. It means that a speculative load can't be used with physical mode. This patch fixes it. but it still implies a issue with metaphyscial mode. There is no way to distinguish RSE fault from DTLB miss. Is there any good idea? isr.rs ? I still fail to see which bug you are trying to fix... (but I don't have the full context here). Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: cleanup in vmx_ivt.S
Hi, this patch removes the commented lines in order to make the code clearer. Tristan. # HG changeset patch # User Tristan Gingold [EMAIL PROTECTED] # Date 1205382564 -3600 # Node ID ac30e3a6b9fccc9d0213dc0eed7c1545c4312b1f # Parent 7a00b54e1ce9b0ec3930f7d78d5a519cf588d680 Cleanup: remove useless commented lines. Signed-off-by: Tristan Gingold [EMAIL PROTECTED] diff -r 7a00b54e1ce9 -r ac30e3a6b9fc xen/arch/ia64/vmx/vmx_ivt.S --- a/xen/arch/ia64/vmx/vmx_ivt.S Wed Mar 12 06:46:15 2008 +0100 +++ b/xen/arch/ia64/vmx/vmx_ivt.S Thu Mar 13 05:29:24 2008 +0100 @@ -524,38 +524,33 @@ ENTRY(vmx_break_fault) * to prevent leaking bits from kernel to user level. */ -// mov.m r16=IA64_KR(CURRENT) // M2 r16 - current task (12 cyc) -mov r14=r21 -bsw.1 // B (6 cyc) regs are saved, switch to bank 1 +mov r14=r21// save r21 before bsw.1 +bsw.1 // B (6 cyc) switch to bank 1 ;; -mov r29=cr.ipsr// M2 (12 cyc) +mov r29=cr.ipsr// M2 (12 cyc) mov r31=pr // I0 (2 cyc) mov r16=r14 mov r15=r2 -mov r17=cr.iim // M2 (2 cyc) +mov r17=cr.iim // M2 (2 cyc) mov.m r27=ar.rsc // M2 (12 cyc) -// mov r18=__IA64_BREAK_SYSCALL // A - -mov.m ar.rsc=0 // M2 + +mov.m ar.rsc=0 // M2 mov.m r21=ar.fpsr // M2 (12 cyc) mov r19=b6 // I0 (2 cyc) ;; -mov.m r23=ar.bspstore // M2 (12 cyc) +mov.m r23=ar.bspstore // M2 (12 cyc) mov.m r24=ar.rnat // M2 (5 cyc) mov.i r26=ar.pfs // I0 (2 cyc) -invala // M0|1 -nop.m 0// M +invala // M0|1 +nop.m 0// M mov r20=r1 // Asave r1 nop.m 0 -// movl r30=sys_call_table// X -movl r30=ia64_hypercall_table // X - -mov r28=cr.iip // M2 (2 cyc) -// cmp.eq p0,p7=r18,r17 // I0 is this a system call? -//(p7) br.cond.spnt non_syscall // B no - +movl r30=ia64_hypercall_table // X + +mov r28=cr.iip // M2 (2 cyc) // // From this point on, we are definitely on the syscall-path // and we can use (non-banked) scratch registers. @@ -563,37 +558,30 @@ ENTRY(vmx_break_fault) /// mov r1=r16 // Amove task-pointer to addl-addressable reg mov r2=r16 // Asetup r2 for ia64_syscall_setup -// add r9=TI_FLAGS+IA64_TASK_SIZE,r16 // Ar9 = current_thread_info()-flags - -// adds r16=IA64_TASK_THREAD_ON_USTACK_OFFSET,r16 -// adds r15=-1024,r15 // Asubtract 1024 from syscall number -// mov r3=NR_syscalls - 1 + mov r3=NR_hypercalls - 1 ;; -// ld1.bias r17=[r16] // M0|1 r17 = current-thread.on_ustack flag -// ld4 r9=[r9]// M0|1 r9 = current_thread_info()-flags -mov r9=r0 // force flags = 0 +mov r9=r0 // force flags = 0 extr.u r8=r29,41,2 // I0 extract ei field from cr.ipsr -shladd r30=r15,3,r30 // Ar30 = sys_call_table + 8*(syscall-1024) +shladd r30=r15,3,r30 // Ar30 = hcall_table + 8*syscall addl r22=IA64_RBS_OFFSET,r1// Acompute base of RBS -cmp.leu p6,p7=r15,r3 // Asyscall number in range? +cmp.leu p6,p7=r15,r3 // Asyscall number in range? ;; lfetch.fault.excl.nt1 [r22]// M0|1 prefetch RBS -(p6) ld8 r30=[r30] // M0|1 load address of syscall entry point -tnat.nz.or p7,p0=r15 // I0 is syscall nr a NaT? - -mov.m ar.bspstore=r22 // M2 switch to kernel RBS +(p6) ld8 r30=[r30] // M0|1 load address of syscall entry point +tnat.nz.or p7,p0=r15 // I0 is syscall nr a NaT? + +mov.m ar.bspstore=r22 // M2 switch to kernel RBS cmp.eq p8,p9=2,r8 // Aisr.ei==2? ;; (p8) mov r8=0 // Aclear ei to 0 -//(p7) movl r30=sys_ni_syscall// X -(p7) movl r30=do_ni_hypercall // X - -(p8) adds r28=16,r28 // Aswitch cr.iip to next bundle -(p9) adds r8=1,r8
[Xen-ia64-devel] PATCH: get_wallclock also returns NOW
Hi,
at least sched_poll hypercall needs to have access to the NOW value
(time since boot). This patch makes NOW available from sioemu.
(I haven't look wether pv drivers use sched_poll or not).
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1205043272 -3600
# Node ID 4c9ef8fdebbf9e315e7ad0967f069acc6f47e481
# Parent 5c8da1f449872216bb4cc0b81d153f92b90d97da
get_wallclock also returns NOW value.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 5c8da1f44987 -r 4c9ef8fdebbf xen/arch/ia64/vmx/sioemu.c
--- a/xen/arch/ia64/vmx/sioemu.cSat Mar 08 03:27:13 2008 +0100
+++ b/xen/arch/ia64/vmx/sioemu.cSun Mar 09 07:14:32 2008 +0100
@@ -248,9 +248,10 @@ sioemu_hypercall (struct pt_regs *regs)
break;
case SIOEMU_HYPERCALL_GET_TIME:
{
-uint64_t sec, nsec;
-get_wallclock(sec, nsec);
+uint64_t sec, nsec, now;
+get_wallclock(sec, nsec, now);
regs-r8 = (sec 30) + nsec;
+regs-r9 = now;
break;
}
case SIOEMU_HYPERCALL_GET_REGS:
@@ -272,6 +273,7 @@ sioemu_hypercall (struct pt_regs *regs)
case SIOEMU_HYPERCALL_CALLBACK_RETURN:
regs-r2 = regs-r27;
sioemu_callback_return ();
+vcpu_decrement_iip(current);
break;
default:
panic_domain (NULL, bad sioemu hypercall %lx\n, regs-r2);
diff -r 5c8da1f44987 -r 4c9ef8fdebbf xen/arch/ia64/xen/xentime.c
--- a/xen/arch/ia64/xen/xentime.c Sat Mar 08 03:27:13 2008 +0100
+++ b/xen/arch/ia64/xen/xentime.c Sun Mar 09 07:14:32 2008 +0100
@@ -253,9 +253,11 @@ struct tm wallclock_time(void)
return gmtime(seconds);
}
-void get_wallclock(uint64_t *sec, uint64_t *nsec)
-{
-uint64_t nano = NOW() + wc_nsec;
+void get_wallclock(uint64_t *sec, uint64_t *nsec, uint64_t *now)
+{
+uint64_t n = NOW();
+uint64_t nano = n + wc_nsec;
*sec = wc_sec + nano / NSEC_PER_SEC;
*nsec = nano % NSEC_PER_SEC;
-}
+*now = n;
+}
diff -r 5c8da1f44987 -r 4c9ef8fdebbf xen/include/asm-ia64/time.h
--- a/xen/include/asm-ia64/time.h Sat Mar 08 03:27:13 2008 +0100
+++ b/xen/include/asm-ia64/time.h Sun Mar 09 07:14:32 2008 +0100
@@ -7,6 +7,6 @@ struct tm;
struct tm;
struct tm wallclock_time(void);
-void get_wallclock(uint64_t *sec, uint64_t *nsec);
+void get_wallclock(uint64_t *sec, uint64_t *nsec, uint64_t *now);
#endif /* _ASM_TIME_H_ */
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: avoid multiple calls to lookup_domain_mpa for io emulation
Hi,
__gpfn_is_io macro hides a call to lookup_domain_mpa. This patch avoids
multiple call to lookup_domain_mpa during io emulation.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1205045991 -3600
# Node ID 7aa1d39b7786d741fc89e3c4ceb24badbf674611
# Parent 4c9ef8fdebbf9e315e7ad0967f069acc6f47e481
Avoid multiple calls to lookup_domain_mpa in io emulation code.
Remove __gpfn_is_io and __gpfn_is_mem.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 4c9ef8fdebbf -r 7aa1d39b7786 xen/arch/ia64/vmx/mmio.c
--- a/xen/arch/ia64/vmx/mmio.c Sun Mar 09 07:14:32 2008 +0100
+++ b/xen/arch/ia64/vmx/mmio.c Sun Mar 09 07:59:51 2008 +0100
@@ -352,10 +352,9 @@ static void legacy_io_access(VCPU *vcpu,
return;
}
-static void mmio_access(VCPU *vcpu, u64 src_pa, u64 *dest, size_t s, int ma,
int dir)
-{
-unsigned long iot;
-iot = __gpfn_is_io(vcpu-domain, src_pa PAGE_SHIFT);
+static void mmio_access(VCPU *vcpu, u64 src_pa, u64 *dest, size_t s, int ma,
int dir, u64 pte)
+{
+unsigned long iot = pte GPFN_IO_MASK;
perfc_incra(vmx_mmio_access, iot 56);
switch (iot) {
@@ -395,7 +394,7 @@ enum inst_type_en { SL_INTEGER, SL_FLOAT
/*
dir 1: read 0:write
*/
-void emulate_io_inst(VCPU *vcpu, u64 padr, u64 ma)
+void emulate_io_inst(VCPU *vcpu, u64 padr, u64 ma, u64 pte)
{
REGS *regs;
IA64_BUNDLE bundle;
@@ -537,7 +536,7 @@ void emulate_io_inst(VCPU *vcpu, u64 pad
}
if (vcpu-domain-arch.is_sioemu) {
-unsigned long iot = __gpfn_is_io(vcpu-domain, padr PAGE_SHIFT);
+unsigned long iot = pte GPFN_IO_MASK;
if (iot != GPFN_PIB iot != GPFN_IOSAPIC) {
sioemu_io_emulate(padr, data, data1, update_word);
@@ -546,10 +545,10 @@ void emulate_io_inst(VCPU *vcpu, u64 pad
}
if (size == 4) {
-mmio_access(vcpu, padr + 8, data1, 1 3, ma, dir);
+mmio_access(vcpu, padr + 8, data1, 1 3, ma, dir, pte);
size = 3;
}
-mmio_access(vcpu, padr, data, 1 size, ma, dir);
+mmio_access(vcpu, padr, data, 1 size, ma, dir, pte);
emulate_io_update(vcpu, update_word, data, data1);
}
diff -r 4c9ef8fdebbf -r 7aa1d39b7786 xen/arch/ia64/vmx/vmmu.c
--- a/xen/arch/ia64/vmx/vmmu.c Sun Mar 09 07:14:32 2008 +0100
+++ b/xen/arch/ia64/vmx/vmmu.c Sun Mar 09 07:59:51 2008 +0100
@@ -283,9 +283,10 @@ IA64FAULT vmx_vcpu_itr_d(VCPU *vcpu, u64
#ifdef VTLB_DEBUG
int index;
#endif
-u64 gpfn;
+u64 gpfn, gpte;
u64 ps, va, rid;
thash_data_t * p_dtr;
+
ps = itir_ps(itir);
va = PAGEALIGN(ifa, ps);
#ifdef VTLB_DEBUG
@@ -313,10 +314,11 @@ IA64FAULT vmx_vcpu_itr_d(VCPU *vcpu, u64
if (ps != _PAGE_SIZE_16M)
thash_purge_entries(vcpu, va, ps);
gpfn = (pte _PAGE_PPN_MASK) PAGE_SHIFT;
-if (VMX_DOMAIN(vcpu) __gpfn_is_io(vcpu-domain, gpfn))
+gpte = lookup_domain_mpa(vcpu-domain, gpfn, NULL);
+if (gpte GPFN_IO_MASK)
pte |= VTLB_PTE_IO;
vcpu_get_rr(vcpu, va, rid);
-rid = rid RR_RID_MASK;
+rid = RR_RID_MASK;
p_dtr = (thash_data_t *)vcpu-arch.dtrs[slot];
vmx_vcpu_set_tr((thash_data_t *)vcpu-arch.dtrs[slot], pte, itir, va,
rid);
vcpu_quick_region_set(PSCBX(vcpu,dtr_regions),va);
diff -r 4c9ef8fdebbf -r 7aa1d39b7786 xen/arch/ia64/vmx/vmx_fault.c
--- a/xen/arch/ia64/vmx/vmx_fault.c Sun Mar 09 07:14:32 2008 +0100
+++ b/xen/arch/ia64/vmx/vmx_fault.c Sun Mar 09 07:59:51 2008 +0100
@@ -355,15 +355,16 @@ vmx_hpw_miss(u64 vadr, u64 vec, REGS* re
mmu_mode = VMX_MMU_MODE(v);
if ((mmu_mode == VMX_MMU_PHY_DT
|| (mmu_mode == VMX_MMU_PHY_D type == DSIDE_TLB))
- !((vadr1)62)) {
+ (REGION_NUMBER(vadr) 3) == 0) {
if (type == DSIDE_TLB) {
+u64 pte;
/* DTLB miss. */
if (misr.sp) /* Refer to SDM Vol2 Table 4-11,4-12 */
return vmx_handle_lds(regs);
+pte = lookup_domain_mpa(v-domain, pa_clear_uc(vadr), NULL);
/* Clear UC bit in vadr with the shifts. */
-if (v-domain != dom0
- __gpfn_is_io(v-domain, (vadr 1) (PAGE_SHIFT + 1))) {
-emulate_io_inst(v, ((vadr 1) 1), 4);
+if (v-domain != dom0 (pte GPFN_IO_MASK)) {
+emulate_io_inst(v, pa_clear_uc(vadr), 4, pte);
return IA64_FAULT;
}
}
@@ -377,18 +378,20 @@ try_again:
if (data != 0) {
/* Found. */
if (v-domain != dom0 type == DSIDE_TLB) {
+u64 pte;
if (misr.sp) { /* Refer to SDM Vol2 Table 4-10,4-12 */
if ((data-ma == VA_MATTR_UC) || (data-ma == VA_MATTR_UCE))
return vmx_handle_lds(regs);
}
gppa = (vadr ((1UL data-ps) - 1)) +
(data-ppn (data-ps - 12) data-ps);
-if (__gpfn_is_io(v-domain, gppa PAGE_SHIFT)) {
+pte = lookup_domain_mpa(v-domain, gppa, NULL);
+
[Xen-ia64-devel] PATCH: prepare sioemu for SMP and save restore
Hi,
same as previous patch but indentation updated.
(can boot linux with 2 vcpus).
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1204943233 -3600
# Node ID 5c8da1f449872216bb4cc0b81d153f92b90d97da
# Parent 550ba7a6fe535dde3d0c939e83f8c86168264066
Prepare sioemu for SMP and save restore.
Use macros instead of constants.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 550ba7a6fe53 -r 5c8da1f44987 xen/arch/ia64/vmx/sioemu.c
--- a/xen/arch/ia64/vmx/sioemu.cSat Mar 08 03:08:23 2008 +0100
+++ b/xen/arch/ia64/vmx/sioemu.cSat Mar 08 03:27:13 2008 +0100
@@ -23,21 +23,14 @@
#include public/arch-ia64/sioemu.h
#include asm/dom_fw.h
#include asm/debugger.h
-
-static REGS *
-sioemu_deliver (void)
-{
-VCPU *vcpu = current;
-REGS *regs = vcpu_regs(vcpu);
-unsigned long psr = vmx_vcpu_get_psr(vcpu);
-
-if (vcpu-vcpu_info-evtchn_upcall_mask)
-panic_domain (NULL, sioemu_deliver: aleady in stub mode\n);
-
-/* All cleared, but keep BN. */
-vmx_vcpu_set_psr(vcpu, IA64_PSR_MC | (psr IA64_PSR_BN));
-
-/* Save registers. */
+#include asm/sal.h
+#include asm/vlsapic.h
+
+static void
+sioemu_save_regs (VCPU *vcpu)
+{
+REGS *regs = vcpu_regs(vcpu);
+
vcpu-arch.arch_vmx.stub_saved[0] = regs-r16;
vcpu-arch.arch_vmx.stub_saved[1] = regs-r17;
vcpu-arch.arch_vmx.stub_saved[2] = regs-r18;
@@ -56,42 +49,12 @@ sioemu_deliver (void)
vcpu-arch.arch_vmx.stub_saved[15] = regs-r31;
vcpu-arch.arch_vmx.stub_nats =
(regs-eml_unat IA64_PT_REGS_R16_SLOT) 0x;
-
-/* Context. */
-regs-r28 = regs-cr_iip;
-regs-r29 = psr;
-regs-r30 = regs-cr_ifs;
-
-regs-cr_ifs = 0; // pre-cover
-
-regs-cr_iip = vcpu-arch.event_callback_ip;
-regs-eml_unat = ~(0xUL IA64_PT_REGS_R16_SLOT);
-
-/* Parameters. */
-regs-r16 = 0;
-regs-r17 = vcpu-arch.arch_vmx.stub_buffer;
-
-/* Mask events. */
-vcpu-vcpu_info-evtchn_upcall_mask = 1;
-
-debugger_event(XEN_IA64_DEBUG_ON_EVENT);
-
-return regs;
-}
-
-void
-sioemu_callback_return (void)
-{
-VCPU *vcpu = current;
-REGS *regs = vcpu_regs(vcpu);
-u64 cmd = regs-r16;
-u64 arg1 = regs-r19;
-u64 arg2 = regs-r20;
-u64 arg3 = regs-r21;
-
-if ((cmd ~0x1UL) != 0)
-panic_domain (NULL,
- sioemu_callback_return: bad operation (%lx)\n, cmd);
+}
+
+static void
+sioemu_restore_regs (VCPU *vcpu)
+{
+REGS *regs = vcpu_regs(vcpu);
/* First restore registers. */
regs-cr_iip = regs-r28;
@@ -118,6 +81,67 @@ sioemu_callback_return (void)
regs-r30 = vcpu-arch.arch_vmx.stub_saved[14];
regs-r31 = vcpu-arch.arch_vmx.stub_saved[15];
+}
+
+static REGS *
+sioemu_deliver (void)
+{
+VCPU *vcpu = current;
+REGS *regs = vcpu_regs(vcpu);
+unsigned long psr = vmx_vcpu_get_psr(vcpu);
+
+if (vcpu-vcpu_info-evtchn_upcall_mask)
+panic_domain (NULL, sioemu_deliver: aleady in stub mode\n);
+
+/* All cleared, but keep BN. */
+vmx_vcpu_set_psr(vcpu, IA64_PSR_MC | (psr IA64_PSR_BN));
+
+/* Save registers. */
+sioemu_save_regs (vcpu);
+
+/* Context. */
+regs-r28 = regs-cr_iip;
+regs-r29 = psr;
+regs-r30 = regs-cr_ifs;
+
+regs-cr_ifs = 0; // pre-cover
+
+regs-cr_iip = vcpu-arch.event_callback_ip;
+regs-eml_unat = ~(0xUL IA64_PT_REGS_R16_SLOT);
+
+/* Parameters. */
+regs-r16 = 0;
+regs-r17 = vcpu-arch.arch_vmx.stub_buffer;
+
+/* Mask events. */
+vcpu-vcpu_info-evtchn_upcall_mask = 1;
+
+debugger_event(XEN_IA64_DEBUG_ON_EVENT);
+
+return regs;
+}
+
+void
+sioemu_callback_return (void)
+{
+VCPU *vcpu = current;
+REGS *regs = vcpu_regs(vcpu);
+u64 cmd = regs-r16;
+u64 arg1 = regs-r19;
+u64 arg2 = regs-r20;
+u64 arg3 = regs-r21;
+
+if ((cmd ~0x1UL) != 0)
+panic_domain (NULL, sioemu_callback_return: bad operation (%lx)\n,
+ cmd);
+
+/* First restore registers. */
+regs-cr_iip = regs-r28;
+regs-cr_ifs = regs-r30;
+vmx_vcpu_set_psr (vcpu, regs-r29);
+
+sioemu_restore_regs (vcpu);
+
/* Unmask events. */
vcpu-vcpu_info-evtchn_upcall_mask = 0;
@@ -133,8 +157,7 @@ sioemu_deliver_event (void)
REGS *regs;
regs = sioemu_deliver ();
-
-regs-r16 = 0;
+regs-r16 = SIOEMU_CB_EVENT;
}
void
@@ -144,11 +167,30 @@ sioemu_io_emulate (unsigned long padr, u
REGS *regs;
regs = sioemu_deliver ();
-regs-r16 = 1;
+regs-r16 = SIOEMU_CB_IO_EMULATE;
regs-r19 = padr;
regs-r20 = data;
regs-r21 = data1;
regs-r22 = word;
+}
+
+void
+sioemu_wakeup_vcpu (int vcpu_id)
+{
+REGS *regs;
+
+regs = sioemu_deliver();
+regs-r16 = SIOEMU_CB_WAKEUP_VCPU;
+regs-r19 = vcpu_id;
+}
+
+void
+sioemu_sal_assist (struct vcpu *v)
+{
+REGS *regs;
+
+regs = sioemu_deliver();
+regs-r16 = SIOEMU_CB_SAL_ASSIST;
}
static int
@@ -187,7 +229,7 @@
[Xen-ia64-devel] PATCH: prepare sioemu for SMP and save restore
Hi,
this patch adds new sioemu hypercalls for SMP and save restore.
It also replaces some constants by macros.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1204863502 -3600
# Node ID 99ed430040909e7edd203893a18a72d0d8de1c52
# Parent 687a4068f54284543b52b36b99ea9ea8bdae3ea5
Prepare sioemu for SMP and save restore.
Use macros instead of constants.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 687a4068f542 -r 99ed43004090 xen/arch/ia64/vmx/sioemu.c
--- a/xen/arch/ia64/vmx/sioemu.cFri Mar 07 05:14:33 2008 +0100
+++ b/xen/arch/ia64/vmx/sioemu.cFri Mar 07 05:18:22 2008 +0100
@@ -23,21 +23,14 @@
#include public/arch-ia64/sioemu.h
#include asm/dom_fw.h
#include asm/debugger.h
-
-static REGS *
-sioemu_deliver (void)
-{
- VCPU *vcpu = current;
- REGS *regs = vcpu_regs(vcpu);
- unsigned long psr = vmx_vcpu_get_psr(vcpu);
-
- if (vcpu-vcpu_info-evtchn_upcall_mask)
-panic_domain (NULL, sioemu_deliver: aleady in stub mode\n);
-
- /* All cleared, but keep BN. */
- vmx_vcpu_set_psr(vcpu, IA64_PSR_MC | (psr IA64_PSR_BN));
-
- /* Save registers. */
+#include asm/sal.h
+#include asm/vlsapic.h
+
+static void
+sioemu_save_regs (VCPU *vcpu)
+{
+ REGS *regs = vcpu_regs(vcpu);
+
vcpu-arch.arch_vmx.stub_saved[0] = regs-r16;
vcpu-arch.arch_vmx.stub_saved[1] = regs-r17;
vcpu-arch.arch_vmx.stub_saved[2] = regs-r18;
@@ -56,46 +49,12 @@ sioemu_deliver (void)
vcpu-arch.arch_vmx.stub_saved[15] = regs-r31;
vcpu-arch.arch_vmx.stub_nats =
(regs-eml_unat IA64_PT_REGS_R16_SLOT) 0x;
-
- /* Context. */
- regs-r28 = regs-cr_iip;
- regs-r29 = psr;
- regs-r30 = regs-cr_ifs;
-
- regs-cr_ifs = 0;// pre-cover
-
- regs-cr_iip = vcpu-arch.event_callback_ip;
- regs-eml_unat = ~(0xUL IA64_PT_REGS_R16_SLOT);
-
- /* Parameters. */
- regs-r16 = 0;
- regs-r17 = vcpu-arch.arch_vmx.stub_buffer;
-
- /* Mask events. */
- vcpu-vcpu_info-evtchn_upcall_mask = 1;
-
- debugger_event(XEN_IA64_DEBUG_ON_EVENT);
-
- return regs;
-}
-
-void
-sioemu_callback_return (void)
-{
- VCPU *vcpu = current;
- REGS *regs = vcpu_regs(vcpu);
- u64 cmd = regs-r16;
- u64 arg1 = regs-r19;
- u64 arg2 = regs-r20;
- u64 arg3 = regs-r21;
-
- if ((cmd ~0x1UL) != 0)
-panic_domain (NULL, sioemu_callback_return: bad operation (%lx)\n, cmd);
-
- /* First restore registers. */
- regs-cr_iip = regs-r28;
- regs-cr_ifs = regs-r30;
- vmx_vcpu_set_psr (vcpu, regs-r29);
+}
+
+static void
+sioemu_restore_regs (VCPU *vcpu)
+{
+ REGS *regs = vcpu_regs(vcpu);
regs-eml_unat = ~(0xUL IA64_PT_REGS_R16_SLOT);
regs-eml_unat |= vcpu-arch.arch_vmx.stub_nats IA64_PT_REGS_R16_SLOT;
@@ -117,6 +76,66 @@ sioemu_callback_return (void)
regs-r30 = vcpu-arch.arch_vmx.stub_saved[14];
regs-r31 = vcpu-arch.arch_vmx.stub_saved[15];
+}
+
+static REGS *
+sioemu_deliver (void)
+{
+ VCPU *vcpu = current;
+ REGS *regs = vcpu_regs(vcpu);
+ unsigned long psr = vmx_vcpu_get_psr(vcpu);
+
+ if (vcpu-vcpu_info-evtchn_upcall_mask)
+panic_domain (NULL, sioemu_deliver: aleady in stub mode\n);
+
+ /* All cleared, but keep BN. */
+ vmx_vcpu_set_psr(vcpu, IA64_PSR_MC | (psr IA64_PSR_BN));
+
+ /* Save registers. */
+ sioemu_save_regs (vcpu);
+
+ /* Context. */
+ regs-r28 = regs-cr_iip;
+ regs-r29 = psr;
+ regs-r30 = regs-cr_ifs;
+
+ regs-cr_ifs = 0;// pre-cover
+
+ regs-cr_iip = vcpu-arch.event_callback_ip;
+ regs-eml_unat = ~(0xUL IA64_PT_REGS_R16_SLOT);
+
+ /* Parameters. */
+ regs-r16 = 0;
+ regs-r17 = vcpu-arch.arch_vmx.stub_buffer;
+
+ /* Mask events. */
+ vcpu-vcpu_info-evtchn_upcall_mask = 1;
+
+ debugger_event(XEN_IA64_DEBUG_ON_EVENT);
+
+ return regs;
+}
+
+void
+sioemu_callback_return (void)
+{
+ VCPU *vcpu = current;
+ REGS *regs = vcpu_regs(vcpu);
+ u64 cmd = regs-r16;
+ u64 arg1 = regs-r19;
+ u64 arg2 = regs-r20;
+ u64 arg3 = regs-r21;
+
+ if ((cmd ~0x1UL) != 0)
+panic_domain (NULL, sioemu_callback_return: bad operation (%lx)\n, cmd);
+
+ /* First restore registers. */
+ regs-cr_iip = regs-r28;
+ regs-cr_ifs = regs-r30;
+ vmx_vcpu_set_psr (vcpu, regs-r29);
+
+ sioemu_restore_regs (vcpu);
+
/* Unmask events. */
vcpu-vcpu_info-evtchn_upcall_mask = 0;
@@ -134,7 +153,7 @@ sioemu_deliver_event (void)
regs = sioemu_deliver ();
- regs-r16 = 0;
+ regs-r16 = SIOEMU_CB_EVENT;
}
void
@@ -145,11 +164,30 @@ sioemu_io_emulate (unsigned long padr,
REGS *regs;
regs = sioemu_deliver ();
- regs-r16 = 1;
+ regs-r16 = SIOEMU_CB_IO_EMULATE;
regs-r19 = padr;
regs-r20 = data;
regs-r21 = data1;
regs-r22 = word;
+}
+
+void
+sioemu_wakeup_vcpu (int vcpu_id)
+{
+ REGS *regs;
+
+ regs = sioemu_deliver();
+ regs-r16 = SIOEMU_CB_WAKEUP_VCPU;
+ regs-r19 = vcpu_id;
+}
+
+void
+sioemu_sal_assist (struct vcpu *v)
+{
+ REGS *regs;
+
+ regs = sioemu_deliver();
+ regs-r16 = SIOEMU_CB_SAL_ASSIST;
}
static int
@@ -191,7 +229,7 @@ sioemu_hypercall (struct pt_regs *regs)
//regs-r2,
[Xen-ia64-devel] PATCH: remove GPFN_INV_MASK
Hi,
this patch removes GPFN_INV_MASK. VTi code now uses INVALID_MFN like pv.
This slightly simplify code and free a pte bit (more to come here).
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1204864887 -3600
# Node ID 2b050b0bc7a6dd697d1b1c9711fd345f9f621c58
# Parent 99ed430040909e7edd203893a18a72d0d8de1c52
Remove GPFN_INV_MASK.
This slightly simplify code and free a pte bit.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 99ed43004090 -r 2b050b0bc7a6 xen/arch/ia64/vmx/sioemu.c
--- a/xen/arch/ia64/vmx/sioemu.cFri Mar 07 05:18:22 2008 +0100
+++ b/xen/arch/ia64/vmx/sioemu.cFri Mar 07 05:41:27 2008 +0100
@@ -208,7 +208,7 @@ sioemu_add_io_physmap (struct domain *d,
for (i = start; i start + size; i += PAGE_SIZE) {
unsigned long mpa;
mpa = lookup_domain_mpa(d, i);
-if (mpa != GPFN_INV_MASK mpa != INVALID_MFN)
+if (mpa != INVALID_MFN)
return -EBUSY;
}
diff -r 99ed43004090 -r 2b050b0bc7a6 xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.cFri Mar 07 05:18:22 2008 +0100
+++ b/xen/arch/ia64/xen/mm.cFri Mar 07 05:41:27 2008 +0100
@@ -726,8 +726,6 @@ lookup_domain_mpa(struct domain *d,
if (pte_present(*pte))
return (pte-pte _PFN_MASK);
-else if (VMX_DOMAIN(d-vcpu[0]))
-return GPFN_INV_MASK;
return INVALID_MFN;
}
@@ -742,8 +740,8 @@ unsigned long lookup_domain_mpa(struct d
if (entry != NULL)
p2m_entry_set(entry, pte, tmp_pte);
return pte_val(tmp_pte);
-} else if (VMX_DOMAIN(d-vcpu[0]))
-return GPFN_INV_MASK;
+} else if (is_hvm_domain(d))
+return INVALID_MFN;
}
if (mpaddr d-arch.convmem_end !d-is_dying) {
@@ -2797,7 +2795,7 @@ arch_memory_op(int op, XEN_GUEST_HANDLE(
}
/* This hypercall is used for VT-i domain only */
-if (!VMX_DOMAIN(d-vcpu[0])) {
+if (!is_hvm_domain(d)) {
rcu_unlock_domain(d);
return -ENOSYS;
}
diff -r 99ed43004090 -r 2b050b0bc7a6
xen/include/asm-ia64/linux-xen/asm/pgtable.h
--- a/xen/include/asm-ia64/linux-xen/asm/pgtable.h Fri Mar 07 05:18:22
2008 +0100
+++ b/xen/include/asm-ia64/linux-xen/asm/pgtable.h Fri Mar 07 05:41:27
2008 +0100
@@ -108,7 +108,6 @@
#define GPFN_HIGH_MMIO (7UL 60) /* High MMIO range */
#define GPFN_IO_MASK (7UL 60) /* Guest pfn is I/O type */
-#define GPFN_INV_MASK (1UL 63) /* Guest pfn is invalid */
#else
#define _PAGE_PROTNONE (__IA64_UL(1) 63)
@@ -342,8 +341,7 @@ set_pte_rel(volatile pte_t* ptep, pte_t
#define pte_file(pte) ((pte_val(pte) _PAGE_FILE) != 0)
#ifdef XEN
#define pte_pgc_allocated(pte) ((pte_val(pte) _PAGE_PGC_ALLOCATED) != 0)
-#define pte_mem(pte) \
- (!(pte_val(pte) (GPFN_IO_MASK | GPFN_INV_MASK)) !pte_none(pte))
+#define pte_mem(pte) (!(pte_val(pte) GPFN_IO_MASK)
!pte_none(pte))
#endif
/*
* Note: we convert AR_RWX to AR_RX and AR_RW to AR_R by clearing the 2nd bit
in the
diff -r 99ed43004090 -r 2b050b0bc7a6 xen/include/asm-ia64/mm.h
--- a/xen/include/asm-ia64/mm.h Fri Mar 07 05:18:22 2008 +0100
+++ b/xen/include/asm-ia64/mm.h Fri Mar 07 05:41:27 2008 +0100
@@ -479,7 +479,7 @@ extern u64 translate_domain_pte(u64 ptev
gmfn_to_mfn_foreign((_d), (gpfn))
#define __gpfn_invalid(_d, gpfn) \
- (lookup_domain_mpa((_d), ((gpfn)PAGE_SHIFT), NULL) GPFN_INV_MASK)
+ (lookup_domain_mpa((_d), ((gpfn)PAGE_SHIFT), NULL) == INVALID_MFN)
#define __gmfn_valid(_d, gpfn) !__gpfn_invalid(_d, gpfn)
@@ -488,8 +488,7 @@ extern u64 translate_domain_pte(u64 ptev
({ \
u64 pte, ret=0;\
pte = lookup_domain_mpa((_d), ((gpfn)PAGE_SHIFT), NULL); \
-if(!(pteGPFN_INV_MASK))\
-ret = pte GPFN_IO_MASK;\
+ret = (pte != INVALID_MFN) ? pte GPFN_IO_MASK : 0;\
ret;\
})
@@ -497,8 +496,7 @@ extern u64 translate_domain_pte(u64 ptev
({ \
u64 pte, ret=0;\
pte = lookup_domain_mpa((_d), ((gpfn)PAGE_SHIFT), NULL);\
-if((!(pteGPFN_INV_MASK))((pte GPFN_IO_MASK)==GPFN_MEM)) \
-ret = 1; \
+ret = (pte != INVALID_MFN) (pte GPFN_IO_MASK) == GPFN_MEM;\
ret;\
})
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH] unify vtlb and vhpt
Hi Kouya, to be honest I have mixed feelings about your patch. I like it but I don't really understand its purpose. See my comment. I still think it would be nice if the vTLB were TR-mapped. Quoting Kouya Shimura [EMAIL PROTECTED]: Dong, Eddie writes: This can be simply solved by increasing vTLB size, or use same memory with VHPT. The problem is, how much size is suitable? There is a trade off. The larger size consumes a time for ptc.e emulation and causes a serious slowdown for a Windows guest. Ok. Currently vTLB size is configurable but ordinary users can't understand what vTLB is. A purpose of this patch is to make users free from setting vTLB size. By merging vTLB and VHPT the user can't anymore set the size of the vTLB. This is obvious. But is your patch different from increasing vTLB size ? Did I miss a point ? I am not sure it is a good idea to remove vTLB size. On a real processor the TLB structure is fixed and defined. To tell the truth, I rewrote the vtlb_thash() function before. See. http://lists.xensource.com/archives/html/xen-ia64-devel/2007-08/msg00108.html I think the algorithm is the same as HW. I did a reverse engineering on a Montecito processor. (I'm afraid Montvale use the different algorithm...) This seems to be the same algorithm as the one for Madison. Cf Matthew Chapman pages. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [kvm-ia64-devel] [PATCH 0/4] ia64/xen: paravirtualization of hand written assembly code
Quoting Keith Owens [EMAIL PROTECTED]:
{...}
A combination of options (2) and (3) would work. Have a single source
file for the IVT, using conditional macros. Use that source file to
build (at least) two copies of the IVT, for native and any virtualized
modes. The native copy of the IVT starts at label ia64_ivt in section
.text.ivt, as it does now. Any IVT versions for virtualized mode are
defined as __cpuinitdata, so they are discarded after boot, unless
CONFIG_HOTPLUG_CPU=y. arch/ia64/kernel/head.S copies the relevant
virtualized version over ia64_ivt when necessary, before initializing
cr.iva.
Single source for maintenance. No indirect function overhead at run
time. Binary patching at boot time for the right mode. No wasted
space in the kernel.
Good idea. The linker script will be slightly more complex however...
Tristan.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [kvm-ia64-devel] [PATCH 0/4] ia64/xen: paravirtualization of hand written assembly code
Quoting Keith Owens [EMAIL PROTECTED]:
[EMAIL PROTECTED] (on Mon, 25 Feb 2008 13:54:48 +0100) wrote:
Quoting Keith Owens [EMAIL PROTECTED]:
{...}
A combination of options (2) and (3) would work. Have a single source
file for the IVT, using conditional macros. Use that source file to
build (at least) two copies of the IVT, for native and any virtualized
modes. The native copy of the IVT starts at label ia64_ivt in section
.text.ivt, as it does now. Any IVT versions for virtualized mode are
defined as __cpuinitdata, so they are discarded after boot, unless
CONFIG_HOTPLUG_CPU=y. arch/ia64/kernel/head.S copies the relevant
virtualized version over ia64_ivt when necessary, before initializing
cr.iva.
Single source for maintenance. No indirect function overhead at run
time. Binary patching at boot time for the right mode. No wasted
space in the kernel.
Good idea. The linker script will be slightly more complex however...
Don't see why the linker script needs to change at all. The existing
native IVT is at label ia64_ivt in section .text.ivt, as it is now.
arch/ia64/kernel/head.S simply overwrites ia64_ivt with 32K of data for
the virtualized IVT, copying from another data area. AFAICT, nothing
in that process requires linker changes.
Humm, what about relative jumps ? The object code must be linked as if it were
at .text.ivt. I suppose this is doable with OVERLAY in linker script.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: add a dump command to xenitp
Hi,
this patch adds a dump command to xenitp, which allows to display memory
content.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1203829710 -3600
# Node ID 9405d0ff17ab4e1934a9f17e956f78ad8b4ac5c0
# Parent 7c93b5ba807c9c1a4692813c6881f44ca625eb52
Add a dump command.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 7c93b5ba807c -r 9405d0ff17ab tools/debugger/xenitp/xenitp.c
--- a/tools/debugger/xenitp/xenitp.cMon Feb 18 07:26:23 2008 +0100
+++ b/tools/debugger/xenitp/xenitp.cSun Feb 24 06:08:30 2008 +0100
@@ -1081,6 +1081,36 @@ cmd_disassemble (char *args)
}
static enum cmd_status
+cmd_dump (char *args)
+{
+static unsigned long addr;
+unsigned long end_addr = addr + 256;
+unsigned long p;
+
+if (*args != 0) {
+if (parse_expr (args, addr, 0) 0)
+return CMD_ERROR;
+if (*args != 0) {
+if (parse_expr (args, end_addr, 0) 0)
+return CMD_ERROR;
+}
+else
+end_addr = addr + 256;
+}
+for (p = addr; p end_addr; p += 16) {
+int i;
+printf (%016lx:, p);
+for (i = 0; i 16; i++) {
+unsigned char *m = target_map_memory (p + i);
+printf (%c%02x, i == 8 ? '-' : ' ', *m);
+}
+printf (\n);
+}
+addr = end_addr;
+return CMD_REPEAT;
+}
+
+static enum cmd_status
cmd_break (char *args)
{
unsigned long addr;
@@ -1461,6 +1491,7 @@ const struct command_desc commands[] = {
{ quit, quit debugger, cmd_quit },
{ echo, display parameters, cmd_echo },
{ disassemble, disassemble memory, cmd_disassemble },
+{ dump, dump memory, cmd_dump },
{ break, set a break point, cmd_break },
{ watch, set a watch point, cmd_watch },
{ cb, resume until branch, cmd_cb },
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: clear console page for sioemu
Hi,
this patch fixes an annoying bug on sioemu: the console page was not
cleared during domain building. The domain fails to boot if the page
contained garbage.
(note: the start_page is cleared).
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1203830089 -3600
# Node ID 94f88355c04d5fb77f93b07918505711502511be
# Parent 9405d0ff17ab4e1934a9f17e956f78ad8b4ac5c0
Be sure console page is cleared.
This fixes a bug: by using pfn 0 for console, the page was not cleared.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 9405d0ff17ab -r 94f88355c04d tools/libxc/ia64/xc_ia64_dom_fwloader.c
--- a/tools/libxc/ia64/xc_ia64_dom_fwloader.c Sun Feb 24 06:08:30 2008 +0100
+++ b/tools/libxc/ia64/xc_ia64_dom_fwloader.c Sun Feb 24 06:14:49 2008 +0100
@@ -58,9 +58,11 @@ static int alloc_magic_pages(struct xc_d
static int alloc_magic_pages(struct xc_dom_image *dom)
{
/* allocate special pages */
-dom-console_pfn = 0;
-dom-xenstore_pfn = 1;
-dom-start_info_pfn = 2;
+/* Note: do not use 0 for console or xenstore otherwise clear_page won't
+ clear the page. */
+dom-start_info_pfn = 0;
+dom-console_pfn = 1;
+dom-xenstore_pfn = 2;
return 0;
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [PATCH] [Open GFW] Only use irq 10 and 11 for pci use.
Quoting Zhang, Xiantao [EMAIL PROTECTED]: Tristan Gingold wrote: On Tue, Dec 25, 2007 at 03:22:37PM +0800, Zhang, Xiantao wrote: Hi Tristan, This patch fixes possible failures on windows boot in some environment. Since current piix3 and piix4 in qemu only uses irq 10 and irq 11 for pci irqs, so here don't need to assign irq 5 and irq 6 for this purpose. IRQ 6 may conflict with the irq of legacy floppy disk controllers. Hi, I was about to commit this patch, but shouldn't EdkQemuPkg/Pei/BochsPciScan/BochsPciScan.c be updated too ? Yes. Sure to change. Maybe we need to consolidate these two definitions to one. Do you know how to ? Hi, old issue... If you can send me a changeset that changes both BochsPciScan and build.c I will be happy to apply it. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: fix warning
hi, fix compile time warning after recent patch. Tristan. # HG changeset patch # User Tristan Gingold [EMAIL PROTECTED] # Date 1203312598 -3600 # Node ID e2b8468d4bc6b9ab5d9d6699ee3f13a9c7ee47e3 # Parent 4cd5a4f036c4482a87d4e158c55e56deacaf84d6 Fix warning. Signed-off-by: Tristan Gingold [EMAIL PROTECTED] diff -r 4cd5a4f036c4 -r e2b8468d4bc6 xen/include/asm-ia64/vmx_vcpu.h --- a/xen/include/asm-ia64/vmx_vcpu.h Mon Feb 18 06:29:28 2008 +0100 +++ b/xen/include/asm-ia64/vmx_vcpu.h Mon Feb 18 06:29:58 2008 +0100 @@ -54,6 +54,7 @@ extern int check_indirect_reg_rsv_fields extern int check_indirect_reg_rsv_fields(int type, int index, u64 value); extern u64 set_isr_ei_ni(VCPU * vcpu); extern u64 set_isr_for_na_inst(VCPU * vcpu, int op); +extern void set_illegal_op_isr (VCPU *vcpu); /* next all for VTI domain APIs definition */ extern void vmx_vcpu_set_psr(VCPU * vcpu, unsigned long value); ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH[1/1]: Self IO Emulator
Hi,
this patch fixes the previously reported issue: old macro name used in tools.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1203314891 -3600
# Node ID d872714b6e5d1c1d810d1ed68f82305bf506a13a
# Parent e2b8468d4bc6b9ab5d9d6699ee3f13a9c7ee47e3
Implements Self-IOEMUlator - loader
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r e2b8468d4bc6 -r d872714b6e5d tools/libxc/ia64/Makefile
--- a/tools/libxc/ia64/Makefile Mon Feb 18 06:29:58 2008 +0100
+++ b/tools/libxc/ia64/Makefile Mon Feb 18 07:08:11 2008 +0100
@@ -7,6 +7,8 @@ GUEST_SRCS-y += ia64/xc_ia64_linux_resto
GUEST_SRCS-y += ia64/xc_dom_ia64_util.c
GUEST_SRCS-y += ia64/dom_fw_acpi.c
+
+GUEST_SRCS-y += ia64/xc_ia64_dom_fwloader.c
DOMFW_SRCS_BASE := dom_fw_common.c dom_fw_domu.c dom_fw_asm.S
endif
diff -r e2b8468d4bc6 -r d872714b6e5d tools/libxc/ia64/xc_dom_ia64_util.h
--- a/tools/libxc/ia64/xc_dom_ia64_util.h Mon Feb 18 06:29:58 2008 +0100
+++ b/tools/libxc/ia64/xc_dom_ia64_util.h Mon Feb 18 07:08:11 2008 +0100
@@ -16,4 +16,11 @@ xen_ia64_dom_fw_setup(struct xc_dom_imag
#define efi_systable_init_dom0(tables) assert(0)
#define complete_dom0_memmap(d, tables) ({assert(0);0;})
+/* Defined in xc_dom_ia64.c */
+extern int start_info_ia64(struct xc_dom_image *dom);
+extern int shared_info_ia64(struct xc_dom_image *dom, void *ptr);
+
+#define FW_MEM_BASE 0xff00UL
+#define FW_MEM_SIZE 0x0100UL
+
#endif /* XC_IA64_DOM_IA64_UTIL_H */
diff -r e2b8468d4bc6 -r d872714b6e5d tools/libxc/ia64/xc_ia64_dom_fwloader.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/tools/libxc/ia64/xc_ia64_dom_fwloader.c Mon Feb 18 07:08:11 2008 +0100
@@ -0,0 +1,124 @@
+#include stdlib.h
+#include inttypes.h
+#include asm/kregs.h
+
+#include xen/xen.h
+#include xen/foreign/ia64.h
+#include xen/io/protocols.h
+
+#include xg_private.h
+#include xc_dom.h
+
+#include ia64/xc_dom_ia64_util.h
+
+static const char fw_magic[16] = {'X', 'e', 'n', '-',
+ 'i', 'a', '6', '4',
+ '-', 'f', 'w', 0,
+ 0, 0, 0, 0};
+#define FW_LOAD 0xff80UL
+#define FW_SIZE (8 * 1024 * 1024)
+
+static int xc_dom_probe_fw_kernel(struct xc_dom_image *dom)
+{
+if (dom-kernel_size != FW_SIZE)
+return -EINVAL;
+if (memcmp (dom-kernel_blob, fw_magic, sizeof (fw_magic)))
+return -EINVAL;
+return 0;
+}
+
+static int xc_dom_parse_fw_kernel(struct xc_dom_image *dom)
+{
+dom-kernel_seg.vstart = FW_LOAD;
+dom-kernel_seg.vend = FW_LOAD + FW_SIZE;
+dom-parms.virt_base = FW_MEM_BASE;
+dom-parms.virt_entry = FW_LOAD + sizeof (fw_magic);
+dom-ramdisk_blob = NULL; /* No ramdisk yet. */
+dom-guest_type = hvm-3.0-ia64-sioemu;
+return 0;
+}
+
+static int xc_dom_load_fw_kernel(struct xc_dom_image *dom)
+{
+char *dest;
+unsigned long i;
+
+dest = xc_dom_vaddr_to_ptr(dom, dom-kernel_seg.vstart);
+memcpy(dest, dom-kernel_blob, FW_SIZE);
+
+/* Synchronize cache. */
+for (i = 0; i FW_SIZE; i += 32)
+asm volatile (fc.i %0 :: r(dest + i) : memory);
+
+return 0;
+}
+
+/* */
+
+static int alloc_magic_pages(struct xc_dom_image *dom)
+{
+/* allocate special pages */
+dom-console_pfn = 0;
+dom-xenstore_pfn = 1;
+dom-start_info_pfn = 2;
+return 0;
+}
+
+extern unsigned long xc_ia64_fpsr_default(void);
+
+static int vcpu_ia64(struct xc_dom_image *dom, void *ptr)
+{
+vcpu_guest_context_ia64_t *ctxt = ptr;
+
+xc_dom_printf(%s: called\n, __FUNCTION__);
+
+/* clear everything */
+memset(ctxt, 0, sizeof(*ctxt));
+
+ctxt-flags = 0;
+ctxt-regs.ip = dom-parms.virt_entry;
+#ifdef __ia64__/* FIXME */
+ctxt-regs.ar.fpsr = xc_ia64_fpsr_default();
+#endif
+ctxt-regs.cr.isr = 1UL 63;
+ctxt-regs.psr = IA64_PSR_AC | IA64_PSR_BN;
+ctxt-regs.cr.dcr = 0;
+ctxt-regs.cr.pta = 15 2;
+
+return 0;
+}
+
+static struct xc_dom_arch xc_dom_arch_ia64_fw = {
+.guest_type = hvm-3.0-ia64-sioemu,
+.native_protocol = XEN_IO_PROTO_ABI_IA64,
+.page_shift = PAGE_SHIFT_IA64,
+.alloc_magic_pages = alloc_magic_pages,
+.start_info = start_info_ia64,
+.shared_info = shared_info_ia64,
+.vcpu = vcpu_ia64,
+};
+
+/* */
+
+static struct xc_dom_loader fw_loader = {
+.name = xen-ia64-fw,
+.probe = xc_dom_probe_fw_kernel,
+.parser = xc_dom_parse_fw_kernel,
+.loader = xc_dom_load_fw_kernel,
+};
+
+static void __init register_fwloader(void)
+{
+xc_dom_register_arch_hooks(xc_dom_arch_ia64_fw);
+xc_dom_register_loader(fw_loader);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-set-style: BSD
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff -r e2b8468d4bc6 -r d872714b6e5d tools/libxc/xc_dom_ia64.c
---
[Xen-ia64-devel] PATCH[2/2]: Self IO Emulator - xen
Hi, updated version of the SIOEMU patch. Here is a config to be used. Firmware is still the same. Tristan. # -*- mode: python; -*- # # Python configuration setup for 'xm create'. # This script sets the parameters used when a domain is created using 'xm create'. # You use a separate script for each domain you want to create, or # you can set the parameters for the domain on the xm command line. # # # Kernel image file. kernel = /path-to/sioemu-fw # Optional ramdisk. #ramdisk = /boot/initrd.gz # The domain build function. Default is 'linux'. #builder='hvmstub' # Initial memory allocation (in megabytes) for the new domain. # # WARNING: Creating a domain with insufficient memory may cause out of # memory errors. The domain needs enough memory to boot kernel # and modules. Allocating less than 32MBs is not recommended. memory = 1024 # A name for your domain. All domains must have different names. name = dom-stub # 128-bit UUID for the domain. The default behavior is to generate a new UUID # on each call to 'xm create'. #uuid = 06ed00fe-1162-4fc4-b5d8-11993ee4a8b9 # List of which CPUS this domain is allowed to use, default Xen picks #cpus = # leave to Xen to pick #cpus = 0# all vcpus run on CPU0 #cpus = 0-3,5,^1 # run on cpus 0,2,3,5 # Number of Virtual CPUS to use, default is 1 #vcpus = 1 # # Define network interfaces. # By default, no network interfaces are configured. You may have one created # with sensible defaults using an empty vif clause: # # vif = [ '' ] # # or optionally override backend, bridge, ip, mac, script, type, or vifname: # # vif = [ 'mac=00:16:3e:00:00:11, bridge=xenbr0' ] # # or more than one interface may be configured: # # vif = [ '', 'bridge=xenbr1' ] #vif = [ '' ] # # Define the disk devices you want the domain to have access to, and # what you want them accessible as. # Each disk entry is of the form phy:UNAME,DEV,MODE # where UNAME is the device, DEV is the device name the domain will see, # and MODE is r for read-only, w for read-write. disk = [ 'phy:sda5,hda1,w' ] # # Define frame buffer device. # # By default, no frame buffer device is configured. # # To create one using the SDL backend and sensible defaults: # # vfb = [ 'type=sdl' ] # # This uses environment variables XAUTHORITY and DISPLAY. You # can override that: # # vfb = [ 'type=sdl,xauthority=/home/bozo/.Xauthority,display=:1' ] # # To create one using the VNC backend and sensible defaults: # # vfb = [ 'type=vnc' ] # # The backend listens on 127.0.0.1 port 5900+N by default, where N is # the domain ID. You can override both address and N: # # vfb = [ 'type=vnc,vnclisten=127.0.0.1,vncdisplay=1' ] # # Or you can bind the first unused port above 5900: # # vfb = [ 'type=vnc,vnclisten=0.0.0.0,vnunused=1' ] # # You can override the password: # # vfb = [ 'type=vnc,vncpasswd=MYPASSWD' ] # # Empty password disables authentication. Defaults to the vncpasswd # configured in xend-config.sxp. # # Define to which TPM instance the user domain should communicate. # The vtpm entry is of the form 'instance=INSTANCE,backend=DOM' # where INSTANCE indicates the instance number of the TPM the VM # should be talking to and DOM provides the domain where the backend # is located. # Note that no two virtual machines should try to connect to the same # TPM instance. The handling of all TPM instances does require # some management effort in so far that VM configration files (and thus # a VM) should be associated with a TPM instance throughout the lifetime # of the VM / VM configuration file. The instance number must be # greater or equal to 1. #vtpm = [ 'instance=1,backend=0' ] # # Set the kernel command line for the new domain. # You only need to define the IP parameters and hostname if the domain's # IP config doesn't, e.g. in ifcfg-eth0 or via DHCP. # You can use 'extra' to set the runlevel and custom environment # variables used by custom rc scripts (e.g. VMID=, usr= ). # Set if you want dhcp to allocate the IP address. #dhcp=dhcp # Set netmask. #netmask= # Set default gateway. #gateway= # Set the hostname. #hostname= vm%d % vmid # Set root device. root = /dev/hda1 ro # Root device for nfs. #root = /dev/nfs # The nfs server. #nfs_server = '169.254.1.0' # Root directory on the nfs server. #nfs_root = '/full/path/to/root/directory' # Sets runlevel 4. extra = 4
[Xen-ia64-devel] PATCH: long vhpt format for thash, ttag + tak
Hi,
this patch add long vhpt format emulation for thash and ttag. The hash
algorithm is hard-coded so that it can also be written in asm in optvfault.S
This patch also improve tak emulation and reformat tpa code.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1203315796 -3600
# Node ID 82a165516da6b696da444bf8dffd87b22816153a
# Parent f05d78cd9ed47a99e95694742c4036de8ddf5a4e
Handle long vhpt format for ttag and thash.
Improve tak emulation.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r f05d78cd9ed4 -r 82a165516da6 xen/arch/ia64/vmx/vmmu.c
--- a/xen/arch/ia64/vmx/vmmu.c Mon Feb 18 07:09:06 2008 +0100
+++ b/xen/arch/ia64/vmx/vmmu.c Mon Feb 18 07:23:16 2008 +0100
@@ -467,31 +467,37 @@ u64 vmx_vcpu_thash(VCPU *vcpu, u64 vadr)
ia64_rr vrr;
u64 pval;
u64 vhpt_offset;
+u64 mask;
+
+vpta.val = vmx_vcpu_get_pta(vcpu);
+vcpu_get_rr(vcpu, vadr, vrr.rrval);
+mask = (1UL vpta.size) - 1;
+if (vpta.vf) {
+vadr = (vadr 0x1fffUL) vrr.ps;
+vhpt_offset = vadr ^ vrr.rid;
+pval = (vpta.val ~0x7fffUL) + ((vhpt_offset 5) mask);
+} else {
+vhpt_offset=((vadrvrr.ps)3) mask;
+pval = (vadr VRN_MASK) |
+(vpta.val3(vpta.size+3)(vpta.size))|
+vhpt_offset;
+}
+return pval;
+}
+
+
+u64 vmx_vcpu_ttag(VCPU *vcpu, u64 vadr)
+{
+ia64_rr vrr;
+PTA vpta;
+u64 pval;
+u64 rid;
vpta.val = vmx_vcpu_get_pta(vcpu);
vcpu_get_rr(vcpu, vadr, vrr.rrval);
if(vpta.vf){
-pval = ia64_call_vsa(PAL_VPS_THASH, vadr, vrr.rrval,
- vpta.val, 0, 0, 0, 0);
-pval = vpta.val ~0x;
-}else{
-vhpt_offset=((vadrvrr.ps)3)((1UL(vpta.size))-1);
-pval = (vadr VRN_MASK) |
-(vpta.val3(vpta.size+3)(vpta.size))|
-vhpt_offset;
-}
-return pval;
-}
-
-
-u64 vmx_vcpu_ttag(VCPU *vcpu, u64 vadr)
-{
-ia64_rr vrr;
-PTA vpta;
-u64 pval;
-vpta.val = vmx_vcpu_get_pta(vcpu);
-vcpu_get_rr(vcpu, vadr, vrr.rrval);
-if(vpta.vf){
-pval = ia64_call_vsa(PAL_VPS_TTAG, vadr, vrr.rrval, 0, 0, 0, 0, 0);
+vadr = (vadr 0x1fffUL) vrr.ps;
+rid = vrr.rid;
+pval = vadr ^ (rid 39);
}else{
pval = 1;
}
@@ -507,83 +513,89 @@ IA64FAULT vmx_vcpu_tpa(VCPU *vcpu, u64 v
REGS *regs;
u64 vhpt_adr, madr;
IA64_PSR vpsr;
-regs=vcpu_regs(vcpu);
-pt_isr.val=VMX(vcpu,cr_isr);
-visr.val=0;
-visr.ei=pt_isr.ei;
-visr.ir=pt_isr.ir;
+
+regs = vcpu_regs(vcpu);
+pt_isr.val = VMX(vcpu, cr_isr);
+visr.val = 0;
+visr.ei = pt_isr.ei;
+visr.ir = pt_isr.ir;
vpsr.val = VCPU(vcpu, vpsr);
-visr.na=1;
+visr.na = 1;
+
+/* First look in VTLB. */
data = vtlb_lookup(vcpu, vadr, DSIDE_TLB);
-if(data){
-if(data-p==0){
+if (data) {
+if (data-p == 0) {
vcpu_set_isr(vcpu,visr.val);
data_page_not_present(vcpu, vadr);
return IA64_FAULT;
-}else if(data-ma == VA_MATTR_NATPAGE){
+} else if (data-ma == VA_MATTR_NATPAGE) {
vcpu_set_isr(vcpu, visr.val);
dnat_page_consumption(vcpu, vadr);
return IA64_FAULT;
-}else{
+} else {
*padr = ((data-ppn (data-ps - 12)) data-ps) |
(vadr (PSIZE(data-ps) - 1));
return IA64_NO_FAULT;
}
}
+
+/* Look in mVHPT. */
data = vhpt_lookup(vadr);
-if(data){
-if(data-p==0){
+if (data) {
+if (data-p == 0) {
vcpu_set_isr(vcpu,visr.val);
data_page_not_present(vcpu, vadr);
return IA64_FAULT;
-}else if(data-ma == VA_MATTR_NATPAGE){
+} else if (data-ma == VA_MATTR_NATPAGE) {
vcpu_set_isr(vcpu, visr.val);
dnat_page_consumption(vcpu, vadr);
return IA64_FAULT;
-}else{
+} else {
madr = (data-ppn (data-ps - 12) data-ps) |
(vadr (PSIZE(data-ps) - 1));
*padr = __mpa_to_gpa(madr);
return IA64_NO_FAULT;
}
}
-else{
-if(!vhpt_enabled(vcpu, vadr, NA_REF)){
-if(vpsr.ic){
-vcpu_set_isr(vcpu, visr.val);
-alt_dtlb(vcpu, vadr);
-return IA64_FAULT;
-}
-else{
-nested_dtlb(vcpu);
-return IA64_FAULT;
-}
-}
-else{
-vhpt_adr = vmx_vcpu_thash(vcpu, vadr);
-data = vtlb_lookup(vcpu, vhpt_adr, DSIDE_TLB);
-if(data){
-if(vpsr.ic){
-vcpu_set_isr(vcpu, visr.val);
-dtlb_fault(vcpu, vadr);
-return IA64_FAULT;
-}
-else{
-nested_dtlb(vcpu);
-return
[Xen-ia64-devel] PATCH: avoid wild use of registers in guest_vhpt_lookup
Hi,
this patch avoids wild use of registers (r9,p6,p7) in guest_vhpt_lookup.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1203315983 -3600
# Node ID 7c93b5ba807c9c1a4692813c6881f44ca625eb52
# Parent 82a165516da6b696da444bf8dffd87b22816153a
Avoid wild use of registers.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 82a165516da6 -r 7c93b5ba807c xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.c Mon Feb 18 07:23:16 2008 +0100
+++ b/xen/arch/ia64/vmx/vtlb.c Mon Feb 18 07:26:23 2008 +0100
@@ -272,9 +272,10 @@ thash_data_t * vhpt_lookup(u64 va)
u64 guest_vhpt_lookup(u64 iha, u64 *pte)
{
-u64 ret;
+u64 ret, tmp;
thash_data_t * data;
+/* Try to fill mTLB for the gVHPT entry. */
data = vhpt_lookup(iha);
if (data == NULL) {
data = __vtr_lookup(current, iha, DSIDE_TLB);
@@ -285,17 +286,18 @@ u64 guest_vhpt_lookup(u64 iha, u64 *pte)
asm volatile (rsm psr.ic|psr.i;;
srlz.d;;
- ld8.s r9=[%1];;
- tnat.nz p6,p7=r9;;
- (p6) mov %0=1;
- (p6) mov r9=r0;
- (p7) extr.u r9=r9,0,53;;
- (p7) mov %0=r0;
- (p7) st8 [%2]=r9;;
+ ld8.s %1=[%2];;/* Read VHPT
entry. */
+ tnat.nz p6,p7=%1;; /* Success ? */
+ (p6) mov %0=1; /* No - ret =
1. */
+ (p6) mov %1=r0;
+ (p7) extr.u %1=%1,0,53;; /* Yes - mask ig bits. */
+ (p7) mov %0=r0;/* - ret =
0. */
+ (p7) st8 [%3]=%1;; /* - save. */
ssm psr.ic;;
srlz.d;;
ssm psr.i;;
- : =r(ret) : r(iha), r(pte):memory);
+ : =r(ret), =r(tmp)
+ : r(iha), r(pte):memory,p6,p7);
return ret;
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH[1/2] Self IO EMUlator (sioemu) - Hypervisor part
Hi,
these patches implements the self io emulator. It's an hybrid domain: looks
like PV from an external point of view but runs with VTI enabled.
All MMIO/IO writes/reads are reflected to the firmware, which converts the
access to PV drivers requests.
The most difference with the previous patch is the loader, which is now
fully integrated with PV loaders (only the image format change).
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1202795731 -3600
# Node ID 6ba0c3a71fe1e3579e4d07bfa54a26fd8648a7ad
# Parent 8bbc0b7b1759314d7c640874e71556479f95b532
Implements Self IO-EMUlator.
Hypervisor part.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 8bbc0b7b1759 -r 6ba0c3a71fe1 xen/arch/ia64/vmx/Makefile
--- a/xen/arch/ia64/vmx/MakefileTue Feb 12 06:43:56 2008 +0100
+++ b/xen/arch/ia64/vmx/MakefileTue Feb 12 06:55:31 2008 +0100
@@ -21,3 +21,4 @@ obj-y += vacpi.o
obj-y += vacpi.o
obj-y += vmx_vcpu_save.o
obj-y += save.o
+obj-y += sioemu.o
diff -r 8bbc0b7b1759 -r 6ba0c3a71fe1 xen/arch/ia64/vmx/mmio.c
--- a/xen/arch/ia64/vmx/mmio.c Tue Feb 12 06:43:56 2008 +0100
+++ b/xen/arch/ia64/vmx/mmio.c Tue Feb 12 06:55:31 2008 +0100
@@ -39,6 +39,8 @@
#include asm/hvm/vacpi.h
#include asm/hvm/support.h
#include public/hvm/save.h
+#include public/arch-ia64/sioemu.h
+#include asm/sioemu.h
#define HVM_BUFFERED_IO_RANGE_NR 1
@@ -388,6 +390,8 @@ static void mmio_access(VCPU *vcpu, u64
return;
}
+enum inst_type_en { SL_INTEGER, SL_FLOATING, SL_FLOATING_FP8 };
+
/*
dir 1: read 0:write
*/
@@ -396,11 +400,12 @@ void emulate_io_inst(VCPU *vcpu, u64 pad
REGS *regs;
IA64_BUNDLE bundle;
int slot, dir=0;
-enum { SL_INTEGER, SL_FLOATING, SL_FLOATING_FP8 } inst_type;
+enum inst_type_en inst_type;
size_t size;
u64 data, data1, temp, update_reg;
s32 imm;
INST64 inst;
+unsigned long update_word;
regs = vcpu_regs(vcpu);
if (IA64_RETRY == __vmx_get_domain_bundle(regs-cr_iip, bundle)) {
@@ -523,24 +528,54 @@ void emulate_io_inst(VCPU *vcpu, u64 pad
inst.inst, regs-cr_iip);
}
+update_word = size | (dir 7) | (ma 8) | (inst_type 12);
+if (dir == IOREQ_READ) {
+if (inst_type == SL_INTEGER)
+update_word |= (inst.M1.r1 16);
+else if (inst_type == SL_FLOATING_FP8)
+update_word |= (inst.M12.f1 16) | (inst.M12.f2 24);
+}
+
+if (vcpu-domain-arch.is_sioemu) {
+unsigned long iot;
+iot = __gpfn_is_io(vcpu-domain, padr PAGE_SHIFT);
+
+if (iot != GPFN_PIB iot != GPFN_IOSAPIC) {
+sioemu_io_emulate (padr, data, data1, update_word);
+return;
+}
+}
+
if (size == 4) {
mmio_access(vcpu, padr + 8, data1, 1 3, ma, dir);
size = 3;
}
mmio_access(vcpu, padr, data, 1 size, ma, dir);
+emulate_io_update (vcpu, update_word, data, data1);
+}
+
+void
+emulate_io_update (VCPU *vcpu, u64 word, u64 data, u64 data1)
+{
+int dir = (word 7) 1;
+
if (dir == IOREQ_READ) {
+int r1 = (word 16) 0xff;
+int r2 = (word 24) 0xff;
+enum inst_type_en inst_type = (word 12) 0x0f;
+
if (inst_type == SL_INTEGER) {
-vcpu_set_gr(vcpu, inst.M1.r1, data, 0);
+vcpu_set_gr(vcpu, r1, data, 0);
} else if (inst_type == SL_FLOATING_FP8) {
struct ia64_fpreg v;
v.u.bits[0] = data;
v.u.bits[1] = 0x1003E;
-vcpu_set_fpreg(vcpu, inst.M12.f1, v);
+vcpu_set_fpreg(vcpu, r1, v);
v.u.bits[0] = data1;
v.u.bits[1] = 0x1003E;
-vcpu_set_fpreg(vcpu, inst.M12.f2, v);
+vcpu_set_fpreg(vcpu, r2, v);
} else {
panic_domain(NULL, Don't support ldfd now !);
}
diff -r 8bbc0b7b1759 -r 6ba0c3a71fe1 xen/arch/ia64/vmx/sioemu.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/xen/arch/ia64/vmx/sioemu.cTue Feb 12 06:55:31 2008 +0100
@@ -0,0 +1,223 @@
+/* -*- Mode:C; c-basic-offset:4; tab-width:4; indent-tabs-mode:nil -*- */
+/*
+ * sioemu.c: Self IO emulation - hypercall and return.
+ * Copyright (c) 2008, Tristan Gingold [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 asm/vcpu.h
+#include asm/vmx_vcpu.h
+#include
[Xen-ia64-devel] PATH: makes xenitp more '|tee' friendly
Hi, when stdout is redirected, it is buffered. To make xenitp more '|tee' friendly (or any other piped command), just flush stdout after printing the prompt. Tristan. # HG changeset patch # User Tristan Gingold [EMAIL PROTECTED] # Date 1202795036 -3600 # Node ID 8bbc0b7b1759314d7c640874e71556479f95b532 # Parent bac4cda6eb309d41f910b70fec00c3995cdc51d7 Flush stdout after printing the prompt. Makes xenitp more '|tee' friendly. Signed-off-by: Tristan Gingold [EMAIL PROTECTED] diff -r bac4cda6eb30 -r 8bbc0b7b1759 tools/debugger/xenitp/xenitp.c --- a/tools/debugger/xenitp/xenitp.cThu Feb 07 06:29:34 2008 +0100 +++ b/tools/debugger/xenitp/xenitp.cTue Feb 12 06:43:56 2008 +0100 @@ -1577,6 +1577,7 @@ void xenitp (int vcpu) int len; printf (XenITP ); +fflush (stdout); if (fgets (buf, sizeof (buf), stdin) == NULL) break; ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Time for hybrid virtualization?
Quoting Dong, Eddie [EMAIL PROTECTED]: Yes, we met this too yesterday, current Xen/IA64 doesn't check supported VA address bits # in architecture safe way, it just assume it is 61 bits. See http://lists.xensource.com/archives/html/xen-ia64-devel/2006-10/msg00227.html for a patch. This one was not fully ok and VA size is statically defined. main issue my patch addresses. The other issue is VHPT long format. Can u repost it? We need to make Xen/IA64 following SDM. Yes, LVHPT is another major gap, good catch indeed! This is worth to solving, and it should not be a very big effort if we don't work guest page table. Luckily, today's Xen/IA64 is implementing virtual TLB rather than shadow page table which makes it simple, right? Xen vti allows a LVHPT but do as if it doesn't exist. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH][Open GFW] fix incorrect EFI memmap
Quoting Akio Takebe [EMAIL PROTECTED]: Yes, I also confirmed the memory is not clear at booting EFI. The memory was cleared by linux kernel because the region set conventional memory. Ok, I now understand the issue. Thanks. Can you apply also the new patch? Sure. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH][Open GFW] fix make dsdt.c
Quoting Akio Takebe [EMAIL PROTECTED]: Hi, Tristan I cannot make dsdt.c in edk2-sparse/EdkXenPkg/Dxe/XenAcpi. The patch fix it. Well, I am not a big fan of this approach. I'd really prefer each developer installs its own version of iasl. Maybe the documentation should be improved. (there is already an iasl package for debian so it is very easy with this distribution). Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Time for hybrid virtualization?
Quoting Xu, Anthony [EMAIL PROTECTED]: Hi Alex, I'm a little confused by hybrid mode for IA64. If all priviledged instructions are emulated by VT, Seems we don't need to modify linux kernel. Other modifications except privileged instructions are not performance critical. We can remove it. Not sure we can avoid to virtualize iosapic for example. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: ´ð¸´: [Xen-ia64-devel] Re: [PATCH 0/12] various fixes related the xenrelocation
Quoting de Dinechin, Christophe (Integrity VM) [EMAIL PROTECTED]: Another peculiar thing about HPUX, which probably has some impact, is that its performance is tuned and dependent on variable page sizes. So you should expect for example user-space mappings to contain, say, 4K, 16K, 1M and 4M pages for the same process. The reason it may matter for Xen is if you do physical address translation (as I assume you do). In that case, it's possible that the guest requests 4M of what it thinks is physically contiguous memory, but the corresponding host memory is not contiguous. In that case, you need to break up the large page into smaller pages. We do exactly that: break up large pages into smaller pages. Not really good for performance... Stupid question from a newcomer: what does metaphysical mean? Funny name ;-) Indeed. It is the mode when the guest is in physical (ie MMU disabled) mode. Invented by Dan, from HP. I think the support is complete enough for VMS although we don't yet support protection keys. Does HP-UX use them ? Yes, pretty extensively. So we will have to add support for them... Well, we used to boot with IDE a long time ago, but we have dropped IDE support for so long that I cannot really tell if a modern HPUX can still boot that way. Can you boot from CD ? Which disk controller does HP support and which one does the HP VM emulate ? (If you are allowed to answer!) Our disk controller and VGA adapter are really basic. HPUX can boot headless, so no problem even if there is no VGA at all. Ok. This is definitely not a difficult problem, but may prevent HP-UX from going far. I don't know enough about how Xen emulates instructions. If there is any binary translation of privileged operations (I think that's not the case, just checking), then the generated code accesses data in guest endianness, and must be ready to deal with (unprivileged) endianness changes. There are no translation, just emulation. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: ´ð¸´: [Xen-ia64-devel] Re: [PATCH 0/12] various fixes related the xenrelocation
Quoting de Dinechin, Christophe (Integrity VM) [EMAIL PROTECTED]: Well, we used to boot with IDE a long time ago, but we have dropped IDE support for so long that I cannot really tell if a modern HPUX can still boot that way. Can you boot from CD ? Which disk controller does HP support and which one does the HP VM emulate ? (If you are allowed to answer!) You can boot HPUX from CD (DVD actually). I do not know the exact list of disk controllers. HPVM now emulates MPT SCSI as a disk controller, and the Intel i82546 for networking. It's not a secret, any customer can tell by looking at the hardware from within an HPVM guest :-) For HPUX, we also have accelerated drivers starting with HPVM version 3.5. Also not a secret, it's one of the selling points of that version :-) For example, here is what lspci says on one of my Linux guests: 00:00.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion MPT Dual Ultra320 SCSI (rev 07) 00:01.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controler 00:03.0 ISA bridge: Intel Corporation 82372FB PIIX5 ISA (rev 01) The physical devices we emulate were chosen because they were supported by all guest operating systems we cared about, and their design made it possible to get relatively good performance when virtualized. However, they are not the simplest to emulate. Xen is far behind as all devices emulated are rather old devices. (I once tried to find the spec of 53c1030 but was not lucky.) Do you have rough performance benchmarks for Xen running a VT-i guest right now? We discarded trap-and-emulate very early in the HPVM design because an early experiment had shown that on Itanium, fault handling alone amounted to something like 15% performance degradation. This may have changed with more recent chips, but I'm curious about this. I don't have figure but maybe some were sent in the mailing list. For sure VT-i degradation is severe. The Xen approach is para-virtualization where a tiny part of the OS is rewritten. This approach is very effective but works only for open source OSes. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: ´ð¸´: [Xen-ia64-devel] Re: [PATCH 0/12] various fixes related the xenrelocation
Quoting Yuzhong Sun [EMAIL PROTECTED]: Hi Kazuhiro, We are considering possibility to Xen-ia64 support to HP-UX. Obviously, the current Xen-ia64 supports Linux regarding of HP-UX is not open-sourced. Do you have any ideas about how to implement this kind of possibility? Change which parts or libs? Hi, interesting idea! Unless you have the sources of HP-UX, you're bound to use VTi. You can try to install HP-UX and see when/where it crashes. HP-UX is big endian. That can be an issue, because I am pretty sure big-endian support is not complete. Our VTi virtual machine is almost a PC with an ia64 instead of an x86. This is rather far from an HP zx1 machine. I am currently trying to run OpenVMS on Xen/ia64 and the last point is currently the blocking one. I have a plan to address it. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] Fix vmx_asm_thash
Quoting Kouya Shimura [EMAIL PROTECTED]: It must be typo. Certainly mine. Thanks for catching it. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH][TAKE3] Fix vulnerability of copy_to_user in PAL emulation
Quoting Kouya Shimura [EMAIL PROTECTED]: Hi, The reputation of my previous patch was not so good, then I rewrote it. An attached patch is temporary fix for xen-3.2. I think this patch is enough for normal usage. Please see SDM Vol2 11.10.2.1.3 Making PAL Procedure Calls in Physical or Virtual Mode. If the caller has a responsibility of providing DTR or DTC mapping, xencomm for PAL might be unnecessary. Right, that's a very interesting way. It also implies the buffer can't spread across two pages. I confirmed there is no problem in linux, windows 2003, windows 2008 with this patch. Good! As for PV domain, the same logic can't be used due to only one vTLB. This patch only checks that the buffer never point VMM address, that would avoid the vulnerability. Ok. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Open Guest Firmware/IPF test report
Quoting Mu, Qin [EMAIL PROTECTED]: Issues: -- 1. Standard VGA can't be supported in either linux or windows guest HVM when stdvga option was switched on in configuration file. This is expected. Should we embed the two vgabios in the GFW and copy the right one according to the VGA card OR should we declare stdvga as unsupported ? 2. Even if configured with USB mouse in guest HVM, mouse's behavior is too far from users' expectation to tolerate, particularly to window guys. I fear windows doesn't support USB tablet... Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [Xen-ia64][GFW PATCH]VGA high color fix
Quoting Zhang, Xing Z [EMAIL PROTECTED]: Yes. I also notice that. The VGA bios produced in compiling time. But IA64 can not generate IA32 code, so QEMU doesn't load VGA bios at our side. So I withdraw all my objections! ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] Fix vulnerability of copy_to_user in PAL emulation
Quoting Kouya Shimura [EMAIL PROTECTED]: There is a security vulnerability in PAL emulation since alt-dtlb miss handler of HVM absolutely inserts a identity-mapped TLB when psr.vm=0. HVM guest can access an arbitrary machine physical memory with this security hole. Actually windows 2008 destroys the content of machine physical address 0x108000. This is a serious problem. Hi, I was not aware that this issue was that serious. Thank you for pointing this out. I think your solution is not the right approach. We already have a mechanism to avoid TLB issues: xencomm, and I think we should re-use it. As we control the PAL (which is always in guest space), I think we should simply xencomm-ize it (Must be done both in the GFW and PV firmware). Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-ia64][GFW PATCH]VGA high color fix
Quoting Zhang, Xing Z [EMAIL PROTECTED]: This patch fixes low VGA show in windows guest. Congrat! The root cause is win2k3 will check VGA bios during HalInitSystem(). Open GFW has no VGA bios support. I see. I suppose win2k3 has an x86 emulator (or ia32-el). This patch is for that. I suppose the cirrus bios is the cirrus-bios image ? Do you know how it is loaded on x86/ia32 ? Hi Tristan: I'd like to invoke CopyMem() which includes in BaseMemoryLib in VgaInit.c. I add BaseMemoryLib declaration in VgaInit.msa but it still complains undefined reference to CopyMem during link time. What I lost? I directly copy InternalMemCopyMem() to VgaInit.c as a workaround but it need be replaced by CopyMem() when it is checked in. Could you offer me some help on this compiling issue? I don't know how to do this by heart, but I will take care of this. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] PATCH: remove is_vti
Quoting Masaki Kanno [EMAIL PROTECTED]: Hi Tristan, I have two questions. The general answer is: this is for backward compatibility. I think we could remove that in the future. [...] Why should we check both flags? Is XEN_DOMAINSETUP_hvm_guest flag for xm restore command? No. [...] Why should we set is_hvm flag? I think that is_hvm flag was already set in domain_create(). True, but we were able to switch from PV to hvm with this hypercall! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: remove is_vti
Hi,
in fact is_vti is a duplicate of is_hvm. This patch remove the ia64 is_vti
flag.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1196660723 -3600
# Node ID c5ffe6158794a0dfc8d71004da8354088e5e5d72
# Parent 32ec5dbe2978fdff4682912de0c78a14d479a8a3
Remove is_vti arch flag.
arch.is_vti is a duplicate of is_hvm.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 32ec5dbe2978 -r c5ffe6158794 tools/libxc/ia64/xc_ia64_hvm_build.c
--- a/tools/libxc/ia64/xc_ia64_hvm_build.c Fri Nov 30 08:54:33 2007 -0700
+++ b/tools/libxc/ia64/xc_ia64_hvm_build.c Mon Dec 03 06:45:23 2007 +0100
@@ -980,7 +980,7 @@ setup_guest(int xc_handle, uint32_t dom,
goto error_out;
}
-domctl.u.arch_setup.flags = XEN_DOMAINSETUP_hvm_guest;
+domctl.u.arch_setup.flags = 0;
domctl.u.arch_setup.bp = 0;
domctl.u.arch_setup.maxmem = GFW_START + GFW_SIZE;
if (dom_memsize MMIO_START)
diff -r 32ec5dbe2978 -r c5ffe6158794 xen/arch/ia64/linux-xen/unwind.c
--- a/xen/arch/ia64/linux-xen/unwind.c Fri Nov 30 08:54:33 2007 -0700
+++ b/xen/arch/ia64/linux-xen/unwind.c Mon Dec 03 06:45:23 2007 +0100
@@ -2012,7 +2012,7 @@ unw_unwind_to_user (struct unw_frame_inf
return 0;
#else
if (unw_is_intr_frame(info)
- !info-task-domain-arch.is_vti
+ !is_hvm_vcpu (info-task)
(pr (1UL PRED_USER_STACK)))
return 0;
/*
@@ -2021,7 +2021,7 @@ unw_unwind_to_user (struct unw_frame_inf
* we need to stop unwinding somehow.
*/
if (unw_is_intr_frame(info)
- info-task-domain-arch.is_vti
+ is_hvm_vcpu (info-task)
info-pr_loc == vcpu_regs(info-task)-pr)
return 0;
#endif
diff -r 32ec5dbe2978 -r c5ffe6158794 xen/arch/ia64/xen/dom0_ops.c
--- a/xen/arch/ia64/xen/dom0_ops.c Fri Nov 30 08:54:33 2007 -0700
+++ b/xen/arch/ia64/xen/dom0_ops.c Mon Dec 03 06:45:23 2007 +0100
@@ -89,7 +89,7 @@ long arch_do_domctl(xen_domctl_t *op, XE
if (ds-flags XEN_DOMAINSETUP_query) {
/* Set flags. */
-if (d-arch.is_vti)
+if (is_hvm_domain (d))
ds-flags |= XEN_DOMAINSETUP_hvm_guest;
/* Set params. */
ds-bp = 0;/* unknown. */
@@ -104,12 +104,13 @@ long arch_do_domctl(xen_domctl_t *op, XE
ret = -EFAULT;
}
else {
-if (ds-flags XEN_DOMAINSETUP_hvm_guest) {
+if (is_hvm_domain (d)
+|| (ds-flags XEN_DOMAINSETUP_hvm_guest)) {
if (!vmx_enabled) {
printk(No VMX hardware feature for vmx domain.\n);
ret = -EINVAL;
} else {
-d-arch.is_vti = 1;
+d-is_hvm = 1;
xen_ia64_set_convmem_end(d, ds-maxmem);
ret = vmx_setup_platform(d);
}
diff -r 32ec5dbe2978 -r c5ffe6158794 xen/arch/ia64/xen/domain.c
--- a/xen/arch/ia64/xen/domain.cFri Nov 30 08:54:33 2007 -0700
+++ b/xen/arch/ia64/xen/domain.cMon Dec 03 06:45:23 2007 +0100
@@ -510,7 +510,7 @@ int vcpu_late_initialise(struct vcpu *v)
void vcpu_destroy(struct vcpu *v)
{
- if (v-domain-arch.is_vti)
+ if (is_hvm_vcpu (v))
vmx_relinquish_vcpu_resources(v);
else
relinquish_vcpu_resources(v);
@@ -982,12 +982,12 @@ void arch_get_info_guest(struct vcpu *v,
c.nat-event_callback_ip = v-arch.event_callback_ip;
/* If PV and privregs is not set, we can't read mapped registers. */
- if (!v-domain-arch.is_vti v-arch.privregs == NULL)
+ if (!is_hvm_vcpu (v) v-arch.privregs == NULL)
return;
vcpu_get_dcr(v, c.nat-regs.cr.dcr);
- c.nat-regs.cr.itm = v-domain-arch.is_vti ?
+ c.nat-regs.cr.itm = is_hvm_vcpu (v) ?
vmx_vcpu_get_itm(v) : PSCBX(v, domain_itm);
vcpu_get_iva(v, c.nat-regs.cr.iva);
vcpu_get_pta(v, c.nat-regs.cr.pta);
@@ -1000,7 +1000,7 @@ void arch_get_info_guest(struct vcpu *v,
vcpu_get_iha(v, c.nat-regs.cr.iha);
//XXX change irr[] and arch.insvc[]
- if (v-domain-arch.is_vti)
+ if (is_hvm_vcpu (v))
/* c.nat-regs.cr.ivr = vmx_vcpu_get_ivr(v)*/;//XXXnot SMP-safe
else
vcpu_get_ivr (v, c.nat-regs.cr.ivr);
@@ -1178,7 +1178,7 @@ int arch_set_info_guest(struct vcpu *v,
/* Finish vcpu initialization. */
if (!was_initialised) {
- if (d-arch.is_vti)
+ if (is_hvm_domain (d))
rc = vmx_final_setup_guest(v);
else
rc = vcpu_late_initialise(v);
@@ -1227,7 +1227,7 @@ int arch_set_info_guest(struct vcpu *v,
uregs-r10 =
[Xen-ia64-devel] PATH: add VGCF_SET_CR_IRR
Hi,
unconditionnaly setting cr_irr by vcpu_setcontext broke xenitp (and other)
debugger.
This patch adds a flag so that debugged vcpus don't miss interrupts.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1196206966 -3600
# Node ID 878389697fc07c0b885b7b46ccd7d087c2df8742
# Parent 2106d9ddc767405777e9ca811a8cb095b665983e
vcpu_setcontext: only set cr_irr if VGCF_SET_CR_IRR flag is set.
cr_irr can be modified even when a vcpu is blocked (by itv handler).
Unconditionnaly setting cr_irr can trouble debugger as it may clear a bit
of cr_irr and thus miss an interrupt. This can be very annoying if the
interrupt is itv and the vcpu is inside PAL_HALT_LIGHT (the vcpu stays
blocked forever).
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 2106d9ddc767 -r 878389697fc0 tools/libxc/ia64/xc_ia64_linux_restore.c
--- a/tools/libxc/ia64/xc_ia64_linux_restore.c Fri Nov 23 04:54:32 2007 +0100
+++ b/tools/libxc/ia64/xc_ia64_linux_restore.c Wed Nov 28 00:42:46 2007 +0100
@@ -127,7 +127,7 @@ xc_ia64_recv_vcpu_context(int xc_handle,
fprintf(stderr, ip=%016lx, b0=%016lx\n, ctxt-regs.ip, ctxt-regs.b[0]);
/* Initialize and set registers. */
-ctxt-flags = VGCF_EXTRA_REGS;
+ctxt-flags = VGCF_EXTRA_REGS | VGCF_SET_CR_IRR;
if (xc_vcpu_setcontext(xc_handle, dom, vcpu, ctxt) != 0) {
ERROR(Couldn't set vcpu context);
return -1;
diff -r 2106d9ddc767 -r 878389697fc0 xen/arch/ia64/vmx/vmx_vcpu_save.c
--- a/xen/arch/ia64/vmx/vmx_vcpu_save.c Fri Nov 23 04:54:32 2007 +0100
+++ b/xen/arch/ia64/vmx/vmx_vcpu_save.c Wed Nov 28 00:42:46 2007 +0100
@@ -118,8 +118,8 @@ vmx_arch_set_info_guest(struct vcpu *v,
unsigned long vnat;
unsigned long vbnat;
- union vcpu_ar_regs *ar = c.nat-regs.ar;
- union vcpu_cr_regs *cr = c.nat-regs.cr;
+union vcpu_ar_regs *ar = c.nat-regs.ar;
+union vcpu_cr_regs *cr = c.nat-regs.cr;
int i;
// banked registers
@@ -177,13 +177,15 @@ vmx_arch_set_info_guest(struct vcpu *v,
vpd_low-iim = cr-iim;
vpd_low-iha = cr-iha;
vpd_low-lid = cr-lid;
+vpd_low-tpr = cr-tpr;
vpd_low-ivr = cr-ivr; //XXX vlsapic
-vpd_low-tpr = cr-tpr;
vpd_low-eoi = cr-eoi;
-vpd_low-irr[0] = cr-irr[0];
-vpd_low-irr[1] = cr-irr[1];
-vpd_low-irr[2] = cr-irr[2];
-vpd_low-irr[3] = cr-irr[3];
+if (c.nat-flags VGCF_SET_CR_IRR) {
+vpd_low-irr[0] = cr-irr[0];
+vpd_low-irr[1] = cr-irr[1];
+vpd_low-irr[2] = cr-irr[2];
+vpd_low-irr[3] = cr-irr[3];
+}
vpd_low-itv = cr-itv;
vpd_low-pmv = cr-pmv;
vpd_low-cmcv = cr-cmcv;
diff -r 2106d9ddc767 -r 878389697fc0 xen/include/public/arch-ia64.h
--- a/xen/include/public/arch-ia64.hFri Nov 23 04:54:32 2007 +0100
+++ b/xen/include/public/arch-ia64.hWed Nov 28 00:42:46 2007 +0100
@@ -435,6 +435,7 @@ struct vcpu_guest_context_regs {
struct vcpu_guest_context {
#define VGCF_EXTRA_REGS (1UL 1) /* Set extra regs. */
+#define VGCF_SET_CR_IRR (1UL 2) /* Set cr_irr[0:3]. */
unsigned long flags; /* VGCF_* flags */
struct vcpu_guest_context_regs regs;
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: allows ia64 hypercall in vti mode
Hi, until now it was not possible to use ia64 specific hypercalls (those whose number is beyond 64). This patch enables it. (Found during tries on opt_feature from GFW). Tristan. # HG changeset patch # User Tristan Gingold [EMAIL PROTECTED] # Date 1196207416 -3600 # Node ID 420be5702efd03de91c4184c7aebad07d5e1eb51 # Parent 878389697fc07c0b885b7b46ccd7d087c2df8742 Only use streamlined entry/exit for xen hypercall. This patch allows to use ia64 specific hypercalls in vti mode. Signed-off-by: Tristan Gingold [EMAIL PROTECTED] diff -r 878389697fc0 -r 420be5702efd xen/arch/ia64/vmx/vmx_ivt.S --- a/xen/arch/ia64/vmx/vmx_ivt.S Wed Nov 28 00:42:46 2007 +0100 +++ b/xen/arch/ia64/vmx/vmx_ivt.S Wed Nov 28 00:50:16 2007 +0100 @@ -472,7 +472,7 @@ ENTRY(vmx_break_fault) ;; ld4 r22=[r22] extr.u r24=r29,IA64_PSR_CPL0_BIT,2 -cmp.eq p0,p6=r0,r0 +cmp.ltu p6,p0=NR_hypercalls,r2 ;; cmp.ne.or p6,p0=r22,r17 cmp.ne.or p6,p0=r0,r24 ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [RFC] hvm-stub for ia64
Quoting Keir Fraser [EMAIL PROTECTED]: Does the hvmstub have to look different to an hvm guest from the p.o.v. of the tools? It's rather a shame to introduce a third kind of domain at that level. There are of course differences: qemu shouldn't be started. And the builder C function is different. I can try to merge with the hvm builder function but I am not sure it is worth. The amount of new code is still rather small for tools. How do you think this appraoch compares with a separate stub domain per HVM guest? That's the approach being developed on the x86 side, but it would be nice to not increase divergence between x86 and ia64. I think my approach is much more simpler. Just look at the amount of new code for hypervisor and tools: very small. There is nothing ia64 specific in hvmstub. For performance, it requires cheap virtual to physical (ie switching paging on and off) transitions in the guest, but I think this is already true for x86. The real work is in the stub firmware which could be partially shared between x86 and ia64. However I'd also like to implement more realistic machine emulation for ia64 in order to be able to run more OSes. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [RFC] hvm-stub for ia64
Quoting Keir Fraser [EMAIL PROTECTED]: On 22/11/07 09:31, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Presumably the old HVM builder for ia64 becomes dead code though? So really this is the 'new' hvm building path. Do you need to support the old way (on ia64) if this is checked in? Yes, I don't plan to remove the old way on ia64. I have not implemented a VGA in the stub firmware and I don't plan to do it soon. Only Windows requires a VGA and I don't have Windows for ia64. I doubt the magnitude of changes in tools/hypervisor is different between the two approaches. It might even be smaller in the separate domain approach. We are speaking about around 200 lines of code in the hypervisor and slightly more for tools (300 lines mostly ia64 specific), right ? Is the stub domain code already available ? I'd like to have a look. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [RFC] hvm-stub for ia64
Quoting Samuel Thibault [EMAIL PROTECTED]: That's the main difference between your approach (reimplement a firmware) and the approach being developped here at XenSource (embed qemu in a tiny stubdomain). Your VMX work in Xen is most probably something useful, but reimplementing the hardware emulation support of qemu looks to me like duplicate work. Of course it doesn't reimplement the emulation. The current biggest emulation is the IDE and I have copied ide.c from qemu and made almost no modification. The advantage is my approach is no need for scheduling between two domains for hardware emulation. With the current hvm model, I reach the EFI prompt in about 10sec. With my hvmstub it took less than 2 seconds. Very pleasant to use! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-devel] Re: [Xen-ia64-devel] [RFC 2/3] hvm-stub for ia64: xen
Quoting Isaku Yamahata [EMAIL PROTECTED]:
On Thu, Nov 22, 2007 at 05:00:41AM +0100, [EMAIL PROTECTED] wrote:
{...}
do_softirq() should be called before the device emulation code.
The device emulation code uses timer and the timer callbacks which
are called by softirq may change the device status and trigger interrupts.
I see. In fact I moved do_softirq to improve debugging but it is not required.
Tristan.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [RFC] hvm-stub for ia64
Quoting Samuel Thibault [EMAIL PROTECTED]: [EMAIL PROTECTED], le Thu 22 Nov 2007 12:12:31 +0100, a écrit : Quoting Samuel Thibault [EMAIL PROTECTED]: Of course it doesn't reimplement the emulation. The current biggest emulation is the IDE and I have copied ide.c from qemu and made almost no modification. That's still forking. And you'll also need to do it for vga, network, ... To be fair, I'd need to know better how stubdomain is implemented. The advantage is my approach is no need for scheduling between two domains for hardware emulation. Ah, yes, on ia64 you have room to load your firmware in the domain itself, which makes an extra benefit (with the stubdomain we avoid the need for linux scheduling, but not the need for xen scheduling). Should be the same on x86. Firmware is loaded between 4GB-16MB and 4GB. Enough room for stub firmware and EFI. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: add phy to phy_d and reverse in vmx_phy_mode
Hi,
this patch add some missing transitions due to recently added phy_d mode.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1195790072 -3600
# Node ID 2106d9ddc767405777e9ca811a8cb095b665983e
# Parent 011d69784045c331ee49cb9285c7bcc18e1924d0
Add physical to physical data only and reverse transitions.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 011d69784045 -r 2106d9ddc767 xen/arch/ia64/vmx/vmx_phy_mode.c
--- a/xen/arch/ia64/vmx/vmx_phy_mode.c Fri Nov 23 04:29:01 2007 +0100
+++ b/xen/arch/ia64/vmx/vmx_phy_mode.c Fri Nov 23 04:54:32 2007 +0100
@@ -33,9 +33,9 @@
(((psr).it 2) + ((psr).dt 1) + (psr).rt)
#define SW_BAD0 /* Bad mode transitition */
-#define SW_V2P_DT 1 /* Physical emulation is activated */
-#define SW_V2P_D 2 /* Physical emulation is activated (only for data) */
-#define SW_P2V3 /* Exit physical mode emulation */
+#define SW_2P_DT 1 /* Physical emulation is activated */
+#define SW_2P_D 2 /* Physical emulation is activated (only for data) */
+#define SW_2V 3 /* Exit physical mode emulation */
#define SW_SELF 4 /* No mode transition */
#define SW_NOP5 /* Mode transition, but without action required */
@@ -59,8 +59,10 @@ static const unsigned char mm_switch_tab
* service. Due to gva = gpa in this case (Same region),
* data access can be satisfied though itlb entry for physical
* emulation is hit.
- */
-{SW_SELF,0, 0, SW_NOP, 0, 0, 0, SW_P2V},
+ *
+ * (it,dt,rt): (0,0,0) - (1,0,1)
+ */
+{SW_SELF,0, 0, SW_NOP, 0, SW_2P_D, 0, SW_2V},
{0, 0, 0, 0, 0, 0, 0, 0},
{0, 0, 0, 0, 0, 0, 0, 0},
/*
@@ -70,16 +72,18 @@ static const unsigned char mm_switch_tab
* (it,dt,rt): (0,1,1) - (0,0,0)
* This kind of transition is found in OSYa
*/
-{SW_NOP, 0, 0, SW_SELF,0, 0, 0, SW_P2V},
+{SW_NOP, 0, 0, SW_SELF,0, 0, 0, SW_2V},
/* (1,0,0)-(1,1,1) */
-{0, 0, 0, 0, 0, 0, 0, SW_P2V},
+{0, 0, 0, 0, 0, 0, 0, SW_2V},
/*
* (it,dt,rt): (1,0,1) - (1,1,1)
* This kind of transition usually occurs when Linux returns
* from the low level TLB miss handlers.
* (see arch/ia64/kernel/ivt.S)
- */
-{0, 0, 0, 0, 0, SW_SELF,0, SW_P2V},
+ *
+ * (it,dt,rt): (1,0,1) - (0,0,0)
+ */
+{SW_2P_DT, 0, 0, 0, 0, SW_SELF,0, SW_2V},
{0, 0, 0, 0, 0, 0, 0, 0},
/*
* (it,dt,rt): (1,1,1) - (1,0,1)
@@ -90,9 +94,10 @@ static const unsigned char mm_switch_tab
* This kind of transition usually occurs in pal and efi calls,
* which requires running in physical mode.
* (see arch/ia64/kernel/head.S)
- * (1,1,1)-(1,0,0)
- */
-{SW_V2P_DT, 0, 0, 0, SW_V2P_D, SW_V2P_D, 0, SW_SELF},
+ *
+ * (it,dt,rt): (1,1,1)-(1,0,0)
+ */
+{SW_2P_DT, 0, 0, 0, SW_2P_D, SW_2P_D, 0, SW_SELF},
};
void
@@ -234,17 +239,17 @@ switch_mm_mode(VCPU *vcpu, IA64_PSR old_
act = mm_switch_action(old_psr, new_psr);
perfc_incra(vmx_switch_mm_mode, act);
switch (act) {
-case SW_V2P_DT:
+case SW_2P_DT:
vcpu-arch.arch_vmx.mmu_mode = VMX_MMU_PHY_DT;
switch_to_physical_rid(vcpu);
break;
-case SW_V2P_D:
+case SW_2P_D:
//printk(V - P_D mode transition: (0x%lx - 0x%lx)\n,
// old_psr.val, new_psr.val);
vcpu-arch.arch_vmx.mmu_mode = VMX_MMU_PHY_D;
switch_to_physical_rid(vcpu);
break;
-case SW_P2V:
+case SW_2V:
//printk(P - V mode transition: (0x%lx - 0x%lx)\n,
// old_psr.val, new_psr.val);
vcpu-arch.arch_vmx.mmu_mode = VMX_MMU_VIRTUAL;
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: extract debug_op.h from arch-ia64.h
Hi,
I think arch-ia64.h is getting too big and becomes a bag of stuff.
In order to make things more clear and reduce maintainance, this patch
extracts debug_op.h from arch-ia64.h
Patch for both xen and linux tree.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1195788541 -3600
# Node ID 011d69784045c331ee49cb9285c7bcc18e1924d0
# Parent 53dc1cf505060a06e5b34a4812fce4312743ca26
Extract debug_op.h from arch-ia64.h
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 53dc1cf50506 -r 011d69784045 xen/arch/ia64/vmx/vmx_vcpu.c
--- a/xen/arch/ia64/vmx/vmx_vcpu.c Wed Nov 21 09:12:06 2007 -0700
+++ b/xen/arch/ia64/vmx/vmx_vcpu.c Fri Nov 23 04:29:01 2007 +0100
@@ -35,6 +35,7 @@
#include asm/vmx_mm_def.h
#include asm/vmx.h
#include asm/vmx_phy_mode.h
+#include asm/debugger.h
/**
VCPU general register access routines
diff -r 53dc1cf50506 -r 011d69784045 xen/arch/ia64/xen/hypercall.c
--- a/xen/arch/ia64/xen/hypercall.c Wed Nov 21 09:12:06 2007 -0700
+++ b/xen/arch/ia64/xen/hypercall.c Fri Nov 23 04:29:01 2007 +0100
@@ -32,6 +32,7 @@
#include public/callback.h
#include xen/event.h
#include xen/perfc.h
+#include public/arch-ia64/debug_op.h
extern long do_physdev_op(int cmd, XEN_GUEST_HANDLE(void) arg);
extern long do_callback_op(int cmd, XEN_GUEST_HANDLE(void) arg);
diff -r 53dc1cf50506 -r 011d69784045 xen/include/asm-ia64/debugger.h
--- a/xen/include/asm-ia64/debugger.h Wed Nov 21 09:12:06 2007 -0700
+++ b/xen/include/asm-ia64/debugger.h Fri Nov 23 04:29:01 2007 +0100
@@ -40,6 +40,7 @@
#include xen/sched.h
#include xen/softirq.h
#include xen/gdbstub.h
+#include public/arch-ia64/debug_op.h
void show_registers(struct cpu_user_regs *regs);
void dump_stack(void);
diff -r 53dc1cf50506 -r 011d69784045 xen/include/public/arch-ia64.h
--- a/xen/include/public/arch-ia64.hWed Nov 21 09:12:06 2007 -0700
+++ b/xen/include/public/arch-ia64.hFri Nov 23 04:29:01 2007 +0100
@@ -579,79 +579,6 @@ struct xen_ia64_boot_param {
/* Extra debug features. */
#define __HYPERVISOR_ia64_debug_op __HYPERVISOR_arch_2
-/* Set/Get extra conditions to break. */
-#define XEN_IA64_DEBUG_OP_SET_FLAGS 1
-#define XEN_IA64_DEBUG_OP_GET_FLAGS 2
-
-/* Break on kernel single step. */
-#define XEN_IA64_DEBUG_ON_KERN_SSTEP (1 0)
-
-/* Break on kernel debug (breakpoint or watch point). */
-#define XEN_IA64_DEBUG_ON_KERN_DEBUG (1 1)
-
-/* Break on kernel taken branch. */
-#define XEN_IA64_DEBUG_ON_KERN_TBRANCH (1 2)
-
-/* Break on interrupt injection. */
-#define XEN_IA64_DEBUG_ON_EXTINT (1 3)
-
-/* Break on interrupt injection. */
-#define XEN_IA64_DEBUG_ON_EXCEPT (1 4)
-
-/* Break on event injection. */
-#define XEN_IA64_DEBUG_ON_EVENT(1 5)
-
-/* Break on privop/virtualized instruction (slow path only). */
-#define XEN_IA64_DEBUG_ON_PRIVOP (1 6)
-
-/* Break on emulated PAL call (at entry). */
-#define XEN_IA64_DEBUG_ON_PAL (1 7)
-
-/* Break on emulated SAL call (at entry). */
-#define XEN_IA64_DEBUG_ON_SAL (1 8)
-
-/* Break on emulated EFI call (at entry). */
-#define XEN_IA64_DEBUG_ON_EFI (1 9)
-
-/* Break on rfi emulation (slow path only, before exec). */
-#define XEN_IA64_DEBUG_ON_RFI (1 10)
-
-/* Break on address translation switch. */
-#define XEN_IA64_DEBUG_ON_MMU (1 11)
-
-/* Break on bad guest physical address. */
-#define XEN_IA64_DEBUG_ON_BAD_MPA (1 12)
-
-/* Force psr.ss bit. */
-#define XEN_IA64_DEBUG_FORCE_SS(1 13)
-
-/* Force psr.db bit. */
-#define XEN_IA64_DEBUG_FORCE_DB(1 14)
-
-/* Break on ITR/PTR. */
-#define XEN_IA64_DEBUG_ON_TR (1 15)
-
-/* Break on ITC/PTC.L/PTC.G/PTC.GA. */
-#define XEN_IA64_DEBUG_ON_TC (1 16)
-
-/* Get translation cache. */
-#define XEN_IA64_DEBUG_OP_GET_TC 3
-
-/* Translate virtual address to guest physical address. */
-#define XEN_IA64_DEBUG_OP_TRANSLATE 4
-
-#ifndef __ASSEMBLY__
-union xen_ia64_debug_op {
-uint64_t flags;
-struct xen_ia64_debug_vtlb {
-uint64_t nbr; /* IN/OUT */
-XEN_GUEST_HANDLE_64(ia64_tr_entry_t) tr; /* IN/OUT */
-} vtlb;
-};
-typedef union xen_ia64_debug_op xen_ia64_debug_op_t;
-DEFINE_XEN_GUEST_HANDLE(xen_ia64_debug_op_t);
-#endif /* __ASSEMBLY__ */
-
/* Xencomm macros. */
#define XENCOMM_INLINE_MASK 0xf800UL
#define XENCOMM_INLINE_FLAG 0x8000UL
diff -r 53dc1cf50506 -r 011d69784045 xen/include/public/arch-ia64/debug_op.h
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/xen/include/public/arch-ia64/debug_op.h Fri Nov 23 04:29:01 2007 +0100
@@ -0,0 +1,96 @@
+/**
+ * debug_op.h
+ *
+ * Copyright (c) 2007 Tristan Gingold [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ *
RE: [Xen-ia64-devel] E100 emulator is ready
Quoting Zhang, Xing Z [EMAIL PROTECTED]: Which doc you refer to could tell me how to understand .spd file and .msa file? I search in EDK2's website but get nothing. As far as now, I don't know how to configure these files to build a new driver. IIRC (I don't have the sources here), there is a doc directory either in edk2 or available from tianocore.org. It describe how to add a driver. There is a java applet which helps to do so. Avoid to write these files by hand and use the applet. Even if it is not straightforward, it helps a lot (java is slow but this is another issue...) Tell me if you need more details, I will have a look. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] E100 emulator is ready
Quoting Zhang, Xing Z [EMAIL PROTECTED]: I had a look. I get the doc you mentioned, it introduces the driver lib interface in EDK. But what I want is format of .spd and .msa. See edk2/docs and Build_Packaging_Spec, Module_Surface_Area. what the java tool is? How can I get it? FrameworkWizard. It comes with edk2 so it should be in your path along with build. I used drivers command in EFI shell to see installed drivers during boot time. There is no Cirrus driver. Can we do something to get Cirrus driver work? Reading Xen-Ipf.fpd the Cirrus GOP driver seems to be included. Can you check it is at least compiled ? (I don't currently have access to the ia64). I know I had disabled it but I can't remember how -) Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] E100 emulator is ready
Quoting Zhang, Xing Z [EMAIL PROTECTED]: Tristan. I have a question about current VGA driver in GFW. There are three driver relative files --- vgainit.c vgaclass.c vgaminiport.c. All the driver entry point such as PciVgaMiniPortDriverEntryPoint() are commented. The reason is no EfiLibInstallAllDriverProtocols() function called by driver entry in version 2398 of EDK2, which is current GFW base on. But without the entry point function, how these drivers are installed? Why I have this question is Intel's GFW use VgaMiniport driver with some other logic, and windows can get high color show. VgaInit just setup the vga card (initialize registers and load a font). It doesn't install any protocol. VgaMiniPort publish a protocol to drive a VGA card. VgaClass is a layer to install SimpleTextOut on VgaMiniPorts *EntryPoint are commented because the entry point function is created by the build tool. They also automatically install all protocols. See created files in BUILD/ I don't know how things are supposed to work. My hypothesis is: * Windows knows nothing about the Cirrus, ie all the work must be in the GFW. * Currently the graphic drivers are not compiled (no UGA, no GOP). * I suppose windows enable graphics during EFI phase. And I think GOP is required. The edk2 contains a Cirrus driver. I suppose both GOP and UGA are supported. I had tested it. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] E100 emulator is ready
Quoting Zhang, Xing Z [EMAIL PROTECTED]: Hi All: I am sorry I spent so long a time on E100 emulator, you know, windows is really hard to debug. Anyway it working now, and seems performs better than rtl8139. The attachment is the patch enable E100 in XEN. Hope you can try it on your box to see if everything is ok. Some codes of this emulator are from old eepro100 implementation in QEMU. Congratulation and thank you for the work! We now have networking on Windows. If you like to work on qemu, you can try to add support for a more modern VGA adapter (ATI rage xl or radeon)... :-) Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH][GFW] Fix typo in SalProc
Quoting Alex Williamson [EMAIL PROTECTED]: We're passing the width in place of the data for 1 byte PCI config writes. This shows up when the guest OS tries to write registers such as the cache line size register. With newer upstream Linux kernels, this makes the rtl8139 non-functional as it tries to set a 128 byte cache line size and fails. Thanks for catching this! ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH][GFW] reimplement cfc/cf8 _CRS data
Quoting Alex Williamson [EMAIL PROTECTED]: Since I/O port addresses 0xcfc 0xcf8 do PCI config space cycles on a QEMU box, it seems like we should hide them from the guest OS. This patch adds back a chunk that I previous changed thinking we could advertise a legacy free I/O port space. Thanks, Ok. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Xen on montvale ?
Has anyone tried to run Xen on Montvale ? ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: increase NITRS/NDTRS to 12
Hi,
VMS needs at least 9 DTRS, so I have increased the number of [ID]TRS to 12.
I don't know if this is the right thing to do or if we should add a
config parameter to set the number of trs.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1193631279 -3600
# Node ID 219de952ed630f9118de2981d754c1029b242db4
# Parent 6e6eab061b9f9708afb50e9ceaa82fa21156ae69
Bump NITRS/NDTRS to 12.
(VMS needs at least 9 DTRS).
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 6e6eab061b9f -r 219de952ed63 xen/include/asm-ia64/tlb.h
--- a/xen/include/asm-ia64/tlb.hSun Oct 28 06:45:38 2007 +0100
+++ b/xen/include/asm-ia64/tlb.hMon Oct 29 05:14:39 2007 +0100
@@ -1,8 +1,8 @@
#ifndef XEN_ASM_IA64_TLB_H
#define XEN_ASM_IA64_TLB_H
-#defineNITRS 8
-#define NDTRS 8
+#define NITRS 12
+#define NDTRS 12
union pte_flags {
struct {
diff -r 6e6eab061b9f -r 219de952ed63 xen/include/public/arch-ia64.h
--- a/xen/include/public/arch-ia64.hSun Oct 28 06:45:38 2007 +0100
+++ b/xen/include/public/arch-ia64.hMon Oct 29 05:14:39 2007 +0100
@@ -297,8 +297,8 @@ DEFINE_XEN_GUEST_HANDLE(ia64_tr_entry_t)
DEFINE_XEN_GUEST_HANDLE(ia64_tr_entry_t);
struct vcpu_tr_regs {
-struct ia64_tr_entry itrs[8];
-struct ia64_tr_entry dtrs[8];
+struct ia64_tr_entry itrs[12];
+struct ia64_tr_entry dtrs[12];
};
union vcpu_ar_regs {
@@ -402,6 +402,7 @@ struct vcpu_guest_context_regs {
/* Physical registers in case of debug event. */
unsigned long excp_iipa;
+unsigned long excp_ifa;
unsigned long excp_isr;
unsigned int excp_vector;
@@ -421,7 +422,7 @@ struct vcpu_guest_context_regs {
};
struct vcpu_guest_context {
-#define VGCF_EXTRA_REGS (1UL 1) /* Get/Set extra regs. */
+#define VGCF_EXTRA_REGS (1UL 1) /* Set extra regs. */
unsigned long flags; /* VGCF_* flags */
struct vcpu_guest_context_regs regs;
diff -r 6e6eab061b9f -r 219de952ed63 xen/include/public/foreign/reference.size
--- a/xen/include/public/foreign/reference.size Sun Oct 28 06:45:38 2007 +0100
+++ b/xen/include/public/foreign/reference.size Mon Oct 29 05:14:39 2007 +0100
@@ -7,9 +7,9 @@ cpu_user_regs | 68
cpu_user_regs | 68 200 -
xen_ia64_boot_param | - - 96
ia64_tr_entry | - - 32
-vcpu_tr_regs | - - 512
-vcpu_guest_context_regs | - - 21904
-vcpu_guest_context|28005168 21936
+vcpu_tr_regs | - - 768
+vcpu_guest_context_regs | - - 22176
+vcpu_guest_context|28005168 22208
arch_vcpu_info| 24 16 0
vcpu_time_info| 32 32 32
vcpu_info | 64 64 48
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: typo in ia64-dis.c
Hi, fix a stupid typo. Tristan. # HG changeset patch # User Tristan Gingold [EMAIL PROTECTED] # Date 1193550338 -3600 # Node ID 6e6eab061b9f9708afb50e9ceaa82fa21156ae69 # Parent 54be43f5954665bd01e25dc4ec385c2e131a6d83 Fix a typo. Signed-off-by: Tristan Gingold [EMAIL PROTECTED] diff -r 54be43f59546 -r 6e6eab061b9f tools/debugger/xenitp/ia64-dis.c --- a/tools/debugger/xenitp/ia64-dis.c Fri Sep 28 06:42:25 2007 +0200 +++ b/tools/debugger/xenitp/ia64-dis.c Sun Oct 28 06:45:38 2007 +0100 @@ -228,7 +228,7 @@ print_insn_ia64 (bfd_vma memaddr, struct case 20: strcpy (regname, cr.ifa); break; case 21: strcpy (regname, cr.itir); break; case 22: strcpy (regname, cr.iipa); break; - case 23: strcpy (regname, cr.ifa); break; + case 23: strcpy (regname, cr.ifs); break; case 24: strcpy (regname, cr.iim); break; case 25: strcpy (regname, cr.iha); break; case 64: strcpy (regname, cr.lid); break; ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] PATCH: merge PV and VTi kr
Quoting Xu, Anthony [EMAIL PROTECTED]: [EMAIL PROTECTED] wrote: Hi, previously VTi and PV didn't save kr into the same place. This wasted a little bit of memory. VTi now saves kr in privregs. The privregs is corresponding to VPD structure in VTI, The kr fields is reserved in VPD, In Vti, we can't save kr into privregs Argh, you're right. I thought this was in the vmm_avail area. Thanks for pointing this out! BTW, I should check the usage of vpsr_dfh and hpsr_dfh because I thought they are also used in VTi mode. Anyway I don't think we want the domain to be able to modify hpsr_* flags. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: PATCH: check r2 value for VTi mov rr[r3]=r2
Quoting Alex Williamson [EMAIL PROTECTED]: On Mon, 2007-10-22 at 03:51 +0200, [EMAIL PROTECTED] wrote: Hi, RID value was not checked for mov_to_rr. This is a security hole as it allowed a VTi domain to read memory of any other domain. Also use C fall-back for thash when long VHPT format is used. Comments added. Hi Tristan, This seems to be missing a chunk to define IA64_DOMAIN_RID_BITS_OFFSET. Thanks, Argh, I will complete the patch. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: [patch 5/5] IA64: Kexec: Use a separate RID for EFI
Quoting Simon Horman [EMAIL PROTECTED]: [...] I'll add some more documentation but here is a run down: According to xen/arch/ia64/xen/regionreg.c the RID space is broken up into chunks, one per domain, and 0th block is for Xen. The 0th block is broken up into small blocks, which are used for metaphisical mappins, except for the 0th small block which is used by Xen. Correct. By default each large block is 18 bits wide. And each small block is 1/64 the width of a large block, or in other words, 12 bits wide. These default values are the ones that end up being used on my RX2620 box. 18 bits is the minimum and 1/64 is the current maximum so 12 bits is the minimum. What isn't obvious to me is how the 0th small block is divided up. While xen/arch/ia64/xen/regionreg.c seems to handle allocating RIDs for domains, they hypervisor's RIDs seem to be handled in a bit more of an ad-hoc fashion. The 0th small block is not used except during startup. Once domains are run, hypervisor uses domains RIDs. In xen/include/asm-ia64/mmu_context.h there is IA64_REGION_ID_KERNEL. This is used to form an RID in the follwing way: a: bit 0: VHPT b: bit 1: reserved (0) c: bits 2-7: log 2 page_size d: bits 8-10: Region (0-7, corresponding to the 8 region registers) e: bits 10-N: IA64_REGION_ID_KERNEL (0) f: bits N-53: reserved (0) N is defined by the platform. Areas c and d above form the RID, it just happens to be further divided in two due to the way that its value is calculated buy the code. This subdivision does not reflect any hardware limitation. The hardware sets the limit of the with of this area to between 17 and 24 bits. I I believe that on Itanium it is 17 and on 18 is the minimum, 24 the maximum. Itanium2 it is 24 and my RX2620 box seems to have 24 bits. This means that N should always between 25 (8+17) and 32 (8+24). As we are only using the first 4 bits (3 bits in area d and 1 bit in area e) of RID space, and our small-block should have 12 bits, this should be fine - which is nice because these are the IDs that the hypervisor is using, as set in _start(). As stated above only until RIDs are set by domain 0. I couldn't find a place where the hypervisor gave itself additional RIDs to play with that weren't realated to a domain, so I just took the next slot by defining IA64_REGION_ID_EFI=1, so we can use the following RIDs. a: bit 0: VHPT (1) b: bit 1: reserved (0) c: bits 2-7: log 2 page_size d: bits 8-10: Region (0-7, corresponding to the 8 region registers) e: bits 10-N: IA64_REGION_ID_KERNEL (1) f: bits N-53: reserved (0) * Only 0 is used as we only need one RID. Its not really important what this number is, so long as its between 0 and 7. The nice thing about this is that we are still only using 4 bits of RID space, so it shouldn't have any chance of running into an adjacent small-block. Correct. However, I am not entirely convinced that this avoids an RID collision. Mostly because I'm not entirely convinced that other RIDs aren't being used. If so, then I guess there is an allocation mechanism that I haven't managed to find yet. There is no possible collision. Don't worry! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [patch 2/8] Kexec: Allow page fault handler to handle EFI regions
Quoting Simon Horman [EMAIL PROTECTED]: If the EFI region is mapped into a region within the address space usually used by guests, then the page_fault handler needs to know about it. A description of why this mapping is made is included in the patch that makes the mapping. The patch to actually make use of this code is separate. This does not take into account other ways that relevant functions are called. In particular: - vcpu_itc_d() and vcpu_itc_i() call translate_domain_pte() - ia64_shadow_fault() and vcpu_tpa() call vcpu_translate() This patch needs work, and I am positing it for discussion. Honestly I don't really like this part of the patch: it adds complexity to an already complex area. EFI_[UN]CACHED_OFFSET areas are id-mapped. So why can't the tlb miss be handled directly in the ivt (like we do for id-mapped Xen area) ? Maybe I don't really understand the issues so do not hesitate to explain! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: define IA64_DOMAIN_RID_BITS_OFFSET
Hi, this completes the previous patch. It defines IA64_DOMAIN_RID_BITS_OFFSET. To be applied before the last patch. Sorry for the delay, Tristan. # HG changeset patch # User Tristan Gingold [EMAIL PROTECTED] # Date 1193183335 -7200 # Node ID 2daf73cb51fdc308ed3770b0505a931df2e991b9 # Parent 769c23dcfbf1a2bfcac5307d45e32bdd0e16d969 Define IA64_DOMAIN_RID_BITS_OFFSET. Signed-off-by: Tristan Gingold [EMAIL PROTECTED] diff -r 769c23dcfbf1 -r 2daf73cb51fd xen/arch/ia64/asm-offsets.c --- a/xen/arch/ia64/asm-offsets.c Mon Oct 22 03:49:25 2007 +0200 +++ b/xen/arch/ia64/asm-offsets.c Wed Oct 24 01:48:55 2007 +0200 @@ -78,6 +78,7 @@ void foo(void) BLANK(); DEFINE(IA64_DOMAIN_SHADOW_BITMAP_OFFSET, offsetof (struct domain, arch.shadow_bitmap)); + DEFINE(IA64_DOMAIN_RID_BITS_OFFSET, offsetof (struct domain, arch.rid_bits)); BLANK(); ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: minor fixes in domain.h
Hi,
it seems I also forget to post the changes in domain.h:
* unsigned added (where it makes sense)
* rid_bits is now u8
* indentation.
I don't think it is technically required for the previous patch but still
it's far cleaner.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1193187169 -7200
# Node ID 91705524ac96026d374b866cf297d7e1fb4d46c8
# Parent 2daf73cb51fdc308ed3770b0505a931df2e991b9
Add unsigned, rid_bits is now u8.
Reformat comments.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 2daf73cb51fd -r 91705524ac96 xen/include/asm-ia64/domain.h
--- a/xen/include/asm-ia64/domain.h Wed Oct 24 01:48:55 2007 +0200
+++ b/xen/include/asm-ia64/domain.h Wed Oct 24 02:52:49 2007 +0200
@@ -137,17 +137,17 @@ struct arch_domain {
one big range, used to virtualize domain RID,
one small range for internal Xen use (metaphysical). */
/* Big range. */
-int starting_rid; /* first RID assigned to domain */
-int ending_rid;/* one beyond highest RID assigned to domain */
+unsigned int starting_rid; /* first RID assigned to domain */
+unsigned int ending_rid; /* one beyond highest RID assigned to domain */
/* Metaphysical range. */
-int starting_mp_rid;
-int ending_mp_rid;
+unsigned int starting_mp_rid;
+unsigned int ending_mp_rid;
/* RID for metaphysical mode. */
-unsigned long metaphysical_rid_dt; /* dt=it=0 */
-unsigned long metaphysical_rid_d; /* dt=0, it=1 */
+unsigned int metaphysical_rid_dt; /* dt=it=0 */
+unsigned int metaphysical_rid_d;/* dt=0, it=1 */
-int rid_bits; /* number of virtual rid bits (default: 18) */
-int breakimm; /* The imm value for hypercalls. */
+unsigned char rid_bits;/* number of virtual rid bits (default:
18) */
+int breakimm; /* The imm value for hypercalls. */
struct virtual_platform_def vmx_platform;
#definehvm_domain vmx_platform /* platform defs are not vmx specific */
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: merge PV and VTi kr
Hi,
previously VTi and PV didn't save kr into the same place. This wasted
a little bit of memory.
VTi now saves kr in privregs.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1193187544 -7200
# Node ID 396f89316b8bc74aee932790e19f1c5885da117c
# Parent 91705524ac96026d374b866cf297d7e1fb4d46c8
Merge PV and VTi kr registers.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 91705524ac96 -r 396f89316b8b xen/arch/ia64/vmx/vmx_init.c
--- a/xen/arch/ia64/vmx/vmx_init.c Wed Oct 24 02:52:49 2007 +0200
+++ b/xen/arch/ia64/vmx/vmx_init.c Wed Oct 24 02:59:04 2007 +0200
@@ -232,14 +232,14 @@ vmx_save_state(struct vcpu *v)
/* Need to save KR when domain switch, though HV itself doesn;t
* use them.
*/
- v-arch.arch_vmx.vkr[0] = ia64_get_kr(0);
- v-arch.arch_vmx.vkr[1] = ia64_get_kr(1);
- v-arch.arch_vmx.vkr[2] = ia64_get_kr(2);
- v-arch.arch_vmx.vkr[3] = ia64_get_kr(3);
- v-arch.arch_vmx.vkr[4] = ia64_get_kr(4);
- v-arch.arch_vmx.vkr[5] = ia64_get_kr(5);
- v-arch.arch_vmx.vkr[6] = ia64_get_kr(6);
- v-arch.arch_vmx.vkr[7] = ia64_get_kr(7);
+ v-arch.privregs-krs[0] = ia64_get_kr(0);
+ v-arch.privregs-krs[1] = ia64_get_kr(1);
+ v-arch.privregs-krs[2] = ia64_get_kr(2);
+ v-arch.privregs-krs[3] = ia64_get_kr(3);
+ v-arch.privregs-krs[4] = ia64_get_kr(4);
+ v-arch.privregs-krs[5] = ia64_get_kr(5);
+ v-arch.privregs-krs[6] = ia64_get_kr(6);
+ v-arch.privregs-krs[7] = ia64_get_kr(7);
}
/* Even guest is in physical mode, we still need such double mapping */
@@ -253,14 +253,14 @@ vmx_load_state(struct vcpu *v)
panic_domain(vcpu_regs(v),Restore vp status failed\n);
}
- ia64_set_kr(0, v-arch.arch_vmx.vkr[0]);
- ia64_set_kr(1, v-arch.arch_vmx.vkr[1]);
- ia64_set_kr(2, v-arch.arch_vmx.vkr[2]);
- ia64_set_kr(3, v-arch.arch_vmx.vkr[3]);
- ia64_set_kr(4, v-arch.arch_vmx.vkr[4]);
- ia64_set_kr(5, v-arch.arch_vmx.vkr[5]);
- ia64_set_kr(6, v-arch.arch_vmx.vkr[6]);
- ia64_set_kr(7, v-arch.arch_vmx.vkr[7]);
+ ia64_set_kr(0, v-arch.privregs-krs[0]);
+ ia64_set_kr(1, v-arch.privregs-krs[1]);
+ ia64_set_kr(2, v-arch.privregs-krs[2]);
+ ia64_set_kr(3, v-arch.privregs-krs[3]);
+ ia64_set_kr(4, v-arch.privregs-krs[4]);
+ ia64_set_kr(5, v-arch.privregs-krs[5]);
+ ia64_set_kr(6, v-arch.privregs-krs[6]);
+ ia64_set_kr(7, v-arch.privregs-krs[7]);
/* Guest vTLB is not required to be switched explicitly, since
* anchored in vcpu */
}
diff -r 91705524ac96 -r 396f89316b8b xen/include/asm-ia64/vmx_vpd.h
--- a/xen/include/asm-ia64/vmx_vpd.hWed Oct 24 02:52:49 2007 +0200
+++ b/xen/include/asm-ia64/vmx_vpd.hWed Oct 24 02:59:04 2007 +0200
@@ -49,7 +49,6 @@ struct arch_vmx_struct {
/* if the corresponding bit is 1, then this page size is
used in this region */
unsigned long psbits[8];
-unsigned long vkr[8];
unsigned long cr_iipa; /* for emulation */
unsigned long cr_isr;/* for emulation */
unsigned long cause;
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: check r2 value for VTi mov rr[r3]=r2
Hi, RID value was not checked for mov_to_rr. This is a security hole as it allowed a VTi domain to read memory of any other domain. Also use C fall-back for thash when long VHPT format is used. Comments added. Tristan. # HG changeset patch # User Tristan Gingold [EMAIL PROTECTED] # Date 1193017765 -7200 # Node ID 769c23dcfbf1a2bfcac5307d45e32bdd0e16d969 # Parent 8c7e879e3e81f628714f98b7f2f7968264072fb6 Check range of r2 for mov rr[r3]=r2 This fixes a security hole. Use C fall-back for thash with long VHPT format Add comments. Signed-off-by: Tristan Gingold [EMAIL PROTECTED] diff -r 8c7e879e3e81 -r 769c23dcfbf1 xen/arch/ia64/vmx/optvfault.S --- a/xen/arch/ia64/vmx/optvfault.S Fri Oct 19 06:24:24 2007 +0200 +++ b/xen/arch/ia64/vmx/optvfault.S Mon Oct 22 03:49:25 2007 +0200 @@ -6,7 +6,9 @@ * Xuefei Xu (Anthony Xu) [EMAIL PROTECTED] */ -#include linux/config.h +#include linux/config.h +#include asm/config.h +#include asm/pgtable.h #include asm/asmmacro.h #include asm/kregs.h #include asm/offsets.h @@ -26,6 +28,9 @@ #define ACCE_MOV_TO_PSR #define ACCE_THASH +// Inputs are: r21 (= current), r24 (= cause), r25 (= insn), r31 (=saved pr) + + //mov r1=ar3 (only itc is virtualized) GLOBAL_ENTRY(vmx_asm_mov_from_ar) #ifndef ACCE_MOV_FROM_AR @@ -90,13 +95,16 @@ GLOBAL_ENTRY(vmx_asm_mov_to_rr) #ifndef ACCE_MOV_TO_RR br.many vmx_virtualization_fault_back #endif -extr.u r16=r25,20,7 -extr.u r17=r25,13,7 +add r22=IA64_VCPU_DOMAIN_OFFSET,r21 +extr.u r16=r25,20,7// r3 +extr.u r17=r25,13,7// r2 +;; +ld8 r22=[r22] // Get domain movl r20=asm_mov_from_reg ;; adds r30=vmx_asm_mov_to_rr_back_1-asm_mov_from_reg,r20 -shladd r16=r16,4,r20 -mov r22=b0 +shladd r16=r16,4,r20 // get r3 +mov r18=b0 // save b0 ;; add r27=VCPU_VRR0_OFS,r21 mov b0=r16 @@ -104,47 +112,56 @@ GLOBAL_ENTRY(vmx_asm_mov_to_rr) ;; vmx_asm_mov_to_rr_back_1: adds r30=vmx_asm_mov_to_rr_back_2-asm_mov_from_reg,r20 -shr.u r23=r19,61 -shladd r17=r17,4,r20 +shr.u r23=r19,61 // get RR # +shladd r17=r17,4,r20 // get r2 ;; //if rr7, go back cmp.eq p6,p0=7,r23 -mov b0=r22 +mov b0=r18 // restore b0 (p6) br.cond.dpnt.many vmx_virtualization_fault_back ;; -mov r28=r19 +mov r28=r19// save r3 mov b0=r17 br.many b0 vmx_asm_mov_to_rr_back_2: adds r30=vmx_resume_to_guest-asm_mov_from_reg,r20 -shladd r27=r23,3,r27 -;; // +starting_rid -st8 [r27]=r19 +shladd r27=r23,3,r27 // address of VRR +add r22=IA64_DOMAIN_RID_BITS_OFFSET,r22 +;; +ld1 r22=[r22] // Load rid_bits from domain +mov b0=r18 // restore b0 +adds r16=IA64_VCPU_STARTING_RID_OFFSET,r21 +;; +ld4 r16=[r16] // load starting_rid +extr.u r17=r19,8,24// Extract RID +;; +shr r17=r17,r22// Shift out used bits +shl r16=r16,8 +;; +add r20=r19,r16 +cmp.ne p6,p0=0,r17 // If reserved RID bits are set, use C fall back. +(p6) br.cond.dpnt.many vmx_virtualization_fault_back +;; //mangling rid 1 and 3 +extr.u r16=r20,8,8 +extr.u r17=r20,24,8 +mov r24=r18// saved b0 for resume +;; +extr.u r18=r20,2,6 // page size +dep r20=r16,r20,24,8 mov b0=r30 ;; -adds r16=IA64_VCPU_STARTING_RID_OFFSET,r21 -;; -ld4 r16=[r16] -;; -shl r16=r16,8 -;; -add r19=r19,r16 -;; //mangling rid 1 and 3 -extr.u r16=r19,8,8 -extr.u r17=r19,24,8 -extr.u r18=r19,2,6 // page size -;; -dep r19=r16,r19,24,8 -;; -dep r19=r17,r19,8,8 +dep r20=r17,r20,8,8 ;; //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 -;; +dep r20=-1,r20,0,1 +// If ps PAGE_SHIFT, use PAGE_SHIFT +cmp.lt p6,p0=PAGE_SHIFT,r18 +;; +(p6) mov r18=PAGE_SHIFT +;; +(p6) dep r20=r18,r20,2,6 +;; +st8 [r27]=r19 // Write to vrr. +// Write to save_rr if rr=0 or rr=4. cmp.eq p6,p0=0,r23 ;; cmp.eq.or p6,p0=4,r23 @@ -156,11 +173,10 @@ vmx_asm_mov_to_rr_back_2: cmp.eq p7,p0=r0,r0 (p6) shladd r17=r23,1,r17 ;; -(p6) st8 [r17]=r19 +(p6) st8 [r17]=r20 (p6) cmp.eq p7,p0=VMX_MMU_VIRTUAL,r16 // Set physical rr if in virt mode ;; -(p7) mov rr[r28]=r19 -mov r24=r22 +(p7) mov rr[r28]=r20 br.many b0 END(vmx_asm_mov_to_rr) @@ -420,7 +436,7 @@ ENTRY(vmx_asm_dispatch_vexirq) br.many vmx_dispatch_vexirq END(vmx_asm_dispatch_vexirq) -// thash +// thash r1=r3 // TODO: add support when pta.vf = 1 GLOBAL_ENTRY(vmx_asm_thash) #ifndef ACCE_THASH @@ -433,8 +449,7 @@ GLOBAL_ENTRY(vmx_asm_thash) adds
[Xen-ia64-devel] PATCH: enable switch to PHY_D mmu mode
Hi,
last patch for PHY_D mmu mode:
enable switch to this mode.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1192767864 -7200
# Node ID 8c7e879e3e81f628714f98b7f2f7968264072fb6
# Parent b3a0f39104c3f4fa34d4b61464ced77c62f35885
Enable switch to PHY_D mode.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r b3a0f39104c3 -r 8c7e879e3e81 xen/arch/ia64/vmx/optvfault.S
--- a/xen/arch/ia64/vmx/optvfault.S Fri Oct 19 06:21:50 2007 +0200
+++ b/xen/arch/ia64/vmx/optvfault.S Fri Oct 19 06:24:24 2007 +0200
@@ -209,9 +209,9 @@ GLOBAL_ENTRY(vmx_asm_rsm)
tbit.z.or p6,p0=r26,IA64_PSR_DT_BIT
(p6) br.dptk vmx_resume_to_guest // DT not cleared or already in phy mode
;;
-// Switch to meta physical mode.
-add r26=IA64_VCPU_META_RID_DT_OFFSET,r21
-mov r23=VMX_MMU_PHY_DT
+// Switch to meta physical mode D.
+add r26=IA64_VCPU_META_RID_D_OFFSET,r21
+mov r23=VMX_MMU_PHY_D
;;
ld8 r26=[r26]
st1 [r22]=r23
@@ -338,10 +338,10 @@ vmx_asm_mov_to_psr_back:
cmp.eq p6,p7=r28,r27 // (new_vpsr (dt+rt+it)) == (dt+rt+it)
(p5) br.many vmx_asm_mov_to_psr_1 // no change
;;
-//virtual to physical
-(p7) add r26=IA64_VCPU_META_RID_DT_OFFSET,r21
-(p7) add r27=IA64_VCPU_META_RID_DT_OFFSET,r21
-(p7) mov r23=VMX_MMU_PHY_DT
+//virtual to physical D
+(p7) add r26=IA64_VCPU_META_RID_D_OFFSET,r21
+(p7) add r27=IA64_VCPU_META_RID_D_OFFSET,r21
+(p7) mov r23=VMX_MMU_PHY_D
;;
//physical to virtual
(p6) add r26=IA64_VCPU_META_SAVED_RR0_OFFSET,r21
diff -r b3a0f39104c3 -r 8c7e879e3e81 xen/arch/ia64/vmx/vmx_phy_mode.c
--- a/xen/arch/ia64/vmx/vmx_phy_mode.c Fri Oct 19 06:21:50 2007 +0200
+++ b/xen/arch/ia64/vmx/vmx_phy_mode.c Fri Oct 19 06:24:24 2007 +0200
@@ -235,10 +235,13 @@ switch_mm_mode(VCPU *vcpu, IA64_PSR old_
perfc_incra(vmx_switch_mm_mode, act);
switch (act) {
case SW_V2P_DT:
+vcpu-arch.arch_vmx.mmu_mode = VMX_MMU_PHY_DT;
+switch_to_physical_rid(vcpu);
+break;
case SW_V2P_D:
-//printk(V - P mode transition: (0x%lx - 0x%lx)\n,
+//printk(V - P_D mode transition: (0x%lx - 0x%lx)\n,
// old_psr.val, new_psr.val);
-vcpu-arch.arch_vmx.mmu_mode = VMX_MMU_PHY_DT;
+vcpu-arch.arch_vmx.mmu_mode = VMX_MMU_PHY_D;
switch_to_physical_rid(vcpu);
break;
case SW_P2V:
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: phy_d mode in thash_vhpt_insert
Hi,
Handle PHY_D mmu mode in thash_vhpt_insert.
Indentation.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1192767710 -7200
# Node ID b3a0f39104c3f4fa34d4b61464ced77c62f35885
# Parent 866d02fabf14b73da8a87fa10db07e44f8809081
Handle PHY_D mode in thash_vhpt_insert
Indentation.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 866d02fabf14 -r b3a0f39104c3 xen/arch/ia64/vmx/vtlb.c
--- a/xen/arch/ia64/vmx/vtlb.c Fri Oct 19 06:15:58 2007 +0200
+++ b/xen/arch/ia64/vmx/vtlb.c Fri Oct 19 06:21:50 2007 +0200
@@ -1,4 +1,3 @@
-
/* -*- Mode:C; c-basic-offset:4; tab-width:4; indent-tabs-mode:nil -*- */
/*
* vtlb.c: guest virtual tlb handling module.
@@ -22,6 +21,7 @@
*/
#include asm/vmx_vcpu.h
+#include asm/vmx_phy_mode.h
static thash_data_t *__alloc_chain(thash_cb_t *);
@@ -81,9 +81,10 @@ static thash_data_t *__vtr_lookup(VCPU *
static thash_data_t *__vtr_lookup(VCPU *vcpu, u64 va, int is_data)
{
-thash_data_t *trp;
-int i;
+thash_data_t *trp;
+int i;
u64 rid;
+
vcpu_get_rr(vcpu, va, rid);
rid = RR_RID_MASK;
if (is_data) {
@@ -181,13 +182,15 @@ void thash_vhpt_insert(VCPU *v, u64 pte,
u64 phy_pte, psr;
ia64_rr mrr;
+phy_pte = translate_phy_pte(v, pte, itir, va);
mrr.rrval = ia64_get_rr(va);
-phy_pte = translate_phy_pte(v, pte, itir, va);
-
-if (itir_ps(itir) = mrr.ps) {
+
+if (itir_ps(itir) = mrr.ps VMX_MMU_MODE(v) != VMX_MMU_PHY_D) {
vmx_vhpt_insert(vcpu_get_vhpt(v), phy_pte, itir, va);
} else {
-phy_pte = ~PAGE_FLAGS_RV_MASK;
+if (VMX_MMU_MODE(v) == VMX_MMU_PHY_D)
+itir = (itir ~RR_PS_MASK) | (mrr.rrval RR_PS_MASK);
+phy_pte = ~PAGE_FLAGS_RV_MASK; /* Clear reserved fields. */
psr = ia64_clear_ic();
ia64_itc(type + 1, va, phy_pte, itir);
ia64_set_psr(psr);
@@ -195,6 +198,8 @@ void thash_vhpt_insert(VCPU *v, u64 pte,
}
}
+/* On itr.d, old entries are not purged (optimization for Linux - see
+ vmx_vcpu_itr_d). Fixup possible mismatch. */
int vhpt_access_rights_fixup(VCPU *v, u64 ifa, int is_data)
{
thash_data_t *trp, *data;
@@ -656,7 +661,7 @@ thash_data_t *vtlb_lookup(VCPU *v, u64 v
cch = __vtr_lookup(v, va, is_data);
if (cch)
- return cch;
+return cch;
if (vcpu_quick_region_check(v-arch.tc_regions, va) == 0)
return NULL;
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: new features for xenitp
Hi,
just a few enhancements and fixes for xenitp.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1192766751 -7200
# Node ID 901a2f01f66c9a1faacab5b9958f555bc4433fd9
# Parent 6434adf3d46991dc49952d3b11f563c571b06722
Add auto-repeat feature
(Just press enter to re-execute the last go/sstep/cb/disass command).
Do not flush stdout in the signal handler.
Single step over a breakpoint.
Can quit with domain paused (quit paused)
'disp db' now displays watchpoint.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 6434adf3d469 -r 901a2f01f66c tools/debugger/xenitp/xenitp.c
--- a/tools/debugger/xenitp/xenitp.cWed Oct 17 06:13:07 2007 +0200
+++ b/tools/debugger/xenitp/xenitp.cFri Oct 19 06:05:51 2007 +0200
@@ -687,7 +687,6 @@ static volatile int ctrl_c_hit;
void ctrl_c_handler (int sig)
{
-fflush (stdout);
ctrl_c_hit = 1;
}
@@ -716,6 +715,7 @@ int wait_domain (int vcpu, vcpu_guest_co
break;
if (ctrl_c_hit) {
+fflush (stdout);
/* Force pause. */
ret = xc_domain_pause (xc_handle, domid);
if (ret 0)
@@ -957,48 +957,49 @@ int vcpu_setcontext (int vcpu)
return ret;
}
+enum cmd_status { CMD_ERROR, CMD_OK, CMD_REPEAT, CMD_QUIT };
+
struct command_desc
{
const char *name;
const char *help;
-int (*cmd)(char *line);
+enum cmd_status (*cmd)(char *line);
};
-static int
+static enum cmd_status
cmd_registers (char *line)
{
print_ctx (cur_ctx);
-return 0;
-}
-
-static int
+return CMD_OK;
+}
+
+static enum cmd_status
cmd_sstep (char *line)
{
-if ((cur_ctx-regs.psr (PSR_SS | PSR_TB)) != PSR_SS) {
-cur_ctx-regs.psr |= PSR_SS;
-cur_ctx-regs.psr = ~PSR_TB;
-if (vcpu_setcontext (cur_vcpu) 0)
-return -1;
-}
+/* Set psr.dd and psr.id to skip over current breakpoint. */
+cur_ctx-regs.psr |= PSR_SS | PSR_DD | PSR_ID;
+cur_ctx-regs.psr = ~PSR_TB;
+if (vcpu_setcontext (cur_vcpu) 0)
+return CMD_ERROR;
if (wait_domain (cur_vcpu, cur_ctx) 0) {
perror (wait_domain);
-return -1;
+return CMD_ERROR;
}
print_ctx (cur_ctx);
-return 0;
-}
-
-static int
+return CMD_REPEAT;
+}
+
+static enum cmd_status
cmd_go (char *line)
{
unsigned long n = 1;
if (*line != 0) {
if (parse_expr (line, n, 0) 0)
-return -1;
+return CMD_ERROR;
}
while (n 0) {
/* Set psr.dd and psr.id to skip over current breakpoint. */
@@ -1006,54 +1007,58 @@ cmd_go (char *line)
cur_ctx-regs.psr = ~(PSR_SS | PSR_TB);
cur_ctx-regs.psr |= PSR_DD | PSR_ID;
if (vcpu_setcontext (cur_vcpu) 0)
-return -1;
+return CMD_ERROR;
}
if (wait_domain (cur_vcpu, cur_ctx) 0) {
perror (wait_domain);
-return -1;
+return CMD_ERROR;
}
print_ctx (cur_ctx);
n--;
}
-return 0;
-}
-
-static int
+return CMD_REPEAT;
+}
+
+static enum cmd_status
cmd_cb (char *line)
{
if ((cur_ctx-regs.psr (PSR_SS | PSR_TB)) != PSR_TB) {
cur_ctx-regs.psr = ~PSR_SS;
cur_ctx-regs.psr |= PSR_TB;
if (vcpu_setcontext (cur_vcpu) 0)
-return -1;
+return CMD_ERROR;
}
if (wait_domain (cur_vcpu, cur_ctx) 0) {
perror (wait_domain);
-return -1;
+return CMD_ERROR;
}
print_ctx (cur_ctx);
-return 0;
-}
-
-static int
+return CMD_REPEAT;
+}
+
+static int quit_paused;
+
+static enum cmd_status
cmd_quit (char *line)
{
-return -2;
-}
-
-static int
+if (!strcmp (line, paused))
+quit_paused = 1;
+return CMD_QUIT;
+}
+
+static enum cmd_status
cmd_echo (char *line)
{
printf (%s, line);
-return 0;
-}
-
-static int
+return CMD_OK;
+}
+
+static enum cmd_status
cmd_disassemble (char *args)
{
static unsigned long addr;
@@ -1061,21 +1066,20 @@ cmd_disassemble (char *args)
if (*args != 0) {
if (parse_expr (args, addr, 0) 0)
-return -1;
+return CMD_ERROR;
if (*args != 0) {
if (parse_expr (args, end_addr, 0) 0)
-return -1;
+return CMD_ERROR;
}
else
end_addr = addr + 16;
}
target_disas (stdout, addr, end_addr - addr);
addr = end_addr;
-return 0;
-
-}
-
-static int
+return CMD_REPEAT;
+}
+
+static enum cmd_status
cmd_break (char *args)
{
unsigned long addr;
@@ -1087,20 +1091,23 @@ cmd_break (char *args)
if (i == 4) {
printf (no availabe break points\n);
-return -1;
+return CMD_ERROR;
}
if (parse_expr (args, addr, 0) 0)
-return -1;
+return CMD_ERROR;
cur_ctx-regs.ibr[2 * i] = addr;
cur_ctx-regs.ibr[2 * i + 1] = 0x87f0UL;
[Xen-ia64-devel] PATCH: handle phy_d mode in vmx_hpw_miss
Hi,
phy_d mode is now handled by vmx_hpw_miss.
I also made a few cosmetic changes: indentation and consolidation of common
code.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1192767358 -7200
# Node ID 866d02fabf14b73da8a87fa10db07e44f8809081
# Parent 901a2f01f66c9a1faacab5b9958f555bc4433fd9
Handle PHY_D mmu mode.
Indentation.
Avoid code duplication in vmx_hpw_miss.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 901a2f01f66c -r 866d02fabf14 xen/arch/ia64/vmx/vmx_fault.c
--- a/xen/arch/ia64/vmx/vmx_fault.c Fri Oct 19 06:05:51 2007 +0200
+++ b/xen/arch/ia64/vmx/vmx_fault.c Fri Oct 19 06:15:58 2007 +0200
@@ -66,7 +66,7 @@ extern unsigned long handle_fpu_swa (int
#define DOMN_PAL_REQUEST0x11
#define DOMN_SAL_REQUEST0x110001
-static u64 vec2off[68] = {0x0,0x400,0x800,0xc00,0x1000,0x1400,0x1800,
+static const u16 vec2off[68] = {0x0,0x400,0x800,0xc00,0x1000,0x1400,0x1800,
0x1c00,0x2000,0x2400,0x2800,0x2c00,0x3000,0x3400,0x3800,0x3c00,0x4000,
0x4400,0x4800,0x4c00,0x5000,0x5100,0x5200,0x5300,0x5400,0x5500,0x5600,
0x5700,0x5800,0x5900,0x5a00,0x5b00,0x5c00,0x5d00,0x5e00,0x5f00,0x6000,
@@ -155,13 +155,12 @@ void vmx_reflect_interruption(u64 ifa, u
goto nested_fault;
break;
}
-VCPU(vcpu,isr)=isr;
+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);
-}
+else
+set_ifa_itir_iha(vcpu, ifa, 1, 1, 1);
inject_guest_interruption(vcpu, vector);
return;
@@ -196,17 +195,18 @@ vmx_ia64_handle_break (unsigned long ifa
vcpu_increment_iip(v);
return IA64_NO_FAULT;
}
-else if(iim == DOMN_PAL_REQUEST){
+else if (iim == DOMN_PAL_REQUEST) {
pal_emul(v);
vcpu_increment_iip(v);
return IA64_NO_FAULT;
-}else if(iim == DOMN_SAL_REQUEST){
+}
+else if (iim == DOMN_SAL_REQUEST) {
sal_emul(v);
vcpu_increment_iip(v);
return IA64_NO_FAULT;
}
}
-vmx_reflect_interruption(ifa,isr,iim,11,regs);
+vmx_reflect_interruption(ifa, isr, iim, 11, regs);
}
return IA64_NO_FAULT;
}
@@ -306,7 +306,7 @@ void leave_hypervisor_tail(void)
static int vmx_handle_lds(REGS* regs)
{
-regs-cr_ipsr |=IA64_PSR_ED;
+regs-cr_ipsr |= IA64_PSR_ED;
return IA64_FAULT;
}
@@ -316,6 +316,7 @@ vmx_hpw_miss(u64 vadr, u64 vec, REGS* re
{
IA64_PSR vpsr;
int type;
+unsigned int mmu_mode;
u64 vhpt_adr, gppa, pteval, rr, itir;
ISR misr;
PTA vpta;
@@ -325,22 +326,26 @@ vmx_hpw_miss(u64 vadr, u64 vec, REGS* re
vpsr.val = VCPU(v, vpsr);
misr.val = VMX(v,cr_isr);
-if (vec == 1)
+if (vec == 1 || vec == 3)
type = ISIDE_TLB;
-else if (vec == 2)
+else if (vec == 2 || vec == 4)
type = DSIDE_TLB;
else
panic_domain(regs, wrong vec:%lx\n, vec);
/* Physical mode and region is 0 or 4. */
-if (!is_virtual_mode(v) (!((vadr 1) 62))) {
-if (vec == 2) {
+mmu_mode = VMX_MMU_MODE(v);
+if ((mmu_mode == VMX_MMU_PHY_DT
+ || (mmu_mode == VMX_MMU_PHY_D type == DSIDE_TLB))
+ !((vadr1)62)) {
+if (type == DSIDE_TLB) {
/* DTLB miss. */
if (misr.sp) /* Refer to SDM Vol2 Table 4-11,4-12 */
return vmx_handle_lds(regs);
+/* Clear UC bit in vadr with the shifts. */
if (v-domain != dom0
__gpfn_is_io(v-domain, (vadr 1) (PAGE_SHIFT + 1))) {
-emulate_io_inst(v, ((vadr1)1),4); // UC
+emulate_io_inst(v, ((vadr1)1),4);
return IA64_FAULT;
}
}
@@ -411,64 +416,35 @@ try_again:
if (vpsr.ic) {
vcpu_set_isr(v, misr.val);
alt_dtlb(v, vadr);
-return IA64_FAULT;
} else {
nested_dtlb(v);
-return IA64_FAULT;
-}
+}
+return IA64_FAULT;
}
vpta.val = vmx_vcpu_get_pta(v);
if (vpta.vf) {
/* Long format is not yet supported. */
-if (vpsr.ic) {
-vcpu_set_isr(v, misr.val);
-dtlb_fault(v, vadr);
-return IA64_FAULT;
-} else {
-nested_dtlb(v);
-return IA64_FAULT;
-}
+goto inject_dtlb_fault;
}
/* avoid recursively walking (short format) VHPT */
if (!(optf-mask XEN_IA64_OPTF_IDENT_MAP_REG4)
!(optf-mask XEN_IA64_OPTF_IDENT_MAP_REG5)
(((vadr ^ vpta.val) 3) (vpta.size + 3)) == 0) {
-
-
Re: [Xen-ia64-devel] [PATCH][IA64] configure VHPT size per HVM domain
Quoting Kouya Shimura [EMAIL PROTECTED]: Hi Keir and Alex, A Virtual Hash Page Table(VHPT) is a special feature of IA64. It's an extension of TLB that resides in memory and can be automatically searched by the processor. This patch allows user to configure VHPT size per HVM domain. Good idea. As Isaku suggested it will be nice to have this option for pv too. And if you want to go farther, you may also want to specify vtlb size! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: don't warn for EOI-ing an edge triggered interrupt
Hi,
Edge triggered interrupts don't need an EOI but EOI-ing them is harmless
according to the IOSAPIC documentation.
Do not emit a warning in such case.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1192594387 -7200
# Node ID 701a3e8f8c64adc32e8c49631558da506cbfd8bc
# Parent a421fb1b1db36b02febe14f2f95cf4446a74260d
Don't warn for EOI-ing an edge triggered interrupt.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r a421fb1b1db3 -r 701a3e8f8c64 xen/arch/ia64/vmx/viosapic.c
--- a/xen/arch/ia64/vmx/viosapic.c Sun Oct 14 03:24:30 2007 +0200
+++ b/xen/arch/ia64/vmx/viosapic.c Wed Oct 17 06:13:07 2007 +0200
@@ -135,8 +135,9 @@ static void viosapic_update_EOI(struct v
if ( !test_and_clear_bit(redir_num, viosapic-isr) )
{
spin_unlock(viosapic-lock);
-gdprintk(XENLOG_WARNING, redir %d not set for %d EOI\n,
- redir_num, vector);
+if ( viosapic-redirtbl[redir_num].trig_mode == SAPIC_LEVEL )
+ gdprintk(XENLOG_WARNING, redir %d not set for %d EOI\n,
+redir_num, vector);
return;
}
service_iosapic(viosapic);
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH (cleanup): remove unsued definitions in irq.c
Hi,
mini-cleanup found when trying to compile with gcc 4.2
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1192596414 -7200
# Node ID 65468c0c6c64a234a203f3c8c223196e916ca6a4
# Parent cad488592f731bc59b2bd101ff265f8b1654ef9d
Cleanup: remove unused definitions.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r cad488592f73 -r 65468c0c6c64 xen/arch/ia64/xen/irq.c
--- a/xen/arch/ia64/xen/irq.c Wed Oct 17 06:45:24 2007 +0200
+++ b/xen/arch/ia64/xen/irq.c Wed Oct 17 06:46:54 2007 +0200
@@ -122,14 +122,6 @@ struct hw_interrupt_type no_irq_type = {
};
atomic_t irq_err_count;
-
-/* Some placeholder here, which are used by other files and we
- * don't want to change too much now. Later they should be cleaned.
- */
-#ifdef CONFIG_SMP
-inline void synchronize_irq(unsigned int irq) {}
-EXPORT_SYMBOL(synchronize_irq);
-#endif
/*
* Generic enable/disable code: this just calls
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH (mini): declare field x of M28
Hi,
M28 has now a field x (for fc vs fc.i).
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1192596324 -7200
# Node ID cad488592f731bc59b2bd101ff265f8b1654ef9d
# Parent 701a3e8f8c64adc32e8c49631558da506cbfd8bc
Declare field x of M28 (fc vs fc.i).
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 701a3e8f8c64 -r cad488592f73 xen/include/asm-ia64/bundle.h
--- a/xen/include/asm-ia64/bundle.h Wed Oct 17 06:13:07 2007 +0200
+++ b/xen/include/asm-ia64/bundle.h Wed Oct 17 06:45:24 2007 +0200
@@ -55,7 +55,7 @@ typedef union U_INST64_I28 { // not priv
typedef union U_INST64_M28 {
IA64_INST inst;
-struct { unsigned long qp:6, :14, r3:7, x6:6, x3:3, :1, major:4;};
+struct { unsigned long qp:6, :14, r3:7, x6:6, x3:3, x:1, major:4;};
} INST64_M28;
typedef union U_INST64_M29 {
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH][GFW] fix unalignment ref with gcc 4.x
Quoting Kouya Shimura [EMAIL PROTECTED]: Hi Yamahata-san, Thanks for informing me. My gcc might be Redhat patched one. (I'm using RHEL5) It generates the code I expect. So I rewrote the patch more generally. Tristan, please discard the previous patch and apply the attached patch. Ok. Note this is debugging stuff. It would be removed! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH][GFW] support windows 2008
Quoting Kouya Shimura [EMAIL PROTECTED]: Hi Tristan, Here is a patch to support windows 2008 (aka Longhorn). I don't know EFI spec well and this patch might do something wrong. I think this is defined in SAL specs. I will check. But I succeed in installing and running windows 2008 with this patch. Good news and thank you for this work! This patch does: - pin mapping into tr[0] for IVT - handling alt TLB miss. implementing identity mappping. - ignoring unaligned reference exception when it is speculated. Even if not in the spec, this seems harmless. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: correctly decode imm fields in mmio.c
Hi,
interesting bug: instructions whose imm field was negative were not
correctly emulated in mmio.c
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1192325070 -7200
# Node ID a421fb1b1db36b02febe14f2f95cf4446a74260d
# Parent c29269e32ea653df2a9b6a57a91b55ae89dc1208
Immediat field of ia64 instructions are 2's complement coded
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r c29269e32ea6 -r a421fb1b1db3 xen/arch/ia64/vmx/mmio.c
--- a/xen/arch/ia64/vmx/mmio.c Tue Oct 02 15:33:16 2007 +0200
+++ b/xen/arch/ia64/vmx/mmio.c Sun Oct 14 03:24:30 2007 +0200
@@ -318,7 +318,8 @@ void emulate_io_inst(VCPU *vcpu, u64 pad
IA64_BUNDLE bundle;
int slot, dir=0, inst_type;
size_t size;
-u64 data, post_update, slot1a, slot1b, temp;
+u64 data, slot1a, slot1b, temp, update_reg;
+s32 imm;
INST64 inst;
regs = vcpu_regs(vcpu);
@@ -355,8 +356,8 @@ void emulate_io_inst(VCPU *vcpu, u64 pad
dir = IOREQ_READ; //write
size = (inst.M2.x6 0x3);
vcpu_get_gr_nat(vcpu, inst.M2.r3, temp);
-vcpu_get_gr_nat(vcpu, inst.M2.r2, post_update);
-temp += post_update;
+vcpu_get_gr_nat(vcpu, inst.M2.r2, update_reg);
+temp += update_reg;
vcpu_set_gr(vcpu, inst.M2.r3, temp, 0);
}
// Integer Load/Store + Imm update
@@ -367,20 +368,16 @@ void emulate_io_inst(VCPU *vcpu, u64 pad
dir = IOREQ_WRITE; // write
vcpu_get_gr_nat(vcpu, inst.M5.r2, data);
vcpu_get_gr_nat(vcpu, inst.M5.r3, temp);
-post_update = (inst.M5.i 7) + inst.M5.imm7;
-if (inst.M5.s)
-temp -= post_update;
-else
-temp += post_update;
+imm =
+(inst.M5.s 31) | (inst.M5.i 30) | (inst.M5.imm7 23);
+temp += imm 23;
vcpu_set_gr(vcpu, inst.M5.r3, temp, 0);
} else if ((inst.M3.x6 2) 0xb) { // read
dir = IOREQ_READ;
vcpu_get_gr_nat(vcpu, inst.M3.r3, temp);
-post_update = (inst.M3.i 7) + inst.M3.imm7;
-if (inst.M3.s)
-temp -= post_update;
-else
-temp += post_update;
+imm =
+(inst.M3.s 31) | (inst.M3.i 30) | (inst.M3.imm7 23);
+temp += imm 23;
vcpu_set_gr(vcpu, inst.M3.r3, temp, 0);
}
}
@@ -407,11 +404,9 @@ void emulate_io_inst(VCPU *vcpu, u64 pad
dir = IOREQ_WRITE;
vcpu_get_fpreg(vcpu, inst.M10.f2, v);
vcpu_get_gr_nat(vcpu, inst.M10.r3, temp);
-post_update = (inst.M10.i 7) + inst.M10.imm7;
-if (inst.M10.s)
-temp -= post_update;
-else
-temp += post_update;
+imm =
+(inst.M10.s 31) | (inst.M10.i 30) | (inst.M10.imm7 23);
+temp += imm 23;
vcpu_set_gr(vcpu, inst.M10.r3, temp, 0);
/* Write high word.
@@ -431,11 +426,9 @@ void emulate_io_inst(VCPU *vcpu, u64 pad
vcpu_get_fpreg(vcpu, inst.M10.f2, v);
data = v.u.bits[0]; /* Significand. */
vcpu_get_gr_nat(vcpu, inst.M10.r3, temp);
-post_update = (inst.M10.i 7) + inst.M10.imm7;
-if (inst.M10.s)
-temp -= post_update;
-else
-temp += post_update;
+imm =
+(inst.M10.s 31) | (inst.M10.i 30) | (inst.M10.imm7 23);
+temp += imm 23;
vcpu_set_gr(vcpu, inst.M10.r3, temp, 0);
}
//else if(inst.M6.major==6inst.M6.m==0inst.M6.x==0inst.M6.x6==3){
@@ -446,11 +439,9 @@ void emulate_io_inst(VCPU *vcpu, u64 pad
// lfetch - do not perform accesses.
else if (inst.M15.major== 7 inst.M15.x6 =0x2c inst.M15.x6 = 0x2f) {
vcpu_get_gr_nat(vcpu, inst.M15.r3, temp);
-post_update = (inst.M15.i 7) + inst.M15.imm7;
-if (inst.M15.s)
-temp -= post_update;
-else
-temp += post_update;
+imm =
+(inst.M15.s 31) | (inst.M15.i 30) | (inst.M15.imm7 23);
+temp += imm 23;
vcpu_set_gr(vcpu, inst.M15.r3, temp, 0);
vcpu_increment_iip(vcpu);
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH 0/23] [RFC] VTi domain save/restore
Quoting Isaku Yamahata [EMAIL PROTECTED]: Hi all. I've been working on IA64 HVM domain save/restore. Impressive! Tristan. Could you elaborate on struct vcpu_guest_context_regs rbs_nat, rbs_rnat? The comment above them is somewhat vague. I heavily rewrote the rbs related part of getting/setting vcpu context. I'm not sure about them and I used only rbs_rnat. rbs_rnat is clear. rbs_nat seems to be useless. As you know, these fields were never set. So you can remove rbs_nat. I haven't forgotten hvm domain dump-core fix. I need to implement HVM vcpu context save before fixing it. Ok. - RSE (both PV and HVM domain) The number of physical stacked general register(RSE.N_STACKED_PHYS) isn't virtualized. Guest OS utilizes it via PAL_RSE_INFO call. If the number of cpu where domain is saved/restored aren't same, what should be supposed to do? The SDM says only that the number is cpu implementation specific. So the easiest way is to refuse restore. Any thoughts/comments? Refuse restore by default but have a flag to force it ? struct opt_feature seems stable for save/restore ABI. Or does someone else want to play with opt_feature hypercall? Yes, new flags may be added in the future. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [GFW PATCH] HVM DSDT fixes
Quoting Alex Williamson [EMAIL PROTECTED]: Hi Tristan, There's still a lot of legacy devices in the DSDT that I'd like to remove (both of the motherboard resource devices, the PIC, DMA0, TMR, RTC, SPKR, and FDC0). Do any of these need to be in the system? PIC can be definitely removed. TMR (8254) is used by the GFW although itm should be used instead. RTC is also used by the GFW. SPKR can be removed (I suppose) FDC0+DMA0 could be removed or not. IMHO if a device is removed from the ssdt it should also be removed from qemu emulation. BTW, the README for updating dsdt.c looks rather irrelevant to the GFW Yes, it comes from Xen. build. I've been using the following steps to build it: iasl -p foo -tc dsdt.asl tail --lines=1 dsdt.c foo.hex cp foo.hex dsdt.c The tail just pulls over DsdtLen. Is this correct? Yes, it is. Is there an easier way? Well, we should modify the integration: iasl should produce an .h file which is included by a c file. Will be easier. I think there is a support of .asl in Tiano build but I never used it. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Question about vmx_ivt.S
Quoting Xu, Anthony [EMAIL PROTECTED]: Hi Tristan, Yes the mf is necessary, Hardware can speculatively load vhpt entries from VTHP page. We had spent a lot of effort to identity this issue. I don't fully understand your explanation. Memory ordering issues are only SMP issues, not uniprocessor issue. Am I wrong ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: GFW - unsorted memmap?
Quoting Alex Williamson [EMAIL PROTECTED]: Hi Tristan, I noticed that the memory map produced by the open source GFW isn't producing a sorted list. It's putting the MMIO and I/O port space ranges after everything else. This appears to be a bug in the EDK2 that it simply appends entries from the mGcdMemorySpaceMap list after those from the gMemoryMap list. I did a quick and dirty bubble sort at the end of CoreGetMemoryMap() to fix this up. Any ideas for a better solution? Thanks, I quickly browse EFI spec but I have not found the requirement. Are you sure the memmap must be sorted ? Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: xenitp improvments
Hi,
see cs for the details.
I have compiled xenitp with gcc 4.2
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1191330820 -7200
# Node ID 90929565d0ee0531c846c171bf7710ddef7d36fd
# Parent 672dfa0238710aba0b2e6d0a8c5404f2581786a8
Remove all the casts by using char * instead of unsigned char *.
The go command now accept a number.
The disass command can now accept a range.
Number of TRs is not hard-coded.
'-' (minus) can now be used in expressions.
'$iip' and '$b0' can be used in expressions.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 672dfa023871 -r 90929565d0ee tools/debugger/xenitp/xenitp.c
--- a/tools/debugger/xenitp/xenitp.cTue Oct 02 15:07:54 2007 +0200
+++ b/tools/debugger/xenitp/xenitp.cTue Oct 02 15:13:40 2007 +0200
@@ -57,7 +57,7 @@ static int cur_vcpu;
int virt_to_phys (int is_inst, unsigned long vaddr, unsigned long *paddr);
-inline unsigned int ctx_slot (vcpu_guest_context_t *ctx)
+static inline unsigned int ctx_slot (vcpu_guest_context_t *ctx)
{
return (ctx-regs.psr PSR_RI_SHIFT) 3;
}
@@ -65,7 +65,7 @@ unsigned char *
unsigned char *
target_map_memory (unsigned long paddr)
{
-static unsigned long cur_page = -1;
+static unsigned long cur_page = (unsigned long)-1;
static unsigned char *cur_map = NULL;
if ((paddr XC_PAGE_SHIFT) != cur_page) {
@@ -243,8 +243,6 @@ void target_disas (FILE *out, unsigned l
unsigned long pc;
int count;
struct disassemble_info disasm_info;
-int slot;
-int (*print_insn)(bfd_vma pc, disassemble_info *info);
INIT_DISASSEMBLE_INFO(disasm_info, out, fprintf);
@@ -257,14 +255,15 @@ void target_disas (FILE *out, unsigned l
disasm_info.endian = BFD_ENDIAN_LITTLE;
disasm_info.mach = 0; //bfd_mach_ia64;
-print_insn = print_insn_ia64;
-
-for (pc = code, slot = 0; pc code + size; pc += count, slot++) {
-fprintf (out, 0x%016lx+%d:%c , code, slot,
- ((pc ~0x0fUL) == cur_ctx-regs.ip
- slot == ctx_slot (cur_ctx)) ? '*' : ' ');
-
-count = print_insn (pc, disasm_info);
+
+for (pc = code; pc code + size; pc += count) {
+int slot = (pc 0x0f) / 6;
+fprintf(out, 0x%016lx+%d:%c , pc ~0x0fUL, slot,
+((pc ~0x0fUL) == cur_ctx-regs.ip
+ slot == ctx_slot (cur_ctx)) ? '*' : ' ');
+
+count = print_insn_ia64(pc, disasm_info);
+
#if 0
{
int i;
@@ -337,7 +336,7 @@ static void print_a_tr (int i, const str
ma_val = tr-pte PTE_MA_SHIFT PTE_MA_MASK;
pa = (tr-pte PTE_PPN_SHIFT PTE_PPN_MASK) PTE_PPN_SHIFT;
pa = (pa ps_val) ps_val;
-printf ( [%d] %ld %06lx %016lx %013lx %02d %s %ld %ld %ld %ld
+printf ( [%2d] %ld %06lx %016lx %013lx %02d %s %ld %ld %ld %ld
%ld %d %s %06lx\n, i,
tr-pte PTE_P_SHIFT PTE_P_MASK,
tr-rid RR_RID_SHIFTRR_RID_MASK,
@@ -638,13 +637,13 @@ void print_tr (vcpu_guest_context_t *ctx
printf (\n itr: P ridva paps ed pl
ar a d makey\n);
-for (i = 0; i 8; i++)
+for (i = 0; i sizeof (tr-itrs) / sizeof (tr-itrs[0]); i++)
print_a_tr (i, tr-itrs[i]);
printf (\n dtr: P ridva paps ed pl
ar a d makey\n);
-for (i = 0; i 8; i++)
+for (i = 0; i sizeof (tr-dtrs) / sizeof (tr-dtrs[0]); i++)
print_a_tr (i, tr-dtrs[i]);
}
@@ -734,15 +733,21 @@ int wait_domain (int vcpu, vcpu_guest_co
int virt_to_phys (int is_inst, unsigned long vaddr, unsigned long *paddr)
{
+struct vcpu_tr_regs *trs = cur_ctx-regs.tr;
struct ia64_tr_entry *tr;
int i;
+int num;
/* Search in tr. */
-if (is_inst)
-tr = cur_ctx-regs.tr.itrs;
-else
-tr = cur_ctx-regs.tr.dtrs;
-for (i = 0; i 8; i++, tr++) {
+if (is_inst) {
+tr = trs-itrs;
+num = sizeof (trs-itrs) / sizeof (trs-itrs[0]);
+}
+else {
+tr = trs-dtrs;
+num = sizeof (trs-dtrs) / sizeof (trs-dtrs[0]);
+}
+for (i = 0; i num; i++, tr++) {
int ps_val = (tr-itir ITIR_PS_SHIFT) ITIR_PS_MASK;
unsigned long ps_mask = (-1L) ps_val;
@@ -762,40 +767,44 @@ get_reg_addr (const char *name)
return cur_ctx-regs.ip;
else if (strcmp (name, psr) == 0)
return cur_ctx-regs.psr;
+else if (strcmp (name, iip) == 0)
+return cur_ctx-regs.cr.iip;
+else if (strcmp (name, b0) == 0)
+return cur_ctx-regs.b[0];
else
return 0;
}
enum prio_expr {EXPR_BASE, EXPR_SUM, EXPR_LOGIC, EXPR_PROD};
-int parse_expr (unsigned char **buf, unsigned long *res, enum prio_expr prio);
-
-int next_char (unsigned char **buf)
-{
-unsigned char *b;
+int parse_expr (char **buf, unsigned long *res, enum prio_expr prio);
+
+int next_char (char **buf)
+{
+char *b;
b = *buf;
-while
[Xen-ia64-devel] PATCH: cleanup
Hi, tiny cleanup in vmx code: remove useless #ifndef and some indentation. Tristan. # HG changeset patch # User Tristan Gingold [EMAIL PROTECTED] # Date 1191331313 -7200 # Node ID 5d8b23081846748848409d7b1577ad00a85fabe7 # Parent fc05defecee0aaeb3c5ec722f90c580e0abbfb5d Cleanup: remove useless #ifndef and indentation. Signed-off-by: Tristan Gingold [EMAIL PROTECTED] diff -r fc05defecee0 -r 5d8b23081846 xen/arch/ia64/vmx/vmx_init.c --- a/xen/arch/ia64/vmx/vmx_init.c Tue Oct 02 15:18:57 2007 +0200 +++ b/xen/arch/ia64/vmx/vmx_init.c Tue Oct 02 15:21:53 2007 +0200 @@ -316,11 +316,9 @@ vmx_final_setup_guest(struct vcpu *v) /* Per-domain vTLB and vhpt implementation. Now vmx domain will stick * to this solution. Maybe it can be deferred until we know created * one as vmx domain */ -#ifndef HASH_VHPT rc = init_domain_tlb(v); if (rc) return rc; -#endif vmx_create_event_channels(v); /* v-arch.schedule_tail = arch_vmx_do_launch; */ diff -r fc05defecee0 -r 5d8b23081846 xen/arch/ia64/vmx/vmx_interrupt.c --- a/xen/arch/ia64/vmx/vmx_interrupt.c Tue Oct 02 15:18:57 2007 +0200 +++ b/xen/arch/ia64/vmx/vmx_interrupt.c Tue Oct 02 15:21:53 2007 +0200 @@ -220,8 +220,6 @@ _vhpt_fault(VCPU *vcpu, u64 vadr) /* If vPSR.ic, IFA, ITIR, IHA*/ set_ifa_itir_iha (vcpu, vadr, 1, 1, 1); inject_guest_interruption(vcpu,IA64_VHPT_TRANS_VECTOR); - - } /* @@ -425,4 +423,3 @@ data_access_rights(VCPU *vcpu, u64 vadr) set_ifa_itir_iha (vcpu, vadr, 1, 1, 0); inject_guest_interruption(vcpu, IA64_DATA_ACCESS_RIGHTS_VECTOR); } - ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: cleanup in vmx headers
Hi,
one more mini-cleanup in vmx headers: reduce the size of vmx_arch_structure,
remove one unused macro.
VMX_MMU_MODE macro added.
Tristan.
# HG changeset patch
# User Tristan Gingold [EMAIL PROTECTED]
# Date 1191331494 -7200
# Node ID d4c384228c9bac8499bcec4a35271229e10412d5
# Parent 5d8b23081846748848409d7b1577ad00a85fabe7
Reduce size of arch_vmx_struct (flags is now 1 byte).
Remove unused macro.
Add VMX_MMU_MODE macro.
Signed-off-by: Tristan Gingold [EMAIL PROTECTED]
diff -r 5d8b23081846 -r d4c384228c9b xen/include/asm-ia64/vmx_phy_mode.h
--- a/xen/include/asm-ia64/vmx_phy_mode.h Tue Oct 02 15:21:53 2007 +0200
+++ b/xen/include/asm-ia64/vmx_phy_mode.h Tue Oct 02 15:24:54 2007 +0200
@@ -86,7 +86,8 @@ extern void vmx_load_all_rr(VCPU *vcpu);
extern void vmx_load_all_rr(VCPU *vcpu);
extern void physical_tlb_miss(VCPU *vcpu, u64 vadr, int type);
-#define is_virtual_mode(v) ((v)-arch.arch_vmx.mmu_mode == VMX_MMU_VIRTUAL)
+#define VMX_MMU_MODE(v)((v)-arch.arch_vmx.mmu_mode)
+#define is_virtual_mode(v) (VMX_MMU_MODE(v) == VMX_MMU_VIRTUAL)
#endif /* __ASSEMBLY__ */
diff -r 5d8b23081846 -r d4c384228c9b xen/include/asm-ia64/vmx_vpd.h
--- a/xen/include/asm-ia64/vmx_vpd.hTue Oct 02 15:21:53 2007 +0200
+++ b/xen/include/asm-ia64/vmx_vpd.hTue Oct 02 15:24:54 2007 +0200
@@ -55,8 +55,8 @@ struct arch_vmx_struct {
unsigned long cause;
unsigned long opcode;
unsigned long mpta;
-unsigned long flags;
unsigned long xen_port;
+unsigned char flags;
unsigned char xtp;
unsigned char pal_init_pending;
unsigned char mmu_mode; /* Current mmu mode. See vmx_phy_mode.h */
@@ -68,8 +68,7 @@ struct arch_vmx_struct {
#define VMX_DOMAIN(v) v-arch.arch_vmx.flags
-#define ARCH_VMX_IO_WAIT3 /* Waiting for I/O completion */
-#define ARCH_VMX_DOMAIN 5 /* Need it to indicate VTi domain */
+#define ARCH_VMX_DOMAIN 0 /* Need it to indicate VTi domain */
#endif //__ASSEMBLY__
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] PATCH: micro-optimize and comments in vmx_ivt.S
Hi, while I was working on PHY_D mode, I added comments in vmx_ivt.S and also micro-optimize a little bit (code is more compact). Tristan. # HG changeset patch # User Tristan Gingold [EMAIL PROTECTED] # Date 1191331996 -7200 # Node ID c29269e32ea653df2a9b6a57a91b55ae89dc1208 # Parent d4c384228c9bac8499bcec4a35271229e10412d5 Comments added + micro-optimizations. In PHY_D mode, alt tlb misses can call vmx_hpw_miss. Signed-off-by: Tristan Gingold [EMAIL PROTECTED] diff -r d4c384228c9b -r c29269e32ea6 xen/arch/ia64/vmx/vmx_ivt.S --- a/xen/arch/ia64/vmx/vmx_ivt.S Tue Oct 02 15:24:54 2007 +0200 +++ b/xen/arch/ia64/vmx/vmx_ivt.S Tue Oct 02 15:33:16 2007 +0200 @@ -59,6 +59,7 @@ #include asm/unistd.h #include asm/vhpt.h #include asm/virt_event.h +#include asm/vmx_phy_mode.h #include xen/errno.h #if 1 @@ -103,7 +104,7 @@ #define VMX_FAULT(n)\ vmx_fault_##n:; \ -mov r19=n;; \ +mov r19=n; \ br.sptk.many dispatch_to_fault_handler; \ ;; \ @@ -115,7 +116,7 @@ vmx_fault_##n:; \ ;; \ tbit.z p6,p7=r29,IA64_PSR_VM_BIT; \ (p7)br.sptk.many vmx_dispatch_reflection;\ -br.sptk.many dispatch_to_fault_handler; \ +br.sptk.many dispatch_to_fault_handler GLOBAL_ENTRY(vmx_panic) @@ -144,12 +145,11 @@ END(vmx_vhpt_miss) // 0x0400 Entry 1 (size 64 bundles) ITLB (21) ENTRY(vmx_itlb_miss) VMX_DBG_FAULT(1) +mov r29=cr.ipsr mov r31 = pr -mov r29=cr.ipsr; -;; -tbit.z p6,p7=r29,IA64_PSR_VM_BIT; -(p6) br.sptk vmx_alt_itlb_miss_1 -//(p6) br.sptk vmx_fault_1 +;; +tbit.z p6,p7=r29,IA64_PSR_VM_BIT +(p6) br.sptk vmx_alt_itlb_miss_vmm mov r16 = cr.ifa ;; thash r17 = r16 @@ -159,47 +159,52 @@ ENTRY(vmx_itlb_miss) adds r28 = VLE_TITAG_OFFSET,r17 adds r19 = VLE_CCHAIN_OFFSET, r17 ;; -ld8 r17 = [r19] +ld8 r17 = [r19]// Read chain ;; vmx_itlb_loop: -cmp.eq p6,p0 = r0, r17 +cmp.eq p6,p0 = r0, r17 // End of chain ? (p6)br vmx_itlb_out ;; adds r16 = VLE_TITAG_OFFSET, r17 adds r19 = VLE_CCHAIN_OFFSET, r17 ;; -ld8 r24 = [r16] -ld8 r23 = [r19] +ld8 r24 = [r16] // Read tag +ld8 r23 = [r19] // Read chain ;; lfetch [r23] -cmp.eq p6,p7 = r20, r24 -;; -(p7)mov r17 = r23; -(p7)br.sptk vmx_itlb_loop -;; -ld8 r25 = [r17] -ld8 r27 = [r18] -ld8 r29 = [r28] -dep r22 = -1,r24,63,1//set ti=1 -;; -st8 [r16] = r29, VLE_ITIR_OFFSET - VLE_TITAG_OFFSET -st8 [r28] = r22, VLE_ITIR_OFFSET - VLE_TITAG_OFFSET -extr.u r19 = r27, 56, 4 +cmp.eq p6,p7 = r20, r24 // does tag match ? +;; +(p7)mov r17 = r23; // No: entry = chain +(p7)br.sptk vmx_itlb_loop // again +;; +// Swap the first entry with the entry found in the collision chain +// to speed up next hardware search (and keep LRU). +// In comments 1 stands for the first entry and 2 for the found entry. +ld8 r25 = [r17] // Read value of 2 +ld8 r27 = [r18] // Read value of 1 +ld8 r29 = [r28] // Read tag of 1 +dep r22 = -1,r24,63,1//set ti=1 of 2 (to disable it during the swap) +;; +st8 [r16] = r29, VLE_ITIR_OFFSET - VLE_TITAG_OFFSET // Write tag of 2 +st8 [r28] = r22, VLE_ITIR_OFFSET - VLE_TITAG_OFFSET // Write tag of 1 +extr.u r19 = r27, 56, 4 // Extract collision chain length mf ;; -ld8 r29 = [r16] -ld8 r22 = [r28] -dep r27 = r0, r27, 56, 4 -dep r25 = r19, r25, 56, 4 -;; -st8 [r16] = r22 -st8 [r28] = r29, VLE_TITAG_OFFSET - VLE_ITIR_OFFSET -st8 [r18] = r25 -st8 [r17] = r27 -;; -st8.rel [r28] = r24 +ld8 r29 = [r16] // read itir of 2 +ld8 r22 = [r28] // read itir of 1 +dep r27 = r0, r27, 56, 4 // Clear collision chain length for 2 +dep r25 = r19, r25, 56, 4 // Write collision chain length for 1 +;; +st8 [r16] = r22 // Write itir of 2 +st8 [r28] = r29, VLE_TITAG_OFFSET - VLE_ITIR_OFFSET // write itir of 1 +st8 [r18] = r25 // Write value of 1 +st8 [r17] = r27 // Write value of 2 +;; +st8.rel [r28] = r24 // Write tag of 1 (with ti=0) +// Insert the translation entry itc.i r25 dv_serialize_data +// Resume mov r17=cr.isr mov r23=r31 mov r22=b0 @@ -226,11 +231,11 @@ END(vmx_itlb_miss) // 0x0800 Entry 2 (size 64 bundles) DTLB (9,48) ENTRY(vmx_dtlb_miss) VMX_DBG_FAULT(2) +mov r29=cr.ipsr mov r31 = pr -mov r29=cr.ipsr; -;; -tbit.z p6,p7=r29,IA64_PSR_VM_BIT; -(p6)br.sptk vmx_alt_dtlb_miss_1 +;; +tbit.z p6,p7=r29,IA64_PSR_VM_BIT +(p6)br.sptk vmx_alt_dtlb_miss_vmm mov r16 = cr.ifa ;; thash r17 = r16 @@ -307,14 +312,14 @@ END(vmx_dtlb_miss) // 0x0c00 Entry 3 (size 64 bundles) Alt ITLB (19) ENTRY(vmx_alt_itlb_miss) VMX_DBG_FAULT(3) +mov r29=cr.ipsr mov r31 = pr -mov r29=cr.ipsr -;; -tbit.z p6,p7=r29,IA64_PSR_VM_BIT -(p7)br.spnt
Re: [Xen-ia64-devel] [PATCH] fix wrong insertion of TLB entry in region 0
Quoting Kouya Shimura [EMAIL PROTECTED]: On PV domain with metaphysical mode, emulation of itc.d in region 0 doesn't work well and inserts an wrong TC entry. Because set_one_rr() doesn't set the machine region register. i.e. metaphyisical_rr0 is used instead of guest's rr[0]. This bug causes Dom0/U crash when an application uses region 0. Actually I met the crash when I was building open GFW (java uses region 0). I am a little bit puzzled. Isn't saved_rr0 supposed to be the mangled version of rr[0] ? Either this patch should be a no-op or the bug is somewhere else (or I am wrong). Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] fix wrong insertion of TLB entry in region 0
Quoting Kouya Shimura [EMAIL PROTECTED]: Hi Tristan, vcpu-arch.metaphysical_saved_rr0 is the mangled version of rr[0]. The difference of this patch is whether the machine rr is set or not. Thank you for the details. Your patch will also makes things clearer. Good catch! Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] xenctx: fix rse arithmetic
Quoting Isaku Yamahata [EMAIL PROTECTED]: fix xenctx: rse arithmetic. Argh, you're right. I have fixed this in xenitp but forgot to backport to xenctxt. Tristan. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
