This reduced series consists of the non-contentious and tangential patchs from my large HPET series, which have undergone one round of review already. They are now in a state where I believe they can go straight in. I am currently in the process of trying to adjust the remainder of the series and strip small indepent changes out of the mamoth patch, in an effort to reduce its complexity. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> CC: Keir Fraser <keir@xen.org> CC: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
---
xen/arch/x86/acpi/boot.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/xen/arch/x86/acpi/boot.c b/xen/arch/x86/acpi/boot.c
index df26423..ccbe918 100644
--- a/xen/arch/x86/acpi/boot.c
+++ b/xen/arch/x86/acpi/boot.c
@@ -289,6 +289,22 @@ static int __init acpi_parse_hpet(struct acpi_table_header
*table)
return -1;
}
+ /*
+ * Some BIOSes provide multiple HPET tables. Sometimes this is a BIOS
+ * bug; the intended way of supporting more than 1 HPET is to use AML
+ * entries.
+ *
+ * If someone finds a real system with two genuine HPET tables,
+ * perhaps they will be kind and implement support. Until then
+ * however, warn that we will ignore subsequent tables.
+ */
+ if ( hpet_address )
+ {
+ printk(KERN_WARNING PREFIX
+ "Found multiple HPET tables. Only using first\n");
+ return -1;
+ }
+
hpet_address = hpet_tbl->address.address;
hpet_blockid = hpet_tbl->sequence;
printk(KERN_INFO PREFIX "HPET id: %#x base: %#lx\n",
--
1.7.10.4
Andrew Cooper
2013-Nov-06 17:45 UTC
[PATCH 2/3] x86/hpet: Fix ambiguity in broadcast info message
"$N will be used for broadcast" is ambiguous between "$N
timers" or "timer
$N", particuarly when N is 0.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
CC: Jan Beulich <JBeulich@suse.com>
---
xen/arch/x86/hpet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/hpet.c b/xen/arch/x86/hpet.c
index 99882b1..4373791 100644
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -430,8 +430,8 @@ static void __init hpet_fsb_cap_lookup(void)
num_hpets_used++;
}
- printk(XENLOG_INFO "HPET: %u timers (%u will be used for
broadcast)\n",
- num_chs, num_hpets_used);
+ printk(XENLOG_INFO "HPET: %u timers usable for broadcast (%u
total)\n",
+ num_hpets_used, num_chs);
}
static struct hpet_event_channel *hpet_get_channel(unsigned int cpu)
--
1.7.10.4
Andrew Cooper
2013-Nov-06 17:45 UTC
[PATCH 3/3] x86/msi: Refactor msi_compose_message() to not require an irq_desc
Subsequent changes will cause HPET MSIs to not have an associated IRQ.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Keir Fraser <keir@xen.org>
Reviewed-by: Jan Beulich <JBeulich@suse.com>
---
xen/arch/x86/hpet.c | 2 +-
xen/arch/x86/msi.c | 9 ++++-----
xen/drivers/passthrough/vtd/iommu.c | 2 +-
xen/include/asm-x86/msi.h | 3 ++-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/xen/arch/x86/hpet.c b/xen/arch/x86/hpet.c
index 4373791..3a4f7e8 100644
--- a/xen/arch/x86/hpet.c
+++ b/xen/arch/x86/hpet.c
@@ -331,7 +331,7 @@ static int __hpet_setup_msi_irq(struct irq_desc *desc)
{
struct msi_msg msg;
- msi_compose_msg(desc, &msg);
+ msi_compose_msg(desc->arch.vector, desc->arch.cpu_mask, &msg);
return hpet_msi_write(desc->action->dev_id, &msg);
}
diff --git a/xen/arch/x86/msi.c b/xen/arch/x86/msi.c
index b43c36a..284042e 100644
--- a/xen/arch/x86/msi.c
+++ b/xen/arch/x86/msi.c
@@ -124,13 +124,12 @@ static void msix_put_fixmap(struct arch_msix *msix, int
idx)
/*
* MSI message composition
*/
-void msi_compose_msg(struct irq_desc *desc, struct msi_msg *msg)
+void msi_compose_msg(unsigned vector, const cpumask_t *cpu_mask, struct msi_msg
*msg)
{
unsigned dest;
- int vector = desc->arch.vector;
memset(msg, 0, sizeof(*msg));
- if ( !cpumask_intersects(desc->arch.cpu_mask, &cpu_online_map) ) {
+ if ( !cpumask_intersects(cpu_mask, &cpu_online_map) ) {
dprintk(XENLOG_ERR,"%s, compose msi message error!!\n",
__func__);
return;
}
@@ -138,7 +137,7 @@ void msi_compose_msg(struct irq_desc *desc, struct msi_msg
*msg)
if ( vector ) {
cpumask_t *mask = this_cpu(scratch_mask);
- cpumask_and(mask, desc->arch.cpu_mask, &cpu_online_map);
+ cpumask_and(mask, cpu_mask, &cpu_online_map);
dest = cpu_mask_to_apicid(mask);
msg->address_hi = MSI_ADDR_BASE_HI;
@@ -491,7 +490,7 @@ int __setup_msi_irq(struct irq_desc *desc, struct msi_desc
*msidesc,
desc->msi_desc = msidesc;
desc->handler = handler;
- msi_compose_msg(desc, &msg);
+ msi_compose_msg(desc->arch.vector, desc->arch.cpu_mask, &msg);
return write_msi_msg(msidesc, &msg);
}
diff --git a/xen/drivers/passthrough/vtd/iommu.c
b/xen/drivers/passthrough/vtd/iommu.c
index 2dbe97a..97d5b5e 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1039,7 +1039,7 @@ static void dma_msi_set_affinity(struct irq_desc *desc,
const cpumask_t *mask)
return;
}
- msi_compose_msg(desc, &msg);
+ msi_compose_msg(desc->arch.vector, desc->arch.cpu_mask, &msg);
/* Are these overrides really needed? */
if (x2apic_enabled)
msg.address_hi = dest & 0xFFFFFF00;
diff --git a/xen/include/asm-x86/msi.h b/xen/include/asm-x86/msi.h
index 9eeef63..89a9266 100644
--- a/xen/include/asm-x86/msi.h
+++ b/xen/include/asm-x86/msi.h
@@ -231,7 +231,8 @@ struct arch_msix {
};
void early_msi_init(void);
-void msi_compose_msg(struct irq_desc *, struct msi_msg *);
+void msi_compose_msg(unsigned vector, const cpumask_t *mask,
+ struct msi_msg *msg);
void __msi_set_enable(u16 seg, u8 bus, u8 slot, u8 func, int pos, int enable);
void mask_msi_irq(struct irq_desc *);
void unmask_msi_irq(struct irq_desc *);
--
1.7.10.4
At 17:45 +0000 on 06 Nov (1383756304), Andrew Cooper wrote:> This reduced series consists of the non-contentious and tangential patchs from > my large HPET series, which have undergone one round of review already. They > are now in a state where I believe they can go straight in. > > I am currently in the process of trying to adjust the remainder of the series > and strip small indepent changes out of the mamoth patch, in an effort to > reduce its complexity. > > Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>Reviewed-by: Tim Deegan <tim@xen.org>