Re: [Xen-devel] [PATCH v5 p2 04/19] xen/arm: Implement hypercall DOMCTL_{, un}bind_pt_pirq
Hi Ian,
On 16/04/2015 16:40, Ian Campbell wrote:
On Thu, 2015-04-16 at 16:20 +0100, Julien Grall wrote:
Concerning XSM, even if ARM is using one hypercall rather than 2, the
resulting check is nearly the same.
XSM PHYSDEVOP_map_pirq:
1) Check if the current domain can add resource to the domain
2) Check if the current domain has permission to add the IRQ
3) Check if the target domain has permission to use the IRQ
XSM DOMCTL_bind_pirq_irq:
1) Check if the current domain can add resource to the domain
2) Check if the current domain has permission to bind the IRQ
3) Check if the target domain has permission to use the IRQ
In order to keep the same XSM checks done by the 2 hypercalls on x86,
call both xsm_map_domain_irq xsm_bind_pt_irq in the ARM implementation.
I think this paragraph makes the previous bit obsolete?
Do you mean: Concerning XSM... until and the 2 paragraphs for XSM
hypercalls?
That's right.
Ok. I will drop it.
@@ -1878,6 +1913,25 @@ int xc_domain_bind_pt_isa_irq(
PT_IRQ_TYPE_ISA, 0, 0, 0, machine_irq));
}
+int xc_domain_bind_pt_spi_irq(
+xc_interface *xch,
+uint32_t domid,
+uint16_t spi)
+{
+/* vSPI == SPI */
I wonder if to avoid API churn later we should accept both machine and
guest IRQ here and rely on the check that htey are the same in the
hypervisor to reject?
Fair enough we can change libxc interface if we want, but avoiding a
little churn later on seems reasonable and it makes it a better fit with
the existing interfaces.
what about the following prototype:
int xc_domain_bind_pt_spi_irq(
xc_interface *xch,
uint32_t domid,
uint16_t spi,
uint16_t vspi)
I didn't reuse the current name i.e (machine_irq) because I find the
name confusing.
Sure. Although you hit machine_irq again at the next level in the stack
so I think it's rather moot.
[..]
+case XEN_DOMCTL_unbind_pt_irq:
+{
+int rc;
+xen_domctl_bind_pt_irq_t *bind = domctl-u.bind_pt_irq;
+uint32_t irq = bind-u.spi.spi;
+uint32_t virq = bind-machine_irq;
+
+/* We only support PT_IRQ_TYPE_SPI */
+if ( bind-irq_type != PT_IRQ_TYPE_SPI )
+return -EOPNOTSUPP;
+
+/* For now map the interrupt 1:1 */
+if ( irq != virq )
+return -EINVAL;
The x86 version doesn't appear to consider irq_type or irq, only virq
(from -machine_irq). That seems to be logical to me (if a little
underdocumented) and I think we should be consistent.
On x86, the parameters are used later in pt_create_bind which take the
hypercall data in parameter.
Ah yes, (although you mean pt_irq_destroy_bind I think?)
No I mean pt_irq_create_bind. The function makes usage of machine_irq
and irq_type. Although, there is no clear switch case, just an if in the
code.
The both check are required in order to avoid future issue if we
introduce new type and when we will support virq != irq.
Shouldn't they be in pt_irq_destroy_bind then?
I'm not following you. pt_irq_destroy_bind is an x86 specific function.
The check virq != irq is done in both DOMCTL_{,un}bind_irq on ARM even
though the one in unbind is not necessary useful.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 11/11] p2m/ept: enable PML in p2m-ept for log-dirty
On 17.04.15 at 04:40, kai.hu...@linux.intel.com wrote: On 04/16/2015 11:54 PM, Jan Beulich wrote: On 15.04.15 at 09:03, kai.hu...@linux.intel.com wrote: This patch firstly enables EPT A/D bits if PML is used, as PML depends on EPT A/D bits to work. A bit is set for all present leaf p2m types, D bit is set for all writable types, except log-dirty type. I think the tying of leaf to the A bit part of the description became stale, as you're now also doing this for non-leaf ones. You are right. How about just A bit is set for all present p2m types, ...? Almost - adding leaf to the D bit part would still be desirable for clarity. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 11/19] xen: arm: Annotate handlers for PCTR_EL2.Tx
Hi Ian,
On 16/04/2015 17:53, Ian Campbell wrote:
On Mon, 2015-04-06 at 13:18 +0200, Julien Grall wrote:
Hi Ian,
Subject: s/PCTR/CPTR/
On 31/03/2015 12:07, Ian Campbell wrote:
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9cdbda8..ba120e5 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1704,6 +1704,11 @@ static void do_cp15_32(struct cpu_user_regs *regs,
* ARMv7 (DDI 0406C.b): B1.14.3
* ARMv8 (DDI 0487A.d): D1-1501 Table D1-43
*
+ * CPTR_EL2.T{0..9,12..13}
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.12
+ * ARMv8 (DDI 0487A.d): N/A
I would also update the comment on top of WRITE_SYSREG(..., CPTR_EL2) to
make clear that CP0..CP9 CP12..CP13 are only traps for ARMv7.
On v8 the corresponding bits are RES1, i.e. they always trap. I wrote:
Somehow I read RES0 in the spec.
/* Trap all coprocessor registers (0-13) except cp10 and
* cp11 for VFP.
*
* /!\ All coprocessors except cp10 and cp11 cannot be used in Xen.
*
* On ARM64 the TCPx bits which we set here (0..9,12,13) are all
* RES1, i.e. they would trap whether we did this write or not.
*/
I'm fine with this change.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] VTd/dmar: Tweak how the DMAR table is clobbered
On 16.04.15 at 18:44, kevin.t...@intel.com wrote: From: Andrew Cooper [mailto:andrew.coop...@citrix.com] Sent: Tuesday, April 14, 2015 5:09 PM On 14/04/15 08:50, Jan Beulich wrote: Unless Kevin or Yang object, I'd therefore suggest reverting the change. Once we determined why VT-d needs what AMD Vi doesn't need, and once we settled on the risk of name collision (perhaps using an underscore prefixed name would further reduce this risk), we could then do this another way (zap the table from XSDT/RSDT instead?), or leave it as it was without the change. It is my hope that this can be resolved in the longterm without any modification to the acpi tables. Currently, it is not possible to dump the ACPI tables from dom0 without knowing how to hexedit the XMAR table back into life. This is an impediment to debugging. However, I still believe that the current change is a positive improvement over what happened previously. I'm OK with this patch itself as it does improve current situation a bit, though we do need to figure out the mysterious reason why AMD doesn't require same hack. My gut-feeling is that hypervisor has to do something so an unmodified dom0 iommu driver is not activated to use iommu, unless the dom0 iommu driver has some awareness to give up proactively. There should be no such thing like an unmodified Dom0 IOMMU driver, as Dom0 can't be HVM (and if it was HVM, it would necessarily have to see other than the host's ACPI tables). My impression is that this was solely added as a workaround by someone too lazy to adjust the Dom0 IOMMU driver back when the functionality was added. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 06/11] vmx: add help functions to support PML
On 04/17/2015 02:23 PM, Jan Beulich wrote:
On 17.04.15 at 05:10, kai.hu...@linux.intel.com wrote:
On 04/16/2015 11:42 PM, Jan Beulich wrote:
On 15.04.15 at 09:03, kai.hu...@linux.intel.com wrote:
+void vmx_vcpu_flush_pml_buffer(struct vcpu *v)
+{
+uint64_t *pml_buf;
+unsigned long pml_idx;
+
+ASSERT(vmx_vcpu_pml_enabled(v));
+
+vmx_vmcs_enter(v);
+
+__vmread(GUEST_PML_INDEX, pml_idx);
Don't you require the vCPU to be non-running or current when you
get here? If so, perhaps add a respective ASSERT()?
Yes an ASSERT would be better.
v-pause_count will be increased if vcpu is kicked out by domain_pause
explicitly, but looks the same thing won't be done if vcpu is kicked out
by PML buffer full VMEXIT. So should the ASSERT be done like below?
ASSERT(atomic_read(v-pause_count) || (v == current));
For one I'd reverse the two parts. And then I think pause count
being non-zero is not a sufficient condition - if a non-synchronous
pause was issued against the vCPU it may still be running. I'd
suggest !vcpu_runnable(v) !v-is_running, possibly with the
pause count check instead of the runnable one if the only
permitted case where v != current requires the vCPU to be
paused.
The vmx_vcpu_flush_pml_buffer is only supposed to be called in below cases:
- When PML full VMEXIT happens
- In paging_log_dirty_op hap_track_dirty_vram, before reporting
dirty pages to userspace.
- In vmx_vcpu_disable_pml, called from vmx_vcpu_destroy, or when
log-dirty mode is disabled.
In the latter two cases, domain_pause is guaranteed to be called before
vmx_vcpu_flush_pml_buffer is called, therefore looks there's no
possibility of non-synchronous pause of the vcpu.
Or are you suggesting we should suppose this function can be called from
any caller, and meanwhile is able to act reasonably?
+/*
+ * Need to change type from log-dirty to normal memory for logged GFN.
+ * hap_track_dirty_vram depends on it to work. And we really only need
+ * to mark GFNs which hve been successfully changed from log-dirty to
+ * normal memory to be dirty.
+ */
+if ( !p2m_change_type_one(v-domain, gfn, p2m_ram_logdirty,
+p2m_ram_rw) )
Indentation.
To be where exactly? Sorry I didn't find an example to refer in such case.
p2m_ram_rw should align with the v in v-domain.
Understood. Will do.
Thanks,
-Kai
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 10/11] log-dirty: refine common code to support PML
On 04/17/2015 02:28 PM, Jan Beulich wrote:
On 17.04.15 at 04:46, kai.hu...@linux.intel.com wrote:
On 04/16/2015 11:51 PM, Jan Beulich wrote:
On 15.04.15 at 09:03, kai.hu...@linux.intel.com wrote:
@@ -190,9 +196,15 @@ static int hap_enable_log_dirty(struct domain *d, bool_t
log_global)
d-arch.paging.mode |= PG_log_dirty;
paging_unlock(d);
+/* enable hardware-assisted log-dirty if it is supported */
+p2m_enable_hardware_log_dirty(d);
I don't see that you would anywhere avoid setting up software
log-dirty handling - is that on purpose? If so, is there really a
win from adding PML?
if ( log_global )
{
-/* set l1e entries of P2M table to be read-only. */
+/*
+ * switch to log dirty mode, either by setting l1e entries of P2M table
+ * to be read-only, or via hardware-assisted log-dirty.
+ */
p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
Or did I miss you changing the behavior of this anywhere (as the
changed comment suggests)?
Both of your comments are done in patch 11.
Partly - the new behavior indeed gets added there, but the misconfig
VM exits still seem to be a necessary part of the logic, so the question
stands: Is there really a win from adding PML? Or wait, I think now I
recall - the benefit comes from avoiding the protection violation exits,
not the misconfig ones. Sorry for the noise then.
Yes PML is targeted to significantly reduce number of EPT violation
caused by write protection of guest memory, and thus reduce hypervisor
overhead of log-dirty mechanism.
Thanks,
-Kai
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/4] x86/MSI-X: access MSI-X table only after having enabled MSI-X
On 16.04.15 at 20:21, konrad.w...@oracle.com wrote: What kernel are you using? Or better yet - what branch/tree could one find it at? As always, I'm personally using my own kernel, not in any branch/tree. But for all purposes here, our Kernel-of-the-Day should be good enough, i.e. the stuff under http://download.opensuse.org/repositories/Kernel:/HEAD/standard/. But anyway I hope to get you a replacement patch later today for the one I had previously handed you with some debugging left in. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 06/11] vmx: add help functions to support PML
On 04/17/2015 02:58 PM, Jan Beulich wrote:
On 17.04.15 at 08:51, kai.hu...@linux.intel.com wrote:
On 04/17/2015 02:23 PM, Jan Beulich wrote:
On 17.04.15 at 05:10, kai.hu...@linux.intel.com wrote:
On 04/16/2015 11:42 PM, Jan Beulich wrote:
On 15.04.15 at 09:03, kai.hu...@linux.intel.com wrote:
+void vmx_vcpu_flush_pml_buffer(struct vcpu *v)
+{
+uint64_t *pml_buf;
+unsigned long pml_idx;
+
+ASSERT(vmx_vcpu_pml_enabled(v));
+
+vmx_vmcs_enter(v);
+
+__vmread(GUEST_PML_INDEX, pml_idx);
Don't you require the vCPU to be non-running or current when you
get here? If so, perhaps add a respective ASSERT()?
Yes an ASSERT would be better.
v-pause_count will be increased if vcpu is kicked out by domain_pause
explicitly, but looks the same thing won't be done if vcpu is kicked out
by PML buffer full VMEXIT. So should the ASSERT be done like below?
ASSERT(atomic_read(v-pause_count) || (v == current));
For one I'd reverse the two parts. And then I think pause count
being non-zero is not a sufficient condition - if a non-synchronous
pause was issued against the vCPU it may still be running. I'd
suggest !vcpu_runnable(v) !v-is_running, possibly with the
pause count check instead of the runnable one if the only
permitted case where v != current requires the vCPU to be
paused.
The vmx_vcpu_flush_pml_buffer is only supposed to be called in below cases:
- When PML full VMEXIT happens
- In paging_log_dirty_op hap_track_dirty_vram, before reporting
dirty pages to userspace.
- In vmx_vcpu_disable_pml, called from vmx_vcpu_destroy, or when
log-dirty mode is disabled.
In the latter two cases, domain_pause is guaranteed to be called before
vmx_vcpu_flush_pml_buffer is called, therefore looks there's no
possibility of non-synchronous pause of the vcpu.
Or are you suggesting we should suppose this function can be called from
any caller, and meanwhile is able to act reasonably?
No. All I'm saying is in order to protect against eventual undue
future callers, it should assert that its preconditions are met. I.e.
if the vCPU is expected to be paused, check that the pause
count in non-zero _and_ that the pause actually took effect.
I see. I will do as you suggested:
ASSERT((v == current) || (!vcpu_runnable(v) !v-is_running));
And v != current should be the only case requires the vcpu to be paused.
Thanks,
-Kai
Jan
___
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
Re: [Xen-devel] [PATCH 02/19] xen: arm: add missing break
Hi Ian,
On 16/04/2015 17:08, Ian Campbell wrote:
On Thu, 2015-04-02 at 16:09 +0100, Julien Grall wrote:
Hi Ian,
On 31/03/2015 11:07, Ian Campbell wrote:
Signed-off-by: Ian Campbell ian.campb...@citrix.com
xen: arm: Fix handling of ICC_{SGI1R,SGI0R,ASGI1R}_EL1
Having injected an undefined instruction we don't want to also advance
pc. So return.
THe ICC_{SGI0R,ASGI1R}_EL1 case was previously missing a break, so
would have fallen through to the default case and injected a second
undef, corrupting SPSR_EL1 and ELR_EL1 for the guest.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Reviewed-by: Julien Grall julien.gr...@citrix.com
Thanks. I seem to have two commit messages for this one, I think from a
botched patch squash.
I've dropped the add missing break commit message, since I've actually
written about it in the final paragraph. I've kept your R-by regardless,
which I hope is ok.
I'm fine with the change.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 10/11] log-dirty: refine common code to support PML
On 17.04.15 at 04:46, kai.hu...@linux.intel.com wrote:
On 04/16/2015 11:51 PM, Jan Beulich wrote:
On 15.04.15 at 09:03, kai.hu...@linux.intel.com wrote:
@@ -190,9 +196,15 @@ static int hap_enable_log_dirty(struct domain *d,
bool_t log_global)
d-arch.paging.mode |= PG_log_dirty;
paging_unlock(d);
+/* enable hardware-assisted log-dirty if it is supported */
+p2m_enable_hardware_log_dirty(d);
I don't see that you would anywhere avoid setting up software
log-dirty handling - is that on purpose? If so, is there really a
win from adding PML?
if ( log_global )
{
-/* set l1e entries of P2M table to be read-only. */
+/*
+ * switch to log dirty mode, either by setting l1e entries of P2M
table
+ * to be read-only, or via hardware-assisted log-dirty.
+ */
p2m_change_entry_type_global(d, p2m_ram_rw, p2m_ram_logdirty);
Or did I miss you changing the behavior of this anywhere (as the
changed comment suggests)?
Both of your comments are done in patch 11.
Partly - the new behavior indeed gets added there, but the misconfig
VM exits still seem to be a necessary part of the logic, so the question
stands: Is there really a win from adding PML? Or wait, I think now I
recall - the benefit comes from avoiding the protection violation exits,
not the misconfig ones. Sorry for the noise then.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 07/19] xen: arm: Annotate trap handler for HCR_EL2.{TWI, TWE, TSC}
Hi Ian,
On 16/04/2015 17:34, Ian Campbell wrote:
On Fri, 2015-04-03 at 15:05 +0200, Julien Grall wrote:
Hi Ian,
On 31/03/2015 12:07, Ian Campbell wrote:
Reference the bit which enables the trap and the section/page which
describes what that bit enables.
These ones are pretty trivial, included for completeness.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c9c98d3..70e1b4d 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2083,6 +2083,12 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs
*regs)
switch (hsr.ec) {
case HSR_EC_WFI_WFE:
+/*
+ * HSR_EL2.TWI, HSR_EL2.TWE
Typo: I should be HCR not HSR.
Gah, at least I was consistent pretty much throughout!
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.9
+ * ARMv8 (DDI 0487A.d): D1-1505 Table D1-51
It's a bit confusing that you are using section for ARMv7 and page for
ARMv8.
I wanted to use section numbers everywhere, since in the ARMv7 ARM they
are nice and precise. But the ARMv8 ARM doesn't really use them in the
same way.
In this case D1-1505 is in section D1.15.3 which starts on page D1-1495
and covers the whole of HCR_EL2, which isn't a useful reference since it
would be the same for 2/3 of the patches (AKA bits in HCR_EL2) in this
series. D1-1505 isn't perfect since there is other stuff on that page,
but it's as close I can get.
Right, it's better to have a specific reference. I was surprised to see
that ARMv8 didn't have number for small section.
Bit in the ARMv7 ARM B1.14.9 is exactly about these two traps.
Part of my goal here is to make it so that people (especially me) don't
spend half their life searching for the doc associated with a given
HCR_EL2 trap bit.
Thank you for the explanation. When I reviewed the series, it was very
handy to have a reference to the docs.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 11/11] p2m/ept: enable PML in p2m-ept for log-dirty
On 04/17/2015 02:28 PM, Jan Beulich wrote: On 17.04.15 at 04:40, kai.hu...@linux.intel.com wrote: On 04/16/2015 11:54 PM, Jan Beulich wrote: On 15.04.15 at 09:03, kai.hu...@linux.intel.com wrote: This patch firstly enables EPT A/D bits if PML is used, as PML depends on EPT A/D bits to work. A bit is set for all present leaf p2m types, D bit is set for all writable types, except log-dirty type. I think the tying of leaf to the A bit part of the description became stale, as you're now also doing this for non-leaf ones. You are right. How about just A bit is set for all present p2m types, ...? Almost - adding leaf to the D bit part would still be desirable for clarity. That will be more accurate. Thanks for suggestion. Is below good to you? A bit is set for all present p2m types in middle and leaf EPT entries, and D bit is set for all writable types in the leaf EPT entry, except log-dirty type. And I will update comments at the beginning of ept_p2m_type_to_flags accordingly. Thanks, -Kai Jan ___ 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
Re: [Xen-devel] [v2 06/11] vmx: add help functions to support PML
On 17.04.15 at 08:51, kai.hu...@linux.intel.com wrote:
On 04/17/2015 02:23 PM, Jan Beulich wrote:
On 17.04.15 at 05:10, kai.hu...@linux.intel.com wrote:
On 04/16/2015 11:42 PM, Jan Beulich wrote:
On 15.04.15 at 09:03, kai.hu...@linux.intel.com wrote:
+void vmx_vcpu_flush_pml_buffer(struct vcpu *v)
+{
+uint64_t *pml_buf;
+unsigned long pml_idx;
+
+ASSERT(vmx_vcpu_pml_enabled(v));
+
+vmx_vmcs_enter(v);
+
+__vmread(GUEST_PML_INDEX, pml_idx);
Don't you require the vCPU to be non-running or current when you
get here? If so, perhaps add a respective ASSERT()?
Yes an ASSERT would be better.
v-pause_count will be increased if vcpu is kicked out by domain_pause
explicitly, but looks the same thing won't be done if vcpu is kicked out
by PML buffer full VMEXIT. So should the ASSERT be done like below?
ASSERT(atomic_read(v-pause_count) || (v == current));
For one I'd reverse the two parts. And then I think pause count
being non-zero is not a sufficient condition - if a non-synchronous
pause was issued against the vCPU it may still be running. I'd
suggest !vcpu_runnable(v) !v-is_running, possibly with the
pause count check instead of the runnable one if the only
permitted case where v != current requires the vCPU to be
paused.
The vmx_vcpu_flush_pml_buffer is only supposed to be called in below cases:
- When PML full VMEXIT happens
- In paging_log_dirty_op hap_track_dirty_vram, before reporting
dirty pages to userspace.
- In vmx_vcpu_disable_pml, called from vmx_vcpu_destroy, or when
log-dirty mode is disabled.
In the latter two cases, domain_pause is guaranteed to be called before
vmx_vcpu_flush_pml_buffer is called, therefore looks there's no
possibility of non-synchronous pause of the vcpu.
Or are you suggesting we should suppose this function can be called from
any caller, and meanwhile is able to act reasonably?
No. All I'm saying is in order to protect against eventual undue
future callers, it should assert that its preconditions are met. I.e.
if the vCPU is expected to be paused, check that the pause
count in non-zero _and_ that the pause actually took effect.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 06/11] vmx: add help functions to support PML
On 17.04.15 at 05:10, kai.hu...@linux.intel.com wrote:
On 04/16/2015 11:42 PM, Jan Beulich wrote:
On 15.04.15 at 09:03, kai.hu...@linux.intel.com wrote:
+void vmx_vcpu_flush_pml_buffer(struct vcpu *v)
+{
+uint64_t *pml_buf;
+unsigned long pml_idx;
+
+ASSERT(vmx_vcpu_pml_enabled(v));
+
+vmx_vmcs_enter(v);
+
+__vmread(GUEST_PML_INDEX, pml_idx);
Don't you require the vCPU to be non-running or current when you
get here? If so, perhaps add a respective ASSERT()?
Yes an ASSERT would be better.
v-pause_count will be increased if vcpu is kicked out by domain_pause
explicitly, but looks the same thing won't be done if vcpu is kicked out
by PML buffer full VMEXIT. So should the ASSERT be done like below?
ASSERT(atomic_read(v-pause_count) || (v == current));
For one I'd reverse the two parts. And then I think pause count
being non-zero is not a sufficient condition - if a non-synchronous
pause was issued against the vCPU it may still be running. I'd
suggest !vcpu_runnable(v) !v-is_running, possibly with the
pause count check instead of the runnable one if the only
permitted case where v != current requires the vCPU to be
paused.
+/*
+ * Need to change type from log-dirty to normal memory for logged
GFN.
+ * hap_track_dirty_vram depends on it to work. And we really only
need
+ * to mark GFNs which hve been successfully changed from log-dirty
to
+ * normal memory to be dirty.
+ */
+if ( !p2m_change_type_one(v-domain, gfn, p2m_ram_logdirty,
+p2m_ram_rw) )
Indentation.
To be where exactly? Sorry I didn't find an example to refer in such case.
p2m_ram_rw should align with the v in v-domain.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 06/11] vmx: add help functions to support PML
On 17.04.15 at 09:23, kai.hu...@linux.intel.com wrote:
On 04/17/2015 02:58 PM, Jan Beulich wrote:
On 17.04.15 at 08:51, kai.hu...@linux.intel.com wrote:
On 04/17/2015 02:23 PM, Jan Beulich wrote:
On 17.04.15 at 05:10, kai.hu...@linux.intel.com wrote:
On 04/16/2015 11:42 PM, Jan Beulich wrote:
On 15.04.15 at 09:03, kai.hu...@linux.intel.com wrote:
+void vmx_vcpu_flush_pml_buffer(struct vcpu *v)
+{
+uint64_t *pml_buf;
+unsigned long pml_idx;
+
+ASSERT(vmx_vcpu_pml_enabled(v));
+
+vmx_vmcs_enter(v);
+
+__vmread(GUEST_PML_INDEX, pml_idx);
Don't you require the vCPU to be non-running or current when you
get here? If so, perhaps add a respective ASSERT()?
Yes an ASSERT would be better.
v-pause_count will be increased if vcpu is kicked out by domain_pause
explicitly, but looks the same thing won't be done if vcpu is kicked out
by PML buffer full VMEXIT. So should the ASSERT be done like below?
ASSERT(atomic_read(v-pause_count) || (v == current));
For one I'd reverse the two parts. And then I think pause count
being non-zero is not a sufficient condition - if a non-synchronous
pause was issued against the vCPU it may still be running. I'd
suggest !vcpu_runnable(v) !v-is_running, possibly with the
pause count check instead of the runnable one if the only
permitted case where v != current requires the vCPU to be
paused.
The vmx_vcpu_flush_pml_buffer is only supposed to be called in below cases:
- When PML full VMEXIT happens
- In paging_log_dirty_op hap_track_dirty_vram, before reporting
dirty pages to userspace.
- In vmx_vcpu_disable_pml, called from vmx_vcpu_destroy, or when
log-dirty mode is disabled.
In the latter two cases, domain_pause is guaranteed to be called before
vmx_vcpu_flush_pml_buffer is called, therefore looks there's no
possibility of non-synchronous pause of the vcpu.
Or are you suggesting we should suppose this function can be called from
any caller, and meanwhile is able to act reasonably?
No. All I'm saying is in order to protect against eventual undue
future callers, it should assert that its preconditions are met. I.e.
if the vCPU is expected to be paused, check that the pause
count in non-zero _and_ that the pause actually took effect.
I see. I will do as you suggested:
ASSERT((v == current) || (!vcpu_runnable(v) !v-is_running));
And v != current should be the only case requires the vcpu to be paused.
But if you require (or at least expect) the vCPU to be paused, this
isn't what I suggested. Afaict
ASSERT((v == current) || (!v-is_running atomic_read(v-pause_count)));
would then be the right check (and, while not be a full guarantee that
things wouldn't change behind your back, would at least increase
chances that the vCPU's runnable state won't change, as the vCPU
could have been non-runnable for reasons other than having been
paused).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [v1] x86/cpuidle: get accurate C0 value with xenpm tool
-Original Message- From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Thursday, April 16, 2015 4:49 PM To: Han, Huaitong Cc: xen-devel@lists.xen.org Subject: Re: [v1] x86/cpuidle: get accurate C0 value with xenpm tool On 16.04.15 at 08:03, huaitong@intel.com wrote: When checking the ACPI funciton of C-status, after 100 seconds sleep, the sampling value of C0 C-status from the xenpm tool decreases. Because C0=NOW()-C1-C2-C3-C4, when NOW() value is during idle time, NOW() value is bigger than last C-status update time, and C0 value is also bigger than ture value. if margin of the second error cannot make up for margin of the first error, the value of C0 would decrease. How big of an error are we taking about here? And does that error increase over time? The max error value is about 1s that depends on max C-status time. Error does not increase over time, because C1,C2,C3 and C4 is accurate, and NOW() is random. @@ -1214,6 +1215,10 @@ int pmstat_get_cx_stat(uint32_t cpuid, struct pm_cx_stat *stat) idle_res += res[i]; } +spin_lock_irq(power-stat_lock); +last_cx_update_time = tick_to_ns(power-last_cx_update_tick); +spin_unlock_irq(power-stat_lock); I don't think you need the locking here (all you need is make sure you read and write the field atomically). And in no case do you need it around more than the reading of power-last_cx_update_tick. (Results are anyway not guaranteed to be fully consistent due to the lock being acquired and dropped in each of the loop iterations right above your change. I.e. a better change [if you already care for accurate results] would be to split the loop in two, acquire the lock before the first of them and latch the last update tick between both loops, before dropping the lock again.) I will modify in V2 edition. Thanks. @@ -1243,7 +1248,7 @@ int pmstat_get_cx_stat(uint32_t cpuid, struct pm_cx_stat *stat) } usage[0] = idle_usage; -res[0] = NOW() - idle_res; +res[0] = last_cx_update_time - idle_res; I think this should remain to be NOW() if cpuid == smp_processor_id() or when pm_idle_save == NULL (in that latter case last_cx_update_time would still be zero when getting here). I will modify in V2 edition. Thanks. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Archiving Xen on ARM and PVOPS subprojects
On Thu, 2015-04-16 at 14:25 -0400, Konrad Rzeszutek Wilk wrote: On Thu, Apr 16, 2015 at 12:37:15PM +0100, Ian Campbell wrote: On Wed, 2015-04-15 at 17:23 +0100, Lars Kurth wrote: According to http://xenproject.org/governance.html we would need to perform an archivation review. In this case, the situation is quite clear IMHO and I believe that we do not need to make an extensive case, besides the one above. So my proposal would be to just have a committer vote on these. I would be happy if committers and maintainers listed in a), b) and http://xenproject.org/developers/teams/hypervisor.html were to just reply with the usual +1, 0, -1 to this thread. +1 to exorcising Xen ARM PV, it's just confusing and dead. My personal inclination is also that the pvops project is done and I would vote +1, but I don't really think it is up to me. If formally I am needed to vote to get things done then I would vote with the majority side of David, Konrad Boris (who I believe are the 3 current Linux maintainers). +1 for pvops and +1 for Xen ARM PV With Konrad and David's +1 for pvops my vote is no longer in doubt: +1. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/8] raisin: Use fakeroot for mkdeb so we can build the package as non-root
On Fri, 17 Apr 2015, Ian Campbell wrote:
On Thu, 2015-04-16 at 17:19 +0100, George Dunlap wrote:
Signed-off-by: George Dunlap george.dun...@eu.citrix.com
AIUI raisin does build dependency handling/tracking. If so then fakeroot
ought to be added to it I think?
Good point! Please add fakeroot as Debian specific dependency for every
component, like rpm-build for Fedora.
---
CC: Stefano Stabellini stefano.stabell...@citrix.com
Does CC below a CC work? Interesting.
---
lib/common-functions.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/common-functions.sh b/lib/common-functions.sh
index 06c894a..373d6fb 100644
--- a/lib/common-functions.sh
+++ b/lib/common-functions.sh
@@ -242,7 +242,7 @@ function for_each_component () {
function build_package() {
if [[ $DISTRO = Debian ]]
then
-./scripts/mkdeb $1
+fakeroot bash ./scripts/mkdeb $1
elif [[ $DISTRO = Fedora ]]
then
./scripts/mkrpm $1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST] cri-args-hostlists: No longer export $OSSTEST_CONFIG
All sites now have a suitable
$HOME/.xen-osstest/cri-args-hostslists.settings in place which does
this.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
To be applied once the following commit passes Cambridge push gate, is
merged into the master instance and passes the push gate there.
commit 5926203d0851792e4f6ce26df5a48ba5c79456e1
Author: Ian Campbell ian.campb...@citrix.com
Date: Wed Apr 15 11:04:53 2015 +0100
cri-args-hostslists: allow instance specific settings
In particular this new $HOME/.xen-osstest/cri-args-hostslists.settings
can contain things like export
OSSTEST_CONFIG=production-config-cambridge to tailor things for a
particular instance of osstest running in production mode.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
---
cri-args-hostlists | 1 -
1 file changed, 1 deletion(-)
diff --git a/cri-args-hostlists b/cri-args-hostlists
index bf847f8..6aa6927 100644
--- a/cri-args-hostlists
+++ b/cri-args-hostlists
@@ -19,7 +19,6 @@
if [ -e $HOME/.xen-osstest/cri-args-hostslists.settings ]; then
source $HOME/.xen-osstest/cri-args-hostslists.settings
fi
-export OSSTEST_CONFIG=${OSSTEST_CONFIG:-production-config}
check_stop_core () {
if [ x$OSSTEST_IGNORE_STOP = xy ]; then return; fi
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Is it ok to routing periperal irq to any Domain0's vCPU on Xen ARM 4.5.x?
On Fri, 2015-04-17 at 11:36 +0900, 신정섭 wrote:
I'm studying periperal irq routing to Domain0's vCPU
What do you mean by peripheral irq routing? Do you mean supporting the
guest writing to GICD_ITARGER to cause an interrupt to be injected to a
specific vcpu?
I thought that was supposed to work, Stefano?
I'm testing on Arndale Broad and Domain 0 has 2 vCPU.
So Xen can select vcpu0 or vcpu1 to inject periperal irq.
I tested periperal routing on Xen 4.4.1 and it works well.
But I tested periperal routing on Xen 4.5.0 but irq dosen't works
well.
So I tested very simple periperal routing code like this.
'flag' is grobal variable.
* In do_IRQ function on Xen 4.4.1
-
- from
if ( desc-status IRQ_GUEST )
{
struct domain *d = action-dev_id;
desc-handler-end(desc);
desc-status = IRQ_INPROGRESS;
desc-arch.eoi_cpu = smp_processor_id();
/* XXX: inject irq into all guest vcpus */
vgic_vcpu_inject_irq(d-vcpu[0], irq, 0);
goto out_no_end;
}
-to if ( desc-status IRQ_GUEST ) {
struct domain *d = action-dev_id;
desc-handler-end(desc);
desc-status = IRQ_INPROGRESS;
desc-arch.eoi_cpu = smp_processor_id();
/* XXX: inject irq into all guest vcpus */
vgic_vcpu_inject_irq(d-vcpu[++flag % 2], irq, 0);
goto out_no_end;
}
-
* In vgic_vcpu_inject_spi function on Xen 4.5.0
-
-from
void vgic_vcpu_inject_spi(struct domain *d, unsigned int irq)
{
struct vcpu *v;
/* the IRQ needs to be an SPI */
ASSERT(irq = 32 irq = gic_number_lines());
v = vgic_get_target_vcpu(d-vcpu[0], irq);
vgic_vcpu_inject_irq(v, irq);
}
-tovoid vgic_vcpu_inject_spi(struct domain *d, unsigned int irq)
{
struct vcpu *v;
/* the IRQ needs to be an SPI */
ASSERT(irq = 32 irq = gic_number_lines());
vgic_vcpu_inject_irq(d-vcpu[++flag % 2], irq);
}
-
so periperal irq injected to Domain0's vCPU0 or vCPU1.
on Xen 4.4.1 it work well and i can confirm
periperal irq routed vcpu0 or vcpu1 by using cat /proc/interrupts
command.
* cat /proc/interrupts command on Xen 4.4.1
--
CPU0 CPU1
27: 8690 8558 GIC 27 arch_timer
31: 34 1 GIC 31 events
65: 0 0 GIC 65 1080.mdma
66: 0 0 GIC 66 121a.pdma
67: 0 0 GIC 67 121b.pdma
74: 0 0 GIC 74 101d.watchdog
75: 0 0 GIC 75 s3c2410-rtc alarm
76: 0 0 GIC 76 s3c2410-rtc tick
77: 0 0 GIC 77 1340.pinctrl
78: 0 0 GIC 78 1140.pinctrl
79: 0 0 GIC 79 386.pinctrl
82: 0 0 GIC 82 10d1.pinctrl
88: 229 233 GIC 88 12c6.i2c
90: 0 0 GIC 90 12c8.i2c
91: 0 0 GIC 91 12c9.i2c
96: 0 0 GIC 96 12ce.i2c
97: 0 0 GIC 97 1006.tmu
103: 257 246 GIC 103 ehci_hcd:usb3, ohci_hcd:usb4
104: 0 0 GIC 104 xhci-hcd:usb1
107: 710 710 GIC 107 dw-mci
109: 9602 9610 GIC 109 dw-mci
156: 0 0 GIC 156 11c1.mdma
160: 0 0 xen-dyn-event xenbus
183: 1 0 exynos_wkup_irq_chip 2 s5m8767
184: 33 0 xen-percpu-virq hvc_console
185: 0 0 s5m8767 12 rtc-alarm0
186: 0 0 exynos_wkup_irq_chip 4 SW-TACT2
187: 0 0 exynos_wkup_irq_chip 5 SW-TACT3
188: 0 0 exynos_wkup_irq_chip 6 SW-TACT4
189: 0 0 exynos_wkup_irq_chip 7 SW-TACT5
190: 0 0 exynos_wkup_irq_chip 0 SW-TACT6
191: 0 0 exynos_wkup_irq_chip 1 SW-TACT7
IPI0: 0 0 CPU wakeup interrupts
IPI1: 0 0 Timer broadcast interrupts
IPI2: 6660 6920 Rescheduling interrupts
IPI3: 0 0 Function call interrupts
IPI4: 9 3 Single function call interrupts
IPI5: 0 0 CPU stop interrupts
IPI6: 0 0 IRQ work interrupts
IPI7: 0 0 completion interrupts
Err: 0
-
But on Xen 4.5.0, Dom0 can not booting.
below is domain0's booting message on Xen 4.5.0
* domain0's booting message on Xen 4.5.0
-
[ 3.900830] usb 3-3.2: new high-speed USB device number 3 using
exynos-ehci
[ 4.012184] usb 3-3.2: New USB device found, idVendor=05e3,
idProduct=0610
[ 4.017685] usb 3-3.2: New USB device strings: Mfr=0, Product=1,
SerialNumber=0
[ 4.025075] usb 3-3.2: Product: USB2.0 Hub
[ 4.030156] hub 3-3.2:1.0: USB hub found
[ 4.033555] hub 3-3.2:1.0: 4 ports detected
[ 4.310681] usb 3-3.2.4: new high-speed USB device number 4 using
exynos-ehci
[ 4.406697] usb 3-3.2.4: New USB device found, idVendor=0b95,
idProduct=772a
[ 4.412372] usb 3-3.2.4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[ 4.419921] usb 3-3.2.4: Product: AX88772
[ 4.424087] usb 3-3.2.4: Manufacturer: ASIX Elec. Corp.
[ 4.429393] usb 3-3.2.4: SerialNumber: 01
[
Re: [Xen-devel] [v2 11/11] p2m/ept: enable PML in p2m-ept for log-dirty
On 17.04.15 at 09:10, kai.hu...@linux.intel.com wrote: On 04/17/2015 02:28 PM, Jan Beulich wrote: On 17.04.15 at 04:40, kai.hu...@linux.intel.com wrote: On 04/16/2015 11:54 PM, Jan Beulich wrote: On 15.04.15 at 09:03, kai.hu...@linux.intel.com wrote: This patch firstly enables EPT A/D bits if PML is used, as PML depends on EPT A/D bits to work. A bit is set for all present leaf p2m types, D bit is set for all writable types, except log-dirty type. I think the tying of leaf to the A bit part of the description became stale, as you're now also doing this for non-leaf ones. You are right. How about just A bit is set for all present p2m types, ...? Almost - adding leaf to the D bit part would still be desirable for clarity. That will be more accurate. Thanks for suggestion. Is below good to you? Yes. A bit is set for all present p2m types in middle and leaf EPT entries, and D bit is set for all writable types in the leaf EPT entry, except log-dirty type. And I will update comments at the beginning of ept_p2m_type_to_flags accordingly. Thanks. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 06/11] vmx: add help functions to support PML
On 04/17/2015 03:37 PM, Jan Beulich wrote:
On 17.04.15 at 09:23, kai.hu...@linux.intel.com wrote:
On 04/17/2015 02:58 PM, Jan Beulich wrote:
On 17.04.15 at 08:51, kai.hu...@linux.intel.com wrote:
On 04/17/2015 02:23 PM, Jan Beulich wrote:
On 17.04.15 at 05:10, kai.hu...@linux.intel.com wrote:
On 04/16/2015 11:42 PM, Jan Beulich wrote:
On 15.04.15 at 09:03, kai.hu...@linux.intel.com wrote:
+void vmx_vcpu_flush_pml_buffer(struct vcpu *v)
+{
+uint64_t *pml_buf;
+unsigned long pml_idx;
+
+ASSERT(vmx_vcpu_pml_enabled(v));
+
+vmx_vmcs_enter(v);
+
+__vmread(GUEST_PML_INDEX, pml_idx);
Don't you require the vCPU to be non-running or current when you
get here? If so, perhaps add a respective ASSERT()?
Yes an ASSERT would be better.
v-pause_count will be increased if vcpu is kicked out by domain_pause
explicitly, but looks the same thing won't be done if vcpu is kicked out
by PML buffer full VMEXIT. So should the ASSERT be done like below?
ASSERT(atomic_read(v-pause_count) || (v == current));
For one I'd reverse the two parts. And then I think pause count
being non-zero is not a sufficient condition - if a non-synchronous
pause was issued against the vCPU it may still be running. I'd
suggest !vcpu_runnable(v) !v-is_running, possibly with the
pause count check instead of the runnable one if the only
permitted case where v != current requires the vCPU to be
paused.
The vmx_vcpu_flush_pml_buffer is only supposed to be called in below cases:
- When PML full VMEXIT happens
- In paging_log_dirty_op hap_track_dirty_vram, before reporting
dirty pages to userspace.
- In vmx_vcpu_disable_pml, called from vmx_vcpu_destroy, or when
log-dirty mode is disabled.
In the latter two cases, domain_pause is guaranteed to be called before
vmx_vcpu_flush_pml_buffer is called, therefore looks there's no
possibility of non-synchronous pause of the vcpu.
Or are you suggesting we should suppose this function can be called from
any caller, and meanwhile is able to act reasonably?
No. All I'm saying is in order to protect against eventual undue
future callers, it should assert that its preconditions are met. I.e.
if the vCPU is expected to be paused, check that the pause
count in non-zero _and_ that the pause actually took effect.
I see. I will do as you suggested:
ASSERT((v == current) || (!vcpu_runnable(v) !v-is_running));
And v != current should be the only case requires the vcpu to be paused.
But if you require (or at least expect) the vCPU to be paused, this
isn't what I suggested. Afaict
ASSERT((v == current) || (!v-is_running atomic_read(v-pause_count)));
would then be the right check (and, while not be a full guarantee that
things wouldn't change behind your back, would at least increase
chances that the vCPU's runnable state won't change, as the vCPU
could have been non-runnable for reasons other than having been
paused).
You are right. Your last sentence convinced me. I didn't go that far. I
will use atomic_read(v-pause_count) instead of !vcpu_runnable(v).
Thanks,
-Kai
Jan
___
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
Re: [Xen-devel] [PATCH 2/3] libxl: fd events: Break out fd_occurs
On Thu, 2015-04-16 at 19:23 +0100, Ian Jackson wrote: No functional change, only code motion. Currently, contrary to this function's name, there are two sites where efd-func() is called so one of them doesn't go through here just yet. That will be dealt with in the next commit. Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com CC: Jim Fehlig jfeh...@suse.com CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] Re: libvirtd live-locking on CTX_LOCK when doing 'virsh domid save /tmp/blah' with guest corrupting memory (on purpose).
On Thu, 2015-04-16 at 18:18 +0100, Ian Jackson wrote: Jim Fehlig writes (Re: [PATCH 0/2] Re: libvirtd live-locking on CTX_LOCK when doing 'virsh domid save /tmp/blah' with guest corrupting memory (on purpose).): On 04/14/2015 11:31 AM, Ian Jackson wrote: I have produced what I think are two patches that will fix this. I have compiled them but I haven't tested them. Konrad, are you able to check whether they fix your bug ? I too saw this bug just before Konrad's report, but the patches don't seem to help. Running a script that continually saves and restores domains will eventually lock libvirtd with essentially the same traces reported by Konrad I'm a total idiot. I do the recheck but I don't pay any attention to the result. Your second patch was updating revents which was used in the next if, what have I missed? I will send an updated approach which does this centrally. Ack, that's probably best anyhow. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] memaccess: skipping mem_access_send_req
On Wed, Apr 15, 2015 at 10:26:52, Ian Campbell wrote: We would like to use memaccess to perform (1) - but rather than pausing the VCPU in (2), instead simply directly inject the exception into the VCPU. That is, into the VCPUs whose permissions have been modified behind its back and not into some controlling domain? Correct - the abort should be injected into the VCPU which initiated the invalid transaction. Is the guest expected to be aware of this, i.e. to be somewhat paravirtualised? I suppose it must have to be in order to accept seemingly spurious page faults. Which leads me to wonder whether an extra shared ring between the hypervisor and target VCPU would be desirable, i.e. to allow more fine grained semantics than just computer says no. Specifically if you need to care about the reason for the fault being the actions of an external arbiter rather than some other guest-internal thing. If your application is just to allow the guest OS to kill a process which has tried to touch memory in a way which the external controller has disallowed then a page fault seems like a simple and effective way though. The guest will be aware of the permission changes - in fact in our system permission changes are only enacted following a request from the guest itself. So, a data abort is sufficient - the guest should then be able to work that this was due to it violating its stage-2 permissions, and kill the appropriate process. b) Define new xenmem_access_t values which cause the exception handler to reinject rather than adding a message to the ring buffer. I'm no xenaccess guru but that's the option I'd be inclined to take. My only concern would be limitations on the number of xenaccess types. On ARM we couldn't fit the type into the spare P2M PTE bits so we will already have a separate lookup and therefore not much limitation, but I don't know about on x86. It seems to be the simplest approach, and based on some quick prototyping appears to work - at least on ARM. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] memaccess: skipping mem_access_send_req
On Fri, Apr 10, 2015 at 17:03:26, Andrew Cooper wrote: Are you perhaps looking for something similar to Intel #VE support? Yes, in that we want a way to notify a guest that it has made an access that violated a stage-2 / EPT permission. However, for our purposes a trap into the hypervisor followed by injection of a virtual interrupt into the guest is acceptable; we don't require the interrupt to be directly delivered to the guest. (although I guess you are looking at ARM rather than x86) Yes, my email address is a giveaway ;) It is not safe to always re-inject back into the vcpu, especially if the permission changes were around the guest kernel stack, but a restricted subset ought to be safe to bounce straight in. The permission changes will be applied only to DMA buffers, rather than to anything the guest kernel itself needs to touch - so should be safe to directly re-inject. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England Wales, Company No: 2548782 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 0/5] Tweaks to allow running non-master production instances
On Wed, 2015-04-15 at 14:47 +0100, Ian Jackson wrote:
Ian Campbell writes (Re: [PATCH OSSTEST v2 0/5] Tweaks to allow running
non-master production instances):
Since you have now acked everything may I push to the Cambridge branch
(once the VM is working again)?
Yes.
(modulo if you want me to make the minor change discussed on 1/5 now or
not)
Either way is fine.
I created the file on both sites, but I didn't change this patch since
we are pushing this to Cambridge first if it does cause an issue when
merged back into mainline it'll be annoying to cleanup, better to let a
future change go through the usual mainline gate alone.
I've just pushed the following, which is a bunch of stuff from upstream
osstest and these five patches, to Cambridge pretest and then:
$ rm branches/for-osstest.git/stop
Lets see if the VM stays up long enough to test them!
Ian.
$ git log --oneline a623769..41ac504
41ac504 cambridge: Stop publishing logs to chiark
bcc9c68 cambridge: Do not try to push harness to XenProject instance output
6196543 cambridge: Add a crontab
7007b0a Handle osstest's own local push gate in non-master production instances
5926203 cri-args-hostslists: allow instance specific settings
eff0c77 cambridge: Set HostProp_DhcpWatchMethod back to woking
8f1dc3f ts-host-ping-check: Do not run if host is being reused
ba691ef standalone: Add --dry-run option for run-job.
effe70a tcl: Handle environment variables which are unset.
4a938b2 Merge branch 'production' of osstest.test-lab:/home/osstest/testing
into wip
2d1aa25 production-config: Adjust LogsMinSpaceMby to not be half of the VM's
disk
5ae027f Merge branch 'colo.2015-03-31' of xenbits.xen.org:/home/iwj/ext/osstest
into queue
4bf33f8 production-config*: Set HostnameSortSwapWords as appropriate
e2008dc (Re)Add production config for Cambridge instance
f89d6ac Osstest.pm: Add use IO::File
0ab790c ts-host-install: honour arch-specific boot append properties
e654ecc ts-host-ping-check: New ubiquitous test step
a80d215 sg-report-flight: Produce better output for running jobs.
6ec412e sg-report-flight: Sort email output by results, not job name
6cbaf65 cs-adjust-flight: Support negation of foo-specs
fdddba7 config: turn off HostnameSortSwapWords by default
ea335bc start/stop the guest 10 times in the standard test jobs
4d6bbe0 README.dev: Document steps after restarting ms-ownerdaemon
97fa466 uboot: make flask loading address host property
ab441f3 uboot: do not use readlink on xsm policy
dce7456 Merge remote-tracking branch 'origin/incoming' into wip.colo
bf3a468 Remove passthrough tests
7d87cf0 Empty commit to force test run
bc50a13 Configs: Replace xenbits.xensource.com with xenbits.xen.org
da7c22d mg-branch-setup: Make initial push optional in mg-branch-setup
831c94e ts-debian-install: Honour DebianMirrorProxy, HttpProxy
a141aca production-config: Configuration for new production colo
310c5b5 Branches: Rename incoming branch to production
b294e14 config defaults: Do not use woking for dhcp leases
2fedf11 ts-kernel-build: enable CONFIG_SCSI_HPSA
347eadf ts-kernel-build: enable CONFIG_SCSI_ISCI
591ed47 ts-kernel-build: Document a hacky way to get CONFIG_... options
4d0dba4 HostnameSortSwapWords: Make name order mangling configurable
a4debc0 mg-execute-flight: New -P (publish) option
41e9bf0 cr-ensure-disk-space: Honour different config for published log expiry
2ad7b3f cr-ensure-disk-space: Operate locally entirely separately.
2563b91 cr-ensure-disk-space: Permit argument to specify local directory.
dd6be0f cr-ensure-disk-space: Fix -n option
43a0974 cr-ensure-disk-space: Take argument for what to clean
1d25a8c cr-ensure-disk-space: Do listing of flights on target.
d6edb5d cr-ensure-disk-space: Do df check on target.
438637a cr-ensure-disk-space: Break out ontarget
fdc2659 cr-ensure-disk-space: Move LogsPublish decomposition up
d8b13ac cr-ensure-disk-space: Emacs perl-mode syntax workaround
f16e621 daemons: Allow QueueDaemon and OwnerDaemon to run on different hosts
0ff3bb1 target_cmd_build: Honour $c{HttpProxy}
a11fc63 HostDB Executive: Option to suppress configdb
2b5aa29 readglobalconfig: Support Include
f5b354a readglobalconfig: Break out $readcfg as a sub
bf2b666 Debian mirrors: Support proxy, and default to ftp.debian.org if
specified
eb805e8 pxe setup: mg-hosts mkpxedir has -n (dry run) option
a865cc2 pxe setup: New TftpPxeTemplatesReal feature
14e0e8d Osstest: Default config: Use foreach for empty defaults
bbcce4d mg-hosts: Provide new power subcommand
68f35a1 pxe setup: Define %name% in templates
e8a5b82 PDU: pdu-msw: Support APC v6 firmware
9705c37 PDU: pdu-msw: Split $read_oid and $write_oid
0fb0a00 PDU: msw: support arbitrary arguments
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 p2 04/19] xen/arm: Implement hypercall DOMCTL_{, un}bind_pt_pirq
On Fri, 2015-04-17 at 07:02 +0100, Julien Grall wrote:
Hi Ian,
On 16/04/2015 16:40, Ian Campbell wrote:
On Thu, 2015-04-16 at 16:20 +0100, Julien Grall wrote:
Concerning XSM, even if ARM is using one hypercall rather than 2, the
resulting check is nearly the same.
XSM PHYSDEVOP_map_pirq:
1) Check if the current domain can add resource to the domain
2) Check if the current domain has permission to add the IRQ
3) Check if the target domain has permission to use the IRQ
XSM DOMCTL_bind_pirq_irq:
1) Check if the current domain can add resource to the domain
2) Check if the current domain has permission to bind the IRQ
3) Check if the target domain has permission to use the IRQ
In order to keep the same XSM checks done by the 2 hypercalls on x86,
call both xsm_map_domain_irq xsm_bind_pt_irq in the ARM implementation.
I think this paragraph makes the previous bit obsolete?
Do you mean: Concerning XSM... until and the 2 paragraphs for XSM
hypercalls?
That's right.
Ok. I will drop it.
@@ -1878,6 +1913,25 @@ int xc_domain_bind_pt_isa_irq(
PT_IRQ_TYPE_ISA, 0, 0, 0,
machine_irq));
}
+int xc_domain_bind_pt_spi_irq(
+xc_interface *xch,
+uint32_t domid,
+uint16_t spi)
+{
+/* vSPI == SPI */
I wonder if to avoid API churn later we should accept both machine and
guest IRQ here and rely on the check that htey are the same in the
hypervisor to reject?
Fair enough we can change libxc interface if we want, but avoiding a
little churn later on seems reasonable and it makes it a better fit with
the existing interfaces.
what about the following prototype:
int xc_domain_bind_pt_spi_irq(
xc_interface *xch,
uint32_t domid,
uint16_t spi,
uint16_t vspi)
I didn't reuse the current name i.e (machine_irq) because I find the
name confusing.
Sure. Although you hit machine_irq again at the next level in the stack
so I think it's rather moot.
[..]
+case XEN_DOMCTL_unbind_pt_irq:
+{
+int rc;
+xen_domctl_bind_pt_irq_t *bind = domctl-u.bind_pt_irq;
+uint32_t irq = bind-u.spi.spi;
+uint32_t virq = bind-machine_irq;
+
+/* We only support PT_IRQ_TYPE_SPI */
+if ( bind-irq_type != PT_IRQ_TYPE_SPI )
+return -EOPNOTSUPP;
+
+/* For now map the interrupt 1:1 */
+if ( irq != virq )
+return -EINVAL;
The x86 version doesn't appear to consider irq_type or irq, only virq
(from -machine_irq). That seems to be logical to me (if a little
underdocumented) and I think we should be consistent.
On x86, the parameters are used later in pt_create_bind which take the
hypercall data in parameter.
Ah yes, (although you mean pt_irq_destroy_bind I think?)
No I mean pt_irq_create_bind.
My initial comment was talking specifically about
XEN_DOMCTL_unbind_pt_irq, which AFAICT does not call pt_irq_create_bind
(which is why I assumed you must mean unbind).
I agree that XEN_DOMCTL_bind_pt_irq should contain checks of all its
inputs, of course.
The function makes usage of machine_irq
and irq_type. Although, there is no clear switch case, just an if in the
code.
The both check are required in order to avoid future issue if we
introduce new type and when we will support virq != irq.
Shouldn't they be in pt_irq_destroy_bind then?
I'm not following you. pt_irq_destroy_bind is an x86 specific function.
The check virq != irq is done in both DOMCTL_{,un}bind_irq on ARM even
though the one in unbind is not necessary useful.
This was exactly my point, on x86 XEN_DOMCTL_unbind_pt_irq didn't appear
to pay attention to anything other than the virq provided, I assumed
since it doesn't need any other information from the caller to do as it
has been asked.
But it seems like maybe I was wrong and pt_irq_destroy_bind (called from
XEN_DOMCTL_unbind_pt_irq on x86) does actually need other info (I'm not
sure why, it seems like it ought to know these things without being told
by the toolstack). In which case having your check for consistency with
x86 is probably tolerable.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt bisection] complete build-armhf-libvirt
On Thu, 2015-04-16 at 21:46 +, osstest service user wrote: branch xen-unstable xen branch xen-unstable job build-armhf-libvirt test libvirt-build Tree: libvirt git://libvirt.org/libvirt.git Tree: libvirt_gnulib git://git.sv.gnu.org/gnulib.git Tree: qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: libvirt git://libvirt.org/libvirt.git Bug introduced: 1eccac1d2da7bbe97e1df25fd0ddac6e71b0794a Bug not present: 88dc7e0c2fba1894ec36502aecc229129c8d3111 commit 1eccac1d2da7bbe97e1df25fd0ddac6e71b0794a Author: Peter Krempa pkre...@redhat.com Date: Tue Mar 31 17:29:35 2015 +0200 qemu: domain: Add helper to check block job support This was bisecting the failure in http://logs.test-lab.xenproject.org/osstest/logs/50417/build-armhf-libvirt/5.ts-libvirt-build.log which was: qemu/qemu_driver.c: In function 'qemuDomainAddCgroupForThread': qemu/qemu_driver.c:4641:34: error: declaration of 'index' shadows a global declaration [-Werror=shadow] qemu/qemu_driver.c: In function 'qemuDomainHotplugAddPin': qemu/qemu_driver.c:4674:29: error: declaration of 'index' shadows a global declaration [-Werror=shadow] qemu/qemu_driver.c: In function 'qemuDomainHotplugPinThread': qemu/qemu_driver.c:4702:32: error: declaration of 'index' shadows a global declaration [-Werror=shadow] qemu/qemu_driver.c: In function 'qemuDomainDelCgroupForThread': qemu/qemu_driver.c:4733:34: error: declaration of 'index' shadows a global declaration [-Werror=shadow] I believe this to have been fixed in mainline. However, I don't believe the quoted commit has anything to do with the failure, I suspect there were two overlapping build errors and indeed the first repro case on the bad commit was http://logs.test-lab.xenproject.org/osstest/logs/50460/build-armhf-libvirt/5.ts-libvirt-build.log: qemu/qemu_domain.c: In function 'qemuDomainSupportsBlockJobs': qemu/qemu_domain.c:3067:11: error: declaration of 'sync' shadows a global declaration [-Werror=shadow] cc1: all warnings being treated as errors i.e. another shadow issue. I'll reply to the thread I started about the other issue. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt] [libvirt test] 50401: regressions - FAIL
On Wed, 2015-04-15 at 14:16 +0100, Daniel P. Berrange wrote: Yeah, there is nothing Xen specific about the problem - it is entirely down to the build toolchain compiler options. FYI our bisector has now tripped over another related problem, http://lists.xen.org/archives/html/xen-devel/2015-04/msg01900.html http://lists.xen.org/archives/html/xen-devel/2015-04/msg01968.html in particular: http://logs.test-lab.xenproject.org/osstest/logs/50460/build-armhf-libvirt/5.ts-libvirt-build.log: qemu/qemu_domain.c: In function 'qemuDomainSupportsBlockJobs': qemu/qemu_domain.c:3067:11: error: declaration of 'sync' shadows a global declaration [-Werror=shadow] cc1: all warnings being treated as errors Essentially another instance of the same class of issue, in this case arising from: commit 1eccac1d2da7bbe97e1df25fd0ddac6e71b0794a Author: Peter Krempa pkre...@redhat.com Date: Tue Mar 31 17:29:35 2015 +0200 qemu: domain: Add helper to check block job support Given the code in autoconf to enable essentially all warnings I'm a bit surprised -Wshadow isn't being enabled for everyone -- I thought it was quite a long standing warning. I'm also not sure why we are having a sudden rash of these now. But perhaps it is worth adding Wshadow to the set of excluded options until either it is more widely supported or the libvirt code base has been audited? I can send such a patch if you think that's desirable. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 50428: regressions - FAIL
flight 50428 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/50428/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 50391 Regressions which are regarded as allowable (not blocking): test-amd64-i386-freebsd10-i386 13 guest-localmigrate fail like 50391 test-amd64-i386-freebsd10-amd64 15 guest-localmigrate.2fail like 50391 test-armhf-armhf-libvirt 11 guest-start fail like 50391 test-amd64-i386-pair21 guest-migrate/src_host/dst_host fail like 50391 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-xsm 11 guest-start fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-xsm 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-armhf-armhf-xl-xsm 6 xen-boot fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-winxpsp3 16 guest-stopfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 16 guest-stop fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-winxpsp3 16 guest-stop fail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-xl-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 16 guest-stopfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt-xsm 6 xen-boot fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-amd64-i386-xl-winxpsp3-vcpus1 16 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 16 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 16 guest-stop fail never pass version targeted for testing: qemuub8df9208f357d2b36e1b19634aea973618dc7ba8 baseline version: qemuu58c24a4775ef7ccf16cfcd695753dfdf149fe29d People who touched revisions under test: Andreas Färber afaer...@suse.de Dirk Mueller dmuel...@suse.com Dirk Müller d...@dmllr.de Edgar E. Iglesias edgar.igles...@xilinx.com Peter Maydell peter.mayd...@linaro.org Thomas Huth th...@redhat.com jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl
Re: [Xen-devel] [PATCH 4/9] raisin: add a component to build qemu_traditional
On Thu, 2015-04-16 at 17:03 +0100, Stefano Stabellini wrote: On Wed, 15 Apr 2015, Andrew Cooper wrote: -./configure --prefix=$PREFIX --with-system-qemu=/usr/bin/qemu-system-i386 +./configure --prefix=$PREFIX --with-system-qemu=/usr/bin/qemu-system-i386 \ +--disable-qemu-traditional This does more than just what you want. It also tells libxl that qemu-trad does not exist which compiles out any ability to use qemu-trad as a device model. Actually that is not true: it is not possible to specify where your separately built qemu-traditional binary is with --disable-qemu-traditional, but if you place it under /usr/lib/xen/bin, libxl will pick it up automatically. Probably a bug in the patch which added the option, but lets retcon it into being the expected behaviour ;-) Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] libxl: fd events: Suppress spurious fd events
On Thu, 2015-04-16 at 19:23 +0100, Ian Jackson wrote: Always recheck with poll() right before making the callback. All sorts of things may have happened since poll() originally signaled the fd. We would like the main functional libxl code not to have to worry about spurious wakeups. This works because the recheck and the callback are both done within the same CTX lock critical section. The major assumption here is that anything which could invalidate the result of the previous poll must also happen with the lock held, otherwise you have a race between the recheck and the callback. The new call of fd_occurs here is locked, as is the one from afterpoll_internal (refactored in a previous patch), so good. Are all of the fd's which are going to be involved in this path owned by libxl? I believe that is the case (if not then the application would need to take care). The application may have visibility onto the fds (via the result of libxl_osevent_beforepoll or the use of the fd_register hook) but I think it is pretty obvious that the application should never do anything with those fds other than poll or remember them to give to libxl later. Likewise is all of the code in libxl which touches such an fd locked? I expect this is usually trivially the case because the fd is touched in a callback, and if it is not the case elsewhere that would be a bug to be fixed. (a bit longer than it needed to be, but I figured that having reasoned it out in writing to keep my thoughts straight I may as well post it) In particular, this fixes a bug in the save/restore callout: the save helper message reader operates with the fd in blocking mode. In a multithreaded program one thread might have eaten all the messages out of the fd while another one is busy returning from poll and reaquiring reacquiring the libxl lock, possibly resulting in a deadlock. (Also, we abolish the anomalous direct caller of efd-func.) Reported-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com Reported-by: Jim Fehlig jfeh...@suse.com Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com CC: Jim Fehlig jfeh...@suse.com CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v1] x86/cpuidle: get accurate C0 value with xenpm tool
On 17.04.15 at 09:36, huaitong@intel.com wrote: From: Jan Beulich [mailto:jbeul...@suse.com] Sent: Thursday, April 16, 2015 4:49 PM On 16.04.15 at 08:03, huaitong@intel.com wrote: When checking the ACPI funciton of C-status, after 100 seconds sleep, the sampling value of C0 C-status from the xenpm tool decreases. Because C0=NOW()-C1-C2-C3-C4, when NOW() value is during idle time, NOW() value is bigger than last C-status update time, and C0 value is also bigger than ture value. if margin of the second error cannot make up for margin of the first error, the value of C0 would decrease. How big of an error are we taking about here? And does that error increase over time? The max error value is about 1s that depends on max C-status time. Error does not increase over time, because C1,C2,C3 and C4 is accurate, and NOW() is random. So if the error doesn't increase over time and the values reported to the caller are stale (inaccurate) by the time it gets to see them anyway, is it really worth adjusting the code like you propose? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] passthrough/amd: avoid reading an uninitialized variable.
On 16.04.15 at 19:19, andrew.coop...@citrix.com wrote: On 16/04/15 17:44, Tim Deegan wrote: update_intremap_entry_from_msi() doesn't write to its data pointer on some error paths, so we copying that variable into the msg would count as undefined behaviour. Signed-off-by: Tim Deegan t...@xen.org Cc: Suravee Suthikulpanit suravee.suthikulpa...@amd.com Cc: Aravind Gopalakrishnan aravind.gopalakrish...@amd.com This looks curiously familiar. http://lists.xen.org/archives/html/xen-devel/2015-03/msg03679.html I was meaning to get around to submitting it as a formal patch, but you have definitely beaten me to it :) But sadly it didn't help with the issue Sander reported (and I also didn't expect it to, as errors here should cause the caller to not use msg at all, and the regressing patch didn't alter anything that could have caused errors to surface where none where seen before). Still the patch is a good one as correcting a language spec violation. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 3/5] libxl: add support for vscsi
Port pvscsi support from xend to libxl:
vscsi=['pdev,vdev{,options}']
xl scsi-attach
xl scsi-detach
xl scsi-list
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
---
docs/man/xl.cfg.pod.5| 55 +++
docs/man/xl.pod.1| 18 +
tools/libxl/Makefile | 2 +
tools/libxl/libxl.c | 441
tools/libxl/libxl.h | 27 ++
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.h | 16 +
tools/libxl/libxl_types.idl | 56 +++
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_vscsi.c| 271 +
tools/libxl/libxlu_vscsi.c | 750 +++
tools/libxl/libxlutil.h | 21 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 184 -
tools/libxl/xl_cmdtable.c| 15 +
16 files changed, 1862 insertions(+), 1 deletion(-)
diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
index f936dfc..d395e56 100644
--- a/docs/man/xl.cfg.pod.5
+++ b/docs/man/xl.cfg.pod.5
@@ -510,6 +510,61 @@ value is optional if this is a guest domain.
=back
+=item Bvscsi=[ VSCSI_SPEC_STRING, VSCSI_SPEC_STRING, ...]
+
+Specifies the PVSCSI devices to be provided to the guest. PVSCSI passes
+dom0 SCSI devices as-is to the guest.
+
+Each VSCSI_SPEC_STRING consists of pdev,vdev[,options].
+'pdev' describes the physical device, preferable in a persistant format.
+'vdev' is the domU device in vHOST:CHANNEL:TARGET:LUN notation, all integers.
+'option' lists additional flags which a backend may recognize.
+
+The supported values for pdev and option depends on the used backend
driver:
+
+=over 4
+
+=item BLinux pvops
+
+=over 4
+
+=item Cpdev
+
+The backend driver in the pvops kernel is part of the Linux-IO Target framework
+(LIO). As such the SCSI devices have to be configured first with the tools
+provided by this framework, such as a xen-scsiback aware targetcli. The pdev
+in domU.cfg has to refer to a config item in that framework instead of the raw
+device. Ususally this is a WWN in the form of na.WWN:LUN.
+
+=item Coption
+
+No options recognized.
+
+=back
+
+=item BLinux xenlinux
+
+=over 4
+
+=item Cpdev
+
+The dom0 device in either /dev/scsidev or pHOST:CHANNEL:TARGET:LUN notation.
+
+Its recommended to use persistant names /dev/disk/by-*/* to refer to a
pdev.
+The toolstack will translate this internally to h:c:t:l notation, which is
how
+the backend driver will access the device. Using the h:c:t:l notation for
+pdev in domU.cfg is discouraged because this value will change across
reboots,
+depending on the detection order in the OS.
+
+=item Coption
+
+Currently only the option value feature-host is recognized. SCSI command
+emulation in backend driver is bypassed when feature-host is specified.
+
+=back
+
+=back
+
=item Bvfb=[ VFB_SPEC_STRING, VFB_SPEC_STRING, ...]
Specifies the paravirtual framebuffer devices which should be supplied
diff --git a/docs/man/xl.pod.1 b/docs/man/xl.pod.1
index 16783c8..19bdbfa 100644
--- a/docs/man/xl.pod.1
+++ b/docs/man/xl.pod.1
@@ -1328,6 +1328,24 @@ List virtual trusted platform modules for a domain.
=back
+=head2 PVSCSI DEVICES
+
+=over 4
+
+=item Bscsi-attach Idomain-id Ipdev Ivdev,I[feature-host]
+
+Creates a new vscsi device in the domain specified by Idomain-id.
+
+=item Bscsi-detach Idomain-id Ivdev
+
+Removes the vscsi device from domain specified by Idomain-id.
+
+=item Bscsi-list Idomain-id I[domain-id] ...
+
+List vscsi devices for the domain specified by Idomain-id.
+
+=back
+
=head1 PCI PASS-THROUGH
=over 4
diff --git a/tools/libxl/Makefile b/tools/libxl/Makefile
index 1b16598..79b3867 100644
--- a/tools/libxl/Makefile
+++ b/tools/libxl/Makefile
@@ -91,6 +91,7 @@ endif
LIBXL_LIBS += -lyajl
LIBXL_OBJS = flexarray.o libxl.o libxl_create.o libxl_dm.o libxl_pci.o \
+ libxl_vscsi.o \
libxl_dom.o libxl_exec.o libxl_xshelp.o libxl_device.o \
libxl_internal.o libxl_utils.o libxl_uuid.o \
libxl_json.o libxl_aoutils.o libxl_numa.o libxl_vnuma.o
\
@@ -122,6 +123,7 @@ AUTOINCS= libxlu_cfg_y.h libxlu_cfg_l.h _libxl_list.h
_paths.h \
AUTOSRCS= libxlu_cfg_y.c libxlu_cfg_l.c
AUTOSRCS += _libxl_save_msgs_callout.c _libxl_save_msgs_helper.c
LIBXLU_OBJS = libxlu_cfg_y.o libxlu_cfg_l.o libxlu_cfg.o \
+ libxlu_vscsi.o \
libxlu_disk_l.o libxlu_disk.o libxlu_vif.o libxlu_pci.o
$(LIBXLU_OBJS): CFLAGS += $(CFLAGS_libxenctrl) # For xentoollog.h
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 511eef1..abe7d75 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -2014,6 +2014,437 @@
[Xen-devel] [PATCH v4 0/5] libbxl: add support for pvscsi, iteration 4
Port vscsi=[] and scsi-{attach,detach,list} commands from xend to libxl.
TODO:
- find better name for -feature_host (perhaps -sg_io as used in libvirt?)
- maybe use events instead of polling for state changes in reconfigure
(libxl__wait_for_backend vs. libxl__ev_devstate_wait)
- add code to libvirt to actually allow SCSI and target passthrough. The
current code is still a decade behind: it expects h:c:t:l notation...
- maybe adjust API for xl and libvirt to work directly with .idl provided
structs instead of pass domU.cfg strings around
Changes between v3 and v4:
- Use libxl__device_nextid in libxl__device_vscsi_add
- Remove check for duplicate pdev assignment from libxl_device_vscsi_get_host
- Caller provides libxl_device_vscsi to libxl_device_vscsi_get_host
- Define LIBXL_HAVE_VSCSI
- Remove init_val from libxl_vscsi_pdev_type
- Move some functions from libxl to libxlu
- Introduce libxl_device_vscsi-next_vscsi_dev_id to handle holes
- Use Struct in KeyedUnion for ocaml idl
- docs: Mention pvscsi in xl and xl.cfg
- Turn feature_host into a defbool and add checking
- Support pvops and /dev/ nodes in config
- Wrap entire libxlu_vscsi.c with ifdef linux
- Set remove flag in libxl_device_vscsi_list
- Fix vscsiif path in xenstore-paths.markdown
- vscsiif.h: add some notes about xenstore layout
- Add copyright to libxlu_vscsi.c and libxl_vscsi.c
- Scripts to create and delete xen-scsiback nodes in Linux target framework
- Remove pvscsi.txt
Changes between v2 and v3:
- Adjust change for vscsiif.h
- Support naa.wwn:lun notation in pvops kernel
- Add example for pvops kernel using targetcli
patch required for python-rtslib:
http://article.gmane.org/gmane.linux.scsi.target.devel/8146
- Use vdev variable in libxl_device_vscsi_parse
http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg00734.html
Changes between v1 and v2:
- ported to current staging
http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg00030.html
Initial attempt was sent a year ago:
http://lists.xenproject.org/archives/html/xen-devel/2014-04/msg03958.html
Most comments are addressed.
This version has been tested with SLES as backend and frontend.
This version has been tested with pvops as backend and SLES as frontend.
Olaf Hering (5):
vscsiif.h: fix WWN notation for p-dev property
docs: add vscsi to xenstore-paths.markdown
libxl: add support for vscsi
vscsiif.h: add some notes about xenstore layout
Scripts to create and delete xen-scsiback nodes in Linux target
framework
docs/man/xl.cfg.pod.5| 55 +++
docs/man/xl.pod.1| 18 +
docs/misc/xenstore-paths.markdown| 10 +
tools/libxl/Makefile | 2 +
tools/libxl/libxl.c | 441 ++
tools/libxl/libxl.h | 27 ++
tools/libxl/libxl_create.c | 1 +
tools/libxl/libxl_device.c | 2 +
tools/libxl/libxl_internal.h | 16 +
tools/libxl/libxl_types.idl | 56 +++
tools/libxl/libxl_types_internal.idl | 1 +
tools/libxl/libxl_vscsi.c| 271 +++
tools/libxl/libxlu_vscsi.c | 750 +++
tools/libxl/libxlutil.h | 21 +
tools/libxl/xl.h | 3 +
tools/libxl/xl_cmdimpl.c | 184 +++-
tools/libxl/xl_cmdtable.c| 15 +
tools/misc/Makefile | 4 +
tools/misc/target-create-xen-scsiback.sh | 94
tools/misc/target-delete-xen-scsiback.sh | 39 ++
xen/include/public/io/vscsiif.h | 70 ++-
21 files changed, 2078 insertions(+), 2 deletions(-)
create mode 100644 tools/libxl/libxl_vscsi.c
create mode 100644 tools/libxl/libxlu_vscsi.c
create mode 100644 tools/misc/target-create-xen-scsiback.sh
create mode 100644 tools/misc/target-delete-xen-scsiback.sh
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 5/5] Scripts to create and delete xen-scsiback nodes in Linux target framework
Just to make them public, not meant for merging:
The scripts used during development to create a bunch of SCSI devices in
dom0 using the Linux target framework. targetcli3 and rtslib3 is used.
A patch is required for python-rtslib:
http://article.gmane.org/gmane.linux.scsi.target.devel/8146
Signed-off-by: Olaf Hering o...@aepfle.de
---
tools/misc/Makefile | 4 ++
tools/misc/target-create-xen-scsiback.sh | 94
tools/misc/target-delete-xen-scsiback.sh | 39 +
3 files changed, 137 insertions(+)
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index ccd36af..be101d8 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -32,6 +32,8 @@ INSTALL_SBIN += $(INSTALL_SBIN-y)
# Everything to be installed in a private bin/
INSTALL_PRIVBIN+= xenpvnetboot
+INSTALL_PRIVBIN+= target-create-xen-scsiback.sh
+INSTALL_PRIVBIN+= target-delete-xen-scsiback.sh
# Everything to be installed
TARGETS_ALL := $(INSTALL_BIN) $(INSTALL_SBIN) $(INSTALL_PRIVBIN)
@@ -42,6 +44,8 @@ TARGETS_COPY += xen-ringwatch
TARGETS_COPY += xencons
TARGETS_COPY += xencov_split
TARGETS_COPY += xenpvnetboot
+TARGETS_COPY += target-create-xen-scsiback.sh
+TARGETS_COPY += target-delete-xen-scsiback.sh
# Everything which needs to be built
TARGETS_BUILD := $(filter-out $(TARGETS_COPY),$(TARGETS_ALL))
diff --git a/tools/misc/target-create-xen-scsiback.sh
b/tools/misc/target-create-xen-scsiback.sh
new file mode 100644
index 000..fc49c2e
--- /dev/null
+++ b/tools/misc/target-create-xen-scsiback.sh
@@ -0,0 +1,94 @@
+#!/usr/bin/env bash
+unset LANG
+unset ${!LC_*}
+set -x
+set -e
+
+modprobe --version
+targetcli --version
+udevadm --version
+blockdev --version
+parted --version
+sfdisk --version
+mkswap --version
+
+configfs=/sys/kernel/config
+target_path=$configfs/target
+
+num_luns=4
+num_hosts=4
+
+get_wwn() {
+ sed '
+ s@-@@g
+ s@^\(.\{16\}\)\(.*\)@\1@
+ ' /proc/sys/kernel/random/uuid
+}
+
+if test ! -d ${target_path}
+then
+ modprobe -v configfs
+ mount -vt configfs configfs $configfs
+ modprobe -v target_core_mod
+fi
+modprobe -v xen-scsiback
+
+host=0
+while test $host -lt $num_hosts
+do
+ host=$(( $host + 1 ))
+ lun=0
+ loopback_wwn=naa.`get_wwn`
+ pvscsi_wwn=naa.`get_wwn`
+ targetcli /loopback create ${loopback_wwn}
+ targetcli /xen-pvscsi create ${pvscsi_wwn}
+ while test $lun -lt $num_luns
+ do
+ : h $host l $lun
+ f_file=/dev/shm/Fileio.${host}.${lun}.file
+ f_uuid=/dev/shm/Fileio.${host}.${lun}.uuid
+ f_link=/dev/shm/Fileio.${host}.${lun}.link
+ fileio_name=fio_${host}.${lun}
+ pscsi_name=ps_${host}.${lun}
+
+ targetcli /backstores/fileio create name=${fileio_name}
file_or_dev=${f_file} size=$((1024*1024 * 8 )) sparse=true
+ targetcli /loopback/${loopback_wwn}/luns create
/backstores/fileio/${fileio_name} $lun
+
+ udevadm settle --timeout=4
+
+ vpd_uuid=`sed -n '/^T10 VPD Unit Serial
Number:/s@^[^:]\+:[[:blank:]]\+@@p'
/sys/kernel/config/target/core/fileio_*/${fileio_name}/wwn/vpd_unit_serial`
+ if test -z ${vpd_uuid}
+ then
+ exit 1
+ fi
+ echo ${vpd_uuid} ${f_uuid}
+ by_id=`echo ${vpd_uuid} | sed
's@-@@g;s@^\(.\{25\}\)\(.*\)@scsi-36001405\1@'`
+ ln -sfvbn /dev/disk/by-id/${by_id} ${f_link}
+
+ blockdev --rereadpt ${f_link}
+ udevadm settle --timeout=4
+ echo 1,12,S | sfdisk ${f_link}
+ udevadm settle --timeout=4
+ blockdev --rereadpt ${f_link}
+ udevadm settle --timeout=4
+ parted -s ${f_link} unit s print
+
+ d_link=`readlink \${f_link}\`
+ if test -n ${d_link}
+ then
+ p_link=${d_link}-part1
+ ls -l ${p_link}
+ mkswap -L swp_${fileio_name} ${p_link}
+ udevadm settle --timeout=4
+ blockdev --rereadpt ${f_link}
+ udevadm settle --timeout=4
+ parted -s ${f_link} unit s print
+ fi
+
+ targetcli /backstores/pscsi create dev=${f_link}
${pscsi_name}
+ targetcli /xen-pvscsi/${pvscsi_wwn}/tpg1/luns create
/backstores/pscsi/${pscsi_name} $lun
+
+ lun=$(( $lun + 1 ))
+ done
+done
+
diff --git a/tools/misc/target-delete-xen-scsiback.sh
b/tools/misc/target-delete-xen-scsiback.sh
new file mode 100644
index 000..a90bd82
--- /dev/null
+++ b/tools/misc/target-delete-xen-scsiback.sh
@@ -0,0 +1,39 @@
+#!/usr/bin/env bash
+unset LANG
+unset ${!LC_*}
+set -x
+set -e
+
+targetcli --version
+
+configfs=/sys/kernel/config
[Xen-devel] [PATCH v4 2/5] docs: add vscsi to xenstore-paths.markdown
Signed-off-by: Olaf Hering o...@aepfle.de Cc: Ian Campbell ian.campb...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Keir Fraser k...@xen.org Cc: Tim Deegan t...@xen.org --- docs/misc/xenstore-paths.markdown | 10 ++ 1 file changed, 10 insertions(+) diff --git a/docs/misc/xenstore-paths.markdown b/docs/misc/xenstore-paths.markdown index d94ea9d..d7a5e30 100644 --- a/docs/misc/xenstore-paths.markdown +++ b/docs/misc/xenstore-paths.markdown @@ -232,6 +232,11 @@ A virtual keyboard device frontend. Described by A virtual network device frontend. Described by [xen/include/public/io/netif.h][NETIF] + ~/device/vscsi/$DEVID/* [] + +A virtual scsi device frontend. Described by +[xen/include/public/io/vscsiif.h][SCSIIF] + ~/console/* [] The primary PV console device. Described in [console.txt](console.txt) @@ -302,6 +307,10 @@ A virtual keyboard device backend. Described by A virtual network device backend. Described by [xen/include/public/io/netif.h][NETIF] + ~/backend/vscsi/$DOMID/$DEVID/* [] + +A PV SCSI backend. Described in [pvscsi.txt](pvscsi.txt) + ~/backend/console/$DOMID/$DEVID/* [] A PV console backend. Described in [console.txt](console.txt) @@ -403,6 +412,7 @@ ifb device used by Remus to buffer network output from the associated vif. [KBDIF]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,kbdif.h.html [LIBXLMEM]: http://xenbits.xen.org/docs/unstable/misc/libxl_memory.txt [NETIF]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,netif.h.html +[SCSIIF]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,vscsiif.h.html [SI]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,xen.h.html#Struct_start_info [VCPU]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,vcpu.h.html [XSWIRE]: http://xenbits.xen.org/docs/unstable/hypercall/include,public,io,xs_wire.h.html ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/8] raisin: Use fakeroot for mkdeb so we can build the package as non-root
On Thu, 2015-04-16 at 17:19 +0100, George Dunlap wrote:
Signed-off-by: George Dunlap george.dun...@eu.citrix.com
AIUI raisin does build dependency handling/tracking. If so then fakeroot
ought to be added to it I think?
---
CC: Stefano Stabellini stefano.stabell...@citrix.com
Does CC below a CC work? Interesting.
---
lib/common-functions.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/common-functions.sh b/lib/common-functions.sh
index 06c894a..373d6fb 100644
--- a/lib/common-functions.sh
+++ b/lib/common-functions.sh
@@ -242,7 +242,7 @@ function for_each_component () {
function build_package() {
if [[ $DISTRO = Debian ]]
then
-./scripts/mkdeb $1
+fakeroot bash ./scripts/mkdeb $1
elif [[ $DISTRO = Fedora ]]
then
./scripts/mkrpm $1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] libxl: fd events: Break out libxl__fd_poll_recheck
On Thu, 2015-04-16 at 19:23 +0100, Ian Jackson wrote: Replaces two call sites where a rechecking poll() was open-coded. No functional change, other than to highly unusual error path diagnosis, and debug and error message output. Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com CC: Jim Fehlig jfeh...@suse.com CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/1] x86/hvm: prevent hvm_free_ioreq_gmfn() clobber of arbitrary memory
On 16.04.15 at 18:37, t...@xen.org wrote: At 12:32 +0100 on 16 Apr (1429187564), Jan Beulich wrote: On 16.04.15 at 12:53, t...@xen.org wrote: I would be inclined to use a bigger hammer here. IMO refactoring like this makes it easier to reason about (compile tested only): This looks like a pretty nice cleanup; I particularly like the 4 labels going away. OK, here it is as a proper patch. I still haven't tested it -- indeed I'm not sure how to test multiple ioreq clients. Any suggestions? Paul? Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 4/5] vscsiif.h: add some notes about xenstore layout
Signed-off-by: Olaf Hering o...@aepfle.de
Cc: Ian Campbell ian.campb...@citrix.com
Cc: Ian Jackson ian.jack...@eu.citrix.com
Cc: Jan Beulich jbeul...@suse.com
Cc: Keir Fraser k...@xen.org
Cc: Tim Deegan t...@xen.org
---
xen/include/public/io/vscsiif.h | 68 +
1 file changed, 68 insertions(+)
diff --git a/xen/include/public/io/vscsiif.h b/xen/include/public/io/vscsiif.h
index e8e38a9..6aaba22 100644
--- a/xen/include/public/io/vscsiif.h
+++ b/xen/include/public/io/vscsiif.h
@@ -104,6 +104,74 @@
* response structures.
*/
+/*
+ * Xenstore format in practice
+ * ===
+ *
+ * The backend driver uses a single_host:many_devices notation to manage domU
+ * devices. Everything is stored in /local/domain/0/backend/vscsi/. The
+ * xenstore layout looks like this:
+ *
+ * domid/vhost/feature-host = 0
+ * domid/vhost/frontend = /local/domain/domid/device/vscsi/0
+ * domid/vhost/frontend-id = domid
+ * domid/vhost/online = 1
+ * domid/vhost/state = 4
+ * domid/vhost/vscsi-devs/dev-0/p-dev = 8:0:2:1 or naa.wwn:lun
+ * domid/vhost/vscsi-devs/dev-0/state = 4
+ * domid/vhost/vscsi-devs/dev-0/v-dev = 0:0:0:0
+ * domid/vhost/vscsi-devs/dev-1/p-dev = 8:0:2:2
+ * domid/vhost/vscsi-devs/dev-1/state = 4
+ * domid/vhost/vscsi-devs/dev-1/v-dev = 0:0:1:0
+ *
+ * The frontend driver maintains its state in
+ * /local/domain/domid/device/vscsi/.
+ *
+ * vhost/backend = /local/domain/0/backend/vscsi/domid/vhost
+ * vhost/backend-id = 0
+ * vhost/event-channel = 20
+ * vhost/ring-ref = 43
+ * vhost/state = 4
+ * vhost/vscsi-devs/dev-0/state = 4
+ * vhost/vscsi-devs/dev-1/state = 4
+ *
+ * In addition to the entries for backend and frontend these flags are stored
+ * for the toolstack:
+ *
+ * domid/vhost/vscsi-devs/dev-1/p-devname = /dev/$device
+ *
+ *
+ * Backend/frontend protocol
+ * =
+ *
+ * To create a vhost along with a device:
+ * domid/vhost/feature-host = 0
+ * domid/vhost/frontend = /local/domain/domid/device/vscsi/0
+ * domid/vhost/frontend-id = domid
+ * domid/vhost/online = 1
+ * domid/vhost/state = 1
+ * domid/vhost/vscsi-devs/dev-0/p-dev = 8:0:2:1
+ * domid/vhost/vscsi-devs/dev-0/state = 1
+ * domid/vhost/vscsi-devs/dev-0/v-dev = 0:0:0:0
+ * Wait for domid/vhost/state + domid/vhost/vscsi-devs/dev-0/state
become 4
+ *
+ * To add another device to a vhost:
+ * domid/vhost/state = 7
+ * domid/vhost/vscsi-devs/dev-1/p-dev = 8:0:2:2
+ * domid/vhost/vscsi-devs/dev-1/state = 1
+ * domid/vhost/vscsi-devs/dev-1/v-dev = 0:0:1:0
+ * Wait for domid/vhost/state + domid/vhost/vscsi-devs/dev-1/state
become 4
+ *
+ * To remove a device from a vhost:
+ * domid/vhost/state = 7
+ * domid/vhost/vscsi-devs/dev-1/state = 5
+ * Wait for domid/vhost/state to become 4
+ * Wait for domid/vhost/vscsi-devs/dev-1/state become 6
+ * Remove domid/vhost/vscsi-devs/dev-1/{state,p-dev,v-dev,p-devname}
+ * Remove domid/vhost/vscsi-devs/dev-1/
+ *
+ */
+
/* Requests from the frontend to the backend */
/*
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 1/5] vscsiif.h: fix WWN notation for p-dev property
The pvops kernel expects either naa.WWN:LUN or h:c:t:l in the p-dev property. Add the missing :LUN part to the comment. Signed-off-by: Olaf Hering o...@aepfle.de Cc: Ian Campbell ian.campb...@citrix.com Cc: Ian Jackson ian.jack...@eu.citrix.com Cc: Jan Beulich jbeul...@suse.com Cc: Keir Fraser k...@xen.org Cc: Tim Deegan t...@xen.org --- xen/include/public/io/vscsiif.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/public/io/vscsiif.h b/xen/include/public/io/vscsiif.h index 7a1db05..e8e38a9 100644 --- a/xen/include/public/io/vscsiif.h +++ b/xen/include/public/io/vscsiif.h @@ -60,7 +60,7 @@ * * A string specifying the backend device: either a 4-tuple h:c:t:l * (host, controller, target, lun, all integers), or a WWN (e.g. - * naa.60014054ac780582). + * naa.60014054ac780582:0). * * v-dev * Values: string ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 2/5] docs: add vscsi to xenstore-paths.markdown
On Fri, Apr 17, Olaf Hering wrote: @@ -302,6 +307,10 @@ A virtual keyboard device backend. Described by A virtual network device backend. Described by [xen/include/public/io/netif.h][NETIF] + ~/backend/vscsi/$DOMID/$DEVID/* [] + +A PV SCSI backend. Described in [pvscsi.txt](pvscsi.txt) + ~/backend/console/$DOMID/$DEVID/* [] A PV console backend. Described in [console.txt](console.txt) This hunk still refers to the removed pvscsi.txt. Will be fixed in next version. Olaf ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 06/11] vmx: add help functions to support PML
At 11:32 +0800 on 17 Apr (1429270332), Kai Huang wrote: On 04/17/2015 08:10 AM, Tim Deegan wrote: At 22:57 + on 16 Apr (1429225024), Tian, Kevin wrote: From: Kai Huang [mailto:kai.hu...@linux.intel.com] +if ( !p2m_change_type_one(v-domain, gfn, p2m_ram_logdirty, +p2m_ram_rw) ) +paging_mark_gfn_dirty(v-domain, gfn); Should we handle error from p2m_change_type_one and consequently making this flush function non-void? I don't think we need to return an error, but we should probably call mark_dirty here for anything except -EBUSY. Hi Kevin, Tim, My intention here is to rule out the GFN with original type that is not p2m_ram_logdirty, though with patch 11 it's not likely have such GFN logged. Looks -EBUSY returns exactly when original type is not p2m_ram_logdirty, so I think it might be OK to do as Tim suggested. But given the same thing has already been done in hap_track_dirty_vram (hap_track_dirty_vram-paging_log_dirty_range, in which gfn is set in bitmap with !p2m_change_type_one is true), and in EPT violation (p2m_change_type_one is called unconditionally without checking return value), I think it should be safe to do the current code here. The paging_log_dirty_range case is doing something quite different: it is making pages read-only so they can be tracked, and it needs to mark any page that couldn't be made read-only (because the guest can write to them). Its three cases are: - change succeeded: no mark, we will trap any new writes - EBUSY: mark, since we can't be sure we'll trap new writes - other error: mark, since we can't be sure we'll trap new writes In this case we _know_ the guest has written to the page (because it's in the PML log), so our only reason for not calling mark_dirty() is if we see that someone else has changed the p2m (EBUSY) and that someone else ought to already have DTRT. Now that I've written it out, and since we expect these races to be very rare, I've changed my mind: we should _always_ call mark_dirty here. The extra cost should be negligible, and a missing mark is extremely difficult to debug. Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [v2 06/11] vmx: add help functions to support PML
On 04/17/2015 04:36 PM, Tim Deegan wrote: At 11:32 +0800 on 17 Apr (1429270332), Kai Huang wrote: On 04/17/2015 08:10 AM, Tim Deegan wrote: At 22:57 + on 16 Apr (1429225024), Tian, Kevin wrote: From: Kai Huang [mailto:kai.hu...@linux.intel.com] +if ( !p2m_change_type_one(v-domain, gfn, p2m_ram_logdirty, +p2m_ram_rw) ) +paging_mark_gfn_dirty(v-domain, gfn); Should we handle error from p2m_change_type_one and consequently making this flush function non-void? I don't think we need to return an error, but we should probably call mark_dirty here for anything except -EBUSY. Hi Kevin, Tim, My intention here is to rule out the GFN with original type that is not p2m_ram_logdirty, though with patch 11 it's not likely have such GFN logged. Looks -EBUSY returns exactly when original type is not p2m_ram_logdirty, so I think it might be OK to do as Tim suggested. But given the same thing has already been done in hap_track_dirty_vram (hap_track_dirty_vram-paging_log_dirty_range, in which gfn is set in bitmap with !p2m_change_type_one is true), and in EPT violation (p2m_change_type_one is called unconditionally without checking return value), I think it should be safe to do the current code here. The paging_log_dirty_range case is doing something quite different: it is making pages read-only so they can be tracked, and it needs to mark any page that couldn't be made read-only (because the guest can write to them). Thanks for comprehensive reply. However, looks I can't agree on some points. paging_log_dirty_range currently is only used by hap_track_dirty_vram for video ram tracking, and it doesn't call paging_mark_dirty in any case. Basically, paging_log_dirty_range only does below thing but nothing else: for ( i = 0, pfn = begin_pfn; pfn begin_pfn + nr; i++, pfn++ ) if ( !p2m_change_type_one(d, pfn, p2m_ram_rw, p2m_ram_logdirty) ) dirty_bitmap[i 3] |= (1 (i 7)); From which we can see the purpose of this function (and let us put PML away for now): - change GFN's type from p2m_ram_rw back to p2m_ram_logdirty, in order to be able to log the GFN again (more precisely, to track the GFN again in EPT violation), with the fact that the dirty page's p2m type has been changed from p2m_log_dirty to p2m_ram_rw, in EPT violation. - mark the dirty GFN to the bitmap only when above changing p2m_ram_logdirty to p2m_ram_rw is done successfully. It is reasonable, as only a successful changing from p2m_ram_rw to p2m_ram_dirty means the dirty page has been changed from p2m_ram_logdirty to p2m_ram_rw in EPT violation. Btw, from which we can also note that currently video ram tracking is not via log-dirty radix tree but depends on p2m type change, this is the reason we must call p2m_type_change_one in vmx_vcpu_flush_pml_buffer. Its three cases are: - change succeeded: no mark, we will trap any new writes - EBUSY: mark, since we can't be sure we'll trap new writes - other error: mark, since we can't be sure we'll trap new writes Regarding to the above three cases, I assume you are referring to changing p2m_ram_rw back to p2m_ram_logdirty in paging_log_dirty_range , in which case the paging_mark_dirty is not called at all, as I mentioned above. In this case we _know_ the guest has written to the page (because it's in the PML log), so our only reason for not calling mark_dirty() is if we see that someone else has changed the p2m (EBUSY) and that someone else ought to already have DTRT. I agree on this, given you said we can't be sure for the unsuccessful p2m type change. Now that I've written it out, and since we expect these races to be very rare, I've changed my mind: we should _always_ call mark_dirty here. The extra cost should be negligible, and a missing mark is extremely difficult to debug. Which is also good to me, and in this case we should also call p2m_change_type_one(.., p2m_ram_logdirty, p2m_ram_rw) unconditionally, as this is required for video ram tracking. Thanks, -Kai Cheers, Tim. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC] Linux save_fl PVOP for Xen
On 16/04/15 19:40, Andrew Cooper wrote: Having recently got some Broadwell hardware, our automatic test system discovered that 32bit PV guests would reliably blow up while attempting to boot. It turns out that the save_fl PVOP is at fault. The comment is false, as setup_smap() uses it to check that the Alignment Check flag is clear. As the Xen PVOP leaves everything other than %ah worth of eflags uninitialised, the BUG_ON(eflags X86_EFLAGS_AC) in setup_smap() is unconditional undefined behaviour on all versions of Linux since SMAP support was introduced. I'm somewhat surprised this ever worked... I had developed a patch (see below) and was writing up the commit message, but it would appear that this PVOP is also used by PVHVM domains, which invalidates an assumption underlying the fix (insofar that 'pushf' would unconditionally have IF set). PVHVM uses native save/restore flags. 2) Change setup_smap() to use something like native_safe_fl(). Unlikely to get traction upstream, and fragile to similar changes in the future. This one liner seems preferred to me. Can you try it and see if the x86 maintainers agree? David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] kernel BUG at drivers/xen/grant-table.c:923!
On Fri, 2015-04-17 at 11:31 +0100, David Vrabel wrote:
On 17/04/15 11:28, Ian Campbell wrote:
(Was Re: [osstest test] 50423: regressions - FAIL)
This cropped up in an osstest flight (the results only go to Ian and I).
On Fri, 2015-04-17 at 11:10 +0100, Ian Campbell wrote:
On Thu, 2015-04-16 at 21:36 +, osstest service user wrote:
flight 50423 osstest real [real]
http://logs.test-lab.xenproject.org/osstest/logs/50423/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs.
50331
Looks to have been a real issue:
http://logs.test-lab.xenproject.org/osstest/logs/50423/test-armhf-armhf-xl/serial-cubietruck-gleizes.log
Apr 14 19:01:21.834851 [ 1229.470934] [ cut here ]
Apr 14 19:01:22.445308 [ 1229.471001] kernel BUG at
drivers/xen/grant-table.c:923!
This seems familiar, anyone remember it? (CCing ARM, netback and generic
Linux maintainers).
This doesn't look familiar to me. What BUG_ON() is this?
The one in gnttab_batch_copy:
void gnttab_batch_copy(struct gnttab_copy *batch, unsigned count)
{
struct gnttab_copy *op;
if (HYPERVISOR_grant_table_op(GNTTABOP_copy, batch, count))
BUG();
for (op = batch; op batch + count; op++)
if (op-status == GNTST_eagain)
gnttab_retry_eagain_gop(GNTTABOP_copy, op,
op-status, __func__);
}
EXPORT_SYMBOL_GPL(gnttab_batch_copy);
The actual hypercall has failed, which is a pretty unusual failure case.
r0 == fff2 is likely the return code, which is -14 == EFAULT.
So I suppose something is up with the pointer at batch.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.4-testing test] 50429: tolerable FAIL - PUSHED
flight 50429 xen-4.4-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/50429/ Failures :-/ but no regressions. Tests which are failing intermittently (not blocking): test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail in 50392 pass in 50429 test-amd64-amd64-xl-winxpsp3 15 guest-localmigrate/x10 fail in 50392 pass in 50429 test-armhf-armhf-xl-multivcpu 14 guest-start.2 fail pass in 50392 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail pass in 50392 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-sedf-pin 15 guest-start/debian.repeat fail blocked in 50266 test-amd64-i386-pair21 guest-migrate/src_host/dst_host fail like 36776 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-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 50392 never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 50392 never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 11 guest-start fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 16 guest-stop fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-credit2 6 xen-boot fail never pass test-amd64-i386-xend-winxpsp3 20 leak-check/check fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 16 guest-stop fail never pass build-i386-rumpuserxen6 xen-buildfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass build-amd64-rumpuserxen 6 xen-buildfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-amd64-i386-xl-winxpsp3-vcpus1 16 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 16 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 16 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 16 guest-stop fail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass version targeted for testing: xen 6b09a29ced2e7fc449a39f513e1d8c2b10d2af6d baseline version: xen fc6fe18f1511d4b393057c60a2e6b05ccd963e90 People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com Konrad Rzeszutek Wilk konrad.w...@oracle.com jobs: build-amd64-xend pass build-i386-xend pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-i386-rhel6hvm-amd pass test-amd64-i386-qemut-rhel6hvm-amd pass test-amd64-i386-qemuu-rhel6hvm-amd
Re: [Xen-devel] [PATCHv2 3/6] xen: generic xadd() for ticket locks
On 17/04/15 13:32, Ian Campbell wrote: On Thu, 2015-04-16 at 16:28 +0100, Jan Beulich wrote: On 10.04.15 at 16:19, david.vra...@citrix.com wrote: +#define xadd(ptr, v) generic_xaddl((ptr), (v)) I think it is at least confusing to call the thing xadd (looking to be size generic) and then expand to generic_xaddl (only supporting 32-bit operations), yet subsequently implementing a size-generic xadd() for x86. Indeed, and I went to build on arm32 prior to hacking up a proper xadd and: spinlock.c: In function ‘_spin_lock’: spinlock.c:145:5: error: passing argument 1 of ‘generic_xaddl’ from incompatible pointer type [-Werror] tickets.head_tail = xadd(lock-tickets, tickets.head_tail); ^ spinlock.c:15:12: note: expected ‘volatile u32 *’ but argument is of type ‘union spinlock_tickets_t *’ static u32 generic_xaddl(volatile u32 *ptr, u32 v) ^ (I hope to knock up the arm asm version in the next hour or so, so you may not care...) Can you use git://xenbits.xen.org/people/dvrabel/xen.git ticketlocks-v3 as a base instead? David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv2 3/6] xen: generic xadd() for ticket locks
On Fri, 2015-04-17 at 13:32 +0100, Ian Campbell wrote: On Thu, 2015-04-16 at 16:28 +0100, Jan Beulich wrote: On 10.04.15 at 16:19, david.vra...@citrix.com wrote: +#define xadd(ptr, v) generic_xaddl((ptr), (v)) I think it is at least confusing to call the thing xadd (looking to be size generic) and then expand to generic_xaddl (only supporting 32-bit operations), yet subsequently implementing a size-generic xadd() for x86. Indeed, and I went to build on arm32 prior to hacking up a proper xadd and: Slightly more surprisingly I also see something similar on arm64: spinlock.c: In function ‘_spin_lock’: spinlock.c:145:5: error: passing argument 1 of ‘generic_xaddl’ from incompatible pointer type [-Werror] tickets.head_tail = xadd(lock-tickets, tickets.head_tail); ^ spinlock.c:15:12: note: expected ‘volatile u32 *’ but argument is of type ‘union spinlock_tickets_t *’ static u32 generic_xaddl(volatile u32 *ptr, u32 v) ^ (I hope to knock up the arm asm version in the next hour or so, so you may not care...) ditto. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] crash in efi_runtime_call
On 17.04.15 at 13:59, andrew.coop...@citrix.com wrote: On 17/04/15 12:17, Olaf Hering wrote: Since booting xen fails on my ProBook unless I specify maxcpus=1 I tried the EFI firmware today. To my surprise it boots and finds all cpus. But once some efi driver in dom0 is loaded xen crashes. The same happens with xen-4.4 as included in SLE12. ... (XEN) Xen call trace: (XEN)[aec1e8e1] aec1e8e1 (XEN)[82d080222600] efi_runtime_call+0x7f0/0x890 (XEN)[82d0801641a9] do_platform_op+0x679/0x1670 (XEN)[82d08021dfb9] syscall_enter+0xa9/0xae Can I do anything about it, or is this a firmware bug? I will move the offending efi driver away and try again. Olaf This is a firmware bug. +1 (and I'm surprised how common this is) (XEN) 1-23fff type=7 attr=000 (XEN) 0fec1-0fec10fff type=11 attr=8001 (XEN) 0fff4-0fff46fff type=11 attr=8000 (XEN) Unknown cachability for MFNs 0xfff40-0xfff46 This unknown cacheability causes Xen not to make pagetables for the region. There is a patch or two floating around the list, but currently no resolution on the argument it created. https://github.com/xenserver/xen-4.5.pg/blob/master/master/unknown-cacheabilit y.patch is the XenServer fix. Now that's surely wrong - if anything, unknown should be treated as UC (and quite likely specifically in a case like the one Olaf reports here, as the offending memory range pretty likely is other than normal RAM). What I'd accept as a patch would be the addition of a command line option enforcing the mapping of such unknown cacheability areas with a certain caching type (default then being UC). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] crash in efi_runtime_call
On 17/04/15 13:39, Jan Beulich wrote: On 17.04.15 at 13:59, andrew.coop...@citrix.com wrote: On 17/04/15 12:17, Olaf Hering wrote: Since booting xen fails on my ProBook unless I specify maxcpus=1 I tried the EFI firmware today. To my surprise it boots and finds all cpus. But once some efi driver in dom0 is loaded xen crashes. The same happens with xen-4.4 as included in SLE12. ... (XEN) Xen call trace: (XEN)[aec1e8e1] aec1e8e1 (XEN)[82d080222600] efi_runtime_call+0x7f0/0x890 (XEN)[82d0801641a9] do_platform_op+0x679/0x1670 (XEN)[82d08021dfb9] syscall_enter+0xa9/0xae Can I do anything about it, or is this a firmware bug? I will move the offending efi driver away and try again. Olaf This is a firmware bug. +1 (and I'm surprised how common this is) The bug is present in the reference implementation code, which means it is present in a lot of real firmware. We have kit from 3 different vendors which are affected, including latest available firmware. (XEN) 1-23fff type=7 attr=000 (XEN) 0fec1-0fec10fff type=11 attr=8001 (XEN) 0fff4-0fff46fff type=11 attr=8000 (XEN) Unknown cachability for MFNs 0xfff40-0xfff46 This unknown cacheability causes Xen not to make pagetables for the region. There is a patch or two floating around the list, but currently no resolution on the argument it created. https://github.com/xenserver/xen-4.5.pg/blob/master/master/unknown-cacheabilit y.patch is the XenServer fix. Now that's surely wrong Right or wrong, this is (apparently; I have not checked) what Linux does. - if anything, unknown should be treated as UC (and quite likely specifically in a case like the one Olaf reports here, as the offending memory range pretty likely is other than normal RAM). What I'd accept as a patch would be the addition of a command line option enforcing the mapping of such unknown cacheability areas with a certain caching type (default then being UC). If I can find some copious free time, I will see about making this happen. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] raisin: introduce seabios component
Build SeaBIOS as a separate component.
Pass --with-system-seabios to the xen configure script.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
components/seabios | 57
components/series |1 +
components/xen |3 ++-
defconfig |2 ++
4 files changed, 62 insertions(+), 1 deletion(-)
create mode 100644 components/seabios
diff --git a/components/seabios b/components/seabios
new file mode 100644
index 000..960a538
--- /dev/null
+++ b/components/seabios
@@ -0,0 +1,57 @@
+#!/usr/bin/env bash
+
+function seabios_check_package() {
+local DEP_Debian_common=build-essential iasl
+local DEP_Debian_x86_32=$DEP_Debian_common
+local DEP_Debian_x86_64=$DEP_Debian_common
+local DEP_Debian_arm32=$DEP_Debian_common
+local DEP_Debian_arm64=$DEP_Debian_common
+
+local DEP_Fedora_common=make gcc acpica-tools
+local DEP_Fedora_x86_32=$DEP_Fedora_common
+local DEP_Fedora_x86_64=$DEP_Fedora_common
+
+
+if [[ $ARCH != x86_64 $ARCH != x86_32 ]]
+then
+echo seabios is only supported on x86_32 and x86_64
+return
+fi
+echo Checking SeaBIOS dependencies
+eval check-package \$DEP_$DISTRO_$ARCH
+}
+
+
+function seabios_build() {
+if [[ $ARCH != x86_64 $ARCH != x86_32 ]]
+then
+echo seabios is only supported on x86_32 and x86_64
+return
+fi
+
+cd $BASEDIR
+git-checkout $SEABIOS_URL $SEABIOS_REVISION seabios-dir
+cd seabios-dir
+$RAISIN_MAKE defconfig
+$RAISIN_MAKE
+cd $BASEDIR
+}
+
+function seabios_clean() {
+cd $BASEDIR
+if [[ -d seabios-dir ]]
+then
+cd seabios-dir
+$RAISIN_MAKE distclean
+cd ..
+rm -rf seabios-dir
+fi
+}
+
+function seabios_configure() {
+:
+}
+
+function seabios_unconfigure() {
+:
+}
diff --git a/components/series b/components/series
index d21243a..f0f3cfa 100644
--- a/components/series
+++ b/components/series
@@ -1,3 +1,4 @@
+seabios
xen
qemu
qemu_traditional
diff --git a/components/xen b/components/xen
index d150efb..f64afe6 100644
--- a/components/xen
+++ b/components/xen
@@ -24,7 +24,8 @@ function xen_build() {
git-checkout $XEN_URL $XEN_REVISION xen-dir
cd xen-dir
./configure --prefix=$PREFIX
--with-system-qemu=$PREFIX/lib/xen/bin/qemu-system-i386 \
---disable-qemu-traditional --enable-rombios
+--disable-qemu-traditional --enable-rombios \
+--with-system-seabios=$BASEDIR/seabios-dir/out/bios.bin
$RAISIN_MAKE
$RAISIN_MAKE install DESTDIR=$INST_DIR
cd $BASEDIR
diff --git a/defconfig b/defconfig
index d45e2df..b1a0590 100644
--- a/defconfig
+++ b/defconfig
@@ -16,6 +16,7 @@ DESTDIR=dist
XEN_URL=git://xenbits.xen.org/xen.git
QEMU_URL=git://git.qemu.org/qemu.git
QEMU_TRADITIONAL_URL=git://xenbits.xen.org/qemu-xen-unstable.git
+SEABIOS_URL=git://xenbits.xen.org/seabios.git
GRUB_URL=git://git.savannah.gnu.org/grub.git
LIBVIRT_URL=git://libvirt.org/libvirt.git
@@ -25,5 +26,6 @@ LIBVIRT_URL=git://libvirt.org/libvirt.git
XEN_REVISION=master
QEMU_REVISION=master
QEMU_TRADITIONAL_REVISION=master
+SEABIOS_REVISION=master
GRUB_REVISION=master
LIBVIRT_REVISION=master
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] raisin: build qemu-traditional and seabios
Hi all, This patch series builds qemu-traditional and seabios separately from the Xen tree. It also change the QEMU build to be more Xen specific, installing the QEMU binary under /usr/lib/xen/bin. Changes compared to the previous version of the qemu-traditional patch: - --enable-rombios (otherwise automatically disabled by --disable-qemu-traditional) - suppress unhelpful echo in configure and unconfigure Stefano Stabellini (2): raisin: add a component to build qemu_traditional raisin: introduce seabios component components/qemu_traditional | 49 + components/seabios | 57 +++ components/series |2 ++ components/xen |4 ++- defconfig |4 +++ 5 files changed, 115 insertions(+), 1 deletion(-) create mode 100644 components/qemu_traditional create mode 100644 components/seabios Cheers, Stefano ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv2 3/6] xen: generic xadd() for ticket locks
On Fri, 2015-04-17 at 13:34 +0100, David Vrabel wrote: On 17/04/15 13:32, Ian Campbell wrote: On Thu, 2015-04-16 at 16:28 +0100, Jan Beulich wrote: On 10.04.15 at 16:19, david.vra...@citrix.com wrote: +#define xadd(ptr, v) generic_xaddl((ptr), (v)) I think it is at least confusing to call the thing xadd (looking to be size generic) and then expand to generic_xaddl (only supporting 32-bit operations), yet subsequently implementing a size-generic xadd() for x86. Indeed, and I went to build on arm32 prior to hacking up a proper xadd and: spinlock.c: In function ‘_spin_lock’: spinlock.c:145:5: error: passing argument 1 of ‘generic_xaddl’ from incompatible pointer type [-Werror] tickets.head_tail = xadd(lock-tickets, tickets.head_tail); ^ spinlock.c:15:12: note: expected ‘volatile u32 *’ but argument is of type ‘union spinlock_tickets_t *’ static u32 generic_xaddl(volatile u32 *ptr, u32 v) ^ (I hope to knock up the arm asm version in the next hour or so, so you may not care...) Can you use git://xenbits.xen.org/people/dvrabel/xen.git ticketlocks-v3 as a base instead? I tried that and it built and booted just fine on both arm32 and arm64. I eyeballed the assembly produced via the use of __sync_fetch_and_add (for _spin_lock only) and it is exactly what I would have written in my own versions. I was using gcc 4.8.3 in both cases. For arm64 I'm pretty sure we don't want to consider anything earlier. For arm32 I have also tried gcc 4.6.3 (Debian Wheezy's compiler) and it built and booted, and eyeballing shows the same asm. I think that's the earliest we really need to worry about. IOW I'm not going to bother with custom versions of these functions on ARM. If you wanted you could drop the #ifndef xadd from asm-arm/system.h. Perhaps it would be useful to add some of the info from my tests reported above, or a reference to this mail, to the commit log? in either case you can add: Acked-by: Ian Campbell ian.campb...@citrix.com to the patch below. commit b08cf3fa4791d7ff0d01fb932192e02078ce670a Author: David Vrabel david.vra...@citrix.com Date: Thu Apr 16 15:31:18 2015 +0100 arm: provide xadd() xadd() atomically adds a value and returns the previous value. This is needed to implement ticket locks. This generic arm implementation uses the GCC __sync_fetch_and_add() builtin, but a arm32 or arm64 specific variant could be provided in the future (e.g., if required to support older versions of GCC). Signed-off-by: David Vrabel david.vra...@citrix.com diff --git a/xen/include/asm-arm/system.h b/xen/include/asm-arm/system.h index ce3d38a..f037e84 100644 --- a/xen/include/asm-arm/system.h +++ b/xen/include/asm-arm/system.h @@ -51,6 +51,10 @@ # error unknown ARM variant #endif +#ifndef xadd +# define xadd(x, v) __sync_fetch_and_add(x, v) +#endif + extern struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next); #endif Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/2] raisin: add a component to build qemu_traditional
Introduce a component to build qemu-traditional out of xen-unstable.
Do not compile qemu-traditional from xen-unstable by passing the right
command line option to configure.
Signed-off-by: Stefano Stabellini stefano.stabell...@eu.citrix.com
---
components/qemu_traditional | 49 +++
components/series |1 +
components/xen |3 ++-
defconfig |2 ++
4 files changed, 54 insertions(+), 1 deletion(-)
create mode 100644 components/qemu_traditional
diff --git a/components/qemu_traditional b/components/qemu_traditional
new file mode 100644
index 000..500cbed
--- /dev/null
+++ b/components/qemu_traditional
@@ -0,0 +1,49 @@
+#!/usr/bin/env bash
+
+function qemu_traditional_check_package() {
+local DEP_Debian_common=build-essential zlib1g-dev pciutils-dev
pkg-config \
+ libncurses5-dev
+local DEP_Debian_x86_32=$DEP_Debian_common
+local DEP_Debian_x86_64=$DEP_Debian_common
+local DEP_Debian_arm32=$DEP_Debian_common
+local DEP_Debian_arm64=$DEP_Debian_common
+
+local DEP_Fedora_common=make gcc zlib-devel ncurses-devel pciutils-devel
+local DEP_Fedora_x86_32=$DEP_Fedora_common
+local DEP_Fedora_x86_64=$DEP_Fedora_common
+
+echo Checking QEMU dependencies
+eval check-package \$DEP_$DISTRO_$ARCH
+}
+
+function qemu_traditional_build() {
+cd $BASEDIR
+git-checkout $QEMU_TRADITIONAL_URL $QEMU_TRADITIONAL_REVISION
qemu_traditional-dir
+cd qemu_traditional-dir
+
+export CONFIG_BLKTAP1=n
+export XEN_ROOT=$BASEDIR/xen-dir
+./xen-setup
+$RAISIN_MAKE all
+$RAISIN_MAKE install DESTDIR=$INST_DIR
+cd $BASEDIR
+}
+
+function qemu_traditional_clean() {
+cd $BASEDIR
+if [[ -d qemu_traditional-dir ]]
+then
+cd qemu_traditional-dir
+$MAKE distclean
+cd ..
+rm -rf qemu_traditional-dir
+fi
+}
+
+function qemu_traditional_configure() {
+:
+}
+
+function qemu_traditional_unconfigure() {
+:
+}
diff --git a/components/series b/components/series
index 8f614f0..d21243a 100644
--- a/components/series
+++ b/components/series
@@ -1,4 +1,5 @@
xen
qemu
+qemu_traditional
grub
libvirt
diff --git a/components/xen b/components/xen
index f8959be..d150efb 100644
--- a/components/xen
+++ b/components/xen
@@ -23,7 +23,8 @@ function xen_build() {
cd $BASEDIR
git-checkout $XEN_URL $XEN_REVISION xen-dir
cd xen-dir
-./configure --prefix=$PREFIX
--with-system-qemu=$PREFIX/lib/xen/bin/qemu-system-i386
+./configure --prefix=$PREFIX
--with-system-qemu=$PREFIX/lib/xen/bin/qemu-system-i386 \
+--disable-qemu-traditional --enable-rombios
$RAISIN_MAKE
$RAISIN_MAKE install DESTDIR=$INST_DIR
cd $BASEDIR
diff --git a/defconfig b/defconfig
index 23c76eb..d45e2df 100644
--- a/defconfig
+++ b/defconfig
@@ -15,6 +15,7 @@ DESTDIR=dist
#LIBVIRT_URL=https://gitorious.org/libvirt/libvirt.git;
XEN_URL=git://xenbits.xen.org/xen.git
QEMU_URL=git://git.qemu.org/qemu.git
+QEMU_TRADITIONAL_URL=git://xenbits.xen.org/qemu-xen-unstable.git
GRUB_URL=git://git.savannah.gnu.org/grub.git
LIBVIRT_URL=git://libvirt.org/libvirt.git
@@ -23,5 +24,6 @@ LIBVIRT_URL=git://libvirt.org/libvirt.git
# Grub and Libvirt needs Xen to build and run.
XEN_REVISION=master
QEMU_REVISION=master
+QEMU_TRADITIONAL_REVISION=master
GRUB_REVISION=master
LIBVIRT_REVISION=master
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv2 3/6] xen: generic xadd() for ticket locks
On Thu, 2015-04-16 at 16:28 +0100, Jan Beulich wrote: On 10.04.15 at 16:19, david.vra...@citrix.com wrote: +#define xadd(ptr, v) generic_xaddl((ptr), (v)) I think it is at least confusing to call the thing xadd (looking to be size generic) and then expand to generic_xaddl (only supporting 32-bit operations), yet subsequently implementing a size-generic xadd() for x86. Indeed, and I went to build on arm32 prior to hacking up a proper xadd and: spinlock.c: In function ‘_spin_lock’: spinlock.c:145:5: error: passing argument 1 of ‘generic_xaddl’ from incompatible pointer type [-Werror] tickets.head_tail = xadd(lock-tickets, tickets.head_tail); ^ spinlock.c:15:12: note: expected ‘volatile u32 *’ but argument is of type ‘union spinlock_tickets_t *’ static u32 generic_xaddl(volatile u32 *ptr, u32 v) ^ (I hope to knock up the arm asm version in the next hour or so, so you may not care...) Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv2 3/6] xen: generic xadd() for ticket locks
On 17/04/15 14:09, Ian Campbell wrote: On Fri, 2015-04-17 at 13:34 +0100, David Vrabel wrote: Can you use git://xenbits.xen.org/people/dvrabel/xen.git ticketlocks-v3 git://xenbits.xen.org/people/dvrabel/xen.git ticketlock-v3 I tried that and it built and booted just fine on both arm32 and arm64. I eyeballed the assembly produced via the use of __sync_fetch_and_add (for _spin_lock only) and it is exactly what I would have written in my own versions. I was using gcc 4.8.3 in both cases. For arm64 I'm pretty sure we don't want to consider anything earlier. For arm32 I have also tried gcc 4.6.3 (Debian Wheezy's compiler) and it built and booted, and eyeballing shows the same asm. I think that's the earliest we really need to worry about. IOW I'm not going to bother with custom versions of these functions on ARM. If you wanted you could drop the #ifndef xadd from asm-arm/system.h. Perhaps it would be useful to add some of the info from my tests reported above, or a reference to this mail, to the commit log? in either case you can add: Acked-by: Ian Campbell ian.campb...@citrix.com Thanks, Ian! David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 6/8] raisin: Break build into components and allow the sub-steps to be called individually
On Thu, 16 Apr 2015, George Dunlap wrote:
This makes it easier to debug just one aspect of the build.
Signed-off-by: George Dunlap george.dun...@eu.citrix.com
---
CC: Stefano Stabellini stefano.stabell...@citrix.com
---
lib/commands.sh | 16
raise | 2 +-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/lib/commands.sh b/lib/commands.sh
index 17e2129..c5df9ad 100755
--- a/lib/commands.sh
+++ b/lib/commands.sh
@@ -45,17 +45,25 @@ function install-builddep() {
YES=y check-builddep
}
-function build() {
-check-builddep
-
+function build-only() {
mkdir -p $INST_DIR /dev/null
# build and install under $DESTDIR
for_each_component build
-
+}
+
+function build-package() {
build_package xen-system
}
+function build() {
+check-builddep
+
+build-only
+
+build-package
+}
+
function unraise() {
for_each_component clean
diff --git a/raise b/raise
index bce6908..59de04a 100755
--- a/raise
+++ b/raise
@@ -64,7 +64,7 @@ do
done
case $1 in
-install-builddep | build | install | configure | unraise )
+install-builddep | build | build-only | build-package |
install | configure | unraise )
COMMAND=$1
;;
*)
You have added two new commands, but they are not documented in the help
function or in the README. As they stand they are hidden commands. Is
that on purpose because they are supposed to be used just for debugging?
Maybe it would be worth documenting debugging functions too somewhere.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 8/8] raisin: RFC Add blktap2 as an external tree
On Thu, 16 Apr 2015, George Dunlap wrote:
Until we start hosting the blktap repo on xenbits, use the one from github.
Also, we need to pass in the directories where to find the
libblktapctl headers in the Xen build.
Signed-off-by: George Dunlap george.dun...@eu.citrix.com
---
Note: For now use the upstream XenServer repo.
Also, to build with this you need the patches to allow Xen to use an
out-of-tree blktap,
which can be found here:
git://xenbits.xen.org/people/gdunlap/xen.git out/blktap25/rfc-v2
CC: Stefano Stabellini stefano.stabell...@citrix.com
---
components/blktap | 47 +++
components/series | 1 +
components/xen| 5 +
defconfig | 9 ++---
4 files changed, 59 insertions(+), 3 deletions(-)
create mode 100644 components/blktap
diff --git a/components/blktap b/components/blktap
new file mode 100644
index 000..3062b2a
--- /dev/null
+++ b/components/blktap
@@ -0,0 +1,47 @@
+#!/usr/bin/env bash
+
+function blktap_check_package() {
+local DEP_Debian_common=build-essential autoconf libtool tar libaio-dev
uuid-dev openssl-dev
+local DEP_Debian_x86_32=$DEP_Debian_common
+local DEP_Debian_x86_64=$DEP_Debian_x86_32
+local DEP_Debian_arm32=$DEP_Debian_common
+local DEP_Debian_arm64=$DEP_Debian_arm32
+
+local DEP_Fedora_common=make gcc python-devel autoconf libtool tar file
libaio-devel libuuid-devel openssl-devel
+local DEP_Fedora_x86_32=$DEP_Fedora_common
+local DEP_Fedora_x86_64=$DEP_Fedora_x86_32
+
+local DEP_CentOS_common=make gcc python-devel autoconf libtool tar file
libaio-devel libuuid-devel openssl-devel
+local DEP_CentOS_x86_32=$DEP_Redhat_common
+local DEP_CentOS_x86_64=$DEP_Redhat_x86_32
+
+echo Checking blktap dependencies
+eval check-package \$DEP_$DISTRO_$ARCH
+}
+
+function blktap_build() {
+cd $BASEDIR
+git-checkout $BLKTAP_URL $BLKTAP_REVISION blktap-dir
+cd blktap-dir
+./autogen.sh
+./configure --prefix=$PREFIX
+$MAKE
+$MAKE install DESTDIR=$INST_DIR
+cd $BASEDIR
+}
I think we need to disable the build on architectures other than x86,
see grub for example
+function blktap_clean() {
+cd $BASEDIR
+if [[ -d blktap-dir ]]
+then
+ rm -rf blktap-dir
+fi
+}
+
+function blktap_configure() {
+:
+}
+
+function blktap_unconfigure() {
+:
+}
diff --git a/components/series b/components/series
index 8f614f0..953800a 100644
--- a/components/series
+++ b/components/series
@@ -1,3 +1,4 @@
+blktap
xen
qemu
grub
diff --git a/components/xen b/components/xen
index f2e1254..03a1970 100644
--- a/components/xen
+++ b/components/xen
@@ -29,7 +29,12 @@ function xen_build() {
cd $BASEDIR
git-checkout $XEN_URL $XEN_REVISION xen-dir
cd xen-dir
+CFLAGS=-I$INST_DIR/$PREFIX/include/blktap
-I$INST_DIR/$PREFIX/include/vhd \
+LDFLAGS=-L$INST_DIR/$PREFIX/lib -Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
./configure --prefix=$PREFIX --with-system-qemu=/usr/bin/qemu-system-i386
+CFLAGS_libblktapctl=-I$INST_DIR/$PREFIX/include/blktap
-I$INST_DIR/$PREFIX/include/vhd \
+LDLIBS_libblktapctl=-L$INST_DIR/$PREFIX/lib -lblktapctl \
+SHLIB_libblktapctl=-Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
$RAISIN_MAKE
$RAISIN_MAKE install DESTDIR=$INST_DIR
cd $BASEDIR
diff --git a/defconfig b/defconfig
index 4ec8a0b..283e954 100644
--- a/defconfig
+++ b/defconfig
@@ -1,9 +1,9 @@
# Config variables for raisin
# Components
-# All components: xen grub libvirt
-# Core xen functionality: xen
-DEFAULT_COMPONENTS=xen grub libvirt
+# All components: blktap xen grub libvirt
+# Core xen functionality: xen blktap
+DEFAULT_COMPONENTS=blktap xen grub libvirt
# Build config
## Make command to run
@@ -22,6 +22,8 @@ XEN_URL=git://xenbits.xen.org/xen.git
QEMU_URL=git://git.qemu.org/qemu.git
GRUB_URL=git://git.savannah.gnu.org/grub.git
LIBVIRT_URL=git://libvirt.org/libvirt.git
+BLKTAP_URL=https://github.com/xapi-project/blktap.git
+#BLKTAP_URL=git://xenbits.xen.org/blktap.git
# Software versions. Leave blank if you want to avoid the build, like
# this: GRUB_REVISION=
@@ -30,3 +32,4 @@ XEN_REVISION=master
QEMU_REVISION=master
GRUB_REVISION=master
LIBVIRT_REVISION=master
+BLKTAP_REVISION=blktap2
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V2] xen/arm64: Use virtual address when setting up early_printk fixmap
On Wed, Apr 15, 2015 at 03:41:44PM +0100, Ian Campbell wrote: On Wed, 2015-04-08 at 12:33 +0100, Julien Grall wrote: Hi Chen, On 07/04/15 12:24, Chen Baozi wrote: We have already had the boot pagetable when reaching the point s/had/added/ ? I think switched too is what was meant and more correct. So do I ;-) of early_printk fixmap setup. Thus there is no longer necessary s/there is/it is/ ? Yes. to calculate physical address of xen_fixmap. Signed-off-by: Chen Baozi baoz...@gmail.com Other than the possible typoes above: Reviewed-by: Julien Grall julien.gr...@citrix.com Acked-by: Ian Campbell ian.campb...@citrix.com If it is confirmed that I got the correct meaning in the first one I can fix both on commit. Yes, please. Thanks. Baozi ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 13/19] xen: arm: Annotate registers trapped by MDCR_EL2.TDRA
On Mon, 2015-04-06 at 15:24 +0200, Julien Grall wrote:
Hi Ian,
On 31/03/2015 12:07, Ian Campbell wrote:
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/traps.c | 32
xen/include/asm-arm/cpregs.h |4
xen/include/asm-arm/sysregs.h |1 +
3 files changed, 37 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 21bef01..7c37cec 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1790,6 +1790,17 @@ static void do_cp14_32(struct cpu_user_regs *regs,
const union hsr hsr)
switch ( hsr.bits HSR_CP32_REGS_MASK )
{
+/*
+ * MDCR_EL2.TDRA
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.15
+ * ARMv8 (DDI 0487A.d): D1-1508 Table D1-57
+ *
+ * Unhandled:
+ *DBGDRAR
+ *DBGDSAR
+ */
+
Why did you put the comment here? For AArch32, only DBGDRAR and DBGSAR
are trapped with this bit.
I think this should be moved above the label default.
Yes, not sure how it got out of place here. Moved.
case HSR_CPREG32(DBGDIDR):
/*
* Read-only register. Accessible by EL0 if DBGDSCRext.UDCCdis
@@ -1840,6 +1851,8 @@ static void do_cp14_32(struct cpu_user_regs *regs,
const union hsr hsr)
*
* ARMv7 (DDI 0406C.b): B1.14.16
* ARMv8 (DDI 0487A.d): D1-1507 Table D1-54
+ *
+ * And all other unknown registers.
*/
default:
gdprintk(XENLOG_ERR,
@@ -1870,6 +1883,17 @@ static void do_cp14_64(struct cpu_user_regs *regs,
const union hsr hsr)
*
* ARMv7 (DDI 0406C.b): B1.14.16
* ARMv8 (DDI 0487A.d): D1-1507 Table D1-54
+ *
+ * MDCR_EL2.TDRA
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.15
+ * ARMv8 (DDI 0487A.d): D1-1508 Table D1-57
+ *
+ * Unhandled:
+ *DBGDRAR64
+ *DBGDSAR64
This is confusing. The real name of the register is DBGDRAR. I would say
DBGDRAR 64-bit.
Yes, this was a tricky one because the register is actually two (a 32
and 64 version), hence in the #define I had to add a suffix and I
duplicated that here.
Instead I'll make both of them DBGDRAR (NN-bit accesses), similar to
what I did for the #defines
Furthermore, this is the only registers not handled on AArch32 for this
bit. This is rather strange to list them while you didn't do it for the
trace registers.
My intention was that every register trapped by a bit which we set be
listed somewhere, to make it easier to cross reference with the docs and
check we haven't accidentally forgotten something (as opposed to
deliberately ignoring as indicated by these comments).
You seem to be saying I've missed some trace registers, which ones?
+ *
+ * And all other unknown registers.
For consistency, I would have add this part of the comment in patch #10
(where the comment has been added).
Anyway, the patch is already written so I'm fine with it.
I was rebasing any way so I did this.
*/
gdprintk(XENLOG_ERR,
%s p14, %d, r%d, r%d, cr%d @ 0x%PRIregister\n,
@@ -1936,6 +1960,14 @@ static void do_sysreg(struct cpu_user_regs *regs,
*x = v-arch.actlr;
break;
+/*
+ * MDCR_EL2.TDRA
+ *
+ * ARMv8 (DDI 0487A.d): D1-1508 Table D1-57
+ */
+case HSR_SYSREG_MDRAR_EL1:
+return handle_ro_raz(regs, x, hsr.sysreg.read, hsr, 1);
This change should be in a separate patch or mention in the commit message.
I just added a mention of it since it is the AArch64 version of DBGDRAR.
I can't remember why I made this raz instead of trapping like with
DBGDRAR, but since I already wrote it I left them as is.
Ian
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 15/19] xen: arm: Annotate registers trapped by MDCR_EL2.TDA
On Mon, 2015-04-06 at 15:41 +0200, Julien Grall wrote: Hi Ian, On 31/03/2015 12:07, Ian Campbell wrote: Gather the affected handlers in a single place per trap type. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- xen/arch/arm/traps.c | 71 ++ 1 file changed, 60 insertions(+), 11 deletions(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 518f047..0ab5e56 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -1816,6 +1816,28 @@ static void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr) case HSR_CPREG32(DBGOSDLR): return handle_raz_wi(regs, r, cp32.read, hsr, 1); +/* + * MDCR_EL2.TDA + * + * ARMv7 (DDI 0406C.b): B1.14.15 + * ARMv8 (DDI 0487A.d): D1-1510 Table D1-59 + * + * Unhandled: + *DBGDCCINT + *DBGDTRRXint + *DBGDTRTXint + *DBGWFAR + *DBGDTRTXext + *DBGDTRRXext, + *DBGBXVRn + *DBGCLAIMSET + *DBGCLAIMCLR + *DBGAUTHSTATUS + *DBGDEVID + *DBGDEVID1 + *DBGDEVID2 + *DBGOSECCR Listing unhandled registers doesn't bring much information. Actually it does and it was quite deliberate and part of the purpose of the series. By listing these unhandled registers you can now look at the docs (in particular the ARMv8 table is very good for this) and see immediately that every register is either handled or listed as unhandled. Without that you need to remember why certain things aren't handled in order to distinguish them from things which have been accidentally forgotten. Also, it's very confusing that you are mixing AArch64 name with AArch32 name. The former is used for the traps register while the latter is used for register name. For the traps register where it is similar enough I chose to only list the Aarch64 name, since that is what we use when we write it. I could write both I suppose but it didn't seem especially useful. For the registers themselves it is easier to correlate with the docs if the name which is relevant to the context (e.g. an arm32 vs arm64 handler). Comparing two lists where one is Aarch64 names and the other Aarch32 is hard, especially in the dbg registers where the names don't always correlate especially obviously. The only change I'd be willing to make here would be to list HDCR.TDA after MDCR_EL2.TDA. + */ case HSR_CPREG32(DBGDIDR): /* * Read-only register. Accessible by EL0 if DBGDSCRext.UDCCdis @@ -1925,6 +1947,17 @@ static void do_cp14_dbg(struct cpu_user_regs *regs, const union hsr hsr) return; } +/* + * MDCR_EL2.TDOSA Did you mean MDCR_EL2.TDA? [..] No, this hunk should have been in the previous patch. Moved. case HSR_SYSREG_MDSCR_EL1: -/* - Breakpoints */ [..] -/* - Watchpoints */ I think this 2 comments was useful in order to split the list of registers. In the new code this is just: HSR_SYSREG_DBG_CASES(DBGBVR): HSR_SYSREG_DBG_CASES(DBGBCR): HSR_SYSREG_DBG_CASES(DBGWVR): HSR_SYSREG_DBG_CASES(DBGWCR): return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); I don't think the comments were adding much any more, especially given we aren't actually doing anything with them. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Question about DMA on 1:1 mapping dom0 of arm64
On Fri, 17 Apr 2015, Ian Campbell wrote: On Fri, 2015-04-17 at 19:24 +0800, Chen Baozi wrote: Hi all, According to my recent experience, there might be some problems of swiotlb dma map on 1:1 mapping arm64 dom0 with large memory. The issue is like below: For those arm64 server with large memory, it is possible to set dom0_mem 4G (e.g. I have one set with 16G). In this case, according to my understanding, there is chance that the dom0 kernel needs to map some buffers above 4G to do ^below? DMA operations (e.g. in snps,dwmac ethernet driver). However, most DMA engines support only 32-bit physical address, thus aren't able to operate directly on those memory. Even on arm64 systems with RAM above 4GB? That seems short-sighted. Oh well, I suppose we have to live with it. IIUC, swiotlb is implemented to solve this (using bounce buffer), if there is no IOMMU or IOMMU is not enabled on the system. Sadly, it seems that xen_swiotlb_map_page in my dom0 kernel allocates (start_dma_addr = 0x94480) the buffers for DMA above 4G which fails dma_capable() checking and was then unable to return from xen_swiotlb_map_page() successfully. The swiotlb bounce buffer have been allocated below 4GB? I suspect that xen_swiotlb_init is buggy for ARM -- it allocates some random pages and then swizzles the backing pages for ones 4G, but that won't work on an ARM dom0 with a 1:1 mapping, I don't think. Do you see error messages along those lines? Essentially I think either xen_swiotlb_fixup is unable to work on ARM, or the following: start_dma_addr = xen_virt_to_bus(xen_io_tlb_start); is returning 1:1 and not reflecting the fixup. The swiotlb on arm doesn't necessarily get memory under 4G, see my other reply. If I set dom0_mem to a small value (e.g. 512M), which makes all physical memory of dom0 below 4G, everything goes fine. So you are getting allocated memory below 4G? You message on IRC suggested you weren't, did you hack around this? I think we have two options, either xen_swiotlb_init allocates pages below 4GB (e.g. __GFP_DMA) or we do something to allow xen_swiotlb_fixup to actually work even on a 1:1 dom0. I don't think that making xen_swiotlb_fixup work on ARM is a good idea: it would break the 1:1. Although the first option seems preferable at first glance it has the short coming that it requires dom0 to have some memory below 4GB, which might not necessarily be the case. I think we should arrange dom0 to get some memory under 4G to begin with, not necessarily all of it. The second option seems like it might be uglier but doesn't suffer from this issue. Can you please look and find out if the IPA at 0x94480 is actually backed by 1:1 RAM or if xen_swiotlb_fixup has done it's job and updated things such that the associated PAs are below 4GB? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Question about DMA on 1:1 mapping dom0 of arm64
On Fri, 2015-04-17 at 15:32 +0100, Stefano Stabellini wrote: I think that given that dom0 is mapped 1:1 on ARM, the easiest and best fix would be to simply allocate memory under 4G to begin with. Not necessarily best, see my reply (hint: dom0 might not have RAM under 4GB even if the host does). ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 12/12] docs: add xl-psr.markdown
On Thu, Apr 16, 2015 at 12:58:16PM +0100, Ian Campbell wrote: On Thu, 2015-04-09 at 17:18 +0800, Chao Peng wrote: BTW, do you know if someone is planning to work on libvirt integration for this stuff? As I know, there are people from Intel will take care of this. (Aside: cache-occupancy would be more in keeping with the interfaces, oh well, you can fix if you feel like it, or not bother if you like). It's fixed in v5. + +Detailed information please refer to Intel SDM chapter 17.15. Perhaps a few simple examples, would make the basics clearer without having to hit the SDM for the full gory detail e.g. For example, assuming a system with 8 portions and 3 domains: A CBM of 0xff for every domain means each domain can access the whole cache. This is the default. Giving one domain a CBM of 0x0F and the other two domain's 0xF0 means that the first domain gets exclusive access to half of the cache (half of the portions) and the other two will share the other half. Giving one domain a CBM of 0x0F, one 0x30 and the last 0xc0 would give the first domain exclusive access to half the cache, and the other two exclusive access to one quarter each. Then have the reference the SDM for more detailed stuff. Thank you, for typing so much ... Chao ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Question about DMA on 1:1 mapping dom0 of arm64
On Fri, 2015-04-17 at 15:34 +0100, Stefano Stabellini wrote: If I set dom0_mem to a small value (e.g. 512M), which makes all physical memory of dom0 below 4G, everything goes fine. So you are getting allocated memory below 4G? You message on IRC suggested you weren't, did you hack around this? I think we have two options, either xen_swiotlb_init allocates pages below 4GB (e.g. __GFP_DMA) or we do something to allow xen_swiotlb_fixup to actually work even on a 1:1 dom0. I don't think that making xen_swiotlb_fixup work on ARM is a good idea: it would break the 1:1. This would actually work though, I think, because this is the swiotlb so we definitely have the opportunity to return the actual DMA address whenever we use this buffer and the device will use it in the right places for sure. The swiotlb buffer can't ever get reused for anything else so we don't even need to worry about undoing the damage later. Although the first option seems preferable at first glance it has the short coming that it requires dom0 to have some memory below 4GB, which might not necessarily be the case. I think we should arrange dom0 to get some memory under 4G to begin with, not necessarily all of it. It's another option for sure, the question is how to decide how much, and how to make it configurable etc. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 2/3] xen: arm: propagate gic's #interrupt-cells property to dom0.
On Mon, 2015-03-16 at 16:01 +, Julien Grall wrote:
Hi Ian,
On 12/03/15 17:17, Ian Campbell wrote:
This is similar to 816f5bb1f074 xen: arm: propagate gic's
should propagate (rather than invent our own value) since this value
is used to size fields within other properties within the tree.
I'm not sure why I didn't do this as part of 816f5bb1f074. I think
probably just because #interrupt-cells must always be 3 for a GIC
whereas #address-cells can legitimately differ. Regardless, I think we
might as well do this in common code.
Hmmm... We are creating some interrupt ourself assuming the number of
interrupt cells is 3. So it makes sense to hard-code (not really invent)
the value.
I'll move the addition to common code but leave it as hard coded then.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
xen/arch/arm/domain_build.c | 18 +-
xen/arch/arm/gic-hip04.c|4
xen/arch/arm/gic-v2.c |4
xen/arch/arm/gic-v3.c |4
4 files changed, 13 insertions(+), 17 deletions(-)
diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index ab4ad65..2a2fc2b 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -784,8 +784,8 @@ static int make_gic_node(const struct domain *d, void
*fdt,
{
const struct dt_device_node *gic = dt_interrupt_controller;
int res = 0;
-const void *addrcells;
-u32 addrcells_len;
+const void *cells;
+u32 cells_len;
/*
* Xen currently supports only a single GIC. Discard any secondary
@@ -815,10 +815,18 @@ static int make_gic_node(const struct domain *d, void
*fdt,
return res;
}
-addrcells = dt_get_property(gic, #address-cells, addrcells_len);
-if ( addrcells )
+cells = dt_get_property(gic, #address-cells, cells_len);
+if ( cells )
{
-res = fdt_property(fdt, #address-cells, addrcells,
addrcells_len);
+res = fdt_property(fdt, #address-cells, cells, cells_len);
+if ( res )
+return res;
+}
+
+cells = dt_get_property(gic, #interrupt-cells, cells_len);
+if ( cells )
+{
+res = fdt_property(fdt, #interrupt-cells, cells, cells_len);
The #interrupt-cells as to be present at any time for the GIC. So I
don't think it's worth to check if it presents. Maybe an ASSERT would be
enough?
With the change discussed above it becomes moot.
Also, I would check somewhere that the value is effectively 3 otherwise
we are in trouble for the timer/evtchn interrupt creation. Though, it
was there before too.
Probably somewhere should but I'm not sure where.
diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index ab80670..528500a 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -1102,10 +1102,6 @@ static int gicv3_make_dt_node(const struct domain *d,
if ( res )
return res;
-res = fdt_property_cell(fdt, #interrupt-cells, 3);
-if ( res )
-return res;
-
res = fdt_property(fdt, interrupt-controller, NULL, 0);
if ( res )
return res;
While you move #interrupt-cells to common code. Could you move
interrupt-controller too?
I suppose I may as well.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 19/19] xen: arm: Annotate source of ICC SGI register trapping
I was unable to find an ARMv8 ARM reference to this, so refer to the
GIC Architecture Specification instead.
ARMv8 ARM does cover other ways of trapping these accesses via
ICH_HCR_EL2 but we don't use those and they trap additional registers
as well.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Reviewed-by: Julien Grall julien.gr...@citrix.com
---
xen/arch/arm/traps.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index ad6ff05..6fe9b7a 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2154,6 +2154,12 @@ static void do_sysreg(struct cpu_user_regs *regs,
return inject_undef_exception(regs, hsr);
break;
+/*
+ * HCR_EL2.FMO or HCR_EL2.IMO
+ *
+ * ARMv8: GIC Architecture Specification (PRD03-GENC-010745 24.0)
+ *Section 4.6.8.
+ */
case HSR_SYSREG_ICC_SGI1R_EL1:
if ( !vgic_emulate(regs, hsr) )
{
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 01/19] xen: arm: constify union hsr and struct hsr_* where possible.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Reviewed-by: Julien Grall julien.gr...@citrix.com
---
xen/arch/arm/traps.c | 41 +
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index aaa9d93..69b9513 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -447,7 +447,7 @@ static vaddr_t exception_handler64(struct cpu_user_regs
*regs, vaddr_t offset)
static void inject_undef64_exception(struct cpu_user_regs *regs, int instr_len)
{
vaddr_t handler;
-union hsr esr = {
+const union hsr esr = {
.iss = 0,
.len = instr_len,
.ec = HSR_EC_UNKNOWN,
@@ -1141,7 +1141,7 @@ int do_bug_frame(struct cpu_user_regs *regs, vaddr_t pc)
}
#ifdef CONFIG_ARM_64
-static void do_trap_brk(struct cpu_user_regs *regs, union hsr hsr)
+static void do_trap_brk(struct cpu_user_regs *regs, const union hsr hsr)
{
/* HCR_EL2.TGE and MDCR_EL2.TDE are not set so we never receive
* software breakpoint exception for EL1 and EL0 here.
@@ -1488,7 +1488,8 @@ static const unsigned short cc_map[16] = {
0 /* NV */
};
-static int check_conditional_instr(struct cpu_user_regs *regs, union hsr hsr)
+static int check_conditional_instr(struct cpu_user_regs *regs,
+ const union hsr hsr)
{
unsigned long cpsr, cpsr_cond;
int cond;
@@ -1533,7 +1534,7 @@ static int check_conditional_instr(struct cpu_user_regs
*regs, union hsr hsr)
return 1;
}
-static void advance_pc(struct cpu_user_regs *regs, union hsr hsr)
+static void advance_pc(struct cpu_user_regs *regs, const union hsr hsr)
{
unsigned long itbits, cond, cpsr = regs-cpsr;
@@ -1574,9 +1575,9 @@ static void advance_pc(struct cpu_user_regs *regs, union
hsr hsr)
}
static void do_cp15_32(struct cpu_user_regs *regs,
- union hsr hsr)
+ const union hsr hsr)
{
-struct hsr_cp32 cp32 = hsr.cp32;
+const struct hsr_cp32 cp32 = hsr.cp32;
uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
struct vcpu *v = current;
@@ -1659,7 +1660,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
}
static void do_cp15_64(struct cpu_user_regs *regs,
- union hsr hsr)
+ const union hsr hsr)
{
if ( !check_conditional_instr(regs, hsr) )
{
@@ -1676,7 +1677,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
break;
default:
{
-struct hsr_cp64 cp64 = hsr.cp64;
+const struct hsr_cp64 cp64 = hsr.cp64;
gdprintk(XENLOG_ERR,
%s p15, %d, r%d, r%d, cr%d @ 0x%PRIregister\n,
@@ -1692,9 +1693,9 @@ static void do_cp15_64(struct cpu_user_regs *regs,
advance_pc(regs, hsr);
}
-static void do_cp14_32(struct cpu_user_regs *regs, union hsr hsr)
+static void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr)
{
-struct hsr_cp32 cp32 = hsr.cp32;
+const struct hsr_cp32 cp32 = hsr.cp32;
uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
struct domain *d = current-domain;
@@ -1784,9 +1785,9 @@ static void do_cp14_32(struct cpu_user_regs *regs, union
hsr hsr)
advance_pc(regs, hsr);
}
-static void do_cp14_dbg(struct cpu_user_regs *regs, union hsr hsr)
+static void do_cp14_dbg(struct cpu_user_regs *regs, const union hsr hsr)
{
-struct hsr_cp64 cp64 = hsr.cp64;
+const struct hsr_cp64 cp64 = hsr.cp64;
if ( !check_conditional_instr(regs, hsr) )
{
@@ -1804,9 +1805,9 @@ static void do_cp14_dbg(struct cpu_user_regs *regs, union
hsr hsr)
inject_undef_exception(regs, hsr.len);
}
-static void do_cp(struct cpu_user_regs *regs, union hsr hsr)
+static void do_cp(struct cpu_user_regs *regs, const union hsr hsr)
{
-struct hsr_cp cp = hsr.cp;
+const struct hsr_cp cp = hsr.cp;
if ( !check_conditional_instr(regs, hsr) )
{
@@ -1821,7 +1822,7 @@ static void do_cp(struct cpu_user_regs *regs, union hsr
hsr)
#ifdef CONFIG_ARM_64
static void do_sysreg(struct cpu_user_regs *regs,
- union hsr hsr)
+ const union hsr hsr)
{
register_t *x = select_user_reg(regs, hsr.sysreg.reg);
@@ -1918,7 +1919,7 @@ static void do_sysreg(struct cpu_user_regs *regs,
inject_undef64_exception(regs, hsr.len);
default:
{
-struct hsr_sysreg sysreg = hsr.sysreg;
+const struct hsr_sysreg sysreg = hsr.sysreg;
gdprintk(XENLOG_ERR,
%s %d, %d, c%d, c%d, %d %s x%d @ 0x%PRIregister\n,
@@ -1997,16 +1998,16 @@ done:
}
static void do_trap_instr_abort_guest(struct cpu_user_regs *regs,
- union hsr hsr)
+ const union hsr hsr)
{
register_t addr = READ_SYSREG(FAR_EL2);
[Xen-devel] [PATCH v2 09/19] xen: arm: Annotate registers trapped by HCR_EL1.TIDCP
This traps variety of implementation defined registers, so add a note
to the default case of the respective handler.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Reviewed-by: Julien Grall julien.gr...@citrix.com
---
v2: Typo in subject
---
xen/arch/arm/traps.c | 16
1 file changed, 16 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 522701b..d908738 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1704,6 +1704,14 @@ static void do_cp15_32(struct cpu_user_regs *regs,
*/
return handle_raz_wi(regs, r, cp32.read, hsr, 1);
+/*
+ * HCR_EL2.TIDCP
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.3
+ * ARMv8 (DDI 0487A.d): D1-1501 Table D1-43
+ *
+ * And all other unknown registers.
+ */
default:
gdprintk(XENLOG_ERR,
%s p15, %d, r%d, cr%d, cr%d, %d @ 0x%PRIregister\n,
@@ -1954,6 +1962,14 @@ static void do_sysreg(struct cpu_user_regs *regs,
dprintk(XENLOG_WARNING,
Emulation of sysreg ICC_SGI0R_EL1/ASGI1R_EL1 not
supported\n);
return inject_undef64_exception(regs, hsr.len);
+
+/*
+ * HCR_EL2.TIDCP
+ *
+ * ARMv8 (DDI 0487A.d): D1-1501 Table D1-43
+ *
+ * And all other unknown registers.
+ */
default:
{
const struct hsr_sysreg sysreg = hsr.sysreg;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 03/19] xen: arm: call inject_undef_exception directly
Reducing the amount of goto maze considerably.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Reviewed-by: Julien Grall julien.gr...@citrix.com
---
xen/arch/arm/traps.c | 56 +++---
1 file changed, 26 insertions(+), 30 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 99ceaea..7270116 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -518,13 +518,13 @@ static void inject_iabt64_exception(struct cpu_user_regs
*regs,
#endif
static void inject_undef_exception(struct cpu_user_regs *regs,
- int instr_len)
+ const union hsr hsr)
{
if ( is_32bit_domain(current-domain) )
inject_undef32_exception(regs);
#ifdef CONFIG_ARM_64
else
-inject_undef64_exception(regs, instr_len);
+inject_undef64_exception(regs, hsr.len);
#endif
}
@@ -1592,11 +1592,11 @@ static void do_cp15_32(struct cpu_user_regs *regs,
case HSR_CPREG32(CNTP_CTL):
case HSR_CPREG32(CNTP_TVAL):
if ( !vtimer_emulate(regs, hsr) )
-goto undef_cp15_32;
+return inject_undef_exception(regs, hsr);
break;
case HSR_CPREG32(ACTLR):
if ( psr_mode_is_user(regs) )
-goto undef_cp15_32;
+return inject_undef_exception(regs, hsr);
if ( cp32.read )
*r = v-arch.actlr;
break;
@@ -1612,14 +1612,14 @@ static void do_cp15_32(struct cpu_user_regs *regs,
case HSR_CPREG32(PMUSERENR):
/* RO at EL0. RAZ/WI at EL1 */
if ( psr_mode_is_user(regs) !hsr.cp32.read )
-goto undef_cp15_32;
+return inject_undef_exception(regs, hsr);
goto cp15_32_raz_wi;
case HSR_CPREG32(PMINTENSET):
case HSR_CPREG32(PMINTENCLR):
/* EL1 only, however MDCR_EL2.TPM==1 means EL0 may trap here also. */
if ( psr_mode_is_user(regs) )
-goto undef_cp15_32;
+return inject_undef_exception(regs, hsr);
goto cp15_32_raz_wi;
case HSR_CPREG32(PMCR):
case HSR_CPREG32(PMCNTENSET):
@@ -1638,7 +1638,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
* emulate that register as 0 above.
*/
if ( psr_mode_is_user(regs) )
-goto undef_cp15_32;
+return inject_undef_exception(regs, hsr);
cp15_32_raz_wi:
if ( cp32.read )
*r = 0;
@@ -1652,8 +1652,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
cp32.op1, cp32.reg, cp32.crn, cp32.crm, cp32.op2, regs-pc);
gdprintk(XENLOG_ERR, unhandled 32-bit CP15 access %#x\n,
hsr.bits HSR_CP32_REGS_MASK);
- undef_cp15_32:
-inject_undef_exception(regs, hsr.len);
+inject_undef_exception(regs, hsr);
return;
}
advance_pc(regs, hsr);
@@ -1673,7 +1672,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
case HSR_CPREG64(CNTPCT):
case HSR_CPREG64(CNTP_CVAL):
if ( !vtimer_emulate(regs, hsr) )
-goto undef_cp15_64;
+return inject_undef_exception(regs, hsr);
break;
default:
{
@@ -1685,8 +1684,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs-pc);
gdprintk(XENLOG_ERR, unhandled 64-bit CP15 access %#x\n,
hsr.bits HSR_CP64_REGS_MASK);
- undef_cp15_64:
-inject_undef_exception(regs, hsr.len);
+inject_undef_exception(regs, hsr);
return;
}
}
@@ -1713,7 +1711,7 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
* is set to 0, which we emulated below.
*/
if ( !cp32.read )
-goto undef_cp14_32;
+return inject_undef_exception(regs, hsr);
/* Implement the minimum requirements:
* - Number of watchpoints: 1
@@ -1731,14 +1729,14 @@ static void do_cp14_32(struct cpu_user_regs *regs,
const union hsr hsr)
* is set to 0, which we emulated below.
*/
if ( !cp32.read )
-goto undef_cp14_32;
+return inject_undef_exception(regs, hsr);
*r = 0;
break;
case HSR_CPREG32(DBGDSCREXT):
if ( usr_mode(regs) )
-goto undef_cp14_32;
+return inject_undef_exception(regs, hsr);
/* Implement debug status and control register as RAZ/WI.
* The OS won't use Hardware debug if MDBGen not set
@@ -1756,7 +1754,7 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
case HSR_CPREG32(DBGBCR1):
case HSR_CPREG32(DBGOSDLR):
if ( usr_mode(regs) )
-goto undef_cp14_32;
+return inject_undef_exception(regs, hsr);
/* RAZ/WI */
if ( cp32.read )
*r = 0;
@@ -1764,10 +1762,10 @@ static void
[Xen-devel] [PATCH v2 05/19] xen: arm: Add and use r/o+raz and w/o+wi helpers
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v2: Move last paramter of a handle_ro_raz call to next patch where it
belongs.
---
xen/arch/arm/traps.c | 52 --
1 file changed, 33 insertions(+), 19 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 8b1846a..b54aef6 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1587,6 +1587,34 @@ static void handle_raz_wi(struct cpu_user_regs *regs,
advance_pc(regs, hsr);
}
+/* Write only + write ignore */
+static void handle_wo_wi(struct cpu_user_regs *regs,
+ register_t *reg,
+ bool_t read,
+ const union hsr hsr)
+{
+if ( read )
+return inject_undef_exception(regs, hsr);
+/* else: ignore */
+
+advance_pc(regs, hsr);
+}
+
+/* Read only + read as zero */
+static void handle_ro_raz(struct cpu_user_regs *regs,
+ register_t *reg,
+ bool_t read,
+ const union hsr hsr)
+{
+if ( !read )
+return inject_undef_exception(regs, hsr);
+/* else: raz */
+
+*reg = 0;
+
+advance_pc(regs, hsr);
+}
+
static void do_cp15_32(struct cpu_user_regs *regs,
const union hsr hsr)
{
@@ -1737,11 +1765,7 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
* Read-only register. Accessible by EL0 if DBGDSCRext.UDCCdis
* is set to 0, which we emulated below.
*/
-if ( !cp32.read )
-return inject_undef_exception(regs, hsr);
-
-*r = 0;
-break;
+return handle_ro_raz(regs, r, cp32.read, hsr);
case HSR_CPREG32(DBGDSCREXT):
if ( usr_mode(regs) )
@@ -1768,11 +1792,7 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
case HSR_CPREG32(DBGOSLAR):
if ( usr_mode(regs) )
return inject_undef_exception(regs, hsr);
-/* WO */
-if ( cp32.read )
-return inject_undef_exception(regs, hsr);
-/* else: ignore */
-break;
+return handle_wo_wi(regs, r, cp32.read, hsr);
default:
gdprintk(XENLOG_ERR,
%s p14, %d, r%d, cr%d, cr%d, %d @ 0x%PRIregister\n,
@@ -1857,11 +1877,7 @@ static void do_sysreg(struct cpu_user_regs *regs,
* Accessible at EL0 only if MDSCR_EL1.TDCC is set to 0. We emulate
that
* register as RAZ/WI above. So RO at both EL0 and EL1.
*/
-if ( !hsr.sysreg.read )
-return inject_undef_exception(regs, hsr);
-
-*x = 0;
-break;
+return handle_ro_raz(regs, x, hsr.sysreg.read, hsr);
/* - Perf monitors */
case HSR_SYSREG_PMUSERENR_EL0:
@@ -1891,10 +1907,8 @@ static void do_sysreg(struct cpu_user_regs *regs,
/* Write only, Write ignore registers: */
case HSR_SYSREG_OSLAR_EL1:
-if ( hsr.sysreg.read )
-return inject_undef_exception(regs, hsr);
-/* else: write ignored */
-break;
+return handle_wo_wi(regs, x, hsr.sysreg.read, hsr);
+
case HSR_SYSREG_CNTP_CTL_EL0:
case HSR_SYSREG_CNTP_TVAL_EL0:
case HSR_SYSREG_CNTP_CVAL_EL0:
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 08/19] xen: arm: implement handling of ACTLR_EL1 trap
While annotating ACTLR I noticed that we don't appear to handle the
64-bit version of this trap. Do so and annotate everything.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v2: s/TASC/TACR/ and s/HSR/HCR/
---
xen/arch/arm/traps.c | 20
xen/include/asm-arm/sysregs.h |1 +
2 files changed, 21 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 7b79990..522701b 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1653,6 +1653,13 @@ static void do_cp15_32(struct cpu_user_regs *regs,
if ( !vtimer_emulate(regs, hsr) )
return inject_undef_exception(regs, hsr);
break;
+
+/*
+ * HCR_EL2.TACR / HCR.TAC
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.6
+ * ARMv8 (DDI 0487A.d): G6.2.1
+ */
case HSR_CPREG32(ACTLR):
if ( psr_mode_is_user(regs) )
return inject_undef_exception(regs, hsr);
@@ -1855,9 +1862,22 @@ static void do_sysreg(struct cpu_user_regs *regs,
const union hsr hsr)
{
register_t *x = select_user_reg(regs, hsr.sysreg.reg);
+struct vcpu *v = current;
switch ( hsr.bits HSR_SYSREG_REGS_MASK )
{
+/*
+ * HCR_EL2.TACR
+ *
+ * ARMv8 (DDI 0487A.d): D7.2.1
+ */
+case HSR_SYSREG_ACTLR_EL1:
+if ( psr_mode_is_user(regs) )
+return inject_undef_exception(regs, hsr);
+if ( hsr.sysreg.read )
+ *x = v-arch.actlr;
+break;
+
/* RAZ/WI registers: */
/* - Debug */
case HSR_SYSREG_MDSCR_EL1:
diff --git a/xen/include/asm-arm/sysregs.h b/xen/include/asm-arm/sysregs.h
index 2284fd7..d75e154 100644
--- a/xen/include/asm-arm/sysregs.h
+++ b/xen/include/asm-arm/sysregs.h
@@ -72,6 +72,7 @@
case HSR_SYSREG_##REG##n_EL1(15)
#define HSR_SYSREG_SCTLR_EL1 HSR_SYSREG(3,0,c1, c0,0)
+#define HSR_SYSREG_ACTLR_EL1 HSR_SYSREG(3,0,c1, c0,1)
#define HSR_SYSREG_TTBR0_EL1 HSR_SYSREG(3,0,c2, c0,0)
#define HSR_SYSREG_TTBR1_EL1 HSR_SYSREG(3,0,c2, c0,1)
#define HSR_SYSREG_TCR_EL1HSR_SYSREG(3,0,c2, c0,2)
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 06/19] xen: arm: add minimum exception level argument to trap handler helpers
Removes a load of boiler plate.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v2: Move last parameter of a call to handle_ro_raz here where it
belongs.
Added asserts for valid min_el values
---
xen/arch/arm/traps.c | 73 +++---
1 file changed, 39 insertions(+), 34 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index b54aef6..7110c66 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1578,8 +1578,14 @@ static void advance_pc(struct cpu_user_regs *regs, const
union hsr hsr)
static void handle_raz_wi(struct cpu_user_regs *regs,
register_t *reg,
bool_t read,
- const union hsr hsr)
+ const union hsr hsr,
+ int min_el)
{
+ASSERT((min_el == 0) || (min_el == 1));
+
+if ( min_el 0 psr_mode_is_user(regs) )
+return inject_undef_exception(regs, hsr);
+
if ( read )
*reg = 0;
/* else: write ignored */
@@ -1591,8 +1597,14 @@ static void handle_raz_wi(struct cpu_user_regs *regs,
static void handle_wo_wi(struct cpu_user_regs *regs,
register_t *reg,
bool_t read,
- const union hsr hsr)
+ const union hsr hsr,
+ int min_el)
{
+ASSERT((min_el == 0) || (min_el == 1));
+
+if ( min_el 0 psr_mode_is_user(regs) )
+return inject_undef_exception(regs, hsr);
+
if ( read )
return inject_undef_exception(regs, hsr);
/* else: ignore */
@@ -1604,8 +1616,14 @@ static void handle_wo_wi(struct cpu_user_regs *regs,
static void handle_ro_raz(struct cpu_user_regs *regs,
register_t *reg,
bool_t read,
- const union hsr hsr)
+ const union hsr hsr,
+ int min_el)
{
+ASSERT((min_el == 0) || (min_el == 1));
+
+if ( min_el 0 psr_mode_is_user(regs) )
+return inject_undef_exception(regs, hsr);
+
if ( !read )
return inject_undef_exception(regs, hsr);
/* else: raz */
@@ -1652,16 +1670,15 @@ static void do_cp15_32(struct cpu_user_regs *regs,
*/
case HSR_CPREG32(PMUSERENR):
/* RO at EL0. RAZ/WI at EL1 */
-if ( psr_mode_is_user(regs) !hsr.cp32.read )
-return inject_undef_exception(regs, hsr);
-return handle_raz_wi(regs, r, cp32.read, hsr);
+if ( psr_mode_is_user(regs) )
+return handle_ro_raz(regs, r, cp32.read, hsr, 0);
+else
+return handle_raz_wi(regs, r, cp32.read, hsr, 1);
case HSR_CPREG32(PMINTENSET):
case HSR_CPREG32(PMINTENCLR):
/* EL1 only, however MDCR_EL2.TPM==1 means EL0 may trap here also. */
-if ( psr_mode_is_user(regs) )
-return inject_undef_exception(regs, hsr);
-return handle_raz_wi(regs, r, cp32.read, hsr);
+return handle_raz_wi(regs, r, cp32.read, hsr, 1);
case HSR_CPREG32(PMCR):
case HSR_CPREG32(PMCNTENSET):
case HSR_CPREG32(PMCNTENCLR):
@@ -1678,9 +1695,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
* Accessible at EL0 only if PMUSERENR_EL0.EN is set. We
* emulate that register as 0 above.
*/
-if ( psr_mode_is_user(regs) )
-return inject_undef_exception(regs, hsr);
-return handle_raz_wi(regs, r, cp32.read, hsr);
+return handle_raz_wi(regs, r, cp32.read, hsr, 1);
default:
gdprintk(XENLOG_ERR,
@@ -1765,17 +1780,14 @@ static void do_cp14_32(struct cpu_user_regs *regs,
const union hsr hsr)
* Read-only register. Accessible by EL0 if DBGDSCRext.UDCCdis
* is set to 0, which we emulated below.
*/
-return handle_ro_raz(regs, r, cp32.read, hsr);
+return handle_ro_raz(regs, r, cp32.read, hsr, 1);
case HSR_CPREG32(DBGDSCREXT):
-if ( usr_mode(regs) )
-return inject_undef_exception(regs, hsr);
-
/*
* Implement debug status and control register as RAZ/WI.
* The OS won't use Hardware debug if MDBGen not set.
*/
-return handle_raz_wi(regs, r, cp32.read, hsr);
+return handle_raz_wi(regs, r, cp32.read, hsr, 1);
case HSR_CPREG32(DBGVCR):
case HSR_CPREG32(DBGBVR0):
@@ -1785,14 +1797,10 @@ static void do_cp14_32(struct cpu_user_regs *regs,
const union hsr hsr)
case HSR_CPREG32(DBGBVR1):
case HSR_CPREG32(DBGBCR1):
case HSR_CPREG32(DBGOSDLR):
-if ( usr_mode(regs) )
-return inject_undef_exception(regs, hsr);
-return handle_raz_wi(regs, r, cp32.read, hsr);
+return handle_raz_wi(regs, r, cp32.read, hsr, 1);
case HSR_CPREG32(DBGOSLAR):
-if ( usr_mode(regs) )
-return inject_undef_exception(regs, hsr);
-
[Xen-devel] [PATCH v2 17/19] xen: arm: Remove CNTPCT_EL0 trap handling.
We set CNTHCTL_EL2.EL1PCTEN and therefore according to ARMv8 (DDI
0487A.d) D1-1510 Table D1-60 we are not trapping this.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Reviewed-by: Julien Grall julien.gr...@citrix.com
---
xen/arch/arm/traps.c |1 -
xen/arch/arm/vtimer.c | 30 --
2 files changed, 31 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index d4505b5..c869b96 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1768,7 +1768,6 @@ static void do_cp15_64(struct cpu_user_regs *regs,
switch ( hsr.bits HSR_CP64_REGS_MASK )
{
-case HSR_CPREG64(CNTPCT):
case HSR_CPREG64(CNTP_CVAL):
if ( !vtimer_emulate(regs, hsr) )
return inject_undef_exception(regs, hsr);
diff --git a/xen/arch/arm/vtimer.c b/xen/arch/arm/vtimer.c
index be65c9f..685bfea 100644
--- a/xen/arch/arm/vtimer.c
+++ b/xen/arch/arm/vtimer.c
@@ -243,28 +243,6 @@ static int vtimer_cntp_cval(struct cpu_user_regs *regs,
uint64_t *r, int read)
}
return 1;
}
-static int vtimer_cntpct(struct cpu_user_regs *regs, uint64_t *r, int read)
-{
-struct vcpu *v = current;
-uint64_t ticks;
-s_time_t now;
-
-if ( read )
-{
-if ( !ACCESS_ALLOWED(regs, EL0PCTEN) )
-return 0;
-now = NOW() - v-domain-arch.phys_timer_base.offset;
-ticks = ns_to_ticks(now);
-*r = ticks;
-return 1;
-}
-else
-{
-gprintk(XENLOG_DEBUG, WRITE to R/O CNTPCT\n);
-return 0;
-}
-}
-
static int vtimer_emulate_cp32(struct cpu_user_regs *regs, union hsr hsr)
{
@@ -303,11 +281,6 @@ static int vtimer_emulate_cp64(struct cpu_user_regs *regs,
union hsr hsr)
switch ( hsr.bits HSR_CP64_REGS_MASK )
{
-case HSR_CPREG64(CNTPCT):
-if ( !vtimer_cntpct(regs, x, cp64.read) )
-return 0;
-break;
-
case HSR_CPREG64(CNTP_CVAL):
if ( !vtimer_cntp_cval(regs, x, cp64.read) )
return 0;
@@ -356,9 +329,6 @@ static int vtimer_emulate_sysreg(struct cpu_user_regs
*regs, union hsr hsr)
case HSR_SYSREG_CNTP_CVAL_EL0:
return vtimer_cntp_cval(regs, x, sysreg.read);
-case HSR_SYSREG_CNTPCT_EL0:
-return vtimer_cntpct(regs, x, sysreg.read);
-
default:
return 0;
}
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 02/19] xen: arm: Fix handling of ICC_{SGI1R, SGI0R, ASGI1R}_EL1
Having injected an undefined instruction we don't want to also advance
pc. So return.
The ICC_{SGI0R,ASGI1R}_EL1 case was previously missing a break, so
would have fallen through to the default case and injected a second
undef, corrupting SPSR_EL1 and ELR_EL1 for the guest.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Reviewed-by: Julien Grall julien.gr...@citrix.com
---
v2: Remove vestigial second commit message
---
xen/arch/arm/traps.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 69b9513..99ceaea 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1908,7 +1908,7 @@ static void do_sysreg(struct cpu_user_regs *regs,
{
dprintk(XENLOG_WARNING,
failed emulation of sysreg ICC_SGI1R_EL1 access\n);
-inject_undef64_exception(regs, hsr.len);
+return inject_undef64_exception(regs, hsr.len);
}
break;
case HSR_SYSREG_ICC_SGI0R_EL1:
@@ -1916,7 +1916,7 @@ static void do_sysreg(struct cpu_user_regs *regs,
/* TBD: Implement to support secure grp0/1 SGI forwarding */
dprintk(XENLOG_WARNING,
Emulation of sysreg ICC_SGI0R_EL1/ASGI1R_EL1 not
supported\n);
-inject_undef64_exception(regs, hsr.len);
+return inject_undef64_exception(regs, hsr.len);
default:
{
const struct hsr_sysreg sysreg = hsr.sysreg;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 04/19] xen: arm: provide and use a handle_raz_wi helper
Reduces the use of goto in the trap handlers to none.
Some explicitly 32-bit types become register_t here, but that's OK, on
32-bit they are 32-bit already and on 64-bit it is fine/harmless to
set the larger register, a 32-bit guest won't see the top half in any
case.
Per section B1.2.1 (ARMv8 DDI0487 A.d) writes to wN registers are zero
extended, so there is no risk of leaking the top half here.
Unlike the previous code the advancing of PC is handled within the
helper, rather than after the end of the switch as before. So return
as the handler is called.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v2: Added reference to B1.2.1
---
xen/arch/arm/traps.c | 51 +-
1 file changed, 26 insertions(+), 25 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 7270116..8b1846a 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1574,11 +1574,24 @@ static void advance_pc(struct cpu_user_regs *regs,
const union hsr hsr)
regs-pc += hsr.len ? 4 : 2;
}
+/* Read as zero + write ignore */
+static void handle_raz_wi(struct cpu_user_regs *regs,
+ register_t *reg,
+ bool_t read,
+ const union hsr hsr)
+{
+if ( read )
+*reg = 0;
+/* else: write ignored */
+
+advance_pc(regs, hsr);
+}
+
static void do_cp15_32(struct cpu_user_regs *regs,
const union hsr hsr)
{
const struct hsr_cp32 cp32 = hsr.cp32;
-uint32_t *r = (uint32_t*)select_user_reg(regs, cp32.reg);
+register_t *r = select_user_reg(regs, cp32.reg);
struct vcpu *v = current;
if ( !check_conditional_instr(regs, hsr) )
@@ -1613,14 +1626,14 @@ static void do_cp15_32(struct cpu_user_regs *regs,
/* RO at EL0. RAZ/WI at EL1 */
if ( psr_mode_is_user(regs) !hsr.cp32.read )
return inject_undef_exception(regs, hsr);
-goto cp15_32_raz_wi;
+return handle_raz_wi(regs, r, cp32.read, hsr);
case HSR_CPREG32(PMINTENSET):
case HSR_CPREG32(PMINTENCLR):
/* EL1 only, however MDCR_EL2.TPM==1 means EL0 may trap here also. */
if ( psr_mode_is_user(regs) )
return inject_undef_exception(regs, hsr);
-goto cp15_32_raz_wi;
+return handle_raz_wi(regs, r, cp32.read, hsr);
case HSR_CPREG32(PMCR):
case HSR_CPREG32(PMCNTENSET):
case HSR_CPREG32(PMCNTENCLR):
@@ -1639,11 +1652,7 @@ static void do_cp15_32(struct cpu_user_regs *regs,
*/
if ( psr_mode_is_user(regs) )
return inject_undef_exception(regs, hsr);
- cp15_32_raz_wi:
-if ( cp32.read )
-*r = 0;
-/* else: write ignored */
-break;
+return handle_raz_wi(regs, r, cp32.read, hsr);
default:
gdprintk(XENLOG_ERR,
@@ -1694,7 +1703,7 @@ static void do_cp15_64(struct cpu_user_regs *regs,
static void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr)
{
const struct hsr_cp32 cp32 = hsr.cp32;
-uint32_t *r = (uint32_t *)select_user_reg(regs, cp32.reg);
+register_t *r = select_user_reg(regs, cp32.reg);
struct domain *d = current-domain;
if ( !check_conditional_instr(regs, hsr) )
@@ -1738,12 +1747,11 @@ static void do_cp14_32(struct cpu_user_regs *regs,
const union hsr hsr)
if ( usr_mode(regs) )
return inject_undef_exception(regs, hsr);
-/* Implement debug status and control register as RAZ/WI.
- * The OS won't use Hardware debug if MDBGen not set
+/*
+ * Implement debug status and control register as RAZ/WI.
+ * The OS won't use Hardware debug if MDBGen not set.
*/
-if ( cp32.read )
- *r = 0;
-break;
+return handle_raz_wi(regs, r, cp32.read, hsr);
case HSR_CPREG32(DBGVCR):
case HSR_CPREG32(DBGBVR0):
@@ -1755,10 +1763,7 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
case HSR_CPREG32(DBGOSDLR):
if ( usr_mode(regs) )
return inject_undef_exception(regs, hsr);
-/* RAZ/WI */
-if ( cp32.read )
-*r = 0;
-break;
+return handle_raz_wi(regs, r, cp32.read, hsr);
case HSR_CPREG32(DBGOSLAR):
if ( usr_mode(regs) )
@@ -1845,7 +1850,7 @@ static void do_sysreg(struct cpu_user_regs *regs,
*/
if ( psr_mode_is_user(regs) )
return inject_undef_exception(regs, hsr);
-goto sysreg_raz_wi;
+return handle_raz_wi(regs, x, hsr.sysreg.read, hsr);
case HSR_SYSREG_MDCCSR_EL0:
/*
@@ -1863,7 +1868,7 @@ static void do_sysreg(struct cpu_user_regs *regs,
/* RO at EL0. RAZ/WI at EL1 */
if ( psr_mode_is_user(regs) !hsr.sysreg.read )
return inject_undef_exception(regs, hsr);
-goto sysreg_raz_wi;
+return handle_raz_wi(regs, x, hsr.sysreg.read, hsr);
case
Re: [Xen-devel] [PATCH v2 2/4] x86/MSI-X: access MSI-X table only after having enabled MSI-X
On 15.04.15 at 19:41, konrad.w...@oracle.com wrote:
On Mon, Apr 13, 2015 at 10:05:14AM +0100, Jan Beulich wrote:
On 10.04.15 at 22:02, konrad.w...@oracle.com wrote:
On Wed, Mar 25, 2015 at 04:39:49PM +, Jan Beulich wrote:
As done in Linux by f598282f51 (PCI: Fix the NIU MSI-X problem in a
better way) and its broken predecessor, make sure we don't access the
MSI-X table without having enabled MSI-X first, using the mask-all flag
instead to prevent interrupts from occurring.
This causes an regression with an Linux guest that has the XSA120 + XSA120
addendum with PV guests (hadn't tried yet HVM).
You mentioning XSA-120 and its addendum - are these requirements
for the problem to be seen? I admit I may have tested a PV guest
only with an SR-IOV VF (and only a HVM guest also with an ordinary
device), but I'd like to be clear about the validity of the connection.
No. I just tried with v4.0-rc5 (and then also v4.0) and just
using SR-IOV to make this simpler.
With staging + two of your patches:
a10cc68 TODO: drop //temp-s
1b8721c x86/MSI-X: be more careful during teardown
When trying to enable SR-IOV I get this error:
failed to echo 1
/sys/devices/pci:00/:00:01.0/:0a:00.0/sriov_numvfs, rc: 1
(hadn't tried just passing in an HVM guest).
Attached is the 'xl dmesg'.
Could you replace the patch I handed you earlier on by this one
and try again? I actually was able to determine that I did try a
(SUSE) PV guest without seeing an issue. I just now tried again,
and I don't see either of the two debug warnings. So quite clear
any indication towards a pvops problem.
Jan
x86/MSI-X: access MSI-X table only after having enabled MSI-X
As done in Linux by f598282f51 (PCI: Fix the NIU MSI-X problem in a
better way) and its broken predecessor, make sure we don't access the
MSI-X table without having enabled MSI-X first, using the mask-all flag
instead to prevent interrupts from occurring.
Signed-off-by: Jan Beulich jbeul...@suse.com
---
v3: temporarily enable MSI-X in setup_msi_irq() if not already enabled
--- unstable.orig/xen/arch/x86/msi.c
+++ unstable/xen/arch/x86/msi.c
@@ -142,6 +142,21 @@ static bool_t memory_decoded(const struc
PCI_COMMAND_MEMORY);
}
+static bool_t msix_memory_decoded(const struct pci_dev *dev, unsigned int pos)
+{
+u16 control = pci_conf_read16(dev-seg, dev-bus, PCI_SLOT(dev-devfn),
+ PCI_FUNC(dev-devfn), msix_control_reg(pos));
+
+if ( !(control PCI_MSIX_FLAGS_ENABLE) )
+{//temp
+ static bool_t warned;
+ WARN_ON(!test_and_set_bool(warned));
+return 0;
+}
+
+return memory_decoded(dev);
+}
+
/*
* MSI message composition
*/
@@ -219,7 +234,8 @@ static bool_t read_msi_msg(struct msi_de
void __iomem *base;
base = entry-mask_base;
-if ( unlikely(!memory_decoded(entry-dev)) )
+if ( unlikely(!msix_memory_decoded(entry-dev,
+ entry-msi_attrib.pos)) )
return 0;
msg-address_lo = readl(base + PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET);
msg-address_hi = readl(base + PCI_MSIX_ENTRY_UPPER_ADDR_OFFSET);
@@ -285,7 +301,8 @@ static int write_msi_msg(struct msi_desc
void __iomem *base;
base = entry-mask_base;
-if ( unlikely(!memory_decoded(entry-dev)) )
+if ( unlikely(!msix_memory_decoded(entry-dev,
+ entry-msi_attrib.pos)) )
return -ENXIO;
writel(msg-address_lo,
base + PCI_MSIX_ENTRY_LOWER_ADDR_OFFSET);
@@ -379,7 +396,7 @@ static bool_t msi_set_mask_bit(struct ir
{
struct msi_desc *entry = desc-msi_desc;
struct pci_dev *pdev;
-u16 seg;
+u16 seg, control;
u8 bus, slot, func;
ASSERT(spin_is_locked(desc-lock));
@@ -401,35 +418,38 @@ static bool_t msi_set_mask_bit(struct ir
}
break;
case PCI_CAP_ID_MSIX:
+control = pci_conf_read16(seg, bus, slot, func,
+ msix_control_reg(entry-msi_attrib.pos));
+if ( unlikely(!(control PCI_MSIX_FLAGS_ENABLE)) )
+pci_conf_write16(seg, bus, slot, func,
+ msix_control_reg(entry-msi_attrib.pos),
+ control | (PCI_MSIX_FLAGS_ENABLE |
+PCI_MSIX_FLAGS_MASKALL));
if ( likely(memory_decoded(pdev)) )
{
writel(flag, entry-mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
readl(entry-mask_base + PCI_MSIX_ENTRY_VECTOR_CTRL_OFFSET);
-break;
+if ( likely(control PCI_MSIX_FLAGS_ENABLE) )
+break;
+flag = 1;
}
-if ( flag )
+else if ( flag !(control PCI_MSIX_FLAGS_MASKALL) )
{
-u16 control;
domid_t domid = pdev-domain-domain_id;
-control = pci_conf_read16(seg, bus, slot, func,
-
[Xen-devel] [PATCH v2 13/19] xen: arm: Annotate registers trapped by MDCR_EL2.TDRA
DBGDRAR and DBGDSAR are actually two cp or sys registers each, one 32-bit and one 64-bit. The cpregs #define is suffixed 64 and annotations are added to both handlers. MDRAR_EL1 (arm64 version of DBGDRAR) wasn't handled, so add that here. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- v2: Move comment next to default label where it belongs. Clarify DBGDRAR vs DBGDRAR64 --- xen/arch/arm/traps.c | 28 xen/include/asm-arm/cpregs.h |4 xen/include/asm-arm/sysregs.h |1 + 3 files changed, 33 insertions(+) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 86b5655..17ddcd0 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -1852,6 +1852,15 @@ static void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr) * ARMv7 (DDI 0406C.b): B1.14.16 * ARMv8 (DDI 0487A.d): D1-1507 Table D1-54 * + * MDCR_EL2.TDRA + * + * ARMv7 (DDI 0406C.b): B1.14.15 + * ARMv8 (DDI 0487A.d): D1-1508 Table D1-57 + * + * Unhandled: + *DBGDRAR (32-bit accesses) + *DBGDSAR (32-bit accesses) + * * And all other unknown registers. */ default: @@ -1883,6 +1892,17 @@ static void do_cp14_64(struct cpu_user_regs *regs, const union hsr hsr) * * ARMv7 (DDI 0406C.b): B1.14.16 * ARMv8 (DDI 0487A.d): D1-1507 Table D1-54 + * + * MDCR_EL2.TDRA + * + * ARMv7 (DDI 0406C.b): B1.14.15 + * ARMv8 (DDI 0487A.d): D1-1508 Table D1-57 + * + * Unhandled: + *DBGDRAR (64-bit accesses) + *DBGDSAR (64-bit accesses) + * + * And all other unknown registers. */ gdprintk(XENLOG_ERR, %s p14, %d, r%d, r%d, cr%d @ 0x%PRIregister\n, @@ -1949,6 +1969,14 @@ static void do_sysreg(struct cpu_user_regs *regs, *x = v-arch.actlr; break; +/* + * MDCR_EL2.TDRA + * + * ARMv8 (DDI 0487A.d): D1-1508 Table D1-57 + */ +case HSR_SYSREG_MDRAR_EL1: +return handle_ro_raz(regs, x, hsr.sysreg.read, hsr, 1); + /* RAZ/WI registers: */ /* - Debug */ case HSR_SYSREG_MDSCR_EL1: diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h index afe9148..9db8cfd 100644 --- a/xen/include/asm-arm/cpregs.h +++ b/xen/include/asm-arm/cpregs.h @@ -89,10 +89,14 @@ #define TEECR p14,6,c0,c0,0 /* ThumbEE Configuration Register */ /* CP14 CR1: */ +#define DBGDRAR64 p14,0,c1/* Debug ROM Address Register (64-bit access) */ +#define DBGDRAR p14,0,c1,c0,0 /* Debug ROM Address Register (32-bit access) */ #define TEEHBR p14,6,c1,c0,0 /* ThumbEE Handler Base Register */ #define JOSCR p14,7,c1,c0,0 /* Jazelle OS Control Register */ /* CP14 CR2: */ +#define DBGDSAR64 p14,0,c2/* Debug Self Address Offset Register (64-bit access) */ +#define DBGDSAR p14,0,c2,c0,0 /* Debug Self Address Offset Register (32-bit access) */ #define JMCRp14,7,c2,c0,0 /* Jazelle Main Configuration Register */ diff --git a/xen/include/asm-arm/sysregs.h b/xen/include/asm-arm/sysregs.h index d75e154..55457fd 100644 --- a/xen/include/asm-arm/sysregs.h +++ b/xen/include/asm-arm/sysregs.h @@ -45,6 +45,7 @@ #define HSR_SYSREG_DCCISW HSR_SYSREG(1,0,c7,c14,2) #define HSR_SYSREG_MDSCR_EL1 HSR_SYSREG(2,0,c0,c2,2) +#define HSR_SYSREG_MDRAR_EL1 HSR_SYSREG(2,0,c1,c0,0) #define HSR_SYSREG_OSLAR_EL1 HSR_SYSREG(2,0,c1,c0,4) #define HSR_SYSREG_OSDLR_EL1 HSR_SYSREG(2,0,c1,c3,4) #define HSR_SYSREG_MDCCSR_EL0 HSR_SYSREG(2,3,c0,c1,0) -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 10/19] xen: arm: implement handling of registers trapped by CPTR_EL2.TTA
Add explicit handler for 64-bit CP14 accesses, with more relevant
debug message (as per other handlers) and to provide a place for a
comment.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v2: Changed title from xen: arm: Annotate registers trapped by
CPTR_EL2.TTA
Add And all other unknown registers to new annotation.
---
xen/arch/arm/traps.c | 45 +-
xen/include/asm-arm/perfc_defn.h |1 +
2 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index d908738..afa8a95 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1816,6 +1816,15 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
case HSR_CPREG32(DBGOSLAR):
return handle_wo_wi(regs, r, cp32.read, hsr, 1);
+
+/*
+ * CPTR_EL2.TTA
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.16
+ * ARMv8 (DDI 0487A.d): D1-1507 Table D1-54
+ *
+ * And all other unknown registers.
+ */
default:
gdprintk(XENLOG_ERR,
%s p14, %d, r%d, cr%d, cr%d, %d @ 0x%PRIregister\n,
@@ -1830,7 +1839,7 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
advance_pc(regs, hsr);
}
-static void do_cp14_dbg(struct cpu_user_regs *regs, const union hsr hsr)
+static void do_cp14_64(struct cpu_user_regs *regs, const union hsr hsr)
{
const struct hsr_cp64 cp64 = hsr.cp64;
@@ -1840,12 +1849,37 @@ static void do_cp14_dbg(struct cpu_user_regs *regs,
const union hsr hsr)
return;
}
+/*
+ * CPTR_EL2.TTA
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.16
+ * ARMv8 (DDI 0487A.d): D1-1507 Table D1-54
+ */
gdprintk(XENLOG_ERR,
%s p14, %d, r%d, r%d, cr%d @ 0x%PRIregister\n,
cp64.read ? mrrc : mcrr,
cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs-pc);
gdprintk(XENLOG_ERR, unhandled 64-bit CP14 access %#x\n,
hsr.bits HSR_CP64_REGS_MASK);
+inject_undef_exception(regs, hsr);
+}
+
+static void do_cp14_dbg(struct cpu_user_regs *regs, const union hsr hsr)
+{
+struct hsr_cp64 cp64 = hsr.cp64;
+
+if ( !check_conditional_instr(regs, hsr) )
+{
+advance_pc(regs, hsr);
+return;
+}
+
+gdprintk(XENLOG_ERR,
+ %s p14, %d, r%d, r%d, cr%d @ 0x%PRIregister\n,
+ cp64.read ? mrrc : mcrr,
+ cp64.op1, cp64.reg1, cp64.reg2, cp64.crm, regs-pc);
+gdprintk(XENLOG_ERR, unhandled 64-bit CP14 DBG access %#x\n,
+ hsr.bits HSR_CP64_REGS_MASK);
inject_undef_exception(regs, hsr);
}
@@ -1968,6 +2002,10 @@ static void do_sysreg(struct cpu_user_regs *regs,
*
* ARMv8 (DDI 0487A.d): D1-1501 Table D1-43
*
+ * CPTR_EL2.TTA
+ *
+ * ARMv8 (DDI 0487A.d): D1-1507 Table D1-54
+ *
* And all other unknown registers.
*/
default:
@@ -2162,6 +2200,11 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs
*regs)
perfc_incr(trap_cp14_32);
do_cp14_32(regs, hsr);
break;
+case HSR_EC_CP14_64:
+GUEST_BUG_ON(!psr_mode_is_32bit(regs-cpsr));
+perfc_incr(trap_cp14_64);
+do_cp14_64(regs, hsr);
+break;
case HSR_EC_CP14_DBG:
GUEST_BUG_ON(!psr_mode_is_32bit(regs-cpsr));
perfc_incr(trap_cp14_dbg);
diff --git a/xen/include/asm-arm/perfc_defn.h b/xen/include/asm-arm/perfc_defn.h
index 46015f5..69fabe7 100644
--- a/xen/include/asm-arm/perfc_defn.h
+++ b/xen/include/asm-arm/perfc_defn.h
@@ -9,6 +9,7 @@ PERFCOUNTER(trap_wfe, trap: wfe)
PERFCOUNTER(trap_cp15_32, trap: cp15 32-bit access)
PERFCOUNTER(trap_cp15_64, trap: cp15 64-bit access)
PERFCOUNTER(trap_cp14_32, trap: cp14 32-bit access)
+PERFCOUNTER(trap_cp14_64, trap: cp14 64-bit access)
PERFCOUNTER(trap_cp14_dbg, trap: cp14 dbg access)
PERFCOUNTER(trap_cp, trap: cp access)
PERFCOUNTER(trap_smc32,trap: 32-bit smc)
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 11/19] xen: arm: Annotate handlers for CPTR_EL2.Tx
Also expand on the comment when writing CPTR_EL2 to mention that most
of the bits we are setting are RES1 on arm64 anyway.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v2: s/PCTR/CPTR/
Expand the comment when writing to CPTR_EL2
---
xen/arch/arm/traps.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index afa8a95..a2bae51 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -110,8 +110,13 @@ void __cpuinit init_traps(void)
/* Trap CP15 c15 used for implementation defined registers */
WRITE_SYSREG(HSTR_T(15), HSTR_EL2);
-/* Trap all coprocessor registers (0-13) except cp10 and cp11 for VFP
- * /!\ All processors except cp10 and cp11 cannot be used in Xen
+/* Trap all coprocessor registers (0-13) except cp10 and
+ * cp11 for VFP.
+ *
+ * /!\ All coprocessors except cp10 and cp11 cannot be used in Xen.
+ *
+ * On ARM64 the TCPx bits which we set here (0..9,12,13) are all
+ * RES1, i.e. they would trap whether we did this write or not.
*/
WRITE_SYSREG((HCPTR_CP_MASK ~(HCPTR_CP(10) | HCPTR_CP(11))) | HCPTR_TTA,
CPTR_EL2);
@@ -1710,6 +1715,11 @@ static void do_cp15_32(struct cpu_user_regs *regs,
* ARMv7 (DDI 0406C.b): B1.14.3
* ARMv8 (DDI 0487A.d): D1-1501 Table D1-43
*
+ * CPTR_EL2.T{0..9,12..13}
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.12
+ * ARMv8 (DDI 0487A.d): N/A
+ *
* And all other unknown registers.
*/
default:
@@ -1741,6 +1751,15 @@ static void do_cp15_64(struct cpu_user_regs *regs,
if ( !vtimer_emulate(regs, hsr) )
return inject_undef_exception(regs, hsr);
break;
+
+/*
+ * CPTR_EL2.T{0..9,12..13}
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.12
+ * ARMv8 (DDI 0487A.d): N/A
+ *
+ * And all other unknown registers.
+ */
default:
{
const struct hsr_cp64 cp64 = hsr.cp64;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] crash in efi_runtime_call
On Fri, Apr 17, 2015 at 02:45:23PM +0100, Andrew Cooper wrote: On 17/04/15 14:40, Konrad Rzeszutek Wilk wrote: On Fri, Apr 17, 2015 at 01:54:28PM +0100, Andrew Cooper wrote: On 17/04/15 13:39, Jan Beulich wrote: On 17.04.15 at 13:59, andrew.coop...@citrix.com wrote: On 17/04/15 12:17, Olaf Hering wrote: Since booting xen fails on my ProBook unless I specify maxcpus=1 I tried the EFI firmware today. To my surprise it boots and finds all cpus. But once some efi driver in dom0 is loaded xen crashes. The same happens with xen-4.4 as included in SLE12. ... (XEN) Xen call trace: (XEN)[aec1e8e1] aec1e8e1 (XEN)[82d080222600] efi_runtime_call+0x7f0/0x890 (XEN)[82d0801641a9] do_platform_op+0x679/0x1670 (XEN)[82d08021dfb9] syscall_enter+0xa9/0xae Can I do anything about it, or is this a firmware bug? I will move the offending efi driver away and try again. Olaf This is a firmware bug. +1 (and I'm surprised how common this is) The bug is present in the reference implementation code, which means it is present in a lot of real firmware. We have kit from 3 different vendors which are affected, including latest available firmware. (XEN) 1-23fff type=7 attr=000 (XEN) 0fec1-0fec10fff type=11 attr=8001 (XEN) 0fff4-0fff46fff type=11 attr=8000 (XEN) Unknown cachability for MFNs 0xfff40-0xfff46 This unknown cacheability causes Xen not to make pagetables for the region. There is a patch or two floating around the list, but currently no resolution on the argument it created. https://github.com/xenserver/xen-4.5.pg/blob/master/master/unknown-cacheabilit y.patch is the XenServer fix. Now that's surely wrong Right or wrong, this is (apparently; I have not checked) what Linux does. - if anything, unknown should be treated as UC (and quite likely specifically in a case like the one Olaf reports here, as the offending memory range pretty likely is other than normal RAM). What I'd accept as a patch would be the addition of a command line option enforcing the mapping of such unknown cacheability areas with a certain caching type (default then being UC). If I can find some copious free time, I will see about making this happen. I actually did cobble a patch like this, but it is based on Daniel's Multibootv2 so it won't apply cleany. See attached patchset with various 'work-arounds'. Jan if you are OK with them (well the 'idea' behind them) I can refresh it against staging and post them? I was planning to make one efi= command line option along the psr/ept/iommu line, rather than having a large number of top-level options (and folding our one efi-rs option into it). That does sound more sensible than a bunch of 'efi-XYZ'. But otherwise, that sounds like a plan. Great. Next week I will post it. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Question about DMA on 1:1 mapping dom0 of arm64
On Fri, 2015-04-17 at 19:24 +0800, Chen Baozi wrote: Hi all, According to my recent experience, there might be some problems of swiotlb dma map on 1:1 mapping arm64 dom0 with large memory. The issue is like below: For those arm64 server with large memory, it is possible to set dom0_mem 4G (e.g. I have one set with 16G). In this case, according to my understanding, there is chance that the dom0 kernel needs to map some buffers above 4G to do ^below? DMA operations (e.g. in snps,dwmac ethernet driver). However, most DMA engines support only 32-bit physical address, thus aren't able to operate directly on those memory. Even on arm64 systems with RAM above 4GB? That seems short-sighted. Oh well, I suppose we have to live with it. IIUC, swiotlb is implemented to solve this (using bounce buffer), if there is no IOMMU or IOMMU is not enabled on the system. Sadly, it seems that xen_swiotlb_map_page in my dom0 kernel allocates (start_dma_addr = 0x94480) the buffers for DMA above 4G which fails dma_capable() checking and was then unable to return from xen_swiotlb_map_page() successfully. The swiotlb bounce buffer have been allocated below 4GB? I suspect that xen_swiotlb_init is buggy for ARM -- it allocates some random pages and then swizzles the backing pages for ones 4G, but that won't work on an ARM dom0 with a 1:1 mapping, I don't think. Do you see error messages along those lines? Essentially I think either xen_swiotlb_fixup is unable to work on ARM, or the following: start_dma_addr = xen_virt_to_bus(xen_io_tlb_start); is returning 1:1 and not reflecting the fixup. If I set dom0_mem to a small value (e.g. 512M), which makes all physical memory of dom0 below 4G, everything goes fine. So you are getting allocated memory below 4G? You message on IRC suggested you weren't, did you hack around this? I think we have two options, either xen_swiotlb_init allocates pages below 4GB (e.g. __GFP_DMA) or we do something to allow xen_swiotlb_fixup to actually work even on a 1:1 dom0. Although the first option seems preferable at first glance it has the short coming that it requires dom0 to have some memory below 4GB, which might not necessarily be the case. The second option seems like it might be uglier but doesn't suffer from this issue. Can you please look and find out if the IPA at 0x94480 is actually backed by 1:1 RAM or if xen_swiotlb_fixup has done it's job and updated things such that the associated PAs are below 4GB? Ian. I am not familiar with swiotlb-xen, so there would be misunderstanding about the current situation. Fix me if I did/understood anything wrong. Any ideas? Cheers, Chen Baozi ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Archiving Xen on ARM and PVOPS subprojects
On Wed, 15 Apr 2015, Lars Kurth wrote: Hi all, I wanted to make the proposal to archive the following two subproject on the grounds that they completed their goals a) http://xenproject.org/developers/teams/pvops.html b) http://xenproject.org/developers/teams/arm-hypervisor.html In the case of a) the goal was to establish Xen support in Linux, which has been achieved In the case of b) the goal was to establish ARM support in the Hypervisor which has been achieved According to http://xenproject.org/governance.html we would need to perform an archivation review. In this case, the situation is quite clear IMHO and I believe that we do not need to make an extensive case, besides the one above. So my proposal would be to just have a committer vote on these. I would be happy if committers and maintainers listed in a), b) and http://xenproject.org/developers/teams/hypervisor.html were to just reply with the usual +1, 0, -1 to this thread. In practical terms, the following would happen. I would remove a) from the website and merge bits of b) into http://xenproject.org/developers/teams/hypervisor.html There is no mailing list or repo impact for both projects, as both do not have separate lists. We would probably archive some pages in http://wiki.xenproject.org/wiki/Category:PVOPS - I would need David and Konrad's help for that. Probably 15 minutes should be fine. Maybe in fact it may make sense to rename the Category to Linux. As far as I can see, none of the pages in http://wiki.xenproject.org/wiki/Category:XenARM need to be archived. http://wiki.xenproject.org/wiki/Archived/Xen_ARM_(PV) is already archived. We would probably also put together a blog post, once all of this has been done and maybe put together a press release (up to Sarah and the Advisory Board). Any views? +1 on both counts___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] crash in efi_runtime_call
On Fri, Apr 17, 2015 at 01:54:28PM +0100, Andrew Cooper wrote:
On 17/04/15 13:39, Jan Beulich wrote:
On 17.04.15 at 13:59, andrew.coop...@citrix.com wrote:
On 17/04/15 12:17, Olaf Hering wrote:
Since booting xen fails on my ProBook unless I specify maxcpus=1 I
tried the EFI firmware today. To my surprise it boots and finds all
cpus. But once some efi driver in dom0 is loaded xen crashes. The same
happens with xen-4.4 as included in SLE12.
...
(XEN) Xen call trace:
(XEN)[aec1e8e1] aec1e8e1
(XEN)[82d080222600] efi_runtime_call+0x7f0/0x890
(XEN)[82d0801641a9] do_platform_op+0x679/0x1670
(XEN)[82d08021dfb9] syscall_enter+0xa9/0xae
Can I do anything about it, or is this a firmware bug? I will move the
offending efi driver away and try again.
Olaf
This is a firmware bug.
+1 (and I'm surprised how common this is)
The bug is present in the reference implementation code, which means it
is present in a lot of real firmware. We have kit from 3 different
vendors which are affected, including latest available firmware.
(XEN) 1-23fff type=7 attr=000
(XEN) 0fec1-0fec10fff type=11 attr=8001
(XEN) 0fff4-0fff46fff type=11 attr=8000
(XEN) Unknown cachability for MFNs 0xfff40-0xfff46
This unknown cacheability causes Xen not to make pagetables for the region.
There is a patch or two floating around the list, but currently no
resolution on the argument it created.
https://github.com/xenserver/xen-4.5.pg/blob/master/master/unknown-cacheabilit
y.patch
is the XenServer fix.
Now that's surely wrong
Right or wrong, this is (apparently; I have not checked) what Linux does.
- if anything, unknown should be treated as
UC (and quite likely specifically in a case like the one Olaf reports here,
as the offending memory range pretty likely is other than normal RAM).
What I'd accept as a patch would be the addition of a command line
option enforcing the mapping of such unknown cacheability areas with
a certain caching type (default then being UC).
If I can find some copious free time, I will see about making this happen.
I actually did cobble a patch like this, but it is based on Daniel's Multibootv2
so it won't apply cleany. See attached patchset with various 'work-arounds'.
Jan if you are OK with them (well the 'idea' behind them) I can refresh
it against staging and post them?
From 33badf8e314251e9d9c3b768c0b7a34b225aa45c Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk konrad.w...@oracle.com
Date: Tue, 3 Feb 2015 11:56:33 -0500
Subject: [PATCH 1/3] EFI/early: Implement /noexit to not ExitBootServices
The /noexitboot will inhibit Xen from calling ExitBootServices.
This allows on Lenovo ThinkPad x230 to use GetNextVariableName
in 1-1 mapping mode.
Signed-off-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
---
xen/arch/x86/efi/efi-boot.h | 2 +-
xen/common/efi/boot.c | 15 +++
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/efi/efi-boot.h b/xen/arch/x86/efi/efi-boot.h
index f50c10a..0fbc4de 100644
--- a/xen/arch/x86/efi/efi-boot.h
+++ b/xen/arch/x86/efi/efi-boot.h
@@ -676,7 +676,7 @@ void __init efi_multiboot2(EFI_HANDLE ImageHandle,
EFI_SYSTEM_TABLE *SystemTable
setup_efi_pci();
efi_variables();
efi_set_gop_mode(gop, gop_mode);
-efi_exit_boot(ImageHandle, SystemTable);
+efi_exit_boot(ImageHandle, SystemTable, 0);
}
/*
diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c
index d1d06d7..2389a1a 100644
--- a/xen/common/efi/boot.c
+++ b/xen/common/efi/boot.c
@@ -86,7 +86,7 @@ static void efi_tables(void);
static void setup_efi_pci(void);
static void efi_variables(void);
static void efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN
gop_mode);
-static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
*SystemTable);
+static void efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
*SystemTable, int exit_boot_services);
static const EFI_BOOT_SERVICES *__initdata efi_bs;
static EFI_HANDLE __initdata efi_ih;
@@ -882,7 +882,7 @@ static void __init
efi_set_gop_mode(EFI_GRAPHICS_OUTPUT_PROTOCOL *gop, UINTN gop
efi_arch_video_init(gop, info_size, mode_info);
}
-static void __init efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
*SystemTable)
+static void __init efi_exit_boot(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE
*SystemTable, int exit_boot_services)
{
EFI_STATUS status;
UINTN map_key;
@@ -906,7 +906,10 @@ static void __init efi_exit_boot(EFI_HANDLE ImageHandle,
EFI_SYSTEM_TABLE *Syste
efi_arch_pre_exit_boot();
-status = efi_bs-ExitBootServices(ImageHandle, map_key);
+if ( exit_boot_services )
+status = efi_bs-ExitBootServices(ImageHandle, map_key);
+else
+status = 0;
if ( status !=
Re: [Xen-devel] crash in efi_runtime_call
On 17/04/15 14:40, Konrad Rzeszutek Wilk wrote: On Fri, Apr 17, 2015 at 01:54:28PM +0100, Andrew Cooper wrote: On 17/04/15 13:39, Jan Beulich wrote: On 17.04.15 at 13:59, andrew.coop...@citrix.com wrote: On 17/04/15 12:17, Olaf Hering wrote: Since booting xen fails on my ProBook unless I specify maxcpus=1 I tried the EFI firmware today. To my surprise it boots and finds all cpus. But once some efi driver in dom0 is loaded xen crashes. The same happens with xen-4.4 as included in SLE12. ... (XEN) Xen call trace: (XEN)[aec1e8e1] aec1e8e1 (XEN)[82d080222600] efi_runtime_call+0x7f0/0x890 (XEN)[82d0801641a9] do_platform_op+0x679/0x1670 (XEN)[82d08021dfb9] syscall_enter+0xa9/0xae Can I do anything about it, or is this a firmware bug? I will move the offending efi driver away and try again. Olaf This is a firmware bug. +1 (and I'm surprised how common this is) The bug is present in the reference implementation code, which means it is present in a lot of real firmware. We have kit from 3 different vendors which are affected, including latest available firmware. (XEN) 1-23fff type=7 attr=000 (XEN) 0fec1-0fec10fff type=11 attr=8001 (XEN) 0fff4-0fff46fff type=11 attr=8000 (XEN) Unknown cachability for MFNs 0xfff40-0xfff46 This unknown cacheability causes Xen not to make pagetables for the region. There is a patch or two floating around the list, but currently no resolution on the argument it created. https://github.com/xenserver/xen-4.5.pg/blob/master/master/unknown-cacheabilit y.patch is the XenServer fix. Now that's surely wrong Right or wrong, this is (apparently; I have not checked) what Linux does. - if anything, unknown should be treated as UC (and quite likely specifically in a case like the one Olaf reports here, as the offending memory range pretty likely is other than normal RAM). What I'd accept as a patch would be the addition of a command line option enforcing the mapping of such unknown cacheability areas with a certain caching type (default then being UC). If I can find some copious free time, I will see about making this happen. I actually did cobble a patch like this, but it is based on Daniel's Multibootv2 so it won't apply cleany. See attached patchset with various 'work-arounds'. Jan if you are OK with them (well the 'idea' behind them) I can refresh it against staging and post them? I was planning to make one efi= command line option along the psr/ept/iommu line, rather than having a large number of top-level options (and folding our one efi-rs option into it). But otherwise, that sounds like a plan. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] crash in efi_runtime_call
On 17.04.15 at 15:40, konrad.w...@oracle.com wrote: I actually did cobble a patch like this, but it is based on Daniel's Multibootv2 so it won't apply cleany. See attached patchset with various 'work-arounds'. Jan if you are OK with them (well the 'idea' behind them) I can refresh it against staging and post them? Yeah, the 3rd of these patches looks pretty close to what could be taken right away (largely subject to whether you'd want to follow Andrew's suggestion to put everything behind a single efi= option, and perhaps allowing cacheability to be other than UC; neither of the two would be a strict requirement for acceptance though). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 14/19] xen: arm: Annotate registers trapped by MDCR_EL2.TDOSA
Gather the affected handlers in a single place per trap type.
Add some HSR_SYSREG and AArch32 defines for those registers (because
I'd already typed them in when I realised I didn't need them).
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v2: Move comment block in cp14_dbg handler from incorrect place in
next patch
Drop stray comment
---
xen/arch/arm/traps.c | 51 +
xen/include/asm-arm/cpregs.h |2 ++
xen/include/asm-arm/sysregs.h |2 ++
3 files changed, 45 insertions(+), 10 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 17ddcd0..7606bff 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1801,6 +1801,21 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
switch ( hsr.bits HSR_CP32_REGS_MASK )
{
+/*
+ * MDCR_EL2.TDOSA
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.15
+ * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58
+ *
+ * Unhandled:
+ *DBGOSLSR
+ *DBGPRCR
+ */
+case HSR_CPREG32(DBGOSLAR):
+return handle_wo_wi(regs, r, cp32.read, hsr, 1);
+case HSR_CPREG32(DBGOSDLR):
+return handle_raz_wi(regs, r, cp32.read, hsr, 1);
+
case HSR_CPREG32(DBGDIDR):
/*
* Read-only register. Accessible by EL0 if DBGDSCRext.UDCCdis
@@ -1840,12 +1855,8 @@ static void do_cp14_32(struct cpu_user_regs *regs, const
union hsr hsr)
case HSR_CPREG32(DBGWCR0):
case HSR_CPREG32(DBGBVR1):
case HSR_CPREG32(DBGBCR1):
-case HSR_CPREG32(DBGOSDLR):
return handle_raz_wi(regs, r, cp32.read, hsr, 1);
-case HSR_CPREG32(DBGOSLAR):
-return handle_wo_wi(regs, r, cp32.read, hsr, 1);
-
/*
* CPTR_EL2.TTA
*
@@ -1923,6 +1934,18 @@ static void do_cp14_dbg(struct cpu_user_regs *regs,
const union hsr hsr)
return;
}
+/*
+ * MDCR_EL2.TDOSA
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.15
+ * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58
+ *
+ * Unhandled:
+ *DBGDTRTXint
+ *DBGDTRRXint
+ *
+ * And all other unknown registers.
+ */
gdprintk(XENLOG_ERR,
%s p14, %d, r%d, r%d, cr%d @ 0x%PRIregister\n,
cp64.read ? mrrc : mcrr,
@@ -1977,6 +2000,20 @@ static void do_sysreg(struct cpu_user_regs *regs,
case HSR_SYSREG_MDRAR_EL1:
return handle_ro_raz(regs, x, hsr.sysreg.read, hsr, 1);
+/*
+ * MDCR_EL2.TDOSA
+ *
+ * ARMv8 (DDI 0487A.d): D1-1509 Table D1-58
+ *
+ * Unhandled:
+ *OSLSR_EL1
+ *DBGPRCR_EL1
+ */
+case HSR_SYSREG_OSLAR_EL1:
+return handle_wo_wi(regs, x, hsr.sysreg.read, hsr, 1);
+case HSR_SYSREG_OSDLR_EL1:
+return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1);
+
/* RAZ/WI registers: */
/* - Debug */
case HSR_SYSREG_MDSCR_EL1:
@@ -1986,8 +2023,6 @@ static void do_sysreg(struct cpu_user_regs *regs,
/* - Watchpoints */
HSR_SYSREG_DBG_CASES(DBGWVR):
HSR_SYSREG_DBG_CASES(DBGWCR):
-/* - Double Lock Register */
-case HSR_SYSREG_OSDLR_EL1:
/* - Perf monitors */
case HSR_SYSREG_PMINTENSET_EL1:
case HSR_SYSREG_PMINTENCLR_EL1:
@@ -2029,10 +2064,6 @@ static void do_sysreg(struct cpu_user_regs *regs,
*/
return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1);
-/* Write only, Write ignore registers: */
-case HSR_SYSREG_OSLAR_EL1:
-return handle_wo_wi(regs, x, hsr.sysreg.read, hsr, 1);
-
case HSR_SYSREG_CNTP_CTL_EL0:
case HSR_SYSREG_CNTP_TVAL_EL0:
case HSR_SYSREG_CNTP_CVAL_EL0:
diff --git a/xen/include/asm-arm/cpregs.h b/xen/include/asm-arm/cpregs.h
index 9db8cfd..e5cb00c 100644
--- a/xen/include/asm-arm/cpregs.h
+++ b/xen/include/asm-arm/cpregs.h
@@ -83,7 +83,9 @@
#define DBGBVR1 p14,0,c0,c1,4 /* Breakpoint Value 1 */
#define DBGBCR1 p14,0,c0,c1,5 /* Breakpoint Control 1 */
#define DBGOSLARp14,0,c1,c0,4 /* OS Lock Access */
+#define DBGOSLSRp14,0,c1,c1,4 /* OS Lock Status Register */
#define DBGOSDLRp14,0,c1,c3,4 /* OS Double Lock */
+#define DBGPRCR p14,0,c1,c4,4 /* Debug Power Control Register */
/* CP14 CR0: */
#define TEECR p14,6,c0,c0,0 /* ThumbEE Configuration Register */
diff --git a/xen/include/asm-arm/sysregs.h b/xen/include/asm-arm/sysregs.h
index 55457fd..570f43e 100644
--- a/xen/include/asm-arm/sysregs.h
+++ b/xen/include/asm-arm/sysregs.h
@@ -47,7 +47,9 @@
#define HSR_SYSREG_MDSCR_EL1 HSR_SYSREG(2,0,c0,c2,2)
#define HSR_SYSREG_MDRAR_EL1 HSR_SYSREG(2,0,c1,c0,0)
#define HSR_SYSREG_OSLAR_EL1 HSR_SYSREG(2,0,c1,c0,4)
+#define HSR_SYSREG_OSLSR_EL1 HSR_SYSREG(2,0,c1,c1,4)
#define HSR_SYSREG_OSDLR_EL1 HSR_SYSREG(2,0,c1,c3,4)
+#define HSR_SYSREG_DBGPRCR_EL1HSR_SYSREG(2,0,c1,c4,4)
#define HSR_SYSREG_MDCCSR_EL0 HSR_SYSREG(2,3,c0,c1,0)
#define HSR_SYSREG_DBGBVRn_EL1(n)
[Xen-devel] [PATCH v2 07/19] xen: arm: Annotate trap handler for HSR_EL2.{TWI, TWE, TSC}
Reference the bit which enables the trap and the section/page which
describes what that bit enables.
These ones are pretty trivial, included for completeness.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v2: s/HSR_EL2/HCR_EL2/
---
xen/arch/arm/traps.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 7110c66..7b79990 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -2089,6 +2089,12 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs
*regs)
switch (hsr.ec) {
case HSR_EC_WFI_WFE:
+/*
+ * HCR_EL2.TWI, HCR_EL2.TWE
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.9
+ * ARMv8 (DDI 0487A.d): D1-1505 Table D1-51
+ */
if ( !check_conditional_instr(regs, hsr) )
{
advance_pc(regs, hsr);
@@ -2131,6 +2137,12 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs
*regs)
do_cp(regs, hsr);
break;
case HSR_EC_SMC32:
+/*
+ * HCR_EL2.TSC
+ *
+ * ARMv7 (DDI 0406C.b): B1.14.8
+ * ARMv8 (DDI 0487A.d): D1-1501 Table D1-44
+ */
GUEST_BUG_ON(!psr_mode_is_32bit(regs-cpsr));
perfc_incr(trap_smc32);
inject_undef32_exception(regs);
@@ -2159,6 +2171,11 @@ asmlinkage void do_trap_hypervisor(struct cpu_user_regs
*regs)
do_trap_hypercall(regs, regs-x16, hsr.iss);
break;
case HSR_EC_SMC64:
+/*
+ * HCR_EL2.TSC
+ *
+ * ARMv8 (DDI 0487A.d): D1-1501 Table D1-44
+ */
GUEST_BUG_ON(psr_mode_is_32bit(regs-cpsr));
perfc_incr(trap_smc64);
inject_undef64_exception(regs, hsr.len);
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 16/19] xen: arm: Annotate registers trapped by MDCR_EL2.TPM and TPMCR
Signed-off-by: Ian Campbell ian.campb...@citrix.com --- xen/arch/arm/traps.c | 39 ++- 1 file changed, 34 insertions(+), 5 deletions(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 97cde45..d4505b5 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -1672,6 +1672,24 @@ static void do_cp15_32(struct cpu_user_regs *regs, *r = v-arch.actlr; break; +/* + * MDCR_EL2.TPM + * + * ARMv7 (DDI 0406C.b): B1.14.17 + * ARMv8 (DDI 0487A.d): D1-1511 Table D1-61 + * + * Unhandled: + *PMEVCNTRn + *PMEVTYPERn + *PMCCFILTR + * + * MDCR_EL2.TPMCR + * + * ARMv7 (DDI 0406C.b): B1.14.17 + * ARMv8 (DDI 0487A.d): D1-1511 Table D1-62 + * + * NB: Both MDCR_EL2.TPM and MDCR_EL2.TPMCR cause trapping of PMCR. + */ /* We could trap ID_DFR0 and tell the guest we don't support * performance monitoring, but Linux doesn't check the ID_DFR0. * Therefore it will read PMCR. @@ -1686,7 +1704,6 @@ static void do_cp15_32(struct cpu_user_regs *regs, return handle_ro_raz(regs, r, cp32.read, hsr, 0); else return handle_raz_wi(regs, r, cp32.read, hsr, 1); - case HSR_CPREG32(PMINTENSET): case HSR_CPREG32(PMINTENCLR): /* EL1 only, however MDCR_EL2.TPM==1 means EL0 may trap here also. */ @@ -2067,8 +2084,22 @@ static void do_sysreg(struct cpu_user_regs *regs, HSR_SYSREG_DBG_CASES(DBGWCR): return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); -/* RAZ/WI registers: */ -/* - Perf monitors */ +/* + * MDCR_EL2.TPM + * + * ARMv8 (DDI 0487A.d): D1-1511 Table D1-61 + * + * Unhandled: + *PMEVCNTRn_EL0 + *PMEVTYPERn_EL0 + *PMCCFILTR_EL0 + * MDCR_EL2.TPMCR + * + * ARMv7 (DDI 0406C.b): B1.14.17 + * ARMv8 (DDI 0487A.d): D1-1511 Table D1-62 + * + * NB: Both MDCR_EL2.TPM and MDCR_EL2.TPMCR cause trapping of PMCR. + */ case HSR_SYSREG_PMINTENSET_EL1: case HSR_SYSREG_PMINTENCLR_EL1: /* @@ -2076,8 +2107,6 @@ static void do_sysreg(struct cpu_user_regs *regs, * undef. */ return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); - -/* - Perf monitors */ case HSR_SYSREG_PMUSERENR_EL0: /* RO at EL0. RAZ/WI at EL1 */ if ( psr_mode_is_user(regs) ) -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 15/19] xen: arm: Annotate registers trapped by MDCR_EL2.TDA
Gather the affected handlers in a single place per trap type. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- xen/arch/arm/traps.c | 60 +- 1 file changed, 49 insertions(+), 11 deletions(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 7606bff..97cde45 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -1816,6 +1816,28 @@ static void do_cp14_32(struct cpu_user_regs *regs, const union hsr hsr) case HSR_CPREG32(DBGOSDLR): return handle_raz_wi(regs, r, cp32.read, hsr, 1); +/* + * MDCR_EL2.TDA + * + * ARMv7 (DDI 0406C.b): B1.14.15 + * ARMv8 (DDI 0487A.d): D1-1510 Table D1-59 + * + * Unhandled: + *DBGDCCINT + *DBGDTRRXint + *DBGDTRTXint + *DBGWFAR + *DBGDTRTXext + *DBGDTRRXext, + *DBGBXVRn + *DBGCLAIMSET + *DBGCLAIMCLR + *DBGAUTHSTATUS + *DBGDEVID + *DBGDEVID1 + *DBGDEVID2 + *DBGOSECCR + */ case HSR_CPREG32(DBGDIDR): /* * Read-only register. Accessible by EL0 if DBGDSCRext.UDCCdis @@ -2014,15 +2036,38 @@ static void do_sysreg(struct cpu_user_regs *regs, case HSR_SYSREG_OSDLR_EL1: return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); -/* RAZ/WI registers: */ -/* - Debug */ +/* + * MDCR_EL2.TDA + * + * ARMv8 (DDI 0487A.d): D1-1510 Table D1-59 + * + * Unhandled: + *MDCCINT_EL1 + *DBGDTR_EL0 + *DBGDTRRX_EL0 + *DBGDTRTX_EL0 + *OSDTRRX_EL1 + *OSDTRTX_EL1 + *OSECCR_EL1 + *DBGCLAIMSET_EL1 + *DBGCLAIMCLR_EL1 + *DBGAUTHSTATUS_EL1 + */ case HSR_SYSREG_MDSCR_EL1: -/* - Breakpoints */ +return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); +case HSR_SYSREG_MDCCSR_EL0: +/* + * Accessible at EL0 only if MDSCR_EL1.TDCC is set to 0. We emulate that + * register as RAZ/WI above. So RO at both EL0 and EL1. + */ +return handle_ro_raz(regs, x, hsr.sysreg.read, hsr, 0); HSR_SYSREG_DBG_CASES(DBGBVR): HSR_SYSREG_DBG_CASES(DBGBCR): -/* - Watchpoints */ HSR_SYSREG_DBG_CASES(DBGWVR): HSR_SYSREG_DBG_CASES(DBGWCR): +return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); + +/* RAZ/WI registers: */ /* - Perf monitors */ case HSR_SYSREG_PMINTENSET_EL1: case HSR_SYSREG_PMINTENCLR_EL1: @@ -2032,13 +2077,6 @@ static void do_sysreg(struct cpu_user_regs *regs, */ return handle_raz_wi(regs, x, hsr.sysreg.read, hsr, 1); -case HSR_SYSREG_MDCCSR_EL0: -/* - * Accessible at EL0 only if MDSCR_EL1.TDCC is set to 0. We emulate that - * register as RAZ/WI above. So RO at both EL0 and EL1. - */ -return handle_ro_raz(regs, x, hsr.sysreg.read, hsr, 0); - /* - Perf monitors */ case HSR_SYSREG_PMUSERENR_EL0: /* RO at EL0. RAZ/WI at EL1 */ -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 12/19] xen: arm: Annotate the handlers for HSTR_EL2.T15
Signed-off-by: Ian Campbell ian.campb...@citrix.com --- v2: s/Tx/T15/ --- xen/arch/arm/traps.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index a2bae51..86b5655 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -1720,6 +1720,11 @@ static void do_cp15_32(struct cpu_user_regs *regs, * ARMv7 (DDI 0406C.b): B1.14.12 * ARMv8 (DDI 0487A.d): N/A * + * HSTR_EL2.T15 + * + * ARMv7 (DDI 0406C.b): B1.14.14 + * ARMv8 (DDI 0487A.d): D1-1507 Table D1-55 + * * And all other unknown registers. */ default: @@ -1758,6 +1763,11 @@ static void do_cp15_64(struct cpu_user_regs *regs, * ARMv7 (DDI 0406C.b): B1.14.12 * ARMv8 (DDI 0487A.d): N/A * + * HSTR_EL2.Tx + * + * ARMv7 (DDI 0406C.b): B1.14.14 + * ARMv8 (DDI 0487A.d): D1-1507 Table D1-55 + * * And all other unknown registers. */ default: -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/8] raisin: Fix non-verbose case
On Thu, 16 Apr 2015, George Dunlap wrote:
Because we use set -e, we can't use the a b construct, as it will fail
and stop the script.
Signed-off-by: George Dunlap george.dun...@eu.citrix.com
I am wondering whether we should ban both a b and a || b from the
code and just go with the more verbose but also harder to get wrong:
if [[ $VERBOSE -eq 1 ]]
then
echo calling $component_$1
fi
Reading the code and seeing a || b will tempt you into writing a b.
lib/common-functions.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/common-functions.sh b/lib/common-functions.sh
index 36e1766..06c894a 100644
--- a/lib/common-functions.sh
+++ b/lib/common-functions.sh
@@ -232,9 +232,9 @@ function for_each_component () {
fi
if eval [[ ! -z \$$capital_REVISION ]]
then
-[[ $VERBOSE -eq 1 ]] echo calling $component_$1
+[[ $VERBOSE -eq 0 ]] || echo calling $component_$1
$component_$1
-[[ $VERBOSE -eq 1 ]] echo $component_$1 done
+[[ $VERBOSE -eq 0 ]] || echo $component_$1 done
fi
done
}
--
1.9.1
___
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
Re: [Xen-devel] [PATCH 5/8] raisin: Fix CentOS build
On Thu, 16 Apr 2015, George Dunlap wrote:
Add package dependencies for CentOS. Also use PKGTYPE rather than
DISTRO to determine if we need rpm-build.
I've tested this for xen but not for libvirt or grub.
Signed-off-by: George Dunlap george.dun...@eu.citrix.com
---
CC: Stefano Stabellini stefano.stabell...@citrix.com
---
components/grub| 5 +
components/libvirt | 7 +++
components/xen | 10 --
lib/commands.sh| 2 +-
4 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/components/grub b/components/grub
index 563a28c..af396d9 100644
--- a/components/grub
+++ b/components/grub
@@ -12,6 +12,11 @@ function grub_check_package() {
local DEP_Fedora_x86_32=$DEP_Fedora_common
local DEP_Fedora_x86_64=$DEP_Fedora_common glibc-devel.i686
+local DEP_CentOS_common=make gcc tar automake autoconf sysconftool
bison flex \
+ glibc-devel
+local DEP_CentOS_x86_32=$DEP_CentOS_common
+local DEP_CentOS_x86_64=$DEP_CentOS_common glibc-devel.i686
Given that they are the same as Fedora, I think it is OK to:
local DEP_CentOS_common=$DEP_Fedora_common
if [[ $ARCH != x86_64 $ARCH != x86_32 ]]
then
diff --git a/components/libvirt b/components/libvirt
index 5853950..aef1bc8 100644
--- a/components/libvirt
+++ b/components/libvirt
@@ -18,6 +18,13 @@ function libvirt_check_package() {
local DEP_Fedora_x86_32=$DEP_Fedora_common
local DEP_Fedora_x86_64=$DEP_Fedora_common
+local DEP_CentOS_common=patch make gcc libtool autoconf gettext-devel
\
+ python-devel libxslt yajl-devel libxml2-devel
\
+ device-mapper-devel libpciaccess-devel
\
+ libuuid-devel perl-XML-XPath
+local DEP_CentOS_x86_32=$DEP_CentOS_common
+local DEP_CentOS_x86_64=$DEP_CentOS_common
Same here, also please test the libvirt build: the list of dependencies
is pretty big, I worry that one of them might actually differ from Fedora
echo Checking Libvirt dependencies
eval check-package \$DEP_$DISTRO_$ARCH
}
diff --git a/components/xen b/components/xen
index a0c0034..f2e1254 100644
--- a/components/xen
+++ b/components/xen
@@ -11,10 +11,16 @@ function xen_check_package() {
local DEP_Fedora_common=make gcc python-devel gettext libuuid-devel \
ncurses-devel glib2-devel libaio-devel openssl-devel yajl-devel
\
- patch pixman-devel glibc-devel bridge-utils grub2 wget
-local DEP_Fedora_x86_32=$DEP_Fedora_common dev86 acpica-tools texinfo
+ patch pixman-devel glibc-devel bridge-utils grub2 wget tar
bzip2
+local DEP_Fedora_x86_32=$DEP_Fedora_common dev86 texinfo acpica-devel
local DEP_Fedora_x86_64=$DEP_Fedora_x86_32 glibc-devel.i686
+local DEP_CentOS_common=make gcc python-devel gettext libuuid-devel \
+ ncurses-devel glib2-devel libaio-devel openssl-devel yajl-devel
\
+ patch pixman-devel glibc-devel bridge-utils wget tar bzip2
+local DEP_CentOS_x86_32=$DEP_CentOS_common dev86 texinfo iasl
+local DEP_CentOS_x86_64=$DEP_CentOS_x86_32 glibc-devel.i686
+
echo Checking Xen dependencies
eval check-package \$DEP_$DISTRO_$ARCH
}
I think is fair to DEP_CentOS_common=$DEP_Fedora_common here too (once
the acpica-devel/tools thing is fixed)
diff --git a/lib/commands.sh b/lib/commands.sh
index c47ba1f..17e2129 100755
--- a/lib/commands.sh
+++ b/lib/commands.sh
@@ -5,7 +5,7 @@ function check-builddep() {
check-package git
-if [[ $DISTRO = Fedora ]]
+if [[ $PKGTYPE = rpm ]]
then
check-package rpm-build
fi
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] kernel BUG at drivers/xen/grant-table.c:923!
On Fri, Apr 17, 2015 at 11:28:39AM +0100, Ian Campbell wrote:
(Was Re: [osstest test] 50423: regressions - FAIL)
This cropped up in an osstest flight (the results only go to Ian and I).
On Fri, 2015-04-17 at 11:10 +0100, Ian Campbell wrote:
On Thu, 2015-04-16 at 21:36 +, osstest service user wrote:
flight 50423 osstest real [real]
http://logs.test-lab.xenproject.org/osstest/logs/50423/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl 15 guest-start/debian.repeat fail REGR. vs.
50331
Looks to have been a real issue:
http://logs.test-lab.xenproject.org/osstest/logs/50423/test-armhf-armhf-xl/serial-cubietruck-gleizes.log
Apr 14 19:01:21.834851 [ 1229.470934] [ cut here ]
Apr 14 19:01:22.445308 [ 1229.471001] kernel BUG at
drivers/xen/grant-table.c:923!
This seems familiar, anyone remember it? (CCing ARM, netback and generic
Linux maintainers).
I had a look over
$ git log v3.16..origin/master -- drivers/net/xen-netback/ drivers/xen/
arch/*/xen
and nothing jumped out at me.
The new tests under flight include running tcpdump for the duration of
the migration. I wonder if that might have exposed the problem?
This is ARM for which osstest uses a 3.16 based kernel compared with x86
which is still on 3.14. That might explain why this was only seen on arm
(if tcpdump triggered it) or it might just be a very rare occurrence.
I've never seen this before. If I'm not mistaken this is referring to
918 void gnttab_batch_copy(struct gnttab_copy *batch, unsigned count)
919 {
920 struct gnttab_copy *op;
921
922 if (HYPERVISOR_grant_table_op(GNTTABOP_copy, batch, count))
923 BUG();
924 for (op = batch; op batch + count; op++)
925 if (op-status == GNTST_eagain)
926 gnttab_retry_eagain_gop(GNTTABOP_copy, op,
927 op-status, __func__);
928 }
Grant table op hypercall returns an error.
Would be useful to know what the actually error is.
Wei.
Apr 14 19:01:22.450646 [ 1229.471026] Internal error: Oops - BUG: 0 [#1]
SMP ARM
Apr 14 19:01:22.455886 [ 1229.471052] Modules linked in: xen_gntalloc
bridge stp ipv6 llc brcmfmac brcmutil cfg80211
Apr 14 19:01:22.464140 [ 1229.471145] CPU: 0 PID: 18258 Comm:
vif9.0-q0-guest Not tainted 3.16.7-ckt4+ #1
Apr 14 19:01:22.471529 [ 1229.471181] task: d80e0d80 ti: db73 task.ti:
db73
Apr 14 19:01:22.477016 [ 1229.471219] PC is at gnttab_batch_copy+0xd4/0xe0
Apr 14 19:01:22.481638 [ 1229.471257] LR is at gnttab_batch_copy+0x1c/0xe0
Apr 14 19:01:22.486422 [ 1229.471285] pc : [c04ab434]lr :
[c04ab37c]psr: a013
Apr 14 19:01:22.492642 [ 1229.471285] sp : db731eb0 ip : deadbeef fp :
db731f3c
Apr 14 19:01:22.498021 [ 1229.471329] r10: 0001 r9 : r8 :
0002
Apr 14 19:01:22.503293 [ 1229.471352] r7 : 0001 r6 : 0001 r5 :
r4 : e2003d30
Apr 14 19:01:22.509907 [ 1229.471380] r3 : 0001 r2 : deadbeef r1 :
deadbeef r0 : fff2
Apr 14 19:01:22.516431 [ 1229.471409] Flags: NzCv IRQs on FIQs on Mode
SVC_32 ISA ARM Segment kernel
Apr 14 19:01:22.523802 [ 1229.471440] Control: 10c5387d Table: 7987806a
DAC: 0015
Apr 14 19:01:22.529651 [ 1229.471469] Process vif9.0-q0-guest (pid: 18258,
stack limit = 0xdb730248)
Apr 14 19:01:22.536553 [ 1229.471515] Stack: (0xdb731eb0 to 0xdb732000)
Apr 14 19:01:22.541024 [ 1229.471543] 1ea0:
0001 e1ffb000
Apr 14 19:01:22.549146 [ 1229.471581] 1ec0: 0001 c05d6acc 004e
0a02 db731f3c 0001
Apr 14 19:01:22.557387 [ 1229.471626] 1ee0: dbbbfcc0
0002 db731f20 e2003cfc e2003d30
Apr 14 19:01:22.565641 [ 1229.471663] 1f00: 0001 0001
e2003d30 e202e530 004e 0202
Apr 14 19:01:22.573891 [ 1229.471699] 1f20: d290ee40 d290ee40 0001
db731f2c db731f34 db731f34
Apr 14 19:01:22.582139 [ 1229.471736] 1f40: db56d240
e1ffb000 c05d65f4
Apr 14 19:01:22.590388 [ 1229.471772] 1f60: c0264048
e1ffb000
Apr 14 19:01:22.598639 [ 1229.471808] 1f80: db731f80 db731f80
db731f90 db731f90 db731fac db56d240
Apr 14 19:01:22.606888 [ 1229.471843] 1fa0: c0263f7c
c020f038
Apr 14 19:01:22.615016 [ 1229.471879] 1fc0:
Apr 14 19:01:22.623268 [ 1229.471914] 1fe0:
0013
Apr 14 19:01:22.631514 [ 1229.471978] [c04ab434]
Re: [Xen-devel] [PATCH 8/8] raisin: RFC Add blktap2 as an external tree
On Thu, 16 Apr 2015, George Dunlap wrote:
Until we start hosting the blktap repo on xenbits, use the one from github.
Also, we need to pass in the directories where to find the
libblktapctl headers in the Xen build.
Signed-off-by: George Dunlap george.dun...@eu.citrix.com
---
Note: For now use the upstream XenServer repo.
Also, to build with this you need the patches to allow Xen to use an
out-of-tree blktap,
which can be found here:
git://xenbits.xen.org/people/gdunlap/xen.git out/blktap25/rfc-v2
CC: Stefano Stabellini stefano.stabell...@citrix.com
---
components/blktap | 47 +++
components/series | 1 +
components/xen| 5 +
defconfig | 9 ++---
4 files changed, 59 insertions(+), 3 deletions(-)
create mode 100644 components/blktap
diff --git a/components/blktap b/components/blktap
new file mode 100644
index 000..3062b2a
--- /dev/null
+++ b/components/blktap
@@ -0,0 +1,47 @@
+#!/usr/bin/env bash
+
+function blktap_check_package() {
+local DEP_Debian_common=build-essential autoconf libtool tar libaio-dev
uuid-dev openssl-dev
+local DEP_Debian_x86_32=$DEP_Debian_common
+local DEP_Debian_x86_64=$DEP_Debian_x86_32
+local DEP_Debian_arm32=$DEP_Debian_common
+local DEP_Debian_arm64=$DEP_Debian_arm32
+
+local DEP_Fedora_common=make gcc python-devel autoconf libtool tar file
libaio-devel libuuid-devel openssl-devel
+local DEP_Fedora_x86_32=$DEP_Fedora_common
+local DEP_Fedora_x86_64=$DEP_Fedora_x86_32
+
+local DEP_CentOS_common=make gcc python-devel autoconf libtool tar file
libaio-devel libuuid-devel openssl-devel
DEP_CentOS_common=$DEP_Fedora_common
+local DEP_CentOS_x86_32=$DEP_Redhat_common
+local DEP_CentOS_x86_64=$DEP_Redhat_x86_32
Redhat? I don't know no Redhat.
+echo Checking blktap dependencies
+eval check-package \$DEP_$DISTRO_$ARCH
+}
+
+function blktap_build() {
+cd $BASEDIR
+git-checkout $BLKTAP_URL $BLKTAP_REVISION blktap-dir
+cd blktap-dir
+./autogen.sh
+./configure --prefix=$PREFIX
+$MAKE
+$MAKE install DESTDIR=$INST_DIR
+cd $BASEDIR
+}
+
+function blktap_clean() {
+cd $BASEDIR
+if [[ -d blktap-dir ]]
+then
+ rm -rf blktap-dir
Stray tabs. Do we need the emacs config stanza somewhere in raisin?
+fi
+}
+
+function blktap_configure() {
+:
+}
+
+function blktap_unconfigure() {
+:
+}
Much better than my echo. Maybe submit a patch to replace useless echo
in configure and unconfigure functions with :
diff --git a/components/series b/components/series
index 8f614f0..953800a 100644
--- a/components/series
+++ b/components/series
@@ -1,3 +1,4 @@
+blktap
xen
I take this is on purpose so that blktap is built before xen
qemu
grub
diff --git a/components/xen b/components/xen
index f2e1254..03a1970 100644
--- a/components/xen
+++ b/components/xen
@@ -29,7 +29,12 @@ function xen_build() {
cd $BASEDIR
git-checkout $XEN_URL $XEN_REVISION xen-dir
cd xen-dir
+CFLAGS=-I$INST_DIR/$PREFIX/include/blktap
-I$INST_DIR/$PREFIX/include/vhd \
+LDFLAGS=-L$INST_DIR/$PREFIX/lib -Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
./configure --prefix=$PREFIX --with-system-qemu=/usr/bin/qemu-system-i386
+CFLAGS_libblktapctl=-I$INST_DIR/$PREFIX/include/blktap
-I$INST_DIR/$PREFIX/include/vhd \
+LDLIBS_libblktapctl=-L$INST_DIR/$PREFIX/lib -lblktapctl \
+SHLIB_libblktapctl=-Wl,-rpath-link=$INST_DIR/$PREFIX/lib \
Does this work even if blktap is actually disabled in the raisin build?
If so, then fine.
Actually I think that the xen configure script should be able to figure
out whether it can pick up blktap from an external location
automatically with the CFLAGS and LDFLAGS you set.
$RAISIN_MAKE
$RAISIN_MAKE install DESTDIR=$INST_DIR
cd $BASEDIR
diff --git a/defconfig b/defconfig
index 4ec8a0b..283e954 100644
--- a/defconfig
+++ b/defconfig
@@ -1,9 +1,9 @@
# Config variables for raisin
# Components
-# All components: xen grub libvirt
-# Core xen functionality: xen
-DEFAULT_COMPONENTS=xen grub libvirt
+# All components: blktap xen grub libvirt
+# Core xen functionality: xen blktap
+DEFAULT_COMPONENTS=blktap xen grub libvirt
# Build config
## Make command to run
@@ -22,6 +22,8 @@ XEN_URL=git://xenbits.xen.org/xen.git
QEMU_URL=git://git.qemu.org/qemu.git
GRUB_URL=git://git.savannah.gnu.org/grub.git
LIBVIRT_URL=git://libvirt.org/libvirt.git
+BLKTAP_URL=https://github.com/xapi-project/blktap.git
+#BLKTAP_URL=git://xenbits.xen.org/blktap.git
# Software versions. Leave blank if you want to avoid the build, like
# this: GRUB_REVISION=
@@ -30,3 +32,4 @@ XEN_REVISION=master
QEMU_REVISION=master
GRUB_REVISION=master
LIBVIRT_REVISION=master
+BLKTAP_REVISION=blktap2
--
1.9.1
___
Xen-devel
Re: [Xen-devel] [PATCH 8/8] raisin: RFC Add blktap2 as an external tree
On Fri, 2015-04-17 at 11:50 +0100, Stefano Stabellini wrote: +local DEP_CentOS_x86_32=$DEP_Redhat_common +local DEP_CentOS_x86_64=$DEP_Redhat_x86_32 Redhat? I don't know no Redhat. Is the use of x86_32 rather than common on the x86_64 case deliberate? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
