Re: [Xen-ia64-devel] plan for the next release
On Thu, Aug 07, 2008 at 02:16:37PM +0900, Isaku Yamahata wrote: On Thu, Aug 07, 2008 at 03:07:27PM +1000, Simon Horman wrote: On Wed, Aug 06, 2008 at 06:19:29PM +0900, Isaku Yamahata wrote: On Wed, Aug 06, 2008 at 07:10:51PM +1000, Simon Horman wrote: - the EFI mapping patch set and the panic Kuwamura-san reported The panic haven't been resolved yet. It looks very difficult. If it isn't resolved, the EFI mapping patch will be reverted before requesting the pull. That is fine by me. A shame, but fine. It is fixed by the patch I sent out and Kuwamura-san confirmed it. So the EFI mapping patch will be included. Excellent! Can I confirm that the patch in question is [IA64] fix fpswa mapping which was broken by EFI mapping. aka 18137:c587457f6916 ? changeset: 18139:7affdebb7a1e [IA64] allocate percpu area in the xen va area. Thanks ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
Re: [Xen-ia64-devel] Re: [PATCH] Fix mca handler so as not to destroy ar
On Tue, Aug 05, 2008 at 02:19:06PM +0900, Isaku Yamahata wrote: On Tue, Aug 05, 2008 at 12:37:17PM +0900, Isaku Yamahata wrote: Hi Kazu. Sorry for late alert. VIRTUAL_MODE_ENTER() still refers ar.k6. Could you fix it? One more. Before pinning down vpd and vhpt, it's necessary to make sure that they doesn't overlap with stack like __vmxswitch_rr7() and ia64_new_rr7(). And more. VIRTUAL_MODE_ENTER() sets gp (r1) to ia64_os_mca_virtual_begin and then call ia64_mca_ucmc_handler(). It this correct? It looks like that accessing global variable in ia64_mca_ucmc_handler() results in rondom place access. Linux has the related fix. What do you think? commit f5a3f3dc189485d607fbd42678cc23958acc0a6e Author: Zou Nan hai [EMAIL PROTECTED] Date: Thu Sep 14 08:25:15 2006 +0800 [IA64] Make gp value point to Region 5 in mca handler MCA dispatch code take physical address of GP passed from SAL, then call DATA_PA_TO_VA twice on GP before call into C code. The first time is in ia64_set_kernel_register, the second time is in VIRTUAL_MODE_ENTER. The gp is changed to a virtual address in region 7 because DATA_PA_TO_VA is implemented by dep instruction. However when notify blocks were called from MCA handler code, because notify blocks are supported by callback function pointers, gp value value was switched to region 5 again. The patch set gp register to kernel gp of region 5 at entry of MCA dispatch. Signed-off-by: Zou Nan hai [EMAIL PROTECTED] Signed-off-by: Tony Luck [EMAIL PROTECTED] -- yamahata ___ 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
[Xen-ia64-devel] Re: [PATCH] 0/3 Fix PV driver domains
On Thu, Aug 07, 2008 at 02:20:14PM -0600, Alex Williamson wrote: 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, Applied 1/3, 2/3 and other patches, but didn't apply RFC 3/3 patch. I think those patches are good candidate for the next release. thanks, -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
[Xen-ia64-devel] Re: [Xen-devel] [PATCH][RFC] 3/3 Fix [ia64] PV driver domains - ugly python hacks
On Thu, Aug 07, 2008 at 02:20:34PM -0600, Alex Williamson wrote: x86 IOMMU support added a lot of assumptions about what PCI buses look like and where to find bridge devices. On ia64, we don't yet have virtualization friendly IOMMUs, so for the moment, we just want to keep unsafe PV PCI pass through working as well as it did in Xen 3.2. Looking at the code, it almost seems like x86 has thrown out support for the old style driver domain. Things that don't necessarily work on every PCI compliant architecture: * You can't assume that just because there's a device at 01:01.0 that there's also a bridge at 01:00.0 and blow-up when you don't find it.??? On HP ia64 boxes, PCI root bridges are not necessarily exposed as a PCI device. This pretty much means we can't call into any of the FLR code paths. * BAR alignment: it's hard to have BAR alignment when your page size is 16k. This wasn't a requirement for previous PV driver domains, so I assume it's only for IOMMU support. This is ugly, so I'm open to suggestions. It seems that all of these architecture checks could be replaced by checking some iommu_present variable to test whether the extra requirements are necessary. Signed-off-by: Alex Williamson [EMAIL PROTECTED] Given that iommu is disabled on x86 by default, this functional regression is accidental, I guess. I think a sort of this patch is necessary for the next release. (at least for IA64) thanks, -- yamahata ___ Xen-ia64-devel mailing list Xen-ia64-devel@lists.xensource.com http://lists.xensource.com/xen-ia64-devel
