Re: [Xen-ia64-devel] RE: [PATCH 0/5] fix fpswa and related issues.
On Thu, 2008-12-11 at 11:05 +0900, Isaku Yamahata wrote: Just to make sure. Is fpswa.efi installed in hvm domain? You can also confirm it by dh command in efi shell. Argh, that was it. I loaded fpswa.efi into my EFI partition after the tests started failing, but I didn't have it in the right location for elilo to pick it up automatically. Running load fpswa.efi makes it work, and copying fpswa.efi to \efi\intel firmware\fpswa.efi also works. I'll add your panic fix and let it run for a while, seems like it's running well now. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] RE: [PATCH 0/5] fix fpswa and related issues.
On Thu, 2008-12-11 at 09:04 -0700, Alex Williamson wrote: On Thu, 2008-12-11 at 11:05 +0900, Isaku Yamahata wrote: Just to make sure. Is fpswa.efi installed in hvm domain? You can also confirm it by dh command in efi shell. Argh, that was it. I loaded fpswa.efi into my EFI partition after the tests started failing, but I didn't have it in the right location for elilo to pick it up automatically. Running load fpswa.efi makes it work, and copying fpswa.efi to \efi\intel firmware\fpswa.efi also works. I'll add your panic fix and let it run for a while, seems like it's running well now. Thanks, One other comment on the patches, I'd recommend removing both instances of this: printk(ia64_handle_reflection: handling FP trap\n); from ia64_handle_reflection(). If we're properly handling the trap, this is just unnecessary noise. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] RE: [PATCH 0/5] fix fpswa and related issues.
On Fri, 2008-12-12 at 10:22 +0900, Isaku Yamahata wrote: Thank you for testing. I'll commit my patches with some clean up. Testing update; I've had 2 PV domains, 2 HVM domains, and dom0 all running the test program for over 10 hours. Everything looks good. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] RE: [PATCH 0/5] fix fpswa and related issues.
On Tue, 2008-12-09 at 21:23 -0700, Alex Williamson wrote: On Wed, 2008-12-10 at 10:51 +0800, Zhang, Xiantao wrote: I've been testing this for a few hours today (over 25k iterations) and it seems to fix the problem for me. Thanks! Hi, Alex Have you verified vmx domain as well ? Good point, no I was just testing in dom0. Adding in Isaku's last patch and testing on an HVM domain, it doesn't take long to hit problems. 4-way/4G HVM guest running 4 instances of the test program in parallel will eventually get this in the guest kernel: handle_fpu_swa: fp_emulate() returned -1 and the test program gets killed with a SIGFPE. -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH 0/5] fix fpswa and related issues.
On Tue, 2008-12-09 at 18:29 +0900, Isaku Yamahata wrote: Hi. This patch series addresses the bug reported as http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1392 Please test it. It includes some clean ups and a reimplementation of fpswa hypercall. When fp fault/trap occurs, xen vmm tries to get a bundle in question from guest virtual address space. It sometimes fails because of I/D tlb cache. In that case inject the fault/trap into a guest and let a guest to call fpswa hypercall. Hi Isaku, I've been testing this for a few hours today (over 25k iterations) and it seems to fix the problem for me. Thanks! Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] RE: [PATCH 0/5] fix fpswa and related issues.
On Wed, 2008-12-10 at 10:51 +0800, Zhang, Xiantao wrote: I've been testing this for a few hours today (over 25k iterations) and it seems to fix the problem for me. Thanks! Hi, Alex Have you verified vmx domain as well ? Good point, no I was just testing in dom0. Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Fwd: [Xen-bugs] [Bug 1392] New: Problems with denormalized floating point numbers on XEN-virtualized Linux/IA64]
On Thu, 2008-12-04 at 15:29 +0900, Isaku Yamahata wrote: Although I also replied by the bugzilla, I also send the patch to the list for those who doesn't watch on the bug report. I hope this patch fixes it, please try this. Hi Isaku, Thanks for looking at this. With your patch, it doesn't fail, but I regularly see cases where it doesn't complete, at least not in a reasonable time frame. I imagine it's getting stuck in an endless loop of retries. On bare metal the test takes about 1.3s (1.66GHz Montvale). The few cases I've seen it complete running in dom0, it takes about 3.1s (1.6GHz Montecito). Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [Fwd: [Xen-bugs] [Bug 1392] New: Problems with denormalized floating point numbers on XEN-virtualized Linux/IA64]
arch : IA-64 family : 32 model : 0 revision : 7 archrev: 0 features : branchlong, 16-byte atomic ops cpu number : 0 cpu regs : 4 cpu MHz: 1594.000895 itc MHz: 399.86 BogoMIPS : 3178.49 siblings : 1 CPUID0: 0x756E6547 CPUID1: 0x6C65746E CPUID2: 0x0 CPUID3: 0x2704 CPUID4: 0x5 -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Print ACPI signature before overwriting it
Here's another trivial patch. We're printing out the ACPI table
signature after we overwrite it with OEMx. Let's print it out before
so we know that the table was. Also limit print to 4 chars so we don't
get garbage output.
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
--
diff -r 7c2bc0cd57c5 xen/arch/ia64/xen/dom_fw_dom0.c
--- a/xen/arch/ia64/xen/dom_fw_dom0.c Fri Aug 08 08:50:10 2008 -0600
+++ b/xen/arch/ia64/xen/dom_fw_dom0.c Fri Aug 08 09:37:11 2008 -0600
@@ -154,6 +154,8 @@ acpi_restore_tables()
static int __init __acpi_table_disable(struct acpi_table_header *header)
{
+ printk(Disabling ACPI table: %4.4s\n, header-signature);
+
memcpy(header-oem_id, xx, 6);
memcpy(header-oem_id+1, header-signature, 4);
memcpy(header-oem_table_id, Xen , 8);
@@ -161,7 +163,6 @@ static int __init __acpi_table_disable(s
header-checksum = 0;
header-checksum = -acpi_tb_checksum((u8*)header, header-length);
- printk(Successfully Disabling %s\n, header-signature);
return 0;
}
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] 0/3 Fix PV driver domains
Driver domains seem to be suffering from some neglect and breakage due to x86 support for IOMMU devices. This series of patches get it back into a working state. The first two patches are pretty clear infrastructure and stubs for new hypercalls. I think these two are ok to put in the tree on their own. The last patch is rather ugly, so I'm posting it as an RFC to see if anyone has better ideas. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] 1/3 Fix PV driver domains - xenlinux xencomm support
This adds xencomm support for several PHYSDEVOP calls (manage_pci_add,
manage_pci_remove, map_pirq, and unmap_pirq) as well
as XEN_DOMCTL_assign_device.
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
--
diff -r 2866e6af503e arch/ia64/xen/xcom_hcall.c
--- a/arch/ia64/xen/xcom_hcall.cThu Jul 31 15:33:54 2008 +0100
+++ b/arch/ia64/xen/xcom_hcall.cThu Aug 07 13:51:05 2008 -0600
@@ -143,6 +143,16 @@ xencomm_hypercall_physdev_op(int cmd, vo
break;
case PHYSDEVOP_irq_status_query:
argsize = sizeof(physdev_irq_status_query_t);
+ break;
+ case PHYSDEVOP_manage_pci_add:
+ case PHYSDEVOP_manage_pci_remove:
+ argsize = sizeof(physdev_manage_pci_t);
+ break;
+ case PHYSDEVOP_map_pirq:
+ argsize = sizeof(physdev_map_pirq_t);
+ break;
+ case PHYSDEVOP_unmap_pirq:
+ argsize = sizeof(physdev_unmap_pirq_t);
break;
default:
diff -r 2866e6af503e arch/ia64/xen/xcom_privcmd.c
--- a/arch/ia64/xen/xcom_privcmd.c Thu Jul 31 15:33:54 2008 +0100
+++ b/arch/ia64/xen/xcom_privcmd.c Thu Aug 07 13:51:05 2008 -0600
@@ -327,6 +327,7 @@ xencomm_privcmd_domctl(privcmd_hypercall
case XEN_DOMCTL_settimeoffset:
case XEN_DOMCTL_sendtrigger:
case XEN_DOMCTL_set_opt_feature:
+ case XEN_DOMCTL_assign_device:
break;
case XEN_DOMCTL_pin_mem_cacheattr:
return -ENOSYS;
@@ -828,6 +829,36 @@ xencomm_privcmd_ia64_debug_op(privcmd_hy
return ret;
}
+static int
+xencomm_privcmd_ia64_physdev_op(privcmd_hypercall_t *hypercall)
+{
+ int cmd = hypercall-arg[0];
+ struct xencomm_handle *desc;
+ unsigned int argsize;
+ int ret;
+
+ switch (cmd) {
+ case PHYSDEVOP_map_pirq:
+ argsize = sizeof(physdev_map_pirq_t);
+ break;
+ case PHYSDEVOP_unmap_pirq:
+ argsize = sizeof(physdev_unmap_pirq_t);
+ break;
+ default:
+ printk(%s: unknown PHYSDEVOP %d\n, __func__, cmd);
+ return -EINVAL;
+ }
+
+ desc = xencomm_map((void *)hypercall-arg[1], argsize);
+ if ((void *)hypercall-arg[1] != NULL argsize 0 desc == NULL)
+ return -ENOMEM;
+
+ ret = xencomm_arch_hypercall_physdev_op(cmd, desc);
+
+ xencomm_free(desc);
+ return ret;
+}
+
int
privcmd_hypercall(privcmd_hypercall_t *hypercall)
{
@@ -854,6 +885,8 @@ privcmd_hypercall(privcmd_hypercall_t *h
return xencomm_privcmd_ia64_dom0vp_op(hypercall);
case __HYPERVISOR_ia64_debug_op:
return xencomm_privcmd_ia64_debug_op(hypercall);
+ case __HYPERVISOR_physdev_op:
+ return xencomm_privcmd_ia64_physdev_op(hypercall);
default:
printk(%s: unknown hcall (%ld)\n, __func__, hypercall-op);
return -ENOSYS;
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] 2/3 Fix PV driver domains - xen stubs
Stub out new hypercalls in the hypervisor. The only odd one here is map/unmap_pirq. This seems to be for MSI support, which I don't believe we currently support for driver domains, so this is actually similar to the x86 code path. The tools code doesn't allow us to return -ENOSYS here :( Signed-off-by: Alex Williamson [EMAIL PROTECTED] -- diff -r eff5fcfa69bc xen/arch/ia64/xen/dom0_ops.c --- a/xen/arch/ia64/xen/dom0_ops.c Wed Aug 06 15:19:13 2008 +0100 +++ b/xen/arch/ia64/xen/dom0_ops.c Thu Aug 07 13:50:26 2008 -0600 @@ -388,6 +388,10 @@ long arch_do_domctl(xen_domctl_t *op, XE } break; +case XEN_DOMCTL_assign_device: +ret = -ENOSYS; +break; + default: printk(arch_do_domctl: unrecognized domctl: %d!!!\n,op-cmd); ret = -ENOSYS; diff -r eff5fcfa69bc xen/arch/ia64/xen/hypercall.c --- a/xen/arch/ia64/xen/hypercall.c Wed Aug 06 15:19:13 2008 +0100 +++ b/xen/arch/ia64/xen/hypercall.c Thu Aug 07 13:50:26 2008 -0600 @@ -426,6 +426,16 @@ long do_physdev_op(int cmd, XEN_GUEST_HA break; } +/* + * XXX We don't support MSI for PCI passthrough, so just return success + */ +case PHYSDEVOP_map_pirq: +case PHYSDEVOP_unmap_pirq: +ret = 0; +break; + +case PHYSDEVOP_manage_pci_add: +case PHYSDEVOP_manage_pci_remove: default: ret = -ENOSYS; break; ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] backport EFI version warning fix
We have boxes that report EFI version 2.00 now, so adopt upstream linux
patch to only warn on versions less that 1.00. Based on linux-2.6.git
873ec746158403af82c57ce26780166aafc159e1.
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
--
diff -r eff5fcfa69bc xen/arch/ia64/linux-xen/efi.c
--- a/xen/arch/ia64/linux-xen/efi.c Wed Aug 06 15:19:13 2008 +0100
+++ b/xen/arch/ia64/linux-xen/efi.c Thu Aug 07 15:28:22 2008 -0600
@@ -485,11 +485,11 @@ efi_init (void)
panic(Woah! Can't find EFI system table.\n);
if (efi.systab-hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE)
panic(Woah! EFI system table signature incorrect\n);
- if ((efi.systab-hdr.revision ^ EFI_SYSTEM_TABLE_REVISION) 16 != 0)
- printk(KERN_WARNING Warning: EFI system table major version
mismatch:
- got %d.%02d, expected %d.%02d\n,
- efi.systab-hdr.revision 16, efi.systab-hdr.revision
0x,
- EFI_SYSTEM_TABLE_REVISION 16,
EFI_SYSTEM_TABLE_REVISION 0x);
+ if ((efi.systab-hdr.revision 16) == 0)
+ printk(KERN_WARNING Warning: EFI system table version
+ %d.%02d, expected 1.00 or greater\n,
+ efi.systab-hdr.revision 16,
+ efi.systab-hdr.revision 0x);
config_tables = __va(efi.systab-tables);
diff -r eff5fcfa69bc xen/arch/ia64/xen/dom_fw_common.c
--- a/xen/arch/ia64/xen/dom_fw_common.c Wed Aug 06 15:19:13 2008 +0100
+++ b/xen/arch/ia64/xen/dom_fw_common.c Thu Aug 07 15:28:22 2008 -0600
@@ -416,7 +416,7 @@ dom_fw_init(domain_t *d,
/* EFI systab. */
tables-efi_systab.hdr.signature = EFI_SYSTEM_TABLE_SIGNATURE;
- tables-efi_systab.hdr.revision = EFI_SYSTEM_TABLE_REVISION;
+ tables-efi_systab.hdr.revision = ((1 16) | 00); /* EFI 1.00 */
tables-efi_systab.hdr.headersize = sizeof(tables-efi_systab.hdr);
memcpy(tables-fw_vendor,FW_VENDOR,sizeof(FW_VENDOR));
diff -r eff5fcfa69bc xen/include/asm-ia64/linux-xen/linux/efi.h
--- a/xen/include/asm-ia64/linux-xen/linux/efi.hWed Aug 06 15:19:13
2008 +0100
+++ b/xen/include/asm-ia64/linux-xen/linux/efi.hThu Aug 07 15:28:22
2008 -0600
@@ -217,7 +217,6 @@ typedef struct {
} efi_config_table_t;
#define EFI_SYSTEM_TABLE_SIGNATURE ((u64)0x5453595320494249ULL)
-#define EFI_SYSTEM_TABLE_REVISION ((1 16) | 00)
typedef struct {
efi_table_hdr_t hdr;
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Cleanup ACPI checksum warnings
On bootup, I get a couple of these:
(XEN) ACPI Warning (tbutils-0219): Incorrect checksum in table [APIC] - CE,
should be 04 [20070126]
(XEN) ACPI Warning (tbutils-0219): Incorrect checksum in table [APIC] - CE,
should be 04 [20070126]
I don't remember seeing them before, but they're pretty easy to fix.
The problem is we update the lsapics, causing the checksum to be wrong,
then we look for platform interrupt sources, which spits out a warning,
and finally we look for the MADT again to fix the checksum, which also
prints a warning. If we grab a pointer to the MADT before these, we can
update the checksum after each step and avoid the warnings.
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
--
diff -r eff5fcfa69bc xen/arch/ia64/xen/dom_fw_dom0.c
--- a/xen/arch/ia64/xen/dom_fw_dom0.c Wed Aug 06 15:19:13 2008 +0100
+++ b/xen/arch/ia64/xen/dom_fw_dom0.c Thu Aug 07 16:17:39 2008 -0600
@@ -101,6 +101,9 @@ acpi_update_madt_checksum(struct acpi_ta
{
struct acpi_table_madt *acpi_madt;
+ if (!table)
+ return -EINVAL;
+
acpi_madt = (struct acpi_table_madt *)table;
acpi_madt-header.checksum = 0;
acpi_madt-header.checksum = -acpi_tb_checksum((u8*)acpi_madt,
@@ -170,7 +173,11 @@ static void __init acpi_table_disable(ch
/* base is physical address of acpi table */
static void __init touch_acpi_table(void)
{
+ struct acpi_table_header *madt = NULL;
+
lsapic_nbr = 0;
+
+ acpi_get_table(ACPI_SIG_MADT, 0, madt);
/*
* Modify dom0 MADT:
@@ -179,16 +186,22 @@ static void __init touch_acpi_table(void
* - Hide CPEI interrupt source
*
* ACPI tables must be backed-up before modification!
+*
+* We update the checksum each time we modify to keep the
+* ACPI CA from warning about invalid checksums.
*/
acpi_table_parse(ACPI_SIG_MADT, acpi_backup_table);
if (acpi_table_parse_madt(ACPI_MADT_LSAPIC, acpi_update_lsapic, 0) 0)
printk(Error parsing MADT - no LAPIC entries\n);
+
+ acpi_update_madt_checksum(madt);
+
if (acpi_table_parse_madt(ACPI_MADT_PLAT_INT_SRC,
acpi_patch_plat_int_src, 0) 0)
printk(Error parsing MADT - no PLAT_INT_SRC entries\n);
- acpi_table_parse(ACPI_SIG_MADT, acpi_update_madt_checksum);
+ acpi_update_madt_checksum(madt);
/*
* SRAT SLIT tables aren't useful for Dom0 until
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Remove VT-i no opcode warning
I've never been sure why we have such a big scary warning around this, when I have yet to see any system that does provide opcode decoding. Let's remove it. Signed-off-by: Alex Williamson [EMAIL PROTECTED] -- diff -r eff5fcfa69bc xen/arch/ia64/vmx/vmx_init.c --- a/xen/arch/ia64/vmx/vmx_init.c Wed Aug 06 15:19:13 2008 +0100 +++ b/xen/arch/ia64/vmx/vmx_init.c Thu Aug 07 16:28:08 2008 -0600 @@ -117,9 +117,6 @@ identify_vmx_feature(void) goto no_vti; } - /* Does xen has ability to decode itself? */ - if (!(vp_env_info VP_OPCODE)) - printk(WARNING: no opcode provided from hardware(%lx)!!!\n, vp_env_info); printk(vm buffer size: %ld\n, buffer_size); vmx_enabled = 1; ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH][LINUX] Support timer vector IPIs in PVcode
On Mon, 2008-07-28 at 11:44 +0800, Yu, Luming wrote: Could please you point out url for the patch being accepted into xen-ia64 upstream? I think this is what you're looking for: http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg?rev/c4b12c90de0e raw ascii: http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg?raw-rev/c4b12c90de0e Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH][LINUX] Support timer vector IPIs in PV code
Upstream Linux recently added this change:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3463a93def55c309f3c0d0a8aaf216be3be42d64
Now, for a platform bug check, we issue an IPI for the IA64_TIMER_VECTOR
and wait for it to show up in the IRR. Since a PV kernel doesn't
support a timer IPI, this never happens. The fix is simply to tie this
into xen_send_ipi() for this case. This doesn't actually happen on
2.6.18, but since vendors are backporting changes from upstream, I think
it's good to have this in the reference tree. Thanks,
Alex
Add support for IA64_TIMER_VECTOR as a paravirtualized IPI target
Necessary for the latest upstream Linux implementation of
check_sal_cache_flush() 3463a93def55c309f3c0d0a8aaf216be3be42d64
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
--
diff -r 8a3dc4fdb478 arch/ia64/kernel/irq_ia64.c
--- a/arch/ia64/kernel/irq_ia64.c Tue Jul 22 11:59:42 2008 +0100
+++ b/arch/ia64/kernel/irq_ia64.c Thu Jul 24 12:19:05 2008 -0600
@@ -534,12 +534,11 @@ xen_platform_send_ipi(int cpu, int vecto
xen_platform_send_ipi(int cpu, int vector, int delivery_mode, int redirect)
{
int irq = -1;
+ extern void xen_send_ipi(int cpu, int vec);
#ifdef CONFIG_SMP
/* TODO: we need to call vcpu_up here */
if (unlikely(vector == ap_wakeup_vector)) {
- extern void xen_send_ipi (int cpu, int vec);
-
/* XXX
* This should be in __cpu_up(cpu) in ia64 smpboot.c
* like x86. But don't want to modify it,
@@ -566,6 +565,9 @@ xen_platform_send_ipi(int cpu, int vecto
case IA64_CPEP_VECTOR:
irq = per_cpu(ipi_to_irq, cpu)[CPEP_VECTOR];
break;
+ case IA64_TIMER_VECTOR:
+ xen_send_ipi(cpu, vector);
+ return;
default:
printk(KERN_WARNING Unsupported IPI type 0x%x\n,
vector);
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] zero extend I/O reads
Jes Sorensen debugged an issue recently on KVM that a ld2.acq was
getting sign extended in the I/O emulation path[1][2]. This was exposed
by the VGA console hanging due to some benign looking changes to the VGA
console structure several kernel revisions back. I remember seeing this
on Xen, but I've lost the recipe to reproduce it. I believe the
following patch adds the same logic that is being incorporated for KVM,
but I'm unable to prove we're hitting the same issue since I can no
longer reproduce it. Please review and apply if it looks right.
Thanks,
Alex
[1] http://marc.info/?t=12111893401
[2] http://marc.info/?t=12112784858
[IA64] zero pad emulated I/O instructions
Fixes issue seen on KVM with more recent upstream changes to the VGA
console structure.
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
--
diff -r f04ce41dab84 xen/arch/ia64/vmx/mmio.c
--- a/xen/arch/ia64/vmx/mmio.c Tue May 20 18:54:09 2008 +0900
+++ b/xen/arch/ia64/vmx/mmio.c Wed May 21 13:02:27 2008 -0600
@@ -171,7 +171,7 @@ static void low_mmio_access(VCPU *vcpu,
vmx_send_assist_req(v);
if (dir == IOREQ_READ)
-*val = p-data;
+*val = p-data (~0UL (BITS_PER_LONG - (s * 8)));
return;
}
@@ -340,7 +340,7 @@ static void legacy_io_access(VCPU *vcpu,
vmx_send_assist_req(v);
if (dir == IOREQ_READ) { // read
-*val=p-data;
+*val = p-data (~0UL (BITS_PER_LONG - (s * 8)));
}
#ifdef DEBUG_PCI
if (dir == IOREQ_WRITE)
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] zero extend I/O reads
On Thu, 2008-05-22 at 12:51 +0900, Isaku Yamahata wrote: Hi Alex. I digged into log and found the two commits as below. I think they fixed the issue. So I guess you encountered the issue before committing the c/s 16180:62a7a2f4d9c7. They are several mounths before, so memory might be vague... Hi Isaku, Good, thanks for tracking down the mystery of why it got fixed. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] The commit to xen/ia64 repository.
On Tue, 2008-05-13 at 11:49 +0900, Isaku Yamahata wrote: Hello xen/ia64 developer. I committed some patches to the xenbits ia64 repository. I believe that I caught up pending patches. If I'm missing any, please remind me. ... This commit is my first time to commit. I hope that I didn't do anything wrong. If you find anything bad, please let me know. Hi Isaku, Looks good to me. Thanks! Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] remove warnings in replace_grant_host_mapping()
On Tue, 2008-05-13 at 11:56 +0900, Isaku Yamahata wrote:
[IA64] remove warnings in replace_grant_host_mapping()
diff -r b52e75f2416a xen/arch/ia64/xen/mm.c
--- a/xen/arch/ia64/xen/mm.c Mon May 12 16:23:54 2008 +0900
+++ b/xen/arch/ia64/xen/mm.c Mon May 12 16:30:46 2008 +0900
@@ -2191,7 +2191,7 @@
struct page_info* page = mfn_to_page(mfn);
struct page_info* new_page = NULL;
volatile pte_t* new_page_pte = NULL;
-unsigned long new_page_mfn;
+unsigned long new_page_mfn = INVALID_MFN;
if (new_gpaddr) {
new_page_pte = lookup_noalloc_domain_pte_none(d, new_gpaddr);
@@ -2211,7 +2211,7 @@
new_gpaddr 0x%lx mfn 0x%lx\n,
__func__, gpaddr, mfn, new_gpaddr,
new_page_mfn);
new_page = NULL; /* prevent domain_put_page() */
-goto out;
+goto out_nomsg;
These could really just be 'return GNTST_general_error;' since there's
no other cleanup, then you could avoid a goto.
Alex
--
Alex Williamson HP Open Source Linux Org.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Xen/ia64 maintainership transition
Hi all, The Xen/ia64 project has come a long way in the past few years, and it's with some satisfaction and excitement that I announce the transition of the maintainership. Isaku Yamahata, who is easily the biggest contributor to the project and in many ways the technical expert, has graciously agreed to take over this role. I've been working with Isaku on infrastructure and testing setup, and will continue to help as needed until Isaku is comfortable. I intend to stay involved with the project, but after over two years as the maintainer, I'm ready for a change. Congratulations and best of luck Isaku, thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [patch 00/12] ia64: kexec: Map EFI memory in the same location as Linux (v20080423)
On Thu, 2008-03-20 at 15:52 +0900, Simon Horman wrote: Hi, here is another spin of the kexec EFI patches. Hi Simon, I'm afraid to say it, but I've seen another issue :( I accidentally trashed my win2k3 guest, so as part of testing this set I started reinstalling the guest. Meanwhile I thought I'd test win2k8... boom, the machine silently MCAs. The win2k3 guest is early on, at the point of loading the Windows Executive, the win2k8 box is just after logging in. I don't know if it's an actual interaction between the two guests, but it's surprisingly easy to reproduce on my system. It only seems to occur with the kexec series loaded. An additional scary aspect is that after one of the MCAs, EFI complained that my RTC was invalid and set it back to an initial value. I've only seen that once, but certainly plants the idea that maybe an HVM guest got to it somehow. FWIW, I tried to reproduce these same conditions using the current ia64/xen-unstable.hg tree and ran through a few times w/o hitting any problems. I'll see if I can better characterize the issue, but you might try something similar. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [patch 06/12] ia64: kexec: Repining for EFI RID
Hi Simon,
This series seems to work ok for me, at least as far as existing
functionality, I haven't tested kexec. This patch has some commented
out code (a couple lines in the asm, then a chunk later). Can this be
cleaned out, or should it at least be better commented about why it
remains? There's also a rather obvious FIXME in this patch, has this
been resolved to your satisfaction, or can someone else on list familiar
with unwind statements comment? Thanks,
Alex
On Thu, 2008-04-24 at 09:04 +1000, Simon Horman wrote:
A cut down version of set_one_rr (and ia64_new_rr7) for
use when switching to the EFI RID for SAL, PAL and EFI calls.
There seems to be no need to repin: palcode, mapped_regs or vhpt in this
case. If it turns they do need to be repinned then special care needs to
betaken to track the correct value to repin. That is generally the values
that were most recently pinned by ia64_new_rr7.
ia64_new_rr7_efi can probably be merged with ia64_new_rr7,
as they are quite similar, but for testing purposes it seems
easier to keep them separate.
Cc: Isaku Yamahata [EMAIL PROTECTED]
Cc: Alex Williamson [EMAIL PROTECTED]
Cc: Aron Griffis [EMAIL PROTECTED]
Signed-off-by: Simon Horman [EMAIL PROTECTED]
---
Wed, 23 Apr 2008 10:09:03 +1000
* Repin VPD (privregs) if they have been pinned
- A separate patch handles unpinning on kexec
Thu, 24 Apr 2008 08:35:03 +1000
* Move percpu_set declaration from xen/include/xen/cpumask.h
(symlink, generic code) to xen/include/asm-ia64/regionreg.h
(file, architecture-specific code)
Index: xen-unstable.hg/xen/arch/ia64/xen/regionreg.c
===
--- xen-unstable.hg.orig/xen/arch/ia64/xen/regionreg.c2008-04-24
08:31:32.0 +1000
+++ xen-unstable.hg/xen/arch/ia64/xen/regionreg.c 2008-04-24
08:33:36.0 +1000
@@ -11,6 +11,7 @@
#include linux/config.h
#include linux/types.h
#include linux/sched.h
+#include linux/percpu.h
#include asm/page.h
#include asm/regionreg.h
#include asm/vhpt.h
@@ -20,6 +21,8 @@
/* Defined in xemasm.S */
extern void ia64_new_rr7(unsigned long rid, void *shared_info, void
*shared_arch_info, unsigned long shared_info_va, unsigned long va_vhpt);
+extern void ia64_new_rr7_efi(unsigned long rid, unsigned long percpu_pte,
+ unsigned long privregs);
/* RID virtualization mechanism is really simple: domains have less rid bits
than the host and the host rid space is shared among the domains. (Values
@@ -233,6 +236,7 @@ set_rr(unsigned long rr, unsigned long r
DEFINE_PER_CPU(unsigned long, inserted_vhpt);
#endif
DEFINE_PER_CPU(unsigned long, inserted_shared_info);
+DEFINE_PER_CPU(unsigned long, inserted_privregs);
// validates and changes a single region register
// in the currently executing domain
@@ -281,6 +285,29 @@ int set_one_rr(unsigned long rr, unsigne
return 1;
}
+int set_one_rr_efi(unsigned long rr, unsigned long val)
+{
+ unsigned long rreg = REGION_NUMBER(rr);
+ struct vcpu *v = current;
+ int percpu_set_f;
+ unsigned long privregs = 0UL;
+
+ BUG_ON(rreg != 6 rreg != 7);
+
+ if (rreg == 6) {
+ ia64_set_rr(rr, val);
+ ia64_srlz_d();
+ }
+ else {
+ percpu_set_f = cpu_isset(smp_processor_id(), percpu_set);
+ if (percpu_set_f)
+ privregs = __get_cpu_var(inserted_privregs);
+ ia64_new_rr7_efi(val, percpu_set_f, privregs);
+ }
+
+ return 1;
+}
+
void set_virtual_rr0(void)
{
struct vcpu *v = current;
Index: xen-unstable.hg/xen/arch/ia64/xen/xenasm.S
===
--- xen-unstable.hg.orig/xen/arch/ia64/xen/xenasm.S 2008-04-23
12:30:32.0 +1000
+++ xen-unstable.hg/xen/arch/ia64/xen/xenasm.S2008-04-24
08:33:36.0 +1000
@@ -195,6 +195,193 @@ GLOBAL_ENTRY(ia64_new_rr7)
br.ret.sptk.many rp
END(ia64_new_rr7)
+
+ /* ia64_new_rr7_efi:
+ * in0 = rid
+ * in1 = repin_percpu
+ * in2 = vpd vaddr
+ *
+ * There seems to be no need to repin: palcode, mapped_regs
+ * or vhpt. If they do need to be repinned then special care
+ * needs to betaken to track the correct value to repin.
+ * That is generally the values that were most recently pinned by
+ * ia64_new_rr7.
+ *
+ * This code function could probably be merged with ia64_new_rr7
+ * as it is just a trimmed down version of that function.
+ * However, current can change without repinning occuring,
+ * so simply getting the values from current does not work correctly.
+ */
+
+GLOBAL_ENTRY(ia64_new_rr7_efi)
+ // FIXME? not sure this unwind statement is correct...
+ .prologue ASM_UNW_PRLG_RP|ASM_UNW_PRLG_PFS, ASM_UNW_PRLG_GRSAVE(1)
+ alloc loc1 = ar.pfs, 3, 9, 0, 0
+ movl loc2
Re: [Xen-ia64-devel][PATCH] dom0 p2m setup fix
On Wed, 2008-04-23 at 17:19 +0800, Xu, Anthony wrote: EFI uses 4k page, while xen uses 16k page. For dom0, identity mapping are setup for EFI_ACPI_RECLAIM_MEMORY etc. It is possible when seting up dom0 memory range which may include some EFI_ACPI_RECLAIM_MEMORY due to 4k/16k alignment difference. This patch fix this issue by scaning memory descriptors twice in the first scan, setup dom0 identity mapping in the seconde scan, setup dom0 memory mapping. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] IA64 xen-3.3 unstable hanging
On Fri, 2008-04-25 at 10:30 +0900, Akio Takebe wrote: The above is different from the following log. Is this the right elilo entry? (XEN) Xen command line: BOOT_IMAGE=scsi0:EFI\redhat\xen-3.3.gz root=/dev/ VolGroup00/LogVol00 com1=38400,8n1,0x2f8,45 dom0_mem=2048M Your elilo.conf shows xen's parameter = com1=38400,8n1,0x2f8,45 dom0_mem=2048M. The log show xen's parmeters = root=/dev/VolGroup00/LogVol00 com1=38400,8n1, 0x2f8,45 dom0_mem=2048M. If this is correct, we need to investigate the parameters is passed properly. And Using loglvl=all guest_loglvl=all in xen's parameters may be helpful. We used to have an issue that a root= line in the elilo.conf would get processed this way (added to the xen half of the command line). IIRC, Aron fixed this for us. Perhaps it's an older elilo.efi and there's a global root= somewhere. I don't think that's the issue though as there should be more output around setting up dom0 before we actually start dom0. We're dying somewhere in start_kernel() between the call to init_rid_allocator() and construct_dom0(). Perhaps Kayvan could add some printks in this area to let us know when it stops. It's interesting that gsi 45 is specified for the console interrupt and the console interrupt can be enabled in that gap. Has the console interrupt always been specified there? What happens if you don't specify? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: Release candidates for 3.1.4 and 3.2.1
On Wed, 2008-04-09 at 17:10 +0100, Keir Fraser wrote: Fourth release candidates are available from the public xen-3.1-testing.hg and xen-3.2-testing.hg. BSD/IA64/Sun people: Please at least build test 3.2.1-rc4. There are a couple of bugfix backports in tools/libxc which might break your builds. It's unlikely, but I'd like to be on the safe side. These appear to build on ia64, but I'd like to see if Intel and Fujitsu could run them through their regression testing. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] linux: ia64 counter part of 501:5486a234923d
On Wed, 2008-04-02 at 15:24 +0900, Isaku Yamahata wrote: # HG changeset patch # User [EMAIL PROTECTED] # Date 1207174068 25200 # Node ID d664f2f992527714c323ea55dae662d0ff0b9078 # Parent c88b34aaff3ef008f3ee2b6be96b6275e62cc8de ia64: ia64 counter part of c/s 501:5486a234923d. x86 improved range_straddles_page_boundary() by the c/s 501:5486a234923d. The same discussin applies to ia64. This patch is ia64 counter part of it. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] 3.1-testing ia64 patches
Hi Keir,
The two patches attached are necessary for ia64 in the 3.1-testing
tree. We make use of the x86 pci-dma-xen.c in this code based, but our
pfn_to_mfn() doesn't provide the true machine frame. Instead we need
pfn_to_mfn_for_dma(). On current upstream, we've created our own files
for this and we've made the corresponding update in
ia64/linux-2.6.18-xen.hg. For this backport, the easiest approach seems
to be to redefine pfn_to_mfn() for ia64 in this file. The other patch
simply backports the addition of the paddr_t typedef. Thanks,
Alex
[IA64] avoid unnecessarily SWIOTLB bounce buffering
x86 improved range_straddles_page_boundary() by the c/s 501:5486a234923d.
The same discussion applies to ia64. This patch is ia64 counter part of it.
[ported from mainline version]
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
linux-2.6.18-xen changeset: ec6e3e18ea314e9520ee6bba898e30228bf3bda4
linux-2.6.18-xen date: Wed Apr 02 10:02:57 2008 -0600
diff -r cdca34378e8e linux-2.6-xen-sparse/arch/i386/kernel/pci-dma-xen.c
--- a/linux-2.6-xen-sparse/arch/i386/kernel/pci-dma-xen.c Mon Mar 31 18:09:19 2008 +0100
+++ b/linux-2.6-xen-sparse/arch/i386/kernel/pci-dma-xen.c Wed Apr 02 21:00:10 2008 -0600
@@ -74,6 +74,11 @@ do { \
BUG(); \
} \
} while (0)
+
+#ifdef __ia64__
+#undef pfn_to_mfn
+#define pfn_to_mfn pfn_to_mfn_for_dma
+#endif
static int check_pages_physically_contiguous(unsigned long pfn,
unsigned int offset,
diff -r cdca34378e8e linux-2.6-xen-sparse/include/asm-ia64/dma-mapping.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/dma-mapping.h Mon Mar 31 18:09:19 2008 +0100
+++ b/linux-2.6-xen-sparse/include/asm-ia64/dma-mapping.h Wed Apr 02 21:00:10 2008 -0600
@@ -124,13 +124,7 @@ address_needs_mapping(struct device *hwd
return (addr ~mask) != 0;
}
-static inline int
-range_straddles_page_boundary(void *p, size_t size)
-{
- extern unsigned long *contiguous_bitmap;
- return (unsigned long)p ~PAGE_MASK) + size) PAGE_SIZE)
- !test_bit(__pa(p) PAGE_SHIFT, contiguous_bitmap));
-}
+extern int range_straddles_page_boundary(paddr_t p, size_t size);
#endif
#endif /* _ASM_IA64_DMA_MAPPING_H */
# HG changeset patch
# User Alex Williamson [EMAIL PROTECTED]
# Date 1181684430 21600
# Node ID 50306c16650087922da4b54b4d222cfd8d17697a
# Parent 245902ee7ce0c1499c172b3a9240b8e2ede45a5f
[IA64] Define paddr_t.
Temporary build workaround
Signed-off-by: Isaku Yamahata [EMAIL PROTECTED]
linux-2.6.18-xen changeset: 51:50306c16650087922da4b54b4d222cfd8d17697a
linux-2.6.18-xen date: Tue Jun 12 15:40:30 2007 -0600
diff -r 245902ee7ce0 -r 50306c166500 include/asm-ia64/maddr.h
--- a/linux-2.6-xen-sparse/include/asm-ia64/maddr.h Mon Jun 11 14:59:53 2007 -0600
+++ b/linux-2.6-xen-sparse/include/asm-ia64/maddr.h Tue Jun 12 15:40:30 2007 -0600
@@ -103,5 +104,6 @@ mfn_to_local_pfn(unsigned long mfn)
#define set_phys_to_machine(pfn, mfn) do { } while (0)
typedef unsigned long maddr_t; // to compile netback, netfront
+typedef unsigned long paddr_t;
#endif /* _ASM_IA64_MADDR_H */
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]PAL virtualization service related patch
Hi Anthony,
Could you add prototypes to the appropriate header files and include
them so we can avoid this extern kludgy-ness? I think a descriptive
comment for this function would also be worthwhile. Thanks,
Alex
On Sat, 2008-03-29 at 16:17 +0800, Xu, Anthony wrote:
--- a/xen/arch/ia64/vmx/vmx_init.c Fri Mar 14 15:07:45 2008 -0600
+++ b/xen/arch/ia64/vmx/vmx_init.c Sat Mar 29 15:32:55 2008 +0800
@@ -63,6 +63,33 @@ u64 __vsa_base = 0; /* Run-time service
u64 __vsa_base = 0;/* Run-time service base of VMX */
/* Check whether vt feature is enabled or not. */
+
+void vmx_vps_patch(void)
+{
+ extern void ia64_patch_imm64 (u64 , u64 );
+ extern char vmx_vps_sync_read;
+ extern char vmx_vps_sync_write;
+ extern char vmx_vps_resume_normal;
+ extern char vmx_vps_resume_handler;
+ u64 addr;
--
Alex Williamson HP Open Source Linux Org.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Other Intel IPF platforms use COM1
On Sat, 2008-03-29 at 16:15 +0800, Xu, Anthony wrote: Other Intel IPF platforms use COM1 Applied. Hopefully this will eventually be described via HCDP. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: PATCH: move IO type to ppn [v3]
On Sun, 2008-03-30 at 06:35 +0200, Tristan Gingold wrote: On Fri, Mar 28, 2008 at 03:14:58PM -0600, Alex Williamson wrote: I'm not a fan of adding these ia64 headers directly into common code. Couldn't we at least put these in xenctrl.h, or maybe include them via xen.h or arch-ia64.h? Thanks, Hi, new version of the patch. memmap.h is now included by arch-ia64.h Much better. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] Cleanup vcpu.h
On Mon, 2008-03-31 at 18:27 +0900, Kouya Shimura wrote: Alex Williamson writes: It seems like a good time to remove some of these old krufty comments and previous implementations too (subset below). Could you resubmit with these scrubbed out? Thanks, Alex Attached. Please apply. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Please pull ia64 trees
Hi Keir, Please pull the ia64 trees: http://xenbits.xensource.com/ext/ia64/xen-unstable.hg http://xenbits.xensource.com/ext/ia64/linux-2.6.18-xen.hg This includes some hand tuned hyperprivop optimizations, HVM uncacheable access fixes, automatic xenheap sizing (which make xen easier to get running on some larger systems configured for numa), enhancements to make use of the PAL VPS services for potentially better HVM processor state save/restore, a build fix for gcc-4.3, an increase to the hypervisor memory reservation to better accommodate corner case memory sizes, SIOemu enhancements, and various other fixes, cleanups and enhancements. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH] Re: [Xen-staging] [xen-unstable] Explicitly tag every anonymous aggregate in the public headers.
On Mon, 2008-03-31 at 17:21 +0100, Keir Fraser wrote: On 31/3/08 16:49, Alex Williamson [EMAIL PROTECTED] wrote: It seems pretty clear that in nesting __extension__ attributes in this manner, the struct is actually ignored and the compiler is treating the everything that was in the struct as a separate member of the union. In the mapped_regs example, the structure size remains correct only because the union is full padded out using the full size arrays. Please apply the patch I sent previously to revert the nested __extension__ attributes. Thanks, __extension__ seems worryingly half-baked. We're better off asserting !__STRICT_ANSI__ in my opinion. I don't suppose you much care either way as long as ia64 boot works again. :-) Yup ;^) FWIW, I still haven't been able to create a simple test program that shows this behavior. For these tests I've had to resort to putting printks in xen. There must be some build option we use that tickles this issue. Still, not good for an option that claims to have no side effects. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen/IPF 3.1.4 RC1 Test Result
On Sun, 2008-03-30 at 12:52 +0800, Mu, Qin wrote: Xen/IPF 3.1.4-rc1 Test Result: = Test Result Summary: # total case: 25 # passed case: 24 # failed case: 1 = Thanks for the test report. [FAIL] Unmodified_HVM_save_restore This isn't expected to work in 3.1.x. Can we modify the test to skip this? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel][PATCH]Other Intel IPF platforms use COM1
On Sat, 2008-03-29 at 16:15 +0800, Xu, Anthony wrote: Other Intel IPF platforms use COM1 Hi Anthony, Any chance you could convince your firmware team to implement an HCDP (assuming these are new systems)? Then these model specific switches wouldn't be necessary. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH][Open GFW]Support ACPI SPCR table
On Fri, 2008-03-28 at 18:03 +0900, SUZUKI Kazuhiro wrote: Hi Tristan, The following patch supports ACPI Serial Port Console Redirection(SPCR) table, by which we can use Windows Special Administration Console(SAC). I am not a lawyer, but the SPCR table has quite a license behind it[1]. This is part of the reason why Linux doesn't use it. I would be a little nervous about adding this to the code base. Thanks, Alex [1] http://www.microsoft.com/whdc/system/platform/server/spcr.mspx -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH] Re: [Xen-staging] [xen-unstable] Explicitly tag every anonymous aggregate in the public headers.
On Wed, 2008-03-26 at 10:16 +, Xen staging patchbot-unstable wrote:
# HG changeset patch
# User Keir Fraser [EMAIL PROTECTED]
# Date 1206526490 0
# Node ID 5d25187bac941611a8a836b668a398a72df0afb0
# Parent 966c04d42e94546287a1145c82e13073f28ef116
Explicitly tag every anonymous aggregate in the public headers.
My previous fix allowed this to build on ia64, but it turns out
there's still a boot issue that I don't understand. As is, we take a
nested dtlb fault on boot, which hg bisect determines is caused by this
patch. From a simple test program, I can verify that only the outermost
__extension__ is necessary to include code w/ -std=c99. So embedding an
__extension__ within an __extension__ isn't necessary, but I don't know
why it actually changes the behavior of the code. The patch below
reverts a few chucks of this cset and gets us booting again. FWIW, I'm
using gcc-4.1.2. Thanks,
Alex
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
---
diff -r 6736c28a0d35 xen/include/public/arch-ia64.h
--- a/xen/include/public/arch-ia64.hFri Mar 28 17:58:36 2008 +
+++ b/xen/include/public/arch-ia64.hFri Mar 28 14:51:41 2008 -0600
@@ -182,7 +182,7 @@ struct mapped_regs {
unsigned long reserved4[76];
__anonymous_union {
unsigned long vcr[128];
-__anonymous_struct {
+struct {
unsigned long dcr; // CR0
unsigned long itm;
unsigned long iva;
@@ -216,7 +216,7 @@ struct mapped_regs {
};
__anonymous_union {
unsigned long reserved5[128];
-__anonymous_struct {
+struct {
unsigned long precover_ifs;
unsigned long unat; // not sure if this is needed until NaT arch
is done
int interrupt_collection_enabled; // virtual psr.ic
@@ -609,7 +609,7 @@ struct xen_ia64_opt_feature {
unsigned long cmd; /* Which feature */
unsigned char on; /* Switch feature on/off */
__anonymous_union {
- __anonymous_struct {
+ struct {
/* The page protection bit mask of the pte.
* This will be or'ed with the pte. */
unsigned long pgprot;
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: PATCH: move IO type to ppn [v2]
I'm not a fan of adding these ia64 headers directly into common code. Couldn't we at least put these in xenctrl.h, or maybe include them via xen.h or arch-ia64.h? Thanks, Alex On Wed, 2008-03-26 at 06:59 +0100, [EMAIL PROTECTED] wrote: diff -r a88bb92e5790 -r 485a87e89329 tools/ioemu/hw/xen_machine_fv.c --- a/tools/ioemu/hw/xen_machine_fv.c Mon Mar 24 08:03:37 2008 +0100 +++ b/tools/ioemu/hw/xen_machine_fv.c Wed Mar 26 06:57:48 2008 +0100 @@ -29,6 +29,10 @@ #endif #include xen/hvm/params.h #include sys/mman.h + +#ifdef __ia64__ +#include xen/arch-ia64/hvm/memmap.h +#endif #if defined(MAPCACHE) diff -r a88bb92e5790 -r 485a87e89329 tools/ioemu/vl.c --- a/tools/ioemu/vl.c Mon Mar 24 08:03:37 2008 +0100 +++ b/tools/ioemu/vl.c Wed Mar 26 06:57:48 2008 +0100 @@ -107,6 +107,10 @@ #include disas.h #include exec-all.h + +#if defined(CONFIG_DM) defined (__ia64__) +#include xen/arch-ia64/hvm/memmap.h +#endif #define DEFAULT_NETWORK_SCRIPT /etc/xen/qemu-ifup #ifdef _BSD -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] Cleanup vcpu.h
It seems like a good time to remove some of these old krufty comments
and previous implementations too (subset below). Could you resubmit
with these scrubbed out? Thanks,
Alex
On Wed, 2008-03-26 at 16:52 +0900, Kouya Shimura wrote:
+static inline IA64FAULT vcpu_get_iipa(VCPU * vcpu, u64 * pval)
+{
+ u64 val = PSCB(vcpu, iipa);
+ // SP entry code does not save iipa yet nor does it get
+ // properly delivered in the pscb
+// printk(*** vcpu_get_iipa: cr.iipa not fully implemented yet!!
\n);
+ *pval = val;
+ return IA64_NO_FAULT;
+}
+
+static inline IA64FAULT vcpu_get_ifs(VCPU * vcpu, u64 * pval)
+{
+ //PSCB(vcpu,ifs) = PSCB(vcpu)-regs.cr_ifs;
+ //*pval = PSCB(vcpu,regs).cr_ifs;
+ *pval = PSCB(vcpu, ifs);
+ return IA64_NO_FAULT;
+}
--
Alex Williamson HP Open Source Linux Org.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] Cleanup: TLB translation
On Wed, 2008-03-26 at 17:40 +0900, Kouya Shimura wrote: Add a new static inline function for readability. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] eliminate duble dump_stack
On Thu, 2008-03-27 at 14:38 +0900, Akio Takebe wrote: Hi, show_registers() already has show_stack(NULL,NULL), So we get two same Calltraces. This patch eliminate it. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] Re: [PATCH] Re: [Xen-staging] [xen-unstable] Explicitly tag every anonymous aggregate in the public headers.
On Fri, 2008-03-28 at 22:37 +, Keir Fraser wrote:
On 28/3/08 21:04, Alex Williamson [EMAIL PROTECTED] wrote:
@@ -609,7 +609,7 @@ struct xen_ia64_opt_feature {
unsigned long cmd; /* Which feature */
unsigned char on; /* Switch feature on/off */
__anonymous_union {
- __anonymous_struct {
+ struct {
/* The page protection bit mask of the pte.
* This will be or'ed with the pte. */
unsigned long pgprot;
I have no idea if it's the cause of this particular boot breakage, but I
reckon that an anonymous union containing a single anonymous struct can be
simplified. Or perhaps, if the union is there for stylistic reasons, a
single extra field in the union would fix things?
I toggled this one separately exactly for that reason, but it's not
the one. I still haven't isolated a particular reason why it fails in a
test program, but I'll keep trying. Thanks,
Alex
--
Alex Williamson HP Open Source Linux Org.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen/IPF Unstable CS#17292 Status Report
On Tue, 2008-03-25 at 21:56 +0900, Akio Takebe wrote: Hi, Amy Failed case id Description SMPVTI_Windows SMPVTI windows(vcpu=2) SMPWin_SMPVTI_SMPxenU SMPVTI Linux/Windows XenU VTI_Windows_PV Windows VTI PV If my patch(17292) is revert, can you boot Windows guest? http://xenbits.xensource.com/ext/xen-ia64-unstable.hg?rev/dba5f548b894 I booted a Win2k3 guest is my testing, so I'm curious about this too. How did it fail? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: PATCH: move IO type to ppn (VTi)
On Tue, 2008-03-25 at 06:14 +0100, [EMAIL PROTECTED] wrote: Hi, Instead of using 3 extra bits in pte to store the io type, only one bit is used to mark the page as an IO page and the type is stored in the ppn field. This both save 2 bits and allow many more io types. Move the VTi memory map to arch-ia64/hvm/memmap.h ioemu fails to build with this from a clean tree. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] linux: need to set psr.ac inpage_fault
On Tue, 2008-03-25 at 10:08 +0900, Akio Takebe wrote: Ah, It's redundant. I remove the ifdef. PSR_DEFAULT_BITS is always defined. And even if PSR_DEFAULT_BITS == 0, sum 0x0 is harmless. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] linux: need to set psr.ac inpage_fault
On Mon, 2008-03-24 at 18:49 +0900, Akio Takebe wrote: On Wed, 2008-03-19 at 22:46 +0900, Akio Takebe wrote: ;; +#ifdef PSR_DEFAULT_BITS + sum PSR_DEFAULT_BITS +#endif How would we ever get here w/o PSR_DEFAULT_BITS defined? Thanks, I have tested with/without the patch, nothing happened. But I wanted to be the same as native linux. Hi Akio, My comment is whether it's redundant to have the #ifdef PSR_DEFAULT_BITS surrounding setting the user mask. AFAICT, we can't get to this code w/o PSR_DEFAULT_BITS set, so it seems unnecessary to test for it. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [patch 00/11] ia64: kexec: Map EFI memory in the same location as Linux (v20080320)
On Thu, 2008-03-20 at 15:52 +0900, Simon Horman wrote: Hi, here is another spin of the kexec EFI patches. I think we are getting very close if we aren't there already. Hi Simon, Have you tried launching an HVM domain with this patch set? I never get past the white background in the VNC window (before EFI prints OK), and very shortly after launch, Xen and dom0 die. BTW, patch 4 is trying to patch the linked path to cpumask.h, which makes qimport unhappy. I think you want xen/include/xen/cpumask.h. Also, this file is common code, so let's make sure there's not a better arch specific place to stash this (and if not, I'm not sure CONFIG_XEN is appropriate/necessary in this file). Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: PATCH: fix compilation warnings
On Mon, 2008-03-24 at 08:04 +0100, [EMAIL PROTECTED] wrote: Hi, this simple patch fixes gcc warnings. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] [1/2] fix wrong emulation: move to psr
On Mon, 2008-03-24 at 16:18 +0900, Akio Takebe wrote: Hi, I update it. I did a little further refinement, please check the tree and make sure I didn't break it. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] linux: need to set psr.ac in page_fault
On Wed, 2008-03-19 at 22:46 +0900, Akio Takebe wrote: Hi, This patch fixes a different behavior from the original code. We need to set psr.ac. diff -r ba72914de93a arch/ia64/xen/xenivt.S --- a/arch/ia64/xen/xenivt.SWed Mar 05 17:29:05 2008 + +++ b/arch/ia64/xen/xenivt.SThu Mar 20 06:53:32 2008 +0900 @@ -696,16 +696,19 @@ ENTRY(page_fault) st4 [r3]=r14// vpsr.ic = 1 adds r3=8,r2// set up second base pointer ;; +#ifdef PSR_DEFAULT_BITS + sum PSR_DEFAULT_BITS +#endif How would we ever get here w/o PSR_DEFAULT_BITS defined? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH] fix TLB miss behavior with physical mode
On Mon, 2008-03-17 at 20:30 +0900, Kouya Shimura wrote: The emulation of physical mode will be more precise with this patch. (The previous patch implies a bug. Windows 2003 can't boot.) Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] increase hv memory reservation
On Tue, 2008-03-18 at 17:07 -0400, Jarod Wilson wrote: Not sure if this is actually relevant for hg tip anymore, but with Red Hat's rebase to xen 3.1.2, that if we try to allocate all memory to dom0, we're not leaving enough for the hypervisor anymore. Our quick fix was to simply increase the reservation guestimate by 128M. This does still seem to be relevant, I can make my system unbootable by specifying max_addr=1G dom0_mem=1G. With the patch, it boots up and I can even still create a 256M domU. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: PATCH: new SIOEMU interface
On Thu, 2008-03-20 at 07:11 +0100, [EMAIL PROTECTED] wrote: 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. Applied. I agree, I don't think we need to worry about sioemu backwards compatibility just yet. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] RE: pv_ops polish: config option head file
On Tue, 2008-03-18 at 21:31 +0800, Dong, Eddie wrote: Alex Williamson wrote: On Tue, 2008-03-18 at 11:36 +0800, Dong, Eddie wrote: I think CONFIG_XEN might become something like CONFIG_PARAVIRT_XEN, which will be dependent on CONFIG_PARAVIRT. There might also be CONFIG_PARAVIRT_LGUEST, CONFIG_PARAVIRT_KVM, etc... I think that Then a single image won't be able to run on both lguest/Xen/KVM. This is worse than running_on_xen dynamic condition check. Huh? I never said you couldn't enable more than one CONFIG_PARAVIRT_FOO flavor in the same binary. How about just simply use CONFIG_PARAVIRT ? Then how do you specify that you want a kernel built with Xen support, but not KVM? Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] (no subject)
On Tue, 2008-03-18 at 21:51 +0800, Dong, Eddie wrote:
Following CONFIG_XEN is kind of historic issue, with CONFIG_PARAVIRT,
those code should be always enabled, so replacing with CONFIG_PARAVIRT
makes more sense.
I disagree, these are xen specific.
Alex
diff --git a/arch/ia64/kernel/Makefile b/arch/ia64/kernel/Makefile
index a80dd3f..61643f8 100644
--- a/arch/ia64/kernel/Makefile
+++ b/arch/ia64/kernel/Makefile
@@ -91,8 +91,8 @@ $(obj)/xen_%.o: $(src)/%.S FORCE
#
# xenivt.o, xen_switch_leave.o
#
-obj-$(CONFIG_XEN) += xen_ivt.o xen_switch_leave.o
-ifeq ($(CONFIG_XEN), y)
+obj-$(CONFIG_PARAVIRT) += xen_ivt.o xen_switch_leave.o
+ifeq ($(CONFIG_PARAVIRT), y)
targets += xen_ivt.o xen_switch_leave.o
$(obj)/build-in.o: xen_ivt.o xen_switch_leave.o
endif
diff --git a/arch/ia64/kernel/salinfo.c b/arch/ia64/kernel/salinfo.c
index 91bc631..dd6b986 100644
--- a/arch/ia64/kernel/salinfo.c
+++ b/arch/ia64/kernel/salinfo.c
@@ -378,7 +378,7 @@ salinfo_log_open(struct inode *inode, struct file
*file)
data-open = 0;
return -ENOMEM;
}
-#ifdef CONFIG_XEN
+#ifdef CONFIG_PARAVIRT
if (is_running_on_xen()) {
ia64_mca_xencomm_t *entry;
unsigned long flags;
@@ -408,7 +408,7 @@ salinfo_log_release(struct inode *inode, struct file
*file)
struct salinfo_data *data = entry-data;
if (data-state == STATE_NO_DATA) {
-#ifdef CONFIG_XEN
+#ifdef CONFIG_PARAVIRT
if (is_running_on_xen()) {
struct list_head *pos, *n;
ia64_mca_xencomm_t *found_entry = NULL;
diff --git a/include/asm-ia64/hw_irq.h b/include/asm-ia64/hw_irq.h
diff --git a/include/asm-ia64/sal.h b/include/asm-ia64/sal.h
index 2965112..8aeefd2 100644
--- a/include/asm-ia64/sal.h
+++ b/include/asm-ia64/sal.h
@@ -682,7 +682,7 @@ ia64_sal_clear_state_info (u64 sal_info_type)
/* Get the processor and platform information logged by SAL with
respect to the machine
* state at the time of the MCAs, INITs, CMCs, or CPEs.
*/
-#ifdef CONFIG_XEN
+#ifdef CONFIG_PARAVIRT
static inline u64 ia64_sal_get_state_info_size (u64 sal_info_type);
typedef struct ia64_mca_xencomm_t {
void *record;
@@ -697,7 +697,7 @@ static inline u64
ia64_sal_get_state_info (u64 sal_info_type, u64 *sal_info)
{
struct ia64_sal_retval isrv;
-#ifdef CONFIG_XEN
+#ifdef CONFIG_PARAVIRT
if (is_running_on_xen()) {
ia64_mca_xencomm_t *entry;
struct xencomm_handle *desc = NULL;
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
--
Alex Williamson HP Open Source Linux Org.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] (no subject)
On Tue, 2008-03-18 at 22:19 +0800, Dong, Eddie wrote: Yes, but running_on_xen is already there. Will it be there if we only have a kernel compiled with PV KVM support? Are we going to stub out any *_xen_* function/macro in that case? Alex Alex Williamson wrote: On Tue, 2008-03-18 at 21:51 +0800, Dong, Eddie wrote: Following CONFIG_XEN is kind of historic issue, with CONFIG_PARAVIRT, those code should be always enabled, so replacing with CONFIG_PARAVIRT makes more sense. I disagree, these are xen specific. -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] RE: pv_ops polish: config option head file
On Tue, 2008-03-18 at 22:18 +0800, Dong, Eddie wrote: How about just simply use CONFIG_PARAVIRT ? Then how do you specify that you want a kernel built with Xen support, but not KVM? Mmm, this is kind of what level of detail do we want user to choose. Given that RHEL want one image, so this sub-option is just for in house development even if multiple IA64 VMM really comes. We can argu for the usage model. Leaving some code for this is OK, but but at least for those who have running_on_xen condition already, we don;t need CONFIG_XEN, (rather CONFIG_PARAVIRT). Also for those Xen specific files, i.e. those xen wrapper code, we can treat whole directory as one, either compile it or skip it. Does this make sense? Hmm, I still disagree. The way the Kconfigs are structured now, we have: PARAVIRT_GUEST - PARAVIRT - XEN PARAVIRT_GUEST adds no code, but enables the other config options. XEN is dependent on PARAVIRT. IMHO, PARAVIRT should enable the pv_ops functionality, but not add the Xen specific code. You can imagine a PV KVM option or LGUEST option that wants PARAVIRT, but not XEN (or all of them together in one binary). I think which VMMs you want to support is a reasonable level of detail for someone configuring a kernel to select. The granularity also shows upstream that we've thought about generic PV support and we're not just trying to dump a bunch of Xen-only code into the tree. We don't need to be constantly concerned with RH's config, we need to look at the bigger picture for what's right in Linux. We can make sure RH's config has everything we want for a single binary later as long as we enable that possibility in what we're doing. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] RE: pv_ops polish: config option head file
On Mon, 2008-03-17 at 14:07 +0800, Dong, Eddie wrote: Something I want to get clarified first, eventually with pv_ops patch series get in, RH eventually will only compile to get one image to run on different platforms including xen machine. In this way all the codes with CONFIG_XEN today must be either checked in as generic code, or pv_ops except for those dual compile codes such as IVT gate. In other word, CONFIG_XEN will disappear mostly. RIght? Xen machine vector also needs to be compiled when in CONFIG_IA64_GENERIC. I think CONFIG_XEN might become something like CONFIG_PARAVIRT_XEN, which will be dependent on CONFIG_PARAVIRT. There might also be CONFIG_PARAVIRT_LGUEST, CONFIG_PARAVIRT_KVM, etc... I think that would fit the typical Linux model of being able to selectively include features. We'll need to make sure distributions set these the way we want and maybe add it to the defconfig once the code is stabilized. The Xen machine vector will need to be included in CONFIG_IA64_GENERIC, but it will also depend on CONFIG_PARAVIRT_XEN. Does that sound reasonable? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: [patch] ia64: kexec: add __va_efi
On Sat, 2008-03-15 at 09:08 +0900, Simon Horman wrote: Patch 13/15 seems nasty, so I think that ought to be left out. But the other patches that I suggested omitting seem harmless enough. I tested again with patches 1-12,14,15,__va_efi. This boots on all my systems! I guess 13 should indeed be dropped or fixed, but I'm not seeing the hang after freeing init mem issue it supposedly fixes. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH][PV-OPS] Kconfig cleanup
Hi Isaku,
This is for the pv_ops tree xen-ia64-domu-minimal-2008mar06 branch.
I tried to clean up the Kconfig options for PARAVIRT/XEN. I removed the
long descriptions for the PARAVIRT sub options since they're way too
technical, and probably not things we want to do without. I think these
are going to be non-XEN specific, so I set them if PARAVIRT is
enabled.
I also fixed the dependencies between IA64_GENERIC and IA64_XEN. The
expectation for now is that if you're running a domU, you're using the
Xen machine vector either as a statically compiled option, or
dynamically via IA64_GENERIC. I suppose when we add dom0 support, you
could have IA64_DIG and XEN, but until then, this seems sufficient. Let
me know if you agree this is how it should work. Thanks,
Alex
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
---
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index c62f815..87cee75 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -120,48 +120,24 @@ menuconfig PARAVIRT_GUEST
If you say N, all options in this submenu will be skipped and
disabled.
if PARAVIRT_GUEST
+config PARAVIRT_ALT
+ bool
-config PARAVIRT
+config PARAVIRT_ENTRY
bool
+
+config PARAVIRT
+ bool Enable paravirtualization code
+ depends on PARAVIRT_GUEST
default y
+ select PARAVIRT_ALT
+ select PARAVIRT_ENTRY
help
This changes the kernel so it can modify itself when it is run
under a hypervisor, potentially improving performance significantly
over full virtualization. However, when run without a hypervisor
the kernel is theoretically slower and slightly larger.
-config PARAVIRT_ALT
- bool paravirt_alt binary patching infrastructure
- depends on PARAVIRT
- default y
- help
- The binary patching infratstructure to replace some privileged
- instructions with hypervisor specific instrutions.
- There are several sensitive(i.e. non-virtualizable) instructions and
- performance critical privileged instructions which Xen
- paravirtualize as hyperprivops.
- For transparent paravirtualization (i.e. single binary should run
- on both baremetal and xen environment), xenLinux/IA64 needs
- something like if (is_running_on_xen()) {} else {} where
- is_running_on_xen() is determined at boot time.
- This configuration tries to eliminate the overheads for hyperprivops
- by annotating such instructions and replacing them with hyperprivops
- at boot time.
-
-config PARAVIRT_ENTRY
- bool paravirt entry
- depends on PARAVIRT
- default y
- help
- The entry point hooking infrastructure to change the execution path
- at the boot time.
- There are several paravirtualized paths in hand coded assembly code
- which isn't binary patched easily by the paravirt_alt infrastructure.
- E.g. ia64_switch_to, ia64_leave_syscall, ia64_leave_kernel and
- ia64_pal_call_static.
- For those hand written assembly code, change the execution path
- by hooking them and jumping to hand paravirtualized code.
-
source arch/ia64/xen/Kconfig
endif
diff --git a/arch/ia64/xen/Kconfig b/arch/ia64/xen/Kconfig
index 73c087b..72b2e10 100644
--- a/arch/ia64/xen/Kconfig
+++ b/arch/ia64/xen/Kconfig
@@ -5,24 +5,22 @@
config XEN
bool Xen hypervisor support
default y
- select PARAVIRT
- select PARAVIRT_ALT
- select PARAVIRT_ENTRY
+ depends on PARAVIRT !(IA64_DIG || IA64_HP_ZX1 || IA64_HP_ZX1_SWIOTLB
|| IA64_SGI_SN2 || IA64_HP_SIM) MCKINLEY IA64_PAGE_SIZE_16KB
EXPERIMENTAL
select XEN_XENCOMM
- select IA64_XEN
+ select NO_IDLE_HZ
help
Enable Xen hypervisor support. Resulting kernel runs
both as a guest OS on Xen and natively on hardware.
-if XEN
config XEN_INTERFACE_VERSION
+ depends on XEN
hex
default 0x00030207
config XEN_XENCOMM
- def_bool y
+ depends on XEN
+ bool
config NO_IDLE_HZ
- def_bool y
-
-endif
+ depends on XEN
+ bool
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] [PATCH][PVOPS] remove VMX_GUEST/is_inital_xendomain() code
Hi Isaku,
This removes some obvious unused code in the
xen-ia64-domu-minimal-2008mar06 branch. I'm afraid this kind of stuff
will only get in the way for people reviewing domU-only changes.
Thanks,
Alex
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
---
arch/ia64/xen/irq_xen.c | 10
arch/ia64/xen/xen_pv_ops.c| 80 +-
arch/ia64/xen/xencomm.c |8 ---
include/asm-ia64/xen/hypervisor.h | 29 +++--
4 files changed, 12 insertions(+), 115 deletions(-)
diff --git a/arch/ia64/xen/irq_xen.c b/arch/ia64/xen/irq_xen.c
index 57fab2b..1c6c77b 100644
--- a/arch/ia64/xen/irq_xen.c
+++ b/arch/ia64/xen/irq_xen.c
@@ -407,15 +407,6 @@ xen_init_IRQ_early(void)
#endif
}
-static void __init
-xen_init_IRQ_late(void)
-{
-#ifdef CONFIG_XEN_PRIVILEGED_GUEST
- if (is_running_on_xen() !ia64_platform_is(xen))
- xen_irq_init();
-#endif
-}
-
static void
xen_resend_irq(unsigned int vector)
{
@@ -424,7 +415,6 @@ xen_resend_irq(unsigned int vector)
const struct pv_irq_ops xen_irq_ops __initdata = {
.init_IRQ_early = xen_init_IRQ_early,
- .init_IRQ_late = xen_init_IRQ_late,
.assign_irq_vector = xen_assign_irq_vector,
.free_irq_vector = xen_free_irq_vector,
diff --git a/arch/ia64/xen/xen_pv_ops.c b/arch/ia64/xen/xen_pv_ops.c
index 93a5c64..2a1b485 100644
--- a/arch/ia64/xen/xen_pv_ops.c
+++ b/arch/ia64/xen/xen_pv_ops.c
@@ -134,76 +134,18 @@ xen_arch_setup_early(void)
static void __init
xen_arch_setup_console(char **cmdline_p)
{
- /*
-* If a console= is NOT specified, we assume using the
-* xencons console is desired. By default, this is xvc0
-* for both dom0 and domU.
-*/
- if (!strstr(*cmdline_p, console=)) {
- char *p, *q, name[5] = xvc;
- int offset = 0;
-
-#if defined(CONFIG_VGA_CONSOLE)
- /*
-* conswitchp might be set intelligently from the
-* PCDP code. If set to VGA console, use it.
-*/
- if (is_initial_xendomain() conswitchp == vga_con)
- strncpy(name, tty, 3);
-#endif
-
- p = strstr(*cmdline_p, xencons=);
-
- if (p) {
- p += 8;
- if (!strncmp(p, ttyS, 4)) {
- strncpy(name, p, 4);
- p += 4;
- offset = simple_strtol(p, q, 10);
- if (p == q)
- offset = 0;
- } else if (!strncmp(p, tty, 3) ||
- !strncmp(p, xvc, 3)) {
- strncpy(name, p, 3);
- p += 3;
- offset = simple_strtol(p, q, 10);
- if (p == q)
- offset = 0;
- } else if (!strncmp(p, off, 3))
- offset = -1;
- }
-
- if (offset = 0)
- add_preferred_console(name, offset, NULL);
- } else if (!is_initial_xendomain()) {
- /* use hvc_xen */
- add_preferred_console(hvc, 0, NULL);
- }
+ /* use hvc_xen */
+ add_preferred_console(hvc, 0, NULL);
#if !defined(CONFIG_VT) || !defined(CONFIG_DUMMY_CONSOLE)
- if (!is_initial_xendomain()) {
- conswitchp = NULL;
- }
+ conswitchp = NULL;
#endif
}
static int __init
xen_arch_setup_nomca(void)
{
- if (!is_initial_xendomain())
- return 1;
- return 0;
-}
-
-static void __init
-xen_post_platform_setup(void)
-{
-#ifdef CONFIG_XEN_PRIVILEGED_GUEST
- if (is_running_on_xen() !ia64_platform_is(xen)) {
- extern ia64_mv_setup_t xen_setup;
- xen_setup(cmdline_p);
- }
-#endif
+ return 1;
}
static void __init
@@ -217,17 +159,6 @@ xen_post_paging_init(void)
}
static void __init
-__xen_cpu_init(void)
-{
-#ifdef CONFIG_XEN_PRIVILEGED_GUEST
- if (is_running_on_xen() !ia64_platform_is(xen)) {
- extern ia64_mv_cpu_init_t xen_cpu_init;
- xen_cpu_init();
- }
-#endif
-}
-
-static void __init
xen_post_smp_prepare_boot_cpu(void)
{
xen_setup_vcpu_info_placement();
@@ -241,11 +172,8 @@ static const struct pv_init_ops xen_init_ops __initdata = {
.arch_setup_early = xen_arch_setup_early,
.arch_setup_console = xen_arch_setup_console,
.arch_setup_nomca = xen_arch_setup_nomca,
- .post_platform_setup = xen_post_platform_setup,
.post_paging_init = xen_post_paging_init,
- .cpu_init = __xen_cpu_init,
-
.post_smp_prepare_boot_cpu = xen_post_smp_prepare_boot_cpu,
.bundle_patch_module = xen_alt_bundle_patch_module,
diff --git a/arch/ia64/xen
[Xen-ia64-devel] [PATCH][PVOPS] No MCA support
Hi Isaku,
I believe this MCA/xencomm code is for dom0, not domU, so we can
remove it for now. Thanks,
Alex
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
---
arch/ia64/kernel/mca.c | 22 --
arch/ia64/kernel/salinfo.c | 44
include/asm-ia64/sal.h | 36
3 files changed, 102 deletions(-)
diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
index 94f1023..6e17aed 100644
--- a/arch/ia64/kernel/mca.c
+++ b/arch/ia64/kernel/mca.c
@@ -339,33 +339,11 @@ typedef struct ia64_state_log_s
static ia64_state_log_t ia64_state_log[IA64_MAX_LOG_TYPES];
-#ifdef CONFIG_XEN
-DEFINE_SPINLOCK(ia64_mca_xencomm_lock);
-LIST_HEAD(ia64_mca_xencomm_list);
-
-#define IA64_MCA_XENCOMM_ALLOCATE(rec, desc) \
- if (is_running_on_xen()) { \
- ia64_mca_xencomm_t *entry; \
- entry = alloc_bootmem(sizeof(ia64_mca_xencomm_t)); \
- entry-record = rec; \
- entry-handle = desc; \
- list_add(entry-list, ia64_mca_xencomm_list); \
- }
-#define IA64_LOG_ALLOCATE(it, size) \
- {ia64_err_rec_t *rec; \
- ia64_state_log[it].isl_log[IA64_LOG_CURR_INDEX(it)] = rec = \
- (ia64_err_rec_t *)alloc_bootmem(size); \
- IA64_MCA_XENCOMM_ALLOCATE(rec, xencomm_map(rec, size)); \
- ia64_state_log[it].isl_log[IA64_LOG_NEXT_INDEX(it)] = rec = \
- (ia64_err_rec_t *)alloc_bootmem(size); \
- IA64_MCA_XENCOMM_ALLOCATE(rec, xencomm_map(rec, size));}
-#else
#define IA64_LOG_ALLOCATE(it, size) \
{ia64_state_log[it].isl_log[IA64_LOG_CURR_INDEX(it)] = \
(ia64_err_rec_t *)alloc_bootmem(size); \
ia64_state_log[it].isl_log[IA64_LOG_NEXT_INDEX(it)] = \
(ia64_err_rec_t *)alloc_bootmem(size);}
-#endif
#define IA64_LOG_LOCK_INIT(it) spin_lock_init(ia64_state_log[it].isl_lock)
#define IA64_LOG_LOCK(it) spin_lock_irqsave(ia64_state_log[it].isl_lock,
s)
#define IA64_LOG_UNLOCK(it)
spin_unlock_irqrestore(ia64_state_log[it].isl_lock,s)
diff --git a/arch/ia64/kernel/salinfo.c b/arch/ia64/kernel/salinfo.c
index 91bc631..779c3cc 100644
--- a/arch/ia64/kernel/salinfo.c
+++ b/arch/ia64/kernel/salinfo.c
@@ -378,25 +378,6 @@ salinfo_log_open(struct inode *inode, struct file *file)
data-open = 0;
return -ENOMEM;
}
-#ifdef CONFIG_XEN
- if (is_running_on_xen()) {
- ia64_mca_xencomm_t *entry;
- unsigned long flags;
-
- entry = vmalloc(sizeof(ia64_mca_xencomm_t));
- if (!entry) {
- data-open = 0;
- vfree(data-log_buffer);
- return -ENOMEM;
- }
- entry-record = data-log_buffer;
- entry-handle = xencomm_map(data-log_buffer,
-
ia64_sal_get_state_info_size(data-type));
- spin_lock_irqsave(ia64_mca_xencomm_lock, flags);
- list_add(entry-list, ia64_mca_xencomm_list);
- spin_unlock_irqrestore(ia64_mca_xencomm_lock, flags);
- }
-#endif
return 0;
}
@@ -408,31 +389,6 @@ salinfo_log_release(struct inode *inode, struct file *file)
struct salinfo_data *data = entry-data;
if (data-state == STATE_NO_DATA) {
-#ifdef CONFIG_XEN
- if (is_running_on_xen()) {
- struct list_head *pos, *n;
- ia64_mca_xencomm_t *found_entry = NULL;
- unsigned long flags;
-
- spin_lock_irqsave(ia64_mca_xencomm_lock, flags);
- list_for_each_safe(pos, n, ia64_mca_xencomm_list) {
- ia64_mca_xencomm_t *entry;
-
- entry = list_entry(pos, ia64_mca_xencomm_t,
- list);
- if (entry-record == data-log_buffer) {
- list_del(entry-list);
- found_entry = entry;
- break;
- }
- }
- spin_unlock_irqrestore(ia64_mca_xencomm_lock, flags);
- if (found_entry) {
- xencomm_free(found_entry-handle);
- vfree(found_entry);
- }
- }
-#endif
vfree(data-log_buffer);
vfree(data-oemdata);
data-log_buffer = NULL;
diff --git a/include/asm-ia64/sal.h b/include/asm-ia64/sal.h
index 2965112..f4904db 100644
--- a/include/asm-ia64/sal.h
+++ b/include/asm-ia64/sal.h
@@ -42,9 +42,6 @@
#include asm/pal.h
#include asm/system.h
#include asm/fpu.h
-#ifdef CONFIG_XEN
-#include asm/xen/xencomm.h
-#endif
extern
[Xen-ia64-devel] [PATCH][PVOPS] time.c cleanup
Hi Isaku,
Here's some cleanup to arch/ia64/kernel/time.c. I removed
time_resume() since it's not called from anywhere. I think this file
still needs some work; any PV guest is going to need something like
this, so it would be nice to isolate the Xen specific parts and have
everything else in PARAVIRT_GUEST code instead of XEN. This might be an
opportunity for another pv_ops structure. Maybe we should also create a
is_paravirt_guest() macro to clearly distinguish Xen-isms from things we
think apply to all PV guests. This should probably live in
asm/paravirt.h and include asm/xen/hypervisor.h so we can just include
one file and get both is_paravirt_guest() and is_running_on_xen().
Thanks,
Alex
Signed-off-by: Alex Williamson [EMAIL PROTECTED]
---
time.c | 58 +++---
1 file changed, 7 insertions(+), 51 deletions(-)
diff --git a/arch/ia64/kernel/time.c b/arch/ia64/kernel/time.c
index 1bb0362..cae777e 100644
--- a/arch/ia64/kernel/time.c
+++ b/arch/ia64/kernel/time.c
@@ -31,10 +31,10 @@
#include asm/xen/hypervisor.h
#ifdef CONFIG_XEN
+#include asm/percpu.h
#include linux/kernel_stat.h
#include linux/posix-timers.h
#include xen/interface/vcpu.h
-#include asm/percpu.h
#endif
#include fsyscall_gtod_data.h
@@ -283,7 +283,7 @@ __setup(nojitter, nojitter_setup);
#ifdef CONFIG_XEN
/* taken from i386/kernel/time-xen.c */
-static void init_missing_ticks_accounting(int cpu)
+static void xen_init_missing_ticks_accounting(int cpu)
{
struct vcpu_register_runstate_memory_area area;
struct vcpu_runstate_info *runstate = per_cpu(runstate, cpu);
@@ -301,63 +301,19 @@ static void init_missing_ticks_accounting(int cpu)
+ runstate-time[RUNSTATE_offline];
}
-static int xen_ia64_settimefoday_after_resume;
+static int xen_ia64_settimeofday_after_resume;
static int __init __xen_ia64_settimeofday_after_resume(char *str)
{
- xen_ia64_settimefoday_after_resume = 1;
+ xen_ia64_settimeofday_after_resume = 1;
return 1;
}
-__setup(xen_ia64_settimefoday_after_resume,
+__setup(xen_ia64_settimeofday_after_resume,
__xen_ia64_settimeofday_after_resume);
-/* Called after suspend, to resume time. */
-void
-time_resume(void)
-{
- unsigned int cpu;
-
- /* Just trigger a tick. */
- ia64_cpu_local_tick();
-
- if (xen_ia64_settimefoday_after_resume) {
- /* do_settimeofday() resets timer interplator */
- struct timespec xen_time;
- int ret;
- efi_gettimeofday(xen_time);
-
- ret = do_settimeofday(xen_time);
- WARN_ON(ret);
- } else {
-#if 0
- /* adjust EFI time */
- struct timespec my_time = CURRENT_TIME;
- struct timespec xen_time;
- static timespec diff;
- struct xen_domctl domctl;
- int ret;
-
- efi_gettimeofday(xen_time);
- diff = timespec_sub(xen_time, my_time);
- domctl.cmd = XEN_DOMCTL_settimeoffset;
- domctl.domain = DOMID_SELF;
- domctl.u.settimeoffset.timeoffset_seconds = diff.tv_sec;
- ret = HYPERVISOR_domctl_op(domctl);
- WARN_ON(ret);
-#endif
- /* itc_clocksource remembers the last timer status in
-* itc_jitter_data. Forget it */
- clocksource_resume();
- }
-
- for_each_online_cpu(cpu)
- init_missing_ticks_accounting(cpu);
-
- touch_softlockup_watchdog();
-}
#else
-#define init_missing_ticks_accounting(cpu) do {} while (0)
+#define xen_init_missing_ticks_accounting(cpu) do {} while (0)
#endif
void __devinit
@@ -455,7 +411,7 @@ ia64_init_itm (void)
clocksource_itc.rating = 50;
if (is_running_on_xen())
- init_missing_ticks_accounting(smp_processor_id());
+ xen_init_missing_ticks_accounting(smp_processor_id());
/* avoid softlock up message when cpu is unplug and plugged again. */
touch_softlockup_watchdog();
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: [patch] ia64: kexec: add __va_efi
Hi Simon, On Tue, 2008-03-18 at 11:32 +0900, Simon Horman wrote: that is great news! I think that patch 13 is an error (on my part) and it should be dropped. Can you confirm that 1-12,14,15,__va_efi also works on superdome? You mentioned some PAL problems in your previous email. Are these still a problem? Yes, I tested these on the superdome and it booted. I instrumented the PAL calls, not expecting dropping patch 13 to solve the problem, so I should probably go back and remove the instrumentation before declaring total victory. I can't speak to whether kexec actually works anywhere, but I think a kexec enabled xen is at least not a regression now. I have spent a bit of time poking around to see extra places where __va_efi() may be needed. I have found a bunch of places were we pass in __va() addresses into pal/sal/efi calls, but I think that these are all safe as the appropriate fault handlers are in place. In any case, I will poke around a bit more. Great. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] RE: pv_ops polish: config option head file
On Tue, 2008-03-18 at 11:36 +0800, Dong, Eddie wrote: I think CONFIG_XEN might become something like CONFIG_PARAVIRT_XEN, which will be dependent on CONFIG_PARAVIRT. There might also be CONFIG_PARAVIRT_LGUEST, CONFIG_PARAVIRT_KVM, etc... I think that Then a single image won't be able to run on both lguest/Xen/KVM. This is worse than running_on_xen dynamic condition check. Huh? I never said you couldn't enable more than one CONFIG_PARAVIRT_FOO flavor in the same binary. Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH][PVOPS] No MCA support
On Tue, 2008-03-18 at 11:25 +0900, Isaku Yamahata wrote: Hi Alex. Thank you very much for those unexpected patches. I'm very glad to see those and applied your other patches. Yes, MCA is for dom0. however cat /proc/sal/*/data triggers those code paths. So presumably we have to replace some functions with nop operations for domU. Or domU issues a sal hypercall with bad argument. Hi Isaku, But sal_emulator() only allows sal_get/clear_state_info from dom0, otherwise we return without dereferencing the buffer. So I think it's safe to drop this for domU-only support. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] pv_ops enable
On Fri, 2008-03-14 at 22:31 +0800, Dong, Eddie wrote: Isaku/Alex: There are some some certain features that target dom0 or for some extended domU features such as EXEC support etc, I would suggest we drop it temporary after some basic domU code get in. If this is true, then patch like following can be dropped, also many other files are similar and can be dropped. Yes, I would drop kexec support from the upstream effort for now. It's really a dom0 feature, and probably one that we can push out until after we have functional dom0 support upstream. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] RE: pv_ops polish: config option head file
On Fri, 2008-03-14 at 17:19 +0800, Dong, Eddie wrote: Oh, either are OK, just make sure we are in same page. Pleae keep this here. But we need to make sure generic_defconfig can include Xen machine vector in current case. Some Makefile/source change is needed to include this, I think REDHAT use generic_defconfig. I don't think any distributions use defconfig directly. The RH kernel config is significantly different. I don't think we need to touch the defconfig for now. It's useful to have an example domU config (I think I'm actually the one who requested it) as we put the pieces together. We need to keep that integration in mind, but we're a long way from that point. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: [patch] ia64: kexec: add __va_efi
On Thu, 2008-03-13 at 21:03 -0600, Alex Williamson wrote: On Fri, 2008-03-14 at 10:51 +0900, Simon Horman wrote: On an HP rx2600 this eliminates the problem where the SAL rendezvous address can't be registered and subsequently the boot fails. I suspect it solves similar problems that have been seen on other HP machines too. Actually, its rather amazing that the HP rx2620 and Tiger2 that I have been using work without this fix. Wow, that is rather surprising. Congratulations on tracking this down. I'll try to verify if this also solves the problem on superdome tomorrow. Thanks, Hi Simon, Good news/bad news on the superdome. It was definitely affected by the issue you solved on the rx2600 and no longer hangs at boot. However, PAL calls are still broken. It does make it all the way up to dom0 userspace before it falls over completely though. If you have any test code I'd be happy to try it, otherwise I'll see if I can find a system I can share with you the exhibits the problem. FWIW, I didn't prune down the patch series for this test, I just added this on top of the previous 15 patches. Are you as concerned as I am about how many other machine specific issues might still be hidden in this code? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: PATCH: cleanup in vmx_ivt.S
On Thu, 2008-03-13 at 05:30 +0100, [EMAIL PROTECTED] wrote: Hi, this patch removes the commented lines in order to make the code clearer. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel]PATCH:vmx_init_env must be called on every processor
On Thu, 2008-03-13 at 17:27 +0800, Xu, Anthony wrote: vmx_init_env must be called on every processor Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [Patch] cleanup set_psr_l
On Wed, 2008-03-12 at 19:05 +0900, Akio Takebe wrote: Hi, This patch cleanup vcpu_set_psr_l(). Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH] raise a fault with unimplemented physical address
On Fri, 2008-03-14 at 11:33 +0900, Kouya Shimura wrote: An unimplemented data fault or an unimplemented instruction trap should be raised with unimplemented physical address. Also some cleanups. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [patch] ia64: kexec: add __va_efi
On Fri, 2008-03-14 at 10:51 +0900, Simon Horman wrote: On an HP rx2600 this eliminates the problem where the SAL rendezvous address can't be registered and subsequently the boot fails. I suspect it solves similar problems that have been seen on other HP machines too. Actually, its rather amazing that the HP rx2620 and Tiger2 that I have been using work without this fix. Wow, that is rather surprising. Congratulations on tracking this down. I'll try to verify if this also solves the problem on superdome tomorrow. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: PATCH: prepare sioemu for SMP and save restore
On Sat, 2008-03-08 at 03:28 +0100, [EMAIL PROTECTED] wrote: Hi, same as previous patch but indentation updated. (can boot linux with 2 vcpus). Is a new firmware image required for this? I applied it, but I can no longer boot my sioemu domain. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: PATCH: avoid multiple calls to lookup_domain_mpa for io emulation
On Sun, 2008-03-09 at 08:02 +0100, [EMAIL PROTECTED] wrote: Hi, __gpfn_is_io macro hides a call to lookup_domain_mpa. This patch avoids multiple call to lookup_domain_mpa during io emulation. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel]PATCH:
On Mon, 2008-03-10 at 14:35 +0800, Xu, Anthony wrote: replace pal_vp_save/restore with vps_save/restore. the later have better performance. Applied. Any measurements as to the performance difference? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Xen/IPF Windows guest configured with E1000 VIF failed to ping host
On Mon, 2008-03-10 at 20:13 +0800, Mu, Qin wrote: Hi, When working on Xen/IPF built with source of unstable cs# 17197, I found that E1000 network card in windows guest works well but only failed to ping the host and other guests created by the same host. And the MAC address was always set to 00-16-FF-FF-FF-FF regardless the value specified by user in configuration file. E100 in windows guest doesn't have the problem. Both E100 and E1000 work well in Linux guest. Have you met ever this problem before? Please help if you know the right operations to enable e1000 model in windows guest. Hi Amy, I typically use the e1000 with a Windows Server 2008 domain, using the drivers shipped with the OS. I don't have any problems with the MAC or pinging the dom0 host or other local guests with this combination. I haven't done much testing using Server 2003 though. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps
On Mon, 2008-03-10 at 13:56 +0800, Dong, Eddie wrote: Alex all: I exchanged some ideas with Isaku to discuss the gap and status of pv_ops support in IA64, Isaku did a lot of work toward pv_ops since his previous forward backport patch. Great thanks to Isaku. The attached doc is a draft for some of the key gaps and current status. I think it is time for another cross major company meeting to discuss how we cooperate and how effectively go with pv_ops. Mostly Isaku and I are in same page for what IA64 pv_ops should look like now, though some details may have different understanding. Any ideas? Hi Eddie, Much thanks to you and Isaku for leading this effort. I'm open to another conference call, but maybe we can discuss some items here on the mailing list too. I saw that Isaku has created a wiki page on the Xen wiki and started a new git project on Gitorious.org. The wiki page seems like a good place to keep track of who is working on which chunk and the status. For the git side, I would suggest that the model might be that each developer has a project on gitorious.org and sends out patches or pull requests to have a single upstream reference. Isaku's tree seems to be a good focal point for now if he's willing to take on the task of accepting code from others. The 2.6.26 merge window will likely open before too long, so we also need to do some coordination with Tony Luck and the other upstream developers. Are they going to be interested in putting in pieces at each upstream merge window, or should we build up a complete solution for domU support in Isaku's tree or Tony's testing branch first? We also need to be careful about submitting patch sets that stand on their own and are bisect-able. It's likely going to take several kernel merge windows before we get full domU support, let alone dom0. In your slide set, you mention removing running_on_xen since it conflicts with pv_ops. I think this is a really good goal, but I have doubts about whether it's achievable. We're not likely to make a pv_ops to fit every corner case, and we may have to resort to an ugly direct test for xen. Let's try to avoid them, but we already have a few cases of checking machine vector names for this type of thing in other parts of the ia64 code. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] Paravirt_ops/hybrid directions and next steps
Hi Eddie, On Tue, 2008-03-11 at 06:43 +0800, Dong, Eddie wrote: Alex Williamson wrote: In your slide set, you mention removing running_on_xen since it conflicts with pv_ops. I think this is a really good goal, but I have doubts about whether it's achievable. We're not likely to make a My assumption is that Linux maintainer won't expect to see running_on_xen, running_on_kvm, running_on_lguest, running_on_hybrid_xen, running_on_hybrid_kvm etc. It is too ugly. But if you mean we keep it temporary for now, I am fine. Right, it's a pretty lightweight test to keep around for now, and maybe we can eventually remove it completely. However, we might end up with something that only one VMM cares about and need to keep it around. If all the VMMs are tripping on the same issue, then we can upgrade it or integrate it into a pv_op. pv_ops to fit every corner case, and we may have to resort to an ugly direct test for xen. Let's try to avoid them, but we already have a few cases of checking machine vector names for this type of thing in other parts of the ia64 code. Thanks, Could you point me to the code that you feel pv_ops may be hard here? I don't have any architecture specific examples off the top of my head, but how about skipping serial port detection on dom0? It's rather Xen specific and we haven't yet come up with a way to hide Xen's UART (ioport mmio) from dom0. KVM/Lguest wouldn't care about this, so it may not be worthy of a pv_op. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [patch 00/15] ia64: kexec: Map EFI memory in the same location as Linux
Hi Simon, On Fri, 2008-03-07 at 15:54 +0900, Simon Horman wrote: thanks for the feedback. It sounds like there are a few problems, but hopefully we have moved forwards. With regards to patch 13, ia64: kexec: Set page size identity mapping of EFI in alt_itlb_miss, it is kind of amusing that you report that your rx3600 works without it. Amusing because I have it noted down as a fix to allow rx3600 to boot :-) I guess I got confused somewhere along the way. I will drop it from the series. It may well be required after patch 15 is applied to enable everything. All that I'm noting is that patches 1-13 on their own, don't boot on any of my hardware, which makes doing a bisect difficult. As for the SAL calls failing, I was kind of hoping that problem would have been solved by various other fixes that I made along the way. But its not really surprising that its still there given that I had not spent time on it specifically. Unfortunately it doesn't manifest on any hardware that I have access to. Is it possible for you to provide access to a machine for me like last time? Yes, I'll see if I can get it setup for access. Incidently, my rx2620 has, the following. I updraded to that late last year, though I notice that 4.29 was released even later last year, I will try and upgrade. EFI Boot Manager ver 1.10 [14.62] Firmware ver 4.27 [4721] Lastly, with the superdome problem. I'm not sure that there is much problem tackling that while the SAL problem exists. I suspect the two are related. Hopefully so since the superdome is a shared system and it's more difficult to setup remote access. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: PATCH: prepare sioemu for SMP and save restore
On Fri, 2008-03-07 at 05:19 +0100, [EMAIL PROTECTED] wrote: Hi, this patch adds new sioemu hypercalls for SMP and save restore. It also replaces some constants by macros. Hi Tristan, Can you update this to the version in ia64/xen-unstable.hg? I'm assuming this one is based off a private copy. I updated in tree version to 4 space indenting, inferred from the Mode like at the top of the file. The patch uses 2 space indenting. We already have enough formatting conflicts in the xen tree w/o introducing yet another. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: PATCH: creates a vlsapic - viosapic interface
On Fri, 2008-03-07 at 05:16 +0100, [EMAIL PROTECTED] wrote: Hi, this patch remove duplicated code and create a vlsapic function to inject any interruption. It also removes useless irq_save/restore around atomic updates. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: PATCH: remove GPFN_INV_MASK
On Fri, 2008-03-07 at 05:42 +0100, [EMAIL PROTECTED] wrote: 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). Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] hand optimize for hyperprivop
On Fri, 2008-03-07 at 17:57 +0900, Kouya Shimura wrote: This patch slightly optimizes hyperprivop emulation especially hyper_rfi. It shows about 2% faster in fstat system call on dom0. Nice. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] fix io access from the inside of UC physical address
On Fri, 2008-03-07 at 19:53 +0900, Kouya Shimura wrote: I/O access from the inside of UC physical address causes a panic on HVM. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] cross compiling xen/ia64
Hi, With the latest pull of the ia64 tree, it's now possible, and fairly easy, to cross compile xen/ia64 on an x86_32/64 system. Aron Griffis has been working on this and has posted detailed instructions on the Xen wiki: http://wiki.xensource.com/xenwiki/CrossCompiling These instructions are based on Fedora8, which should be readily available. I'd like to request that an ia64 cross compile be added to the regression testing between the staging and the published development trees. This should allow us to more quickly catch obvious breaks between the architectures. I would also request that anyone making low level changes that might affect other architectures, consider adding this to your testing. It's quite trivial to setup an HVM domain with a cross compiler and build environment given the instructions above. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [patch] ia64: kexec: is for privileged guests only
On Fri, 2008-02-29 at 13:00 +0900, Horms wrote: This makes the KEXEC Kconfig option depend on !XEN_UNPRIVILEGED_GUEST, so that it is not available to unprivelaged guests. Or in other words, it is only available to non-xen linux or privileged guests. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] unify vtlb and vhpt
On Thu, 2008-02-28 at 17:17 +0900, Kouya Shimura wrote:
@@ -82,7 +68,6 @@ int init_domain_tlb(struct vcpu *v)
if (rc)
return rc;
-rc = thash_alloc((v-arch.vtlb), default_vtlb_sz, vtlb);
if (rc) {
free_domain_vhpt(v);
return rc;
The following 'if (rc)' block should be removed here too. Thanks,
Alex
--
Alex Williamson HP Open Source Linux Org.
___
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [patch 0/3] xen: Extend xen kexec hypercall to return additional regions
On Thu, 2008-02-28 at 12:35 +0900, Simon Horman wrote: I'll come right out and say that I don't fancy this two stage .c indirectly including itself approach. And I hope this change can help us move away from there, as well as providing the functionality extendability that this patch set describes. Wow, that's pretty nasty. Thanks for the explanation. Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH] [ia64] efi: allow efi memory regions to be dumped at boot
On Thu, 2008-02-28 at 16:37 +0900, Simon Horman wrote: In Linux, when EFI_DEBUG in xen/arch/ia64/linux-xen/efi.c is set to a non-zero value the EFI memory regions, as supplied by the boot parameter are displayed. In xen similar behaviour is provided by using the efi_print command-line parameter. Hi Simon, I'm sorry to say, there's still an issue. dom_fw_common.c is also compiled as part of tools/libxc, and it can't find print_md() after these changes, so make tools fails. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [patch 0/3] xen: Extend xen kexec hypercall to return additional regions
Hi Simon, I'm not seeing how this doesn't break the x86 COMPAT/CONFIG_COMPAT code paths. Where does kexec_get_range_internal() get defined for COMPAT in [1/3], and where is machine_kexec_get_xen() defined for CONFIG_COMPAT in [2/3]? I'm fine with the ia64 parts if Ian/Keir want to check them into the main tree, but there is some mixed indenting in [3/3]. Thanks, Alex On Wed, 2008-02-27 at 16:01 +0900, Simon Horman wrote: Hi, this series starts off by reworking the hypercall a bit to allow it to have architecture-specific code under xen/arch/ It then extends the hypercall for some extra regions that are needed for xen ia64. There are generic and ia64 specific patches in this series. I wanted to post them together as they don't make much sense without each other. There are related xen-linux patches that I will send as a separate series. There are related kexec-tools patches which I have posted to the kexec mailing list and intend to merge. http://lists.infradead.org/pipermail/kexec/2008-February/001348.html The end-game here is to make sure that all the reserved regions show up in /proc/iomem_machine on ia64. This currently does not happen. And manifests as kexec only being able to be performed once as the boot parameter ends up being overwritten in relocate_kernel before purgatory is reached. Xen--kexec--Xen--kexec [hang in purgatory!] The EFI-RID patches for ia64 xen kexec are also needed for kexec to function on ia64. However they touch different code paths and can be merged separately. -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [patch 0/4] linux-xen: Extend xen kexec hypercall to return additional regions
Hi Simon, These look ok to me. Ack. Thanks, Alex On Wed, 2008-02-27 at 16:10 +0900, Simon Horman wrote: this series makes use of the extra regions that can be retrieved using the kexec hypercall, as per patches posted in a separate series. This allows all regions that kexec needs to avoid to be retrieved from the hypervisor. The patch set also places all of these regions into /proc/iomem_machine - previously some where in /proc/iomem_machine and some where in /proc/iomem. There are generic and ia64 specific patches in this series. I wanted to post them together as they don't make much sense without each other. As well as the related xen patches, there are also related kexec-tools patches which I have posted to the kexec mailing list and intend to merge. http://lists.infradead.org/pipermail/kexec/2008-February/001348.html The end-game here is to make sure that all the reserved regions show up in /proc/iomem_machine on ia64. This currently does not happen. And manifests as kexec only being able to be performed once as the boot parameter ends up being overwritten in relocate_kernel before purgatory is reached. Xen--kexec--Xen--kexec [hang in purgatory!] The EFI-RID patches for ia64 xen kexec are also needed for kexec to function on ia64. However they touch different code paths and can be merged separately. -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH] [ia64] efi: allow efi memory regions to be dumped at boot
Hi Simon, The efi_dump_mem() declaration is extraneous now, right? Also, the current efi_print prints at the default log level, and this changes it to KERN_INFO. Maybe print_md() should take a log level parameter? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] [PATCH] updating collision chain length in VHPT is not necessary
On Wed, 2008-02-27 at 16:16 +0900, Kouya Shimura wrote: updating collision chain length in VHPT is not necessary. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH] [ia64] efi: allow efi memory regions to be dumped at boot
On Tue, 2008-02-26 at 13:42 +0900, Simon Horman wrote: In Linux, when EFI_DEBUG in xen/arch/ia64/linux-xen/efi.c is set to a non-zero value the EFI memory regions, as supplied by the boot parameter are displayed. Unfortunately this doesn't work on Xen as the console is not available at this time. Hi Simon, Looks good, but there's already an efi_print in xensetup that should be incorporated. We can currently dump the EFI memory map by passing the efi_print option on the xen boot line. We should keep that functionality. The split printk you're replacing is a bit dubious as we're relying on not printing another '\n' in the middle to retain the log level. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [PATCH] [ia64] kexec: Use error path if crash region range can't be accessed
On Tue, 2008-02-26 at 13:56 +0900, Simon Horman wrote: Although the error handling path in xen_machine_kexec_setup_resource() is somewhat minmal, it ought to be used if HYPERVISOR_kexec_op() fails when getting the crash kernel region, as this indicates that an error occured, not that the crash kernel region is empty. --- Alex: This is a fairly trivial fix, please consider merging independantly of other kexec patches Hi Simon, I agree, this looks trivial, but it's common code. Shouldn't this go through xen-devel? Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
RE: [Xen-ia64-devel] [PATCH]Add free memory size of every NUMA node inphsical info
On Tue, 2008-02-26 at 16:01 +0800, Duan, Ronghui wrote: Rewrite it using current interface. Applied. Thanks, Alex -- Alex Williamson HP Open Source Linux Org. ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
