Re: [Xen-devel] [PATCH V15 5/9] xen: Make gpfn related memops compatible with wider return values
Julien Grall julien.gr...@citrix.com 04/25/15 10:37 PM On 21/04/2015 20:13, Jan Beulich wrote: For this specific one - is there a reasonable use case? Other than for host PFN, we have control over guest ones, and I'm not sure managing a guest with GPFNs extending past 4 billion can be expected to work if only this one hypercall got fixed. IOW I'm expecting to NAK any such addition without proper rationale. There is hardware coming out with 48 bits address support (i.e 36 bit pfn). Even though the current layout of 64bit address space is using 40 bits IPA, I wouldn't be surprise if we decide to extend it soon (I have in mind PCI passthrough). Without this new hypercall, you rule out the possibility to run the toolstack (included memaccess or any software requiring the maximum PFN used by a domain) in a 32bit domain or 32bit userspace on 64bit domain. For a 32-bit domain, I suppose there are more limitations (unsigned long being used for MFNs/PFNs), so I don't see how this one addition would help. For 32-bit userspace on 64-bit domains the hypercall again isn't the limiting factor, but the kernel's hypercall interface is. (And again I doubt widening the MFN/PFN/GFN representation just here would really make 32-bit userspace work on such large hosts.) Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen: Suspend ticks on all CPUs during suspend
On 08/04/15 19:53, Boris Ostrovsky wrote: Commit 77e32c89a711 (clockevents: Manage device's state separately for the core) decouples clockevent device's modes from states. With this change when a Xen guest tries to resume, it won't be calling its set_mode op which needs to be done on each VCPU in order to make the hypervisor aware that we are in oneshot mode. This happens because clockevents_tick_resume() (which is an intermediate step of resuming ticks on a processor) no longer calls clockevents_set_state() and because during suspend clockevent devices on all VCPUs (except for the one doing the suspend) are left in ONESHOT state. As result, during resume the clockevents state machine will assume that device is already where it should be and doesn't need to be updated. To avoid this problem we should suspend ticks on all VCPUs during suspend. Sorry for the delay in reviewing this. diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c index bf19407..2fd9fe8 100644 --- a/drivers/xen/manage.c +++ b/drivers/xen/manage.c @@ -131,6 +131,8 @@ static void do_suspend(void) goto out_resume; } + xen_arch_suspend(); + si.cancelled = 1; xen_arch_resume() is only called when !si.cancelled but you call xen_arch_suspend() unconditionally. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V15 5/9] xen: Make gpfn related memops compatible with wider return values
Hi Jan, On 27/04/2015 08:02, Jan Beulich wrote: Julien Grall julien.gr...@citrix.com 04/25/15 10:37 PM On 21/04/2015 20:13, Jan Beulich wrote: For this specific one - is there a reasonable use case? Other than for host PFN, we have control over guest ones, and I'm not sure managing a guest with GPFNs extending past 4 billion can be expected to work if only this one hypercall got fixed. IOW I'm expecting to NAK any such addition without proper rationale. There is hardware coming out with 48 bits address support (i.e 36 bit pfn). Even though the current layout of 64bit address space is using 40 bits IPA, I wouldn't be surprise if we decide to extend it soon (I have in mind PCI passthrough). Without this new hypercall, you rule out the possibility to run the toolstack (included memaccess or any software requiring the maximum PFN used by a domain) in a 32bit domain or 32bit userspace on 64bit domain. For a 32-bit domain, I suppose there are more limitations (unsigned long being used for MFNs/PFNs), so I don't see how this one addition would help. For 32-bit userspace on 64-bit domains the hypercall again isn't the limiting factor, but the kernel's hypercall interface is. (And again I doubt widening the MFN/PFN/GFN representation just here would really make 32-bit userspace work on such large hosts.) On ARM 32/64 bits xen_pfn_t is defined as uint64_t. So I don't see any problem, unless the toolstack uses unsigned long which is already obviously wrong... Although, I still don't see why it prevents us to fix this hypercall... It's the first step to make the toolstack x86 agnostic (because unsigned long is x86 specific). Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [RFC 0/2] Cap SMMU s2 input-size based on p2m tables
From: Edgar E. Iglesias edgar.igles...@xilinx.com Hi, This is a first try at fixing the issue I'm seeing on ZynqMP with missmatched setup of the SMMU and the shared page-tables with p2m. I've only handled the case of having an SMMU that supports larger s2 input-sizes than what p2m wants to use. To support the case were the system has SMMUs that can only do smaller input-sizes than the CPU, I think we will need to walk the device-tree when creating domains and somehow cap the p2m IPA size to the largest supported S2 size across the SMMUs used by that particular domain. The max IPA size may need to be domain specific. I did not implement this but I did make the max size domain specific. Julien, you mentioned you might have access to such a system? Does this look reasonable or should we be fixing this some other way? I could make the patch simpler I guess by having a global (not domain specific) max value set once aswell. Comments? Best regards, Edgar Edgar E. Iglesias (2): xen/arm: Save and expose the p2m IPA address size xen/iommu: smmu: Use the p2m IPA size as S2 input-size xen/arch/arm/p2m.c | 7 ++- xen/drivers/passthrough/arm/smmu.c | 17 +++-- xen/include/asm-arm/p2m.h | 3 +++ 3 files changed, 24 insertions(+), 3 deletions(-) -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [RFC 2/2] xen/iommu: smmu: Use the p2m IPA size as S2 input-size
From: Edgar E. Iglesias edgar.igles...@xilinx.com
Because we share the p2m tables between SMMU and CPUs,
we need to make sure the SMMU is configured to use the
same S2 input-size as the CPU.
Signed-off-by: Edgar E. Iglesias edgar.igles...@xilinx.com
---
xen/drivers/passthrough/arm/smmu.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrough/arm/smmu.c
b/xen/drivers/passthrough/arm/smmu.c
index 8a9b58b..95e4dce 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -1038,6 +1038,7 @@ static void arm_smmu_init_context_bank(struct
arm_smmu_domain *smmu_domain)
struct arm_smmu_device *smmu = smmu_domain-smmu;
void __iomem *cb_base, *gr0_base, *gr1_base;
paddr_t p2maddr;
+ unsigned p2m_ipa_bits;
gr0_base = ARM_SMMU_GR0(smmu);
gr1_base = ARM_SMMU_GR1(smmu);
@@ -1123,6 +1124,14 @@ static void arm_smmu_init_context_bank(struct
arm_smmu_domain *smmu_domain)
/* TTBR0 */
/* Xen: The page table is shared with the P2M code */
ASSERT(smmu_domain-cfg.domain != NULL);
+
+ /* Xen: When building the domain, we need to make sure that the p2m
+* IPA size is not larger than what SMMUs can handle. It's to late to
+* do anything about it at this stage, so we simply ASSERT on it.
+*/
+ p2m_ipa_bits = smmu_domain-cfg.domain-arch.p2m.ipa_bits;
+ ASSERT(smmu-s2_input_size = p2m_ipa_bits);
+
p2maddr = page_to_maddr(smmu_domain-cfg.domain-arch.p2m.root);
dev_notice(smmu-dev, d%u: p2maddr 0x%PRIpaddr\n,
@@ -1146,7 +1155,10 @@ static void arm_smmu_init_context_bank(struct
arm_smmu_domain *smmu_domain)
reg = TTBCR_TG0_64K;
if (!stage1) {
- reg |= (64 - smmu-s2_input_size) TTBCR_T0SZ_SHIFT;
+ /* Xen: We reuse the p2m tables, the input size needs
+* to match the p2m IPA size.
+*/
+ reg |= (64 - p2m_ipa_bits) TTBCR_T0SZ_SHIFT;
switch (smmu-s2_output_size) {
case 32:
@@ -1795,10 +1807,11 @@ static int arm_smmu_handle_mapping(struct
arm_smmu_domain *smmu_domain,
struct arm_smmu_cfg *cfg = smmu_domain-cfg;
pgd_t *pgd = cfg-pgd;
unsigned long flags;
+ unsigned int p2m_ipa_bits = smmu_domain-cfg.domain-arch.p2m.ipa_bits;
if (cfg-cbar == CBAR_TYPE_S2_TRANS) {
stage = 2;
- input_mask = (1ULL smmu-s2_input_size) - 1;
+ input_mask = (1ULL p2m_ipa_bits) - 1;
output_mask = (1ULL smmu-s2_output_size) - 1;
} else {
stage = 1;
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [RFC 1/2] xen/arm: Save and expose the p2m IPA address size
From: Edgar E. Iglesias edgar.igles...@xilinx.com
Save and expose the p2m IPA address size to arch specific code.
This is primarily needed to setup SMMUs as these share p2m
tables with guest CPUs.
Signed-off-by: Edgar E. Iglesias edgar.igles...@xilinx.com
---
xen/arch/arm/p2m.c| 7 ++-
xen/include/asm-arm/p2m.h | 3 +++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 8dfee24..58df568 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -17,12 +17,15 @@
#ifdef CONFIG_ARM_64
static unsigned int __read_mostly p2m_root_order;
static unsigned int __read_mostly p2m_root_level;
+static unsigned int __read_mostly p2m_ipa_bits;
#define P2M_ROOT_ORDERp2m_root_order
#define P2M_ROOT_LEVEL p2m_root_level
+#define P2M_IPA_BITS p2m_ipa_bits
#else
/* First level P2M is alway 2 consecutive pages */
#define P2M_ROOT_LEVEL 1
#define P2M_ROOT_ORDER1
+#define P2M_IPA_BITS 40
#endif
#define P2M_ROOT_PAGES(1P2M_ROOT_ORDER)
@@ -1310,6 +1313,7 @@ int p2m_init(struct domain *d)
p2m-root = NULL;
+p2m-ipa_bits = P2M_IPA_BITS;
p2m-max_mapped_gfn = 0;
p2m-lowest_mapped_gfn = ULONG_MAX;
@@ -1557,9 +1561,10 @@ void __init setup_virt_paging(void)
p2m_root_order = pa_range_info[pa_range].root_order;
p2m_root_level = 2 - pa_range_info[pa_range].sl0;
+p2m_ipa_bits = 64 - pa_range_info[pa_range].t0sz;
printk(P2M: %d-bit IPA with %d-bit PA\n,
- 64 - pa_range_info[pa_range].t0sz,
+ p2m_ipa_bits,
pa_range_info[pa_range].pabits);
#endif
printk(P2M: %d levels with order-%d root, VTCR 0x%lx\n,
diff --git a/xen/include/asm-arm/p2m.h b/xen/include/asm-arm/p2m.h
index 341df55..813ddd0 100644
--- a/xen/include/asm-arm/p2m.h
+++ b/xen/include/asm-arm/p2m.h
@@ -28,6 +28,9 @@ struct p2m_domain {
/* Current VMID in use */
uint8_t vmid;
+/* Nr of bits in an IPA. */
+unsigned int ipa_bits;
+
/* Highest guest frame that's ever been mapped in the p2m
* Only takes into account ram and foreign mapping
*/
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v8 3/7] Edit some APIs in TestSupport.pm for nested test
On Thu, 2015-04-23 at 00:34 +, Hu, Robert wrote:
-Original Message-
From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
Sent: Wednesday, April 22, 2015 8:50 PM
To: Ian Campbell
Cc: Pang, LongtaoX; xen-devel@lists.xen.org; wei.l...@citrix.com; Hu, Robert
Subject: Re: [OSSTEST Nested PATCH v8 3/7] Edit some APIs in TestSupport.pm
for nested test
Ian Campbell writes (Re: [OSSTEST Nested PATCH v8 3/7] Edit some APIs in
TestSupport.pm for nested test):
It will, I think, need to be integrated with the existing assignment to
$ho-{Ip} in select host, so something like:
if ( $r{${ident}_ip} ) {
$ho-{Ip}= $r{${ident}_ip};
} else {
$ho-{Ip}= $ho-{IpStatic};
}
Yes.
Yes, otherwise the code would go 'die' somewhere later.
Seems inevitably run into die in our nested test case, since our l1 host
shall not have IpStatic, while currently seems this is a necessary.
$ho-{IpStatic} = get_host_property($ho,'ip-addr');
if (!defined $ho-{IpStatic}) {
my $ip_packed= gethostbyname($ho-{Fqdn});
die $ho-{Fqdn} ? unless $ip_packed;
$ho-{IpStatic}= inet_ntoa($ip_packed);
die $ho-{Fqdn} ? unless defined $ho-{IpStatic};
}
Shall we loosen this for nested l1 host?
i.e. die $ho-{Fqdn} ? unless $ip_packed ||
$r{$ident_enable_nestedhvm} eq 'true';
or perhaps:
$ho-{Ip} = $r{${ident}_ip} ? $r{${ident}_ip} :
$ho-{IpStatic};
The shortest way to spell this is to use //, eg:
$ho-{Ip} = $r{${ident}_ip} // $ho-{IpStatic};
Ah, yes!
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 52624: regressions - FAIL
flight 52624 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/52624/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-libvirt5 libvirt-build fail REGR. vs. 50391 build-i386-pvops 5 kernel-build fail REGR. vs. 50391 build-amd64-pvops 5 kernel-build fail REGR. vs. 50391 build-armhf-pvops 5 kernel-build fail REGR. vs. 50391 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 1 build-check(1) blocked n/a test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-xsm1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-xsm 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 1 build-check(1)blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-armhf-armhf-xl-sedf-pin 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-sedf-pin 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-sedf 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3 1 build-check(1) blocked n/a
[Xen-devel] [xen-4.3-testing test] 52622: regressions - FAIL
flight 52622 xen-4.3-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/52622/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-pvops 5 kernel-build fail REGR. vs. 36755 build-i386-libvirt5 libvirt-build fail REGR. vs. 36755 build-armhf 5 xen-build fail REGR. vs. 36755 build-i386-pvops 5 kernel-build fail REGR. vs. 36755 build-armhf-pvops 5 kernel-build fail REGR. vs. 36755 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-sedf-pin 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-sedf 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-pv 1 build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-pv1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-sedf-pin 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-amd64-xl-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xend-qemut-winxpsp3 1 build-check(1) blocked n/a build-i386-rumpuserxen6 xen-buildfail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass version targeted for testing: xen 58db71c5cdd48126b9380c230dc5b61554bad7d8 baseline version: xen c58b16ef1572176cf2f6a424b527b5ed4bb73f17
Re: [Xen-devel] xen-unstable + 4.1.0-rc1: Dom0 kernel stalls in early boot
On 04/27/2015 04:15 PM, Boris Ostrovsky wrote: On 04/27/2015 11:40 AM, Sander Eikelenboom wrote: Monday, April 27, 2015, 4:55:06 PM, you wrote: Hi David / Konrad, Today i tried upgrading my dom0 kernel to 4.1-rc1, but it stalls in early boot. Xen console was still reponsive so i dumped some info with the debug keys. Serial log is attached. The kernel boots fine on baremetal and my previous test kernel that was pulled and compiled on 20150423 in the mergewindow boots fine (unfortunately my scripts don't add an git commit version to the kernel name yet. (but the 20150423 version has it's own issue when used as a PV guest kernel with pci passthrough, pci-front can't connect somehow, which i was trying to get at .. when i stumbled upon this one :-) ). -- Sander Hrmm shoot, that even didn't need a full bisection (but i looked over it before sending the mails), tested by reverting this one commit, after that it boots fine: 61f01dd941ba9e06d2bf05994450ecc3d61b6b8b x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue Question is .. why does it boot on baremetal, but not under Xen ? (any ideas before getting this to LKML and x86 maintainers / Linus ?) We shouldn't be loading __KERNEL_DS to stack segment in PV, which is what this patch does. The bug that this commit is trying to fix is not applicable to PV guests in the first place (and even if it is it would have to be fixed in the hypervisor) so we essentially need to avoid setting X86_BUG_SYSRET_SS_ATTRS flag in CPU initialization code. I need to find a good place to clear it early enough. The most logical thing to do seems to be adding set_cpu_features op to x86_hyper_xen_hvm (and renaming it). The trouble is that its name string is Xen HVM and so HVM part would have to go. This may be bad if a tool greps for this string in the log. Alternatively we could re-assign name string when we figure out which guest we are but that would require un-constifying struct hypervisor_x86 everywhere. Any preference? -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen-unstable + 4.1.0-rc1: Dom0 kernel stalls in early boot
On 04/27/2015 11:40 AM, Sander Eikelenboom wrote: Monday, April 27, 2015, 4:55:06 PM, you wrote: Hi David / Konrad, Today i tried upgrading my dom0 kernel to 4.1-rc1, but it stalls in early boot. Xen console was still reponsive so i dumped some info with the debug keys. Serial log is attached. The kernel boots fine on baremetal and my previous test kernel that was pulled and compiled on 20150423 in the mergewindow boots fine (unfortunately my scripts don't add an git commit version to the kernel name yet. (but the 20150423 version has it's own issue when used as a PV guest kernel with pci passthrough, pci-front can't connect somehow, which i was trying to get at .. when i stumbled upon this one :-) ). -- Sander Hrmm shoot, that even didn't need a full bisection (but i looked over it before sending the mails), tested by reverting this one commit, after that it boots fine: 61f01dd941ba9e06d2bf05994450ecc3d61b6b8b x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue Question is .. why does it boot on baremetal, but not under Xen ? (any ideas before getting this to LKML and x86 maintainers / Linus ?) We shouldn't be loading __KERNEL_DS to stack segment in PV, which is what this patch does. The bug that this commit is trying to fix is not applicable to PV guests in the first place (and even if it is it would have to be fixed in the hypervisor) so we essentially need to avoid setting X86_BUG_SYSRET_SS_ATTRS flag in CPU initialization code. I need to find a good place to clear it early enough. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] xen: arm: X-Gene Storm check GIC DIST address for EOI quirk
Hi Julien,
On 25 April 2015 at 21:48, Julien Grall julien.gr...@citrix.com wrote:
Hi Pranav,
On 24/04/2015 15:46, Pranavkumar Sawargaonkar wrote:
In old X-Gene Storm firmware and DT, secure mode addresses have been
mentioned in GICv2 node. In this case maintenance interrupt is used
instead of EOI HW method.
This patch checks the GIC Distributor Base Address to enable EOI quirk
for old firmware.
Ref:
http://lists.xen.org/archives/html/xen-devel/2014-07/msg01263.html
ChangeLog:
V2:
- Fine tune interrupt controller node search as per comments on V1 patch
- Incorporating other misc comments on V1.
V1:
- Initial patch.
The changelog should be separated from the commit message by a --- follow
by a new line. So git automatically will stripped the changelog when Ian
will apply the patch to Xen git.
Thanks I will fix this along with other comments to post v3.
-
Pranav
Tested-by: Christoffer Dall christoffer.d...@linaro.org
Signed-off-by: Pranavkumar Sawargaonkar pranavku...@linaro.org
---
xen/arch/arm/platforms/xgene-storm.c | 42
+-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/platforms/xgene-storm.c
b/xen/arch/arm/platforms/xgene-storm.c
index 1812e5b..c9a6dfc 100644
--- a/xen/arch/arm/platforms/xgene-storm.c
+++ b/xen/arch/arm/platforms/xgene-storm.c
@@ -22,6 +22,7 @@
#include asm/platform.h
#include xen/stdbool.h
#include xen/vmap.h
+#include xen/device_tree.h
#include asm/io.h
#include asm/gic.h
@@ -35,9 +36,46 @@ static u64 reset_addr, reset_size;
static u32 reset_mask;
static bool reset_vals_valid = false;
+#define XGENE_SEC_GICV2_DIST_ADDR0x7801
+static u32 __read_mostly xgene_quirks = PLATFORM_QUIRK_GIC_64K_STRIDE;
+
+static void __init xgene_check_pirq_eoi(void)
+{
+struct dt_device_node *node;
I think this can be const.
+int res;
+paddr_t dbase;
+static const struct dt_device_match xgene_dt_int_ctrl_match[] =
The static is not necessary here.
+{
+DT_MATCH_COMPATIBLE(arm,cortex-a15-gic),
+{ /*sentinel*/ },
+};
+
+node = dt_find_interrupt_controller(xgene_dt_int_ctrl_match);
+if ( !node )
+panic(%s: Can not find interrupt controller node\n, __func__);
s/Can not/Cannot/ ?
Panic will add a newline. So it's not necessary here.
Although I'm not sure if we should use panic here. All the platform code is
returning an error code which will be handled to an upper function in the
stack (currently it's platform_init).
I don't have a strong opinion on it. I will let the ARM maintainers decide.
+
+res = dt_device_get_address(node, 0, dbase, NULL);
+if ( !dbase )
+panic(%s: Cannot find a valid address for the
+distributor, __func__);
The indentation looks wrong here. Also, I'm not sure why you split the
message. The line won't be longer than 80 columns.
+
+/*
+ * In old X-Gene Storm firmware and DT, secure mode addresses have
+ * been mentioned in GICv2 node. We have to use maintenance interrupt
+ * instead of EOI HW in this case. We check the GIC Distributor Base
+ * Address to maintain compatibility with older firmware.
+ */
+if ( dbase == XGENE_SEC_GICV2_DIST_ADDR )
+{
+xgene_quirks |= PLATFORM_QUIRK_GUEST_PIRQ_NEED_EOI;
+printk(Xen: warning: Using OLD X-Gene Firmware,
+disabling PIRQ EOI mode ...\n);
Indentation
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v3 01/10] vmx: add new boot parameter to control PML enabling
Kai Huang kaih.li...@gmail.com 04/25/15 5:00 PM On Fri, Apr 24, 2015 at 10:33 PM, Jan Beulich jbeul...@suse.com wrote: On 24.04.15 at 10:19, kai.hu...@linux.intel.com wrote: +} + +custom_param(ept, parse_ept_param); And a superfluous blank line would want to be dropped here. Sure. Will do both of your above comments if a further v4 is needed. Thanks. And I suppose you are talking about the blank line before custom_param(ept, parse_ept_param) ? Yes. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 3/7] xenalyze: include odd mmio states in default output
Signed-off-by: Olaf Hering o...@aepfle.de
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/misc/xenalyze.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/misc/xenalyze.c b/tools/misc/xenalyze.c
index 51a2d1d..58e8456 100644
--- a/tools/misc/xenalyze.c
+++ b/tools/misc/xenalyze.c
@@ -3740,7 +3740,7 @@ void hvm_mmio_assist_postprocess(struct hvm_data *h)
static int warned = 0;
if (!warned)
{
-fprintf(stderr, %s: Strange, MMIO with unexpected exit reason
%d\n,
+fprintf(warn, %s: Strange, MMIO with unexpected exit reason %d\n,
__func__, h-exit_reason);
warned=1;
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 7/7] xenalyze: remove traling whitespaces
Result of sed -i 's@[[:blank:]]\+$@@' tools/misc/xenalyze.c
Signed-off-by: Olaf Hering o...@aepfle.de
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/misc/xenalyze.c | 350 +-
1 file changed, 175 insertions(+), 175 deletions(-)
diff --git a/tools/misc/xenalyze.c b/tools/misc/xenalyze.c
index b9feea9..a367fd8 100644
--- a/tools/misc/xenalyze.c
+++ b/tools/misc/xenalyze.c
@@ -2,7 +2,7 @@
* xenalyze.c: Analyzing xentrace output
*
* Written by George Dunlap.
- *
+ *
* Copyright (c) 2006-2007, XenSource Inc.
* Copyright (c) 2007-2008, Citrix Systems RD Ltd, UK
*
@@ -62,7 +62,7 @@ struct array_struct {
fprintf(warn, ##_x); \
} \
} while(0)\
-
+
/* -- Global variables -- */
struct {
int fd;
@@ -88,7 +88,7 @@ struct {
.progress = { .update_offset = 0 },
};
-/*
+/*
Kinds of errors:
Unexpected values
- RIP with information in high bits (not all 0 or 1)
@@ -116,7 +116,7 @@ struct {
- domain runstates
- runstate / tsc skew
- vcpu_{prev,next}_update p-current{==,!=}null
-- vcpu start conditions
+- vcpu start conditions
- lost_cpu count higher than # of seen cpus / 0
- lost cpu has non-null p-current
Symbol file
@@ -147,7 +147,7 @@ enum error_level {
int verbosity = 5;
struct {
-unsigned
+unsigned
scatterplot_interrupt_eip:1,
scatterplot_cpi:1,
scatterplot_unpin_promote:1,
@@ -226,7 +226,7 @@ struct {
} opt = {
.scatterplot_interrupt_eip=0,
.scatterplot_cpi=0,
-.scatterplot_unpin_promote=0,
+.scatterplot_unpin_promote=0,
.scatterplot_cr3_switch=0,
.scatterplot_wake_to_halt=0,
.scatterplot_vmexit_eip=0,
@@ -356,7 +356,7 @@ void parse_symbol_file(char *fn) {
error(ERR_ASSERT, NULL);
} else
last_addr = (*p)-symbols[(*p)-count].addr;
-
+
(*p)-count++;
/* If this struct is full, point to the next. It will be allocated
@@ -419,7 +419,7 @@ struct {
void (*dump)(struct eip_list_struct *);
} eip_list_type[EIP_LIST_TYPE_MAX] = {
[EIP_LIST_TYPE_NONE] = {
-.update=NULL,
+.update=NULL,
.new=NULL,
.dump=NULL },
};
@@ -428,7 +428,7 @@ struct {
/* --- HVM class of events --- */
/*
- * -- Algorithms --
+ * -- Algorithms --
*
* Interrupt Wake-to-halt detection
*
@@ -451,7 +451,7 @@ struct {
*
* The waking interrupts we want to sub-classify into
* wake-only (when interrupt was the only interrupt from wake to halt) and
- * wake-all (whether this was the only interrupt or not).
+ * wake-all (whether this was the only interrupt or not).
*/
/* VMX data */
@@ -969,7 +969,7 @@ char * hvm_event_handler_name[HVM_EVENT_HANDLER_MAX] = {
pf_inject,
inj_exc,
inj_virq,
-reinj_virq,
+reinj_virq,
io_read,
io_write,
cr_read, /* 8 */
@@ -1470,7 +1470,7 @@ void init_hvm_data(struct hvm_data *h, struct vcpu_data
*v) {
size);
error(ERR_SYSTEM, NULL);
}
-
+
}
for(i=0; iGUEST_INTERRUPT_MAX+1; i++)
h-summary.guest_interrupt[i].count=0;
@@ -1758,7 +1758,7 @@ struct domain_data {
struct cr3_value_struct *cr3_value_head;
struct eip_list_struct *emulate_eip_list;
struct eip_list_struct *interrupt_eip_list;
-
+
int guest_interrupt[GUEST_INTERRUPT_MAX+1];
struct hvm_short_summary_struct hvm_short;
struct {
@@ -1841,7 +1841,7 @@ void volume_summary(struct trace_volume *vol)
printf( +-%-7s: %10lld\n,
hvm_vol_name[k], vol-hvm[k]);
}
-
+
break;
}
}
@@ -2050,7 +2050,7 @@ long long percentile(long long * A, int N, int ple) {
I++; J--;
}
} while (I = J); /* Keep going until our pointers meet or pass */
-
+
/* Re-adjust L and R, based on which element we're looking for */
if(JK)
L=I;
@@ -2134,9 +2134,9 @@ float weighted_percentile(float * A, /* values */
} while (I = J); /* Keep going until our pointers meet or pass */
/* Re-adjust L and R, based on which element we're looking for */
-if(J_weightK_weight)
+if(J_weightK_weight)
L=I; L_weight = I_weight;
-if(K_weightI_weight)
+if(K_weightI_weight)
R=J; R_weight = J_weight;
}
@@ -2365,7 +2365,7 @@ static inline void clear_interval_cpi(struct
weighted_cpi_summary *s) {
static inline void print_cpu_affinity(struct cycle_summary *s, char *p) {
if(s-count) {
long long avg;
-
+
[Xen-devel] [PATCH 6/7] xenalyze: handle more events in sched_process
Signed-off-by: Olaf Hering o...@aepfle.de
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/misc/xenalyze.c | 73 ++-
1 file changed, 66 insertions(+), 7 deletions(-)
diff --git a/tools/misc/xenalyze.c b/tools/misc/xenalyze.c
index 67b44b5..b9feea9 100644
--- a/tools/misc/xenalyze.c
+++ b/tools/misc/xenalyze.c
@@ -30,6 +30,7 @@
#include fcntl.h
#include unistd.h
#include public/trace.h
+#include public/sched.h
#include analyze.h
#include mread.h
#include pv.h
@@ -7573,24 +7574,82 @@ void sched_summary_domain(struct domain_data *d)
}
}
+void sched_class(struct record_info *ri)
+{
+}
void sched_process(struct pcpu_info *p)
{
struct record_info *ri = p-ri;
-if(ri-evt.sub == 0xf) {
+if (ri-evt.sub == 1) {
+sched_runstate_process(p);
+} else if (ri-evt.sub == 2) {
+sched_class(ri);
+} else {
switch(ri-event)
{
+case TRC_SCHED_DOM_ADD:
+printf( %s sched_add_domain d%uv%u\n,
+ ri-dump_header, ri-d[0], ri-d[1]);
+break;
+case TRC_SCHED_DOM_REM:
+printf( %s sched_rem_domain d%uv%u\n,
+ ri-dump_header, ri-d[0], ri-d[1]);
+break;
+case TRC_SCHED_SLEEP:
+printf( %s domain_sleep d%uv%u\n,
+ ri-dump_header, ri-d[0], ri-d[1]);
+break;
+case TRC_SCHED_WAKE:
+printf( %s domain_wake d%uv%u\n,
+ ri-dump_header, ri-d[0], ri-d[1]);
+break;
+case TRC_SCHED_YIELD:
+printf( %s do_yield d%uv%u\n,
+ ri-dump_header, ri-d[0], ri-d[1]);
+break;
+case TRC_SCHED_BLOCK:
+printf( %s do_block d%uv%u\n,
+ ri-dump_header, ri-d[0], ri-d[1]);
+break;
+case TRC_SCHED_SHUTDOWN:
+{
+static const char *reason[] = {
+[SHUTDOWN_poweroff] = poweroff,
+[SHUTDOWN_reboot] = reboot,
+[SHUTDOWN_suspend] = suspend,
+[SHUTDOWN_crash] = crash,
+[SHUTDOWN_watchdog] = watchdog,
+};
+printf( %s domain_shutdown d%uv%u reason %x (%s)\n,
+ ri-dump_header, ri-d[0], ri-d[1], ri-d[2],
+ ri-d[2] SHUTDOWN_MAX ? unknown : reason[ri-d[2]]);
+break;
+}
+case TRC_SCHED_SHUTDOWN_CODE:
+{
+printf( %s domain_shutdown_code d%uv%u reason %x\n,
+ ri-dump_header, ri-d[0], ri-d[1], ri-d[2]);
+break;
+}
+case TRC_SCHED_ADJDOM:
+printf( %s sched_adjdom domid d%u\n,
+ ri-dump_header, ri-d[0]);
+break;
case TRC_SCHED_SWITCH:
sched_switch_process(p);
break;
+case TRC_SCHED_SWITCH_INFPREV:
+printf( %s switch_infprev old_domid %x runtime %d\n,
+ ri-dump_header, ri-d[0], ri-d[1]);
+break;
+case TRC_SCHED_SWITCH_INFNEXT:
+printf( %s switch_infnext new_domid %x time %d r_time %d\n,
+ ri-dump_header, ri-d[0], ri-d[1], ri-d[2]);
+break;
default:
-process_generic(p-ri);
-}
-} else {
-if(ri-evt.sub == 1)
-sched_runstate_process(p);
-else {
+fprintf(warn, %s: event:%x (min:%x sub:%x main:%x)\n, __func__,
ri-event, ri-evt.minor, ri-evt.sub, ri-evt.main);
UPDATE_VOLUME(p, sched_verbose, ri-size);
process_generic(p-ri);
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 5/7] xenalyze: disable sched_switch_process
It causes a crash, dump data and return early Signed-off-by: Olaf Hering o...@aepfle.de Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com --- tools/misc/xenalyze.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/misc/xenalyze.c b/tools/misc/xenalyze.c index 0566d00..67b44b5 100644 --- a/tools/misc/xenalyze.c +++ b/tools/misc/xenalyze.c @@ -7449,6 +7449,10 @@ void sched_switch_process(struct pcpu_info *p) unsigned int prev_dom, prev_vcpu, next_dom, next_vcpu; } * r = (typeof(r))ri-d; +printf( %s __enter_scheduler prev d%uv%u new d%uv%u\n +ri-dump_header, ri-d[0], ri-d[1], ri-d[2], ri-d[3]); +return; + if(opt.dump_all) printf(%s sched_switch prev d%uv%u next d%uv%u\n, ri-dump_header, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 4/7] xenalyze: handle TRC_TRACE_WRAP_BUFFER
Signed-off-by: Olaf Hering o...@aepfle.de
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Wei Liu wei.l...@citrix.com
---
tools/misc/xenalyze.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/misc/xenalyze.c b/tools/misc/xenalyze.c
index 58e8456..0566d00 100644
--- a/tools/misc/xenalyze.c
+++ b/tools/misc/xenalyze.c
@@ -8469,6 +8469,8 @@ void base_process(struct pcpu_info *p) {
struct record_info *ri = p-ri;
switch(ri-event)
{
+case TRC_TRACE_WRAP_BUFFER:
+break;
case TRC_LOST_RECORDS:
process_lost_records(p);
break;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/7] add xenalyze to staging
Having xenalyze in the source tree makes it much easier to keep private debug code in hypervisor and xenalyze in sync. It helped alot while debugging the root cause for commit 607e8494c42397fb249191904066cace6ac9a880. Olaf Olaf Hering (7): xenalyze: add to tools/misc xenalyze: print newline after unknown hvm events xenalyze: include odd mmio states in default output xenalyze: handle TRC_TRACE_WRAP_BUFFER xenalyze: disable sched_switch_process xenalyze: handle more events in sched_process xenalyze: remove traling whitespaces .gitignore| 1 + tools/misc/Makefile | 5 + tools/misc/analyze.h | 107 + tools/misc/mread.c| 160 + tools/misc/mread.h|18 + tools/misc/pv.h |41 + tools/misc/xenalyze.c | 10472 7 files changed, 10804 insertions(+) create mode 100644 tools/misc/analyze.h create mode 100644 tools/misc/mread.c create mode 100644 tools/misc/mread.h create mode 100644 tools/misc/pv.h create mode 100644 tools/misc/xenalyze.c ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/7] xenalyze: print newline after unknown hvm events
Signed-off-by: Olaf Hering o...@aepfle.de Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com --- tools/misc/xenalyze.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/misc/xenalyze.c b/tools/misc/xenalyze.c index 5f0757b..51a2d1d 100644 --- a/tools/misc/xenalyze.c +++ b/tools/misc/xenalyze.c @@ -5435,7 +5435,7 @@ void hvm_process(struct pcpu_info *p) hvm_vmentry_process(ri, p-current-hvm); break; default: -fprintf(warn, Unknown hvm event: %x, ri-event); +fprintf(warn, Unknown hvm event: %x\n, ri-event); } } } ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/7] xenalyze: add to tools/misc
On 27/04/15 14:22, Olaf Hering wrote: This merges xenalyze.hg, changeset 150:24308507be1d into tools/misc to have the tool and public/trace.h in one place. Would this not be better in tools/xentrace/xenalyze ? David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/arm: Make local_events_need_delivery working with idle VPCU
The commit 569fb6c xen/arm: Data abort exception (R/W) mem_access
events makes apply_p2m_changes to call hypercall_preempt_check for any
operation rather than for relinquish.
The function hypercall_preempt_check call local_events_need_delivery
which rely on the current VCPU is not an idle VCPU.
Although, during DOM0 building the current VCPU is an idle one. This
would make Xen crash with the following stack trace:
(XEN) CPU0: Unexpected Trap: Data Abort
[...]
(XEN) Xen call trace:
(XEN)[00256ef4] apply_p2m_changes+0x210/0x1190 (PC)
(XEN)[002506b4] gic_events_need_delivery+0x5c/0x13c (LR)
(XEN)[002580ec] map_mmio_regions+0x64/0x74
(XEN)[00251958] gicv2v_setup+0xf8/0x150
(XEN)[00250964] gicv_setup+0x20/0x30
(XEN)[0024cb3c] arch_domain_create+0x170/0x244
(XEN)[00207df0] domain_create+0x2ac/0x4d8
(XEN)[0028e3d0] start_xen+0xcbc/0xee4
(XEN)[00200540] paging+0x94/0xd8
(XEN)
(XEN)
(XEN)
(XEN) Panic on CPU 0:
(XEN) CPU0: Unexpected Trap: Data Abort
(XEN)
(XEN)
As an idle VCPU can never receive an event, return 0 when the current
VCPU is an idle VCPU in local_events_need_delivery.
Reported-by: Riku Voipio riku.voi...@linaro.org
Signed-off-by: Julien Grall julien.gr...@citrix.com
CC: Tamas K Lengyel tkleng...@sec.in.tum.de
---
This bug has been catched during boot on Mustang. This is because we
have to map large chunk of PCI memory region.
I was able to reproduce the bug on midway by lowering down
preempt_count_limit to 16 in apply_p2m_changes.
Although, I'm not sure this is the right fix for the bug.
---
xen/include/asm-arm/event.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
index 5330dfe..0149d06 100644
--- a/xen/include/asm-arm/event.h
+++ b/xen/include/asm-arm/event.h
@@ -39,7 +39,12 @@ static inline int local_events_need_delivery_nomask(void)
static inline int local_events_need_delivery(void)
{
-if ( !vcpu_event_delivery_is_enabled(current) )
+struct vcpu *v = current;
+
+if ( unlikely(is_idle_vcpu(v)) )
+return 0;
+
+if ( !vcpu_event_delivery_is_enabled(v) )
return 0;
return local_events_need_delivery_nomask();
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/arm: p2m: Add an ASSERT to check that p2m lock is taken in __p2m_lookup
__p2m_lookup should be called with the p2m lock taken. Add an ASSERT in order to catch wrong caller in debug build. Signed-off-by: Julien Grall julien.gr...@citrix.com --- xen/arch/arm/p2m.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c index 8dfee24..65efa94 100644 --- a/xen/arch/arm/p2m.c +++ b/xen/arch/arm/p2m.c @@ -160,6 +160,7 @@ static paddr_t __p2m_lookup(struct domain *d, paddr_t paddr, p2m_type_t *t) p2m_type_t _t; unsigned int level, root_table; +ASSERT(spin_is_locked(p2m-lock)); BUILD_BUG_ON(THIRD_MASK != PAGE_MASK); /* Allow t to be NULL */ -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen-unstable + 4.1.0-rc1: Dom0 kernel stalls in early boot
Monday, April 27, 2015, 4:55:06 PM, you wrote: Hi David / Konrad, Today i tried upgrading my dom0 kernel to 4.1-rc1, but it stalls in early boot. Xen console was still reponsive so i dumped some info with the debug keys. Serial log is attached. The kernel boots fine on baremetal and my previous test kernel that was pulled and compiled on 20150423 in the mergewindow boots fine (unfortunately my scripts don't add an git commit version to the kernel name yet. (but the 20150423 version has it's own issue when used as a PV guest kernel with pci passthrough, pci-front can't connect somehow, which i was trying to get at .. when i stumbled upon this one :-) ). -- Sander Hmm and to add to that .. the 4.1-rc1 also doesn't work in other PV guests (under the 20150423 mergewindow kernel as dom)), from a PV guest console it hangs at: [0.00] PAT configuration [0-7]: WB WT UC- UC WC WP UC UC [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.1.0-rc1-20150427+ (root@serveerstertje) (gcc version 4.7.2 (Debian 4.7.2-5) ) #1 SMP Mon Apr 27 15:05:57 CEST 2015 [0.00] Command line: root=/dev/xvda1 ro [0.00] ACPI in unprivileged domain disabled [0.00] Released 0 page(s) [0.00] e820: BIOS-provided physical RAM map: [0.00] Xen: [mem 0x-0x0009] usable [0.00] Xen: [mem 0x000a-0x000f] reserved [0.00] Xen: [mem 0x0010-0x0fff] usable [0.00] NX (Execute Disable) protection: active [0.00] MPS support code is not built-in. [0.00] Using acpi=off or acpi=noirq or pci=noacpi may have problem [0.00] DMI not present or invalid. [0.00] AGP: No AGP bridge found [0.00] e820: last_pfn = 0x1 max_arch_pfn = 0x4 [0.00] Scanning 1 areas for low memory corruption [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] init_memory_mapping: [mem 0x0fe0-0x0fff] [0.00] init_memory_mapping: [mem 0x0010-0x0fdf] [0.00] RAMDISK: [mem 0x02561000-0x03896fff] [0.00] NUMA turned off [0.00] Faking a node at [mem 0x-0x0fff] [0.00] NODE_DATA(0) allocated [mem 0x0ff94000-0x0ff9efff] [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] DMA32[mem 0x0100-0x0fff] [0.00] Normal empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x0009] [0.00] node 0: [mem 0x0010-0x0fff] [0.00] Initmem setup node 0 [mem 0x1000-0x0fff] [0.00] p2m virtual area at c900, size is 20 [0.00] Remapped 0 page(s) [0.00] smpboot: Allowing 1 CPUs, 0 hotplug CPUs [0.00] No local APIC present [0.00] APIC: disable apic facility [0.00] APIC: switched to apic NOOP [0.00] e820: [mem 0x1000-0x] available for PCI devices [0.00] Booting paravirtualized kernel on Xen [0.00] Xen version: 4.6-unstable (preserve-AD) [0.00] clocksource refined-jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 6370452778343963 ns [0.00] setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1 [0.00] PERCPU: Embedded 32 pages/cpu @88000fc0 s93864 r8192 d29016 u2097152 [0.00] Built 1 zonelists in Node order, mobility grouping on. Total pages: 64394 [0.00] Policy zone: DMA32 [0.00] Kernel command line: root=/dev/xvda1 ro [0.00] PID hash table entries: 1024 (order: 1, 8192 bytes) [0.00] AGP: Checking aperture... [0.00] AGP: No AGP bridge found [0.00] Memory: 214836K/261756K available (11958K kernel code, 987K rwdata, 4520K rodata, 1108K init, 1164K bss, 46920K reserved, 0K cma-reserved) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] Hierarchical RCU implementation. [0.00] RCU dyntick-idle grace-period acceleration is enabled. [0.00] Additional per-CPU info printed with stalls. [0.00] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1. [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 [0.00] NR_IRQS:4352 nr_irqs:32 16 [0.00] xen:events: Using FIFO-based ABI [0.00] Console: colour dummy device 80x25 [0.00] console [tty0] enabled [0.00] console [hvc0] enabled [0.00] kmemleak: Kernel memory leak detector disabled [0.00] clocksource xen: mask: 0x max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns [0.00
Re: [Xen-devel] [PATCH] xen: Suspend ticks on all CPUs during suspend
On 04/27/2015 06:33 AM, David Vrabel wrote: On 08/04/15 19:53, Boris Ostrovsky wrote: Commit 77e32c89a711 (clockevents: Manage device's state separately for the core) decouples clockevent device's modes from states. With this change when a Xen guest tries to resume, it won't be calling its set_mode op which needs to be done on each VCPU in order to make the hypervisor aware that we are in oneshot mode. This happens because clockevents_tick_resume() (which is an intermediate step of resuming ticks on a processor) no longer calls clockevents_set_state() and because during suspend clockevent devices on all VCPUs (except for the one doing the suspend) are left in ONESHOT state. As result, during resume the clockevents state machine will assume that device is already where it should be and doesn't need to be updated. To avoid this problem we should suspend ticks on all VCPUs during suspend. Sorry for the delay in reviewing this. diff --git a/drivers/xen/manage.c b/drivers/xen/manage.c index bf19407..2fd9fe8 100644 --- a/drivers/xen/manage.c +++ b/drivers/xen/manage.c @@ -131,6 +131,8 @@ static void do_suspend(void) goto out_resume; } + xen_arch_suspend(); + si.cancelled = 1; xen_arch_resume() is only called when !si.cancelled but you call xen_arch_suspend() unconditionally. Good point. Let me see if I can move this to xen_arch_post_suspend, when we know whether the suspend has been canceled. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] xen-unstable + 4.1.0-rc1: Dom0 kernel stalls in early boot
Hi David / Konrad, Today i tried upgrading my dom0 kernel to 4.1-rc1, but it stalls in early boot. Xen console was still reponsive so i dumped some info with the debug keys. Serial log is attached. The kernel boots fine on baremetal and my previous test kernel that was pulled and compiled on 20150423 in the mergewindow boots fine (unfortunately my scripts don't add an git commit version to the kernel name yet. (but the 20150423 version has it's own issue when used as a PV guest kernel with pci passthrough, pci-front can't connect somehow, which i was trying to get at .. when i stumbled upon this one :-) ). -- Sander serial.log Description: Binary data ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 1/2] iommu VT-d: separate rmrr addition function
From: Elena Ufimtseva elena.ufimts...@oracle.com
In preparation for auxiliary RMRR data provided on Xen
command line, make RMRR adding a separate function.
No functional changes.
Reviewed-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Acked-by: Kevin Tian kevin.t...@intel.com
Signed-off-by: Elena Ufimtseva elena.ufimts...@oracle.com
---
xen/drivers/passthrough/vtd/dmar.c | 123 +++--
1 file changed, 63 insertions(+), 60 deletions(-)
diff --git a/xen/drivers/passthrough/vtd/dmar.c
b/xen/drivers/passthrough/vtd/dmar.c
index 1152c3a..356d696 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -567,6 +567,66 @@ out:
return ret;
}
+static int register_one_rmrr(struct acpi_rmrr_unit *rmrru)
+{
+bool_t ignore = 0;
+unsigned int i = 0;
+int ret = 0;
+
+/* Skip checking if segment is not accessible yet. */
+if ( !pci_known_segment(rmrru-segment) )
+i = UINT_MAX;
+
+for ( ; i rmrru-scope.devices_cnt; i++ )
+{
+u8 b = PCI_BUS(rmrru-scope.devices[i]);
+u8 d = PCI_SLOT(rmrru-scope.devices[i]);
+u8 f = PCI_FUNC(rmrru-scope.devices[i]);
+
+if ( pci_device_detect(rmrru-segment, b, d, f) == 0 )
+{
+dprintk(XENLOG_WARNING VTDPREFIX,
+ Non-existent device (%04x:%02x:%02x.%u) is reported
+ in RMRR (%PRIx64, %PRIx64)'s scope!\n,
+rmrru-segment, b, d, f,
+rmrru-base_address, rmrru-end_address);
+ignore = 1;
+}
+else
+{
+ignore = 0;
+break;
+}
+}
+
+if ( ignore )
+{
+dprintk(XENLOG_WARNING VTDPREFIX,
+ Ignore the RMRR (%PRIx64, %PRIx64) due to
+devices under its scope are not PCI discoverable!\n,
+rmrru-base_address, rmrru-end_address);
+ret = -EFAULT;
+}
+else if ( rmrru-base_address rmrru-end_address )
+{
+dprintk(XENLOG_WARNING VTDPREFIX,
+ The RMRR (%PRIx64, %PRIx64) is incorrect!\n,
+rmrru-base_address, rmrru-end_address);
+ret = -EFAULT;
+}
+else
+{
+if ( iommu_verbose )
+dprintk(VTDPREFIX,
+ RMRR region: base_addr %PRIx64
+ end_address %PRIx64\n,
+rmrru-base_address, rmrru-end_address);
+acpi_register_rmrr_unit(rmrru);
+}
+
+return ret;
+}
+
static int __init
acpi_parse_one_rmrr(struct acpi_dmar_header *header)
{
@@ -616,67 +676,10 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
dev_scope_end = ((void *)rmrr) + header-length;
ret = acpi_parse_dev_scope(dev_scope_start, dev_scope_end,
rmrru-scope, RMRR_TYPE, rmrr-segment);
-
-if ( ret || (rmrru-scope.devices_cnt == 0) )
+if ( !ret (rmrru-scope.devices_cnt != 0) )
+ret = register_one_rmrr(rmrru);
+if ( ret )
xfree(rmrru);
-else
-{
-u8 b, d, f;
-bool_t ignore = 0;
-unsigned int i = 0;
-
-/* Skip checking if segment is not accessible yet. */
-if ( !pci_known_segment(rmrr-segment) )
-i = UINT_MAX;
-
-for ( ; i rmrru-scope.devices_cnt; i++ )
-{
-b = PCI_BUS(rmrru-scope.devices[i]);
-d = PCI_SLOT(rmrru-scope.devices[i]);
-f = PCI_FUNC(rmrru-scope.devices[i]);
-
-if ( pci_device_detect(rmrr-segment, b, d, f) == 0 )
-{
-dprintk(XENLOG_WARNING VTDPREFIX,
- Non-existent device (%04x:%02x:%02x.%u) is reported
- in RMRR (%PRIx64, %PRIx64)'s scope!\n,
-rmrr-segment, b, d, f,
-rmrru-base_address, rmrru-end_address);
-ignore = 1;
-}
-else
-{
-ignore = 0;
-break;
-}
-}
-
-if ( ignore )
-{
-dprintk(XENLOG_WARNING VTDPREFIX,
- Ignore the RMRR (%PRIx64, %PRIx64) due to
-devices under its scope are not PCI discoverable!\n,
-rmrru-base_address, rmrru-end_address);
-xfree(rmrru);
-}
-else if ( base_addr end_addr )
-{
-dprintk(XENLOG_WARNING VTDPREFIX,
- The RMRR (%PRIx64, %PRIx64) is incorrect!\n,
-rmrru-base_address, rmrru-end_address);
-xfree(rmrru);
-ret = -EFAULT;
-}
-else
-{
-if ( iommu_verbose )
-dprintk(VTDPREFIX,
- RMRR region: base_addr %PRIx64
- end_address %PRIx64\n,
-rmrru-base_address, rmrru-end_address);
-acpi_register_rmrr_unit(rmrru);
-}
-}
return ret;
}
--
2.1.3
[Xen-devel] [PATCH v4 2/2] iommu: add rmrr Xen command line option for misc rmrrs
From: Elena Ufimtseva elena.ufimts...@oracle.com
On some platforms RMRR regions may be not specified
in ACPI and thus will not be mapped 1:1 in dom0. This
causes IO Page Faults and prevents dom0 from booting
in PVH mode.
New Xen command line option rmrr allows to specify
such devices and memory regions. These regions are added
to the list of RMRR defined in ACPI if the device
is present in system. As a result, additional RMRRs will
be mapped 1:1 in dom0 with correct permissions.
Mentioned above problems were discovered during PVH work with
ThinkCentre M and Dell 5600T. No official documentation
was found so far in regards to what devices and why cause this.
Experiments show that ThinkCentre M USB devices with enabled
debug port generate DMA read transactions to the regions of
memory marked reserved in host e820 map.
For Dell 5600T the device and faulting addresses are not found yet.
For detailed history of the discussion please check following threads:
http://lists.Xen.org/archives/html/xen-devel/2015-02/msg01724.html
http://lists.Xen.org/archives/html/xen-devel/2015-01/msg02513.html
Format for rmrr Xen command line option:
rmrr=start-end=[s1]bdf1[,[s1]bdf2[,...]];start-end=[s2]bdf1[,[s2]bdf2[,...]]
If grub used and multiple ranges are specified, ';' should be quoted/escaped,
refer to grub man for more information.
Signed-off-by: Elena Ufimtseva elena.ufimts...@oracle.com
---
docs/misc/xen-command-line.markdown | 12
xen/drivers/passthrough/vtd/dmar.c | 135
xen/drivers/passthrough/vtd/dmar.h | 10 +++
3 files changed, 157 insertions(+)
diff --git a/docs/misc/xen-command-line.markdown
b/docs/misc/xen-command-line.markdown
index 1dda1f0..4065ea3 100644
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1170,6 +1170,18 @@ Specify the host reboot method.
'efi' instructs Xen to reboot using the EFI reboot call (in EFI mode by
default it will use that method first).
+### rmrr
+ '=
start-end=[s1]bdf1[,[s1]bdf2[,...]];start-end=[s2]bdf1[,[s2]bdf2[,...]]
+
+Define RMRRs units that are missing from ACPI table along with device
+they belong to and use them for 1:1 mapping. End addresses can be omitted
+and one page will be mapped. The ranges are inclusive when start and end
+are specified. Note: grub requires to escape or use quotations if special
+characters are used, namely ';', refer to the grub documentation if multiple
+ranges are specified.
+Note that segments cannot differ for the same RMRR region. If segment
+is not specified, default pci segment is used.
+
### ro-hpet
`= boolean`
diff --git a/xen/drivers/passthrough/vtd/dmar.c
b/xen/drivers/passthrough/vtd/dmar.c
index 356d696..0643c63 100644
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -49,6 +49,7 @@ static LIST_HEAD_READ_MOSTLY(acpi_rhsa_units);
static struct acpi_table_header *__read_mostly dmar_table;
static int __read_mostly dmar_flags;
static u64 __read_mostly igd_drhd_address;
+static void __init add_misc_rmrr(void);
static void __init dmar_scope_add_buses(struct dmar_scope *scope, u16 sec_bus,
u16 sub_bus)
@@ -846,6 +847,72 @@ out:
return ret;
}
+static __initdata LIST_HEAD(misc_rmrr_units);
+
+static void __init add_misc_rmrr(void)
+{
+struct acpi_rmrr_unit *rmrrn;
+struct misc_rmrr_unit *rmrru;
+unsigned int dev;
+unsigned int seg;
+
+list_for_each_entry( rmrru, misc_rmrr_units, list )
+{
+rmrrn = xmalloc(struct acpi_rmrr_unit);
+if ( !rmrrn )
+return;
+
+rmrrn-scope.devices = xmalloc_array(typeof(*rmrrn-scope.devices),
+ rmrru-dev_count);
+if ( !rmrrn-scope.devices )
+{
+xfree(rmrrn);
+return;
+}
+if ( mfn_valid(rmrru-base_address PAGE_SHIFT) ||
+ mfn_valid(rmrru-end_address PAGE_SHIFT) )
+{
+if ( iommu_verbose )
+printk(XENLOG_ERR VTDPREFIX
+ Invalid RMRR range [%PRIx64 - %PRIx64]\n,
+ rmrru-base_address, rmrru-end_address);
+xfree(rmrrn-scope.devices);
+xfree(rmrrn);
+return;
+}
+
+rmrrn-base_address = rmrru-base_address;
+rmrrn-end_address = rmrru-end_address;
+seg = rmrru-sbdf[0] 16;
+
+for ( dev = 0; dev rmrru-dev_count; dev++ )
+{
+rmrrn-scope.devices[dev] = rmrru-sbdf[dev];
+seg = seg | (rmrru-sbdf[dev] 16);
+}
+
+if ( seg != (rmrru-sbdf[0] 16) )
+{
+if ( iommu_verbose )
+printk(XENLOG_ERR VTDPREFIX
+ Segments are not equal for RMRR range [%PRIx64 -
%PRIx64]\n,
+ rmrru-base_address, rmrru-end_address);
+xfree(rmrrn-scope.devices);
+xfree(rmrrn);
+return;
[Xen-devel] [PATCH v4 0/2] iommu: add rmrr Xen command line option
From: Elena Ufimtseva elena.ufimts...@oracle.com Add Xen command line option rmrr to specify RMRR regions for devices that are not defined in ACPI thus causing IO Page Fault while booting dom0 in PVH mode. These additional regions will be added to the list of RMRR regions parsed from ACPI. Changes in v4 after comments by Jan Beulich: - keep sbdf per device instead of bdf and one segment per RMRR when parsing and compare later; - add check for segment values and make sure they are same for one RMRR; - move RMRR parameters checks and add error messages if RMRRs are incorrect; - make relevant variables and functions static; - mention requirement for segment values in rmrr documentation; Changes in v3: - use ';' instead of '#' in command line and add proper notes for grub ';' special treatment; Changes in v2: - move rmrr parser to dmar.c and make it custom_param; - change of rmrr command line oprion format; since adding multiple device per range support needs to utilize more special characters and offered from the previous review ';' is not supported, '[' ']' are reserved, ':' and used in pci format, range and devices are separated by '#'; Suggestions are welcome; - added support for multiple devices per range; - moved adding misc RMRRs before ACPI RMRR parsing; - make parser fail if pci device is specified incorrectly; Elena Ufimtseva (2): iommu VT-d: separate rmrr addition function iommu: add rmrr Xen command line option for misc rmrrs docs/misc/xen-command-line.markdown | 12 ++ xen/drivers/passthrough/vtd/dmar.c | 258 +++- xen/drivers/passthrough/vtd/dmar.h | 10 ++ 3 files changed, 220 insertions(+), 60 deletions(-) -- 2.1.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/7] xenalyze: disable sched_switch_process
On Mon, Apr 27, 2015 at 01:22:14PM +, Olaf Hering wrote: It causes a crash, dump data and return early Signed-off-by: Olaf Hering o...@aepfle.de Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com --- tools/misc/xenalyze.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/misc/xenalyze.c b/tools/misc/xenalyze.c index 0566d00..67b44b5 100644 --- a/tools/misc/xenalyze.c +++ b/tools/misc/xenalyze.c @@ -7449,6 +7449,10 @@ void sched_switch_process(struct pcpu_info *p) unsigned int prev_dom, prev_vcpu, next_dom, next_vcpu; } * r = (typeof(r))ri-d; +printf( %s __enter_scheduler prev d%uv%u new d%uv%u\n +ri-dump_header, ri-d[0], ri-d[1], ri-d[2], ri-d[3]); +return; + This doesn't look right. You skip all things below. Wei. if(opt.dump_all) printf(%s sched_switch prev d%uv%u next d%uv%u\n, ri-dump_header, ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/7] xenalyze: add to tools/misc
On Mon, Apr 27, 2015 at 01:22:10PM +, Olaf Hering wrote: This merges xenalyze.hg, changeset 150:24308507be1d into tools/misc to have the tool and public/trace.h in one place. Signed-off-by: Olaf Hering o...@aepfle.de Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Stefano Stabellini stefano.stabell...@eu.citrix.com Cc: Ian Campbell ian.campb...@citrix.com Cc: Wei Liu wei.l...@citrix.com --- .gitignore| 1 + tools/misc/Makefile | 5 + tools/misc/analyze.h | 107 + tools/misc/mread.c| 160 + tools/misc/mread.h|18 + tools/misc/pv.h |41 + tools/misc/xenalyze.c | 10407 7 files changed, 10739 insertions(+) Please don't mix xenalyze with other misc stuff. You can put it in its own directory. Wei. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: Make local_events_need_delivery working with idle VPCU
IMHO we should check if op==RELINQUISH || op==MEMACCESS before calling
hypercall_preempt_check.
That was a change I made - previously it was only called if the op was
RELINQUISH
and not the other way around.
Tamas
On Mon, Apr 27, 2015 at 4:39 PM, Julien Grall julien.gr...@citrix.com
wrote:
The commit 569fb6c xen/arm: Data abort exception (R/W) mem_access
events makes apply_p2m_changes to call hypercall_preempt_check for any
operation rather than for relinquish.
The function hypercall_preempt_check call local_events_need_delivery
which rely on the current VCPU is not an idle VCPU.
Although, during DOM0 building the current VCPU is an idle one. This
would make Xen crash with the following stack trace:
(XEN) CPU0: Unexpected Trap: Data Abort
[...]
(XEN) Xen call trace:
(XEN)[00256ef4] apply_p2m_changes+0x210/0x1190 (PC)
(XEN)[002506b4] gic_events_need_delivery+0x5c/0x13c (LR)
(XEN)[002580ec] map_mmio_regions+0x64/0x74
(XEN)[00251958] gicv2v_setup+0xf8/0x150
(XEN)[00250964] gicv_setup+0x20/0x30
(XEN)[0024cb3c] arch_domain_create+0x170/0x244
(XEN)[00207df0] domain_create+0x2ac/0x4d8
(XEN)[0028e3d0] start_xen+0xcbc/0xee4
(XEN)[00200540] paging+0x94/0xd8
(XEN)
(XEN)
(XEN)
(XEN) Panic on CPU 0:
(XEN) CPU0: Unexpected Trap: Data Abort
(XEN)
(XEN)
As an idle VCPU can never receive an event, return 0 when the current
VCPU is an idle VCPU in local_events_need_delivery.
Reported-by: Riku Voipio riku.voi...@linaro.org
Signed-off-by: Julien Grall julien.gr...@citrix.com
CC: Tamas K Lengyel tkleng...@sec.in.tum.de
---
This bug has been catched during boot on Mustang. This is because we
have to map large chunk of PCI memory region.
I was able to reproduce the bug on midway by lowering down
preempt_count_limit to 16 in apply_p2m_changes.
Although, I'm not sure this is the right fix for the bug.
---
xen/include/asm-arm/event.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
index 5330dfe..0149d06 100644
--- a/xen/include/asm-arm/event.h
+++ b/xen/include/asm-arm/event.h
@@ -39,7 +39,12 @@ static inline int
local_events_need_delivery_nomask(void)
static inline int local_events_need_delivery(void)
{
-if ( !vcpu_event_delivery_is_enabled(current) )
+struct vcpu *v = current;
+
+if ( unlikely(is_idle_vcpu(v)) )
+return 0;
+
+if ( !vcpu_event_delivery_is_enabled(v) )
return 0;
return local_events_need_delivery_nomask();
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] Xen-unstable + linux 4.1-mergewindow: problems with PV guest pci passthrough: pcifront pci-0: pciback not responding!!!
Hi David / Konrad, Here the other problem i found, which is introduced somewhere in the 4.1 mergewindow: on 4.1.0-rc1 (with the one revert to get things booting) i get this in the PV Guest console: [0.517392] crc32c_combine: 8373 self tests passed [0.517608] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [0.517655] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [0.517677] cpcihp_generic: Generic port I/O CompactPCI Hot Plug Driver version: 0.1 [0.517684] cpcihp_generic: not configured, disabling. [0.517700] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [0.517713] acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed [0.519849] usbcore: registered new interface driver udlfb [0.613289] xen:xen_evtchn: Event-channel device installed [0.613436] pcifront pci-0: Installing PCI frontend [0.613578] pcifront pci-0: Creating PCI Frontend Bus :00 [0.613616] pcifront pci-0: PCI host bridge to bus :00 [0.613624] pci_bus :00: root bus resource [io 0x-0x] [0.613631] pci_bus :00: root bus resource [mem 0x-0x] [0.613638] pci_bus :00: root bus resource [bus 00-ff] [0.616672] pcifront pci-0: pciback not responding!!! [2.613762] clocksource tsc: mask: 0x max_cycles: 0x2e20fd6f2ba, max_idle_ns: 440795302556 ns [2.614275] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [2.614682] Linux agpgart interface v0.103 [2.614731] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). [2.614762] [drm] Initialized drm 1.1.0 20060810 [2.614789] [drm] radeon kernel modesetting enabled. [2.616529] brd: module loaded [2.617844] loop: module loaded [2.620008] pcifront pci-0: pciback not responding!!! [4.621490] pcifront pci-0: pciback not responding!!! [6.621866] pcifront pci-0: pciback not responding!!! [8.622421] pcifront pci-0: pciback not responding!!! etc. etc. etc. Where on 4.0.0 it get: [0.442554] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [0.442583] acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed [0.443293] pcifront pci-0: Allocated pdev @ 0x88001ab23c00 pdev-sh_info @ 0x88001937f000 [0.444885] pcifront pci-0: publishing successful! [0.445302] usbcore: registered new interface driver udlfb [0.445829] xen:xen_evtchn: Event-channel device installed [0.446499] pcifront pci-0: Installing PCI frontend [0.446715] pcifront pci-0: Creating PCI Frontend Bus :00 [0.446951] pcifront pci-0: PCI host bridge to bus :00 [0.446960] pci_bus :00: root bus resource [io 0x-0x] [0.446968] pci_bus :00: root bus resource [mem 0x-0x] [0.446988] pci_bus :00: root bus resource [bus 00-ff] [0.447002] pci_bus :00: scanning bus [0.447140] pci :00:00.0: [13f6:0111] type 00 class 0x040100 [0.447520] pci :00:00.0: reg 0x10: [io 0x7800-0x78ff] [0.449148] pci :00:00.0: supports D1 D2 [0.449791] pci_bus :00: fixups for bus [0.449794] pci_bus :00: bus scan returning with max=00 [0.450604] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [0.451991] Linux agpgart interface v0.103 [0.452160] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180 seconds, margin is 60 seconds). [0.45] [drm] Initialized drm 1.1.0 20060810 [0.452300] [drm] radeon kernel modesetting enabled. [0.462384] pcifront pci-0: claiming resource :00:00.0/0 But i thought the patches that would change pci bus scanning were destined for 4.2 though ... -- Sander ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: Make local_events_need_delivery working with idle VPCU
On Mon, 27 Apr 2015, Julien Grall wrote:
The commit 569fb6c xen/arm: Data abort exception (R/W) mem_access
events makes apply_p2m_changes to call hypercall_preempt_check for any
operation rather than for relinquish.
The function hypercall_preempt_check call local_events_need_delivery
which rely on the current VCPU is not an idle VCPU.
Although, during DOM0 building the current VCPU is an idle one. This
would make Xen crash with the following stack trace:
(XEN) CPU0: Unexpected Trap: Data Abort
[...]
(XEN) Xen call trace:
(XEN)[00256ef4] apply_p2m_changes+0x210/0x1190 (PC)
(XEN)[002506b4] gic_events_need_delivery+0x5c/0x13c (LR)
(XEN)[002580ec] map_mmio_regions+0x64/0x74
(XEN)[00251958] gicv2v_setup+0xf8/0x150
(XEN)[00250964] gicv_setup+0x20/0x30
(XEN)[0024cb3c] arch_domain_create+0x170/0x244
(XEN)[00207df0] domain_create+0x2ac/0x4d8
(XEN)[0028e3d0] start_xen+0xcbc/0xee4
(XEN)[00200540] paging+0x94/0xd8
(XEN)
(XEN)
(XEN)
(XEN) Panic on CPU 0:
(XEN) CPU0: Unexpected Trap: Data Abort
(XEN)
(XEN)
As an idle VCPU can never receive an event, return 0 when the current
VCPU is an idle VCPU in local_events_need_delivery.
Reported-by: Riku Voipio riku.voi...@linaro.org
Signed-off-by: Julien Grall julien.gr...@citrix.com
CC: Tamas K Lengyel tkleng...@sec.in.tum.de
---
This bug has been catched during boot on Mustang. This is because we
have to map large chunk of PCI memory region.
I was able to reproduce the bug on midway by lowering down
preempt_count_limit to 16 in apply_p2m_changes.
Although, I'm not sure this is the right fix for the bug.
---
xen/include/asm-arm/event.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
index 5330dfe..0149d06 100644
--- a/xen/include/asm-arm/event.h
+++ b/xen/include/asm-arm/event.h
@@ -39,7 +39,12 @@ static inline int local_events_need_delivery_nomask(void)
static inline int local_events_need_delivery(void)
{
-if ( !vcpu_event_delivery_is_enabled(current) )
+struct vcpu *v = current;
+
+if ( unlikely(is_idle_vcpu(v)) )
+return 0;
+
+if ( !vcpu_event_delivery_is_enabled(v) )
return 0;
return local_events_need_delivery_nomask();
}
Is it actually considered correct in Xen to call hypercall_preempt_check
and/or local_events_need_delivery on the idle vcpu?
Shouldn't it be avoided and maybe a BUG_ON added here instead?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] xen-unstable + 4.1.0-rc1: Dom0 kernel stalls in early boot
Monday, April 27, 2015, 4:55:06 PM, you wrote: Hi David / Konrad, Today i tried upgrading my dom0 kernel to 4.1-rc1, but it stalls in early boot. Xen console was still reponsive so i dumped some info with the debug keys. Serial log is attached. The kernel boots fine on baremetal and my previous test kernel that was pulled and compiled on 20150423 in the mergewindow boots fine (unfortunately my scripts don't add an git commit version to the kernel name yet. (but the 20150423 version has it's own issue when used as a PV guest kernel with pci passthrough, pci-front can't connect somehow, which i was trying to get at .. when i stumbled upon this one :-) ). -- Sander Hrmm shoot, that even didn't need a full bisection (but i looked over it before sending the mails), tested by reverting this one commit, after that it boots fine: 61f01dd941ba9e06d2bf05994450ecc3d61b6b8b x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue Question is .. why does it boot on baremetal, but not under Xen ? (any ideas before getting this to LKML and x86 maintainers / Linus ?) -- Sander ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 2/3] EFI/early: Add /map to map EfiBootServicesData and Code
Hi Konrad, On 24/04/15 21:47, Konrad Rzeszutek Wilk wrote: To help on certain platforms to run. Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com --- xen/arch/x86/efi/efi-boot.h | 10 -- xen/common/efi/boot.c | 28 +++- xen/common/efi/efi.h| 2 +- xen/common/efi/runtime.c| 1 + 4 files changed, 33 insertions(+), 8 deletions(-) diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h index 3a3b4fe..f6a2ba9 100644 --- a/xen/arch/x86/efi/efi-boot.h +++ b/xen/arch/x86/efi/efi-boot.h @@ -133,7 +133,8 @@ static void __init efi_arch_process_memory_map(EFI_SYSTEM_TABLE *SystemTable, void *map, UINTN map_size, UINTN desc_size, - UINT32 desc_ver) + UINT32 desc_ver, + UINT32 map_bootservices) You also need to modify efi_arch_process_memory_map in arch/arm/efi/efi-boot.h. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: Make local_events_need_delivery working with idle VPCU
Hi Tamas, On 27/04/15 16:40, Tamas K Lengyel wrote: IMHO we should check if op==RELINQUISH || op==MEMACCESS before calling hypercall_preempt_check. That was a change I made - previously it was only called if the op was RELINQUISH and not the other way around. I though about it but it make the code a lot uglier. It would be worst if we decide to preempt more operations in the future... Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: Make local_events_need_delivery working with idle VPCU
On Mon, Apr 27, 2015 at 6:13 PM, Julien Grall julien.gr...@citrix.com wrote: Hi Tamas, On 27/04/15 16:40, Tamas K Lengyel wrote: IMHO we should check if op==RELINQUISH || op==MEMACCESS before calling hypercall_preempt_check. That was a change I made - previously it was only called if the op was RELINQUISH and not the other way around. I though about it but it make the code a lot uglier. It would be worst if we decide to preempt more operations in the future... Regards, -- Julien Grall Ack, that was my original reasoning as well for switching it up. Tamas ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm: Make local_events_need_delivery working with idle VPCU
Hi Stefano,
On 27/04/15 16:36, Stefano Stabellini wrote:
On Mon, 27 Apr 2015, Julien Grall wrote:
The commit 569fb6c xen/arm: Data abort exception (R/W) mem_access
events makes apply_p2m_changes to call hypercall_preempt_check for any
operation rather than for relinquish.
The function hypercall_preempt_check call local_events_need_delivery
which rely on the current VCPU is not an idle VCPU.
Although, during DOM0 building the current VCPU is an idle one. This
would make Xen crash with the following stack trace:
(XEN) CPU0: Unexpected Trap: Data Abort
[...]
(XEN) Xen call trace:
(XEN)[00256ef4] apply_p2m_changes+0x210/0x1190 (PC)
(XEN)[002506b4] gic_events_need_delivery+0x5c/0x13c (LR)
(XEN)[002580ec] map_mmio_regions+0x64/0x74
(XEN)[00251958] gicv2v_setup+0xf8/0x150
(XEN)[00250964] gicv_setup+0x20/0x30
(XEN)[0024cb3c] arch_domain_create+0x170/0x244
(XEN)[00207df0] domain_create+0x2ac/0x4d8
(XEN)[0028e3d0] start_xen+0xcbc/0xee4
(XEN)[00200540] paging+0x94/0xd8
(XEN)
(XEN)
(XEN)
(XEN) Panic on CPU 0:
(XEN) CPU0: Unexpected Trap: Data Abort
(XEN)
(XEN)
As an idle VCPU can never receive an event, return 0 when the current
VCPU is an idle VCPU in local_events_need_delivery.
Reported-by: Riku Voipio riku.voi...@linaro.org
Signed-off-by: Julien Grall julien.gr...@citrix.com
CC: Tamas K Lengyel tkleng...@sec.in.tum.de
---
This bug has been catched during boot on Mustang. This is because we
have to map large chunk of PCI memory region.
I was able to reproduce the bug on midway by lowering down
preempt_count_limit to 16 in apply_p2m_changes.
Although, I'm not sure this is the right fix for the bug.
---
xen/include/asm-arm/event.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/xen/include/asm-arm/event.h b/xen/include/asm-arm/event.h
index 5330dfe..0149d06 100644
--- a/xen/include/asm-arm/event.h
+++ b/xen/include/asm-arm/event.h
@@ -39,7 +39,12 @@ static inline int local_events_need_delivery_nomask(void)
static inline int local_events_need_delivery(void)
{
-if ( !vcpu_event_delivery_is_enabled(current) )
+struct vcpu *v = current;
+
+if ( unlikely(is_idle_vcpu(v)) )
+return 0;
+
+if ( !vcpu_event_delivery_is_enabled(v) )
return 0;
return local_events_need_delivery_nomask();
}
Is it actually considered correct in Xen to call hypercall_preempt_check
and/or local_events_need_delivery on the idle vcpu?
It seems that the x86 version of hypercall_preempt_check is able to cope
with idle VCPU. Although, I'm not sure if there is path where
hypercall_preempt_check can be called on an idle VCPU (cc x86
maintainers for this purpose).
Shouldn't it be avoided and maybe a BUG_ON added here instead?
This patch was the simple way to fix the bug. I have other ideas in mind
which require some rework in apply_p2m_changes.
I'll wait to see what x86 maintainers think.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] ivtv: use arch_phys_wc_add() and require PAT disabled
From: Luis R. Rodriguez mcg...@suse.com
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.
This is a worthy comprmise given that the hardware is
really rare these days, and perhaps only some lost souls
in some third world country are expected to be using this
feature of the device driver.
Cc: Andy Walls awa...@md.metrocast.net
Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Cc: Andy Lutomirski l...@amacapital.net
Cc: Suresh Siddha sbsid...@gmail.com
Cc: Ingo Molnar mi...@elte.hu
Cc: Thomas Gleixner t...@linutronix.de
Cc: Juergen Gross jgr...@suse.com
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: Dave Airlie airl...@redhat.com
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Antonino Daplas adap...@gmail.com
Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
Cc: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Dave Hansen dave.han...@linux.intel.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Stefan Bader stefan.ba...@canonical.com
Cc: Ville Syrjälä syrj...@sci.fi
Cc: Mel Gorman mgor...@suse.de
Cc: Vlastimil Babka vba...@suse.cz
Cc: Borislav Petkov b...@suse.de
Cc: Davidlohr Bueso dbu...@suse.de
Cc: konrad.w...@oracle.com
Cc: ville.syrj...@linux.intel.com
Cc: david.vra...@citrix.com
Cc: jbeul...@suse.com
Cc: toshi.k...@hp.com
Cc: Roger Pau Monné roger@citrix.com
Cc: linux-fb...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: ivtv-de...@ivtvdriver.org
Cc: linux-me...@vger.kernel.org
Cc: xen-de...@lists.xensource.com
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
This v2 moves the PAT bail out error check on to ivtvfb_init()
as per Andy's request. It also removes some comment about TODO
items for PAT.
drivers/media/pci/ivtv/Kconfig | 3 +++
drivers/media/pci/ivtv/ivtvfb.c | 58 -
2 files changed, 26 insertions(+), 35 deletions(-)
diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
index dd6ee57e..b2a7f88 100644
--- a/drivers/media/pci/ivtv/Kconfig
+++ b/drivers/media/pci/ivtv/Kconfig
@@ -57,5 +57,8 @@ config VIDEO_FB_IVTV
This is used in the Hauppauge PVR-350 card. There is a driver
homepage at http://www.ivtvdriver.org.
+ If you have this hardware you will need to boot with PAT disabled
+ on your x86 systems, use the nopat kernel parameter.
+
To compile this driver as a module, choose M here: the
module will be called ivtvfb.
diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..8761e3e 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -44,8 +44,8 @@
#include linux/ivtvfb.h
#include linux/slab.h
-#ifdef CONFIG_MTRR
-#include asm/mtrr.h
+#ifdef CONFIG_X86_64
+#include asm/pat.h
#endif
#include ivtv-driver.h
@@ -155,12 +155,11 @@ struct osd_info {
/* Buffer size */
u32 video_buffer_size;
-#ifdef CONFIG_MTRR
/* video_base rounded down as required by hardware MTRRs */
unsigned long fb_start_aligned_physaddr;
/* video_base rounded up as required by hardware MTRRs */
unsigned long fb_end_aligned_physaddr;
-#endif
+ int wc_cookie;
/* Store the buffer offset */
int set_osd_coords_x;
@@ -1099,6 +1098,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
static int ivtvfb_init_io(struct ivtv *itv)
{
struct osd_info *oi = itv-osd_info;
+ /* Find the largest power of two that maps the whole buffer */
+ int size_shift = 31;
mutex_lock(itv-serialize_lock);
if (ivtv_init_on_first_open(itv)) {
@@ -1132,29 +1133,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_pbase, oi-video_vbase,
oi-video_buffer_size / 1024);
-#ifdef CONFIG_MTRR
- {
- /* Find the largest power of two that maps the whole buffer */
- int size_shift = 31;
-
- while (!(oi-video_buffer_size (1 size_shift))) {
- size_shift--;
- }
- size_shift++;
- oi-fb_start_aligned_physaddr = oi-video_pbase ~((1
size_shift) - 1);
- oi-fb_end_aligned_physaddr = oi-video_pbase +
oi-video_buffer_size;
- oi-fb_end_aligned_physaddr += (1 size_shift) - 1;
- oi-fb_end_aligned_physaddr = ~((1 size_shift) - 1);
- if (mtrr_add(oi-fb_start_aligned_physaddr,
- oi-fb_end_aligned_physaddr -
Re: [Xen-devel] [PATCH] [media] ivtv: use arch_phys_wc_add() and require PAT disabled
On Sat, Apr 25, 2015 at 07:12:05AM -0400, Andy Walls wrote:
Hi Luis,
Sorry for the late reply.
Thank you for the patch! See my comments below:
On Wed, 2015-04-22 at 12:33 -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to help both enable us to later make strong
UC default and in order to phase out direct MTRR access
code port the driver over to arch_phys_wc_add() and
annotate that the device driver requires systems to
boot with PAT disabled, with the nopat kernel parameter.
This is a worthy comprmise given that the hardware is
really rare these days,
I'm OK with the compromise solution. It makes sense.
OK great!
diff --git a/drivers/media/pci/ivtv/ivtvfb.c
b/drivers/media/pci/ivtv/ivtvfb.c
index 9ff1230..552408b 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -1120,6 +1121,7 @@ static int ivtvfb_init_io(struct ivtv *itv)
oi-video_buffer_size = 1704960;
oi-video_pbase = itv-base_addr + IVTV_DECODER_OFFSET +
oi-video_rbase;
+ /* XXX: split this for PAT */
Please remove this comment.
Done.
@@ -1190,6 +1172,13 @@ static int ivtvfb_init_card(struct ivtv *itv)
{
int rc;
+#ifdef CONFIG_X86_64
+ if (WARN(pat_enabled,
This check might be better placed in ivtvfb_init(). This check is going
to have the same result for every PVR-350 card in the system that is
found by ivtvfb.
OK moved!
+ivtv needs PAT disabled, boot with nopat kernel
parameter\n)) {
This needs to read ivtvfb needs [...] to avoid user confusion with the
main ivtv driver module.
OK!
This change is the only one I really care about. Then I can give my
Ack.
OK!
Luis
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] IB/ipath: use arch_phys_wc_add() and require PAT disabled
On Wed, Apr 22, 2015 at 12:26 PM, Luis R. Rodriguez mcg...@do-not-panic.com wrote: From: Luis R. Rodriguez mcg...@suse.com We are burrying direct access to MTRR code support on x86 in order to take advantage of PAT. In the future we also want to make the default behaviour of ioremap_nocache() to use strong UC, use of mtrr_add() on those systems would make write-combining void. In order to help both enable us to later make strong UC default and in order to phase out direct MTRR access code port the driver over to arch_phys_wc_add() and annotate that the device driver requires systems to boot with PAT disabled, with the nopat kernel parameter. This is a worthy compromise given that the ipath device driver powers the old HTX bus cards that only work in AMD systems, while the newer IB/qib device driver powers all PCI-e cards. The ipath device driver is obsolete, hardware hard to find and because of this this its a reasonable compromise to make to require users of ipath to boot with nopat. Hey folks, I realize its being discussed whether or not to remove the driver entirely from the kernel but in the meantime, is this a reasonable compromise ? Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC v1 00/15] Add VT-d Posted-Interrupts support
Wu, Feng feng...@intel.com 04/24/15 7:50 PM Ping.. I'm confused - I said it makes little sense to wait, i.e. go ahead posting v2 without waiting for me. Jan -Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Monday, April 13, 2015 5:13 AM To: Wu, Feng Cc: Tian, Kevin; Zhang, Yang Z; xen-devel@lists.xen.org; k...@xen.org Subject: RE: [RFC v1 00/15] Add VT-d Posted-Interrupts support On 01.04.15 at 15:21, feng...@intel.com wrote: Hi Jan, Any more comments about this series? Thanks a lot! I think it makes little sense to wait for my review before posting v2 with issues addressed which others have pointed out. I just returned from vacation, and would have time to look at v1 next week the earliest (with the week after being occupied by travel). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/7] xenalyze: add to tools/misc
On Mon, Apr 27, David Vrabel wrote: On 27/04/15 14:22, Olaf Hering wrote: This merges xenalyze.hg, changeset 150:24308507be1d into tools/misc to have the tool and public/trace.h in one place. Would this not be better in tools/xentrace/xenalyze ? Yes, I forgot that tools/xentrace/ exists. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 5/7] xenalyze: disable sched_switch_process
On Tue, Apr 28, Wei Liu wrote: On Mon, Apr 27, 2015 at 01:22:14PM +, Olaf Hering wrote: It causes a crash, dump data and return early This doesn't look right. You skip all things below. Yes, to avoid the crash when booted with tbuf_size=-1. When I noticed that I did not have the energy to dig into how the vcpu machinery works. Appearently it cant cope with bootup data. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/arm: gic-v3: Implement correctly the callback send_SGI
Currently, the GICv3 drivers is only able to send an SGI when the cpumask
is provided. Although with the modes SGI_TARGET_OTHERS and SGI_TARGET_SELF,
no cpumask is provided. Any usage of those modes will crash the hypersivor.
Move the rename gicv3_send_sgi to gicv3_send_sgi_list and implement the
different modes:
- SGI_TARGET_OTHERS: Set the Interrupt Routing Mode (bit 40) to 1
(see Table 4 on Section 4.2.6 PRD03-GENC-010745 24.0)
- SGI_TARGET_SELF: Contrawise GICv2, the SGI registers doesn't provide
a specific field. So use gicv3_send_sgi_list and pass the cpumask of
the current CPU
- SGI_TARGET_LIST: Directly call gicv3_send_sgi_list with the given
cpumask
Reported-by: Chen Baozi baoz...@gmail.com
Signed-off-by: Julien Grall julien.gr...@citrix.com
---
xen/arch/arm/gic-v3.c | 25 +++--
xen/include/asm-arm/gic_v3_defs.h | 2 +-
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index b0f498e..e1574d8 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -808,8 +808,7 @@ out:
return tlist;
}
-static void gicv3_send_sgi(enum gic_sgi sgi, enum gic_sgi_mode mode,
- const cpumask_t *cpumask)
+static void gicv3_send_sgi_list(enum gic_sgi sgi, const cpumask_t *cpumask)
{
int cpu = 0;
uint64_t val;
@@ -839,6 +838,28 @@ static void gicv3_send_sgi(enum gic_sgi sgi, enum
gic_sgi_mode mode,
isb();
}
+static void gicv3_send_sgi(enum gic_sgi sgi, enum gic_sgi_mode mode,
+ const cpumask_t *cpumask)
+{
+switch ( mode )
+{
+case SGI_TARGET_OTHERS:
+WRITE_SYSREG(ICH_SGI_TARGET_OTHERS ICH_SGI_IRQMODE_SHIFT |
+ (register_t)sgi ICH_SGI_IRQ_SHIFT,
+ ICC_SGI1R_EL1);
+isb();
+break;
+case SGI_TARGET_SELF:
+gicv3_send_sgi_list(sgi, cpumask_of(smp_processor_id()));
+break;
+case SGI_TARGET_LIST:
+gicv3_send_sgi_list(sgi, cpumask);
+break;
+default:
+BUG();
+}
+}
+
/* Shut down the per-CPU GIC interface */
static void gicv3_disable_interface(void)
{
diff --git a/xen/include/asm-arm/gic_v3_defs.h
b/xen/include/asm-arm/gic_v3_defs.h
index b8a1c2e..556f114 100644
--- a/xen/include/asm-arm/gic_v3_defs.h
+++ b/xen/include/asm-arm/gic_v3_defs.h
@@ -147,7 +147,7 @@
#define ICH_SGI_IRQMODE_SHIFT40
#define ICH_SGI_IRQMODE_MASK 0x1
-#define ICH_SGI_TARGET_OTHERS1
+#define ICH_SGI_TARGET_OTHERS1UL
#define ICH_SGI_TARGET_LIST 0
#define ICH_SGI_IRQ_SHIFT24
#define ICH_SGI_IRQ_MASK 0xf
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing test] 52623: regressions - FAIL
flight 52623 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/52623/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 5 xen-build fail REGR. vs. 50408 build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 50408 build-amd64-pvops 5 kernel-build fail REGR. vs. 50408 build-armhf-pvops 5 kernel-build fail REGR. vs. 50408 build-i386-pvops 5 kernel-build fail REGR. vs. 50408 Tests which did not succeed, but are not blocking: build-armhf-libvirt 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-sedf-pin 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-sedf 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-amd64-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-sedf-pin 1 build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-xl-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-amd 1 build-check(1) blocked n/a test-amd64-amd64-xl-sedf 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-amd64-pair 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-amd64-xl-pvh-intel 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-xl-multivcpu 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1)blocked n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-pair 1 build-check(1) blocked n/a version targeted for testing: xen d41906197d9a89355f43d4359d795b1d0257a53a baseline version: xen 0b754fb3ed6b7b6d0f2e1f7c1877d3c0a7da2168 People who touched revisions under test: Andrew Cooper
