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, 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 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, wrote: On 04/16/2015 11:54 PM, Jan Beulich wrote: On 15.04.15 at 09:03, 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 04/17/2015 02:58 PM, Jan Beulich wrote:
On 17.04.15 at 08:51, wrote:
On 04/17/2015 02:23 PM, Jan Beulich wrote:
On 17.04.15 at 05:10, wrote:
On 04/16/2015 11:42 PM, Jan Beulich wrote:
On 15.04.15 at 09:03, 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] [v2 11/11] p2m/ept: enable PML in p2m-ept for log-dirty
>>> On 17.04.15 at 09:10, wrote: > On 04/17/2015 02:28 PM, Jan Beulich wrote: > On 17.04.15 at 04:40, wrote: >>> On 04/16/2015 11:54 PM, Jan Beulich wrote: >>> On 15.04.15 at 09:03, 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 17.04.15 at 09:23, wrote:
>
> On 04/17/2015 02:58 PM, Jan Beulich wrote:
> On 17.04.15 at 08:51, wrote:
>>> On 04/17/2015 02:23 PM, Jan Beulich wrote:
>>> On 17.04.15 at 05:10, wrote:
> On 04/16/2015 11:42 PM, Jan Beulich wrote:
> On 15.04.15 at 09:03, 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, 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
[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 Dirk Mueller Dirk Müller Edgar E. Iglesias Peter Maydell Thomas Huth 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 pass test-amd64-i386-xl pass test-amd64-am
Re: [Xen-devel] [v1] x86/cpuidle: get accurate C0 value with xenpm tool
>>> On 17.04.15 at 09:36, wrote: > From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Thursday, April 16, 2015 4:49 PM On 16.04.15 at 08:03, 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] [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, wrote:
On 04/17/2015 02:58 PM, Jan Beulich wrote:
On 17.04.15 at 08:51, wrote:
On 04/17/2015 02:23 PM, Jan Beulich wrote:
On 17.04.15 at 05:10, wrote:
On 04/16/2015 11:42 PM, Jan Beulich wrote:
On 15.04.15 at 09:03, 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 1/1] x86/hvm: prevent hvm_free_ioreq_gmfn() clobber of arbitrary memory
>>> On 16.04.15 at 18:37, wrote: > At 12:32 +0100 on 16 Apr (1429187564), Jan Beulich wrote: >> >>> On 16.04.15 at 12:53, 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
Re: [Xen-devel] [PATCH] passthrough/amd: avoid reading an uninitialized variable.
>>> On 16.04.15 at 19:19, 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 >> Cc: Suravee Suthikulpanit >> Cc: Aravind Gopalakrishnan > > 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 4/5] vscsiif.h: add some notes about xenstore layout
Signed-off-by: Olaf Hering
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Keir Fraser
Cc: Tim Deegan
---
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:
+ *
+ * //feature-host = "0"
+ * //frontend = "/local/domain//device/vscsi/0"
+ * //frontend-id = ""
+ * //online = "1"
+ * //state = "4"
+ * //vscsi-devs/dev-0/p-dev = "8:0:2:1" or "naa.wwn:lun"
+ * //vscsi-devs/dev-0/state = "4"
+ * //vscsi-devs/dev-0/v-dev = "0:0:0:0"
+ * //vscsi-devs/dev-1/p-dev = "8:0:2:2"
+ * //vscsi-devs/dev-1/state = "4"
+ * //vscsi-devs/dev-1/v-dev = "0:0:1:0"
+ *
+ * The frontend driver maintains its state in
+ * /local/domain//device/vscsi/.
+ *
+ * /backend = "/local/domain/0/backend/vscsi//"
+ * /backend-id = "0"
+ * /event-channel = "20"
+ * /ring-ref = "43"
+ * /state = "4"
+ * /vscsi-devs/dev-0/state = "4"
+ * /vscsi-devs/dev-1/state = "4"
+ *
+ * In addition to the entries for backend and frontend these flags are stored
+ * for the toolstack:
+ *
+ * //vscsi-devs/dev-1/p-devname = "/dev/$device"
+ *
+ *
+ * Backend/frontend protocol
+ * =
+ *
+ * To create a vhost along with a device:
+ * //feature-host = "0"
+ * //frontend = "/local/domain//device/vscsi/0"
+ * //frontend-id = ""
+ * //online = "1"
+ * //state = "1"
+ * //vscsi-devs/dev-0/p-dev = "8:0:2:1"
+ * //vscsi-devs/dev-0/state = "1"
+ * //vscsi-devs/dev-0/v-dev = "0:0:0:0"
+ * Wait for //state + //vscsi-devs/dev-0/state
become 4
+ *
+ * To add another device to a vhost:
+ * //state = "7"
+ * //vscsi-devs/dev-1/p-dev = "8:0:2:2"
+ * //vscsi-devs/dev-1/state = "1"
+ * //vscsi-devs/dev-1/v-dev = "0:0:1:0"
+ * Wait for //state + //vscsi-devs/dev-1/state
become 4
+ *
+ * To remove a device from a vhost:
+ * //state = "7"
+ * //vscsi-devs/dev-1/state = "5"
+ * Wait for //state to become 4
+ * Wait for //vscsi-devs/dev-1/state become 6
+ * Remove //vscsi-devs/dev-1/{state,p-dev,v-dev,p-devname}
+ * Remove //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 Cc: Ian Campbell Cc: Ian Jackson Cc: Jan Beulich Cc: Keir Fraser Cc: Tim Deegan --- 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
[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
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
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 B
+
+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 B
+
+=over 4
+
+=item C
+
+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 C
+
+No options recognized.
+
+=back
+
+=item B
+
+=over 4
+
+=item C
+
+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 C
+
+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 B
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 B I I I,I<[feature-host]>
+
+Creates a new vscsi device in the domain specified by I.
+
+=item B I I
+
+Removes the vscsi device from domain specified by I.
+
+=item B I I<[domain-id] ...>
+
+List vscsi devices for the domain specified by I.
+
+=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 @@ static int libxl__resolve_domid(libxl__gc *gc, const
char *name,
}
/**/
+
+static void libxl__device_vscsi_dev_backend_rm(libxl__gc *gc,
+ libxl_vscsi_dev *v,
+
[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
---
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 --ver
[Xen-devel] [PATCH v4 2/5] docs: add vscsi to xenstore-paths.markdown
Signed-off-by: Olaf Hering Cc: Ian Campbell Cc: Ian Jackson Cc: Jan Beulich Cc: Keir Fraser Cc: Tim Deegan --- 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] [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] [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] [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/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
AIUI raisin does build dependency handling/tracking. If so then fakeroot
ought to be added to it I think?
> ---
> CC: Stefano Stabellini
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] 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 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 > CC: Jim Fehlig > CC: Konrad Rzeszutek Wilk Acked-by: Ian Campbell ___ 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 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 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] [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 > CC: Jim Fehlig > CC: Konrad Rzeszutek Wilk Acked-by: Ian Campbell ___ 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 > Reported-by: Jim Fehlig > Signed-off-by: Ian Jackson > CC: Jim Fehlig > CC: Konrad Rzeszutek Wilk Acked-by: Ian Campbell ___ 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] [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] 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] 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] [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
>
> 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
>
> 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
---
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
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
Acked-by: Ian Jackson
---
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] [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] 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
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 > 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 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
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
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 4/8] raisin: Use PKGTYPE rather than DISTRO to determine how to build a package
On Thu, 16 Apr 2015, George Dunlap wrote:
> Signed-off-by: George Dunlap
> ---
> CC: Stefano Stabellini
> ---
> lib/common-functions.sh | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/lib/common-functions.sh b/lib/common-functions.sh
> index 373d6fb..e66c6f4 100644
> --- a/lib/common-functions.sh
> +++ b/lib/common-functions.sh
> @@ -239,16 +239,16 @@ function for_each_component () {
> done
> }
>
> +function _build_package_deb() {
> +fakeroot bash ./scripts/mkdeb "$1"
> +}
> +
> +function _build_package_rpm() {
> +./scripts/mkrpm "$1"
> +}
> +
> function build_package() {
> -if [[ $DISTRO = "Debian" ]]
> -then
> -fakeroot bash ./scripts/mkdeb "$1"
> -elif [[ $DISTRO = "Fedora" ]]
> -then
> -./scripts/mkrpm "$1"
> -else
> -echo "Don't know how to create packages for $DISTRO"
> -fi
> +_build_package_${PKGTYPE} "$1"
Just use "$PKGTYPE" instead of ${}
Also please document PKGTYPE among the exported global variables in the
README.
> }
>
> function install_package() {
> --
> 1.9.1
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/8] Include actual config in package, not defconfig
On Thu, 16 Apr 2015, George Dunlap wrote: > We want to include the actual config used to build the packages. > > Signed-off-by: George Dunlap Acked and committed > CC: Stefano Stabellini > --- > raise | 1 - > scripts/mkdeb | 2 +- > scripts/mkrpm | 2 +- > 3 files changed, 2 insertions(+), 3 deletions(-) > > diff --git a/raise b/raise > index 94507d2..bce6908 100755 > --- a/raise > +++ b/raise > @@ -74,4 +74,3 @@ case "$1" in > esac > > $COMMAND > - > diff --git a/scripts/mkdeb b/scripts/mkdeb > index 86fac72..0225736 100755 > --- a/scripts/mkdeb > +++ b/scripts/mkdeb > @@ -36,7 +36,7 @@ cp -r data deb/opt/raisin > cp -r components deb/opt/raisin > cp -r scripts deb/opt/raisin > cp -r lib deb/opt/raisin > -cp defconfig raise deb/opt/raisin > +cp config raise deb/opt/raisin > > > # Debian doesn't use /usr/lib64 for 64-bit libraries > diff --git a/scripts/mkrpm b/scripts/mkrpm > index 98b630c..8de4508 100755 > --- a/scripts/mkrpm > +++ b/scripts/mkrpm > @@ -48,7 +48,7 @@ cp -r "$BASEDIR"/data \$RPM_BUILD_ROOT/opt/raisin > cp -r "$BASEDIR"/components \$RPM_BUILD_ROOT/opt/raisin > cp -r "$BASEDIR"/scripts \$RPM_BUILD_ROOT/opt/raisin > cp -r "$BASEDIR"/lib \$RPM_BUILD_ROOT/opt/raisin > -cp "$BASEDIR"/defconfig \$RPM_BUILD_ROOT/opt/raisin > +cp "$BASEDIR"/config \$RPM_BUILD_ROOT/opt/raisin > cp "$BASEDIR"/raise \$RPM_BUILD_ROOT/opt/raisin > > %clean > -- > 1.9.1 > ___ 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
> ---
> CC: Stefano Stabellini
> ---
> 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
[Xen-devel] [PATCH OSSTEST] sg-run-job: Repeat rumpuserxen-demo-xenstorels test 150 times
(Was: Re: [osstest test] 50423: regressions - FAIL)
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-amd64-amd64-rumpuserxen-amd64 15
> > rumpuserxen-demo-xenstorels/xenstorels.repeat fail REGR. vs. 50331
>
> The previous pass of this must have been spurious. We should crank the
> number of repetitions I think.
I thought I'd sent such a patch, but no sign of it in the relevant
folders. Here's another.
I'm unsure if the testid should change, I think not in which case this
will take a force push to clear the is-a-regression-ness.
8<
>From b6ec9b81503b8e0a4fb3c529290e2da82b7421a4 Mon Sep 17 00:00:00 2001
From: Ian Campbell
Date: Fri, 17 Apr 2015 11:01:29 +0100
Subject: [PATCH] sg-run-job: Repeat rumpuserxen-demo-xenstorels test 150
times
With 50 we are still seeing occasional spurious passes.
Looking at some logs the current 50 iterations takes around 4 minutes
to run (3-4s per iteration).
I think we can justify spending 10 minutes running this test, which is
150x4s.
Signed-off-by: Ian Campbell
---
sg-run-job | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sg-run-job b/sg-run-job
index 11e33a6..e393408 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -337,7 +337,7 @@ proc run-job/test-rumpuserxen {} {
run-ts . = ts-rumpuserxen-demo-setup + host + $g
run-ts . = ts-rumpuserxen-demo-xenstorels + host + $g
run-ts . = ts-guest-destroy-hard + host + $g
-repeat-ts 50 =.repeat \
+repeat-ts 150 =.repeat \
ts-rumpuserxen-demo-xenstorels + host + $g + \; \
ts-guest-destroy-hardhost $g +
}
--
2.1.4
___
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
> ---
> CC: Stefano Stabellini
> ---
> 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] [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
[Xen-devel] kernel BUG at drivers/xen/grant-table.c:923!
(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. > 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 : []lr : [] > 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] [] (gnttab_batch_copy) from > [] (xenvif_kthread_guest_rx+0x4d8/0xbc0) > Apr 14 19:01:22.640766 [ 1229.472045] [] (xenvif_kthread_guest_rx) > from [] (kthread+0xcc/0xe8) > Apr 14 19:01:22.648924 [ 1229.472093] [] (kthread) from > [] (ret_from_fork+0x14/0x3c) > Apr 14 19:01:22.656138 [ 1229.472132] Code: 0ae5 eaed e8bd80f8 > e7f001f2 (e7f001f2) > Apr 14 19:01:22.662285 [ 1229.472180] ---[ end trace 47a1647ddcea66dd ]--- ___ 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, 2015-04-17 at 10:35 +0100, Gareth Stockwell wrote: > On Wed, Apr 15, 2015 at 10:26:52, Ian Campbell wrote: > > > We would like to use memaccess to perform (1) - but rather than > > 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. Great, in which case this does seem to be a good approach. [...] > It seems to be the simplest approach, and based on some quick prototyping > appears to work - at least on ARM. Excellent! Ian ___ 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 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? David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 05/19] xen: arm: Add and use r/o+raz and w/o+wi helpers
On Fri, 2015-04-17 at 07:18 +0100, Julien Grall wrote: > >>> +/* Read only + read as zero */ > >> > >> This comment may confuse developer who wants to implement RO register > >> which another value than 0. > >> > >> I got confuse too. It would be nice to expand the comment for the RO case. > > > > I'm afraid I don't understand the confusion so I'm not sure how to > > clarify. What did you think this comment was saying? > > When I read the comment I though you were implemented two distinct part: > RO and RAZ. Well, in a sense I am ;-) > As the value return by RO may not always be 0 (we have a handful of > cases in traps.c), I didn't understand why you were implementing both > within the same helper. > > Although this helper choose to implement RO as RAZ. So I think it would > be good to mention it in order to avoid confusion later. Perhaps rather than: /* Read as zero + write ignore */ /* Write only + write ignore */ /* Read only + read as zero */ this would be clearer: /* Read as zero and write ignore */ /* Write only as write ignore */ /* Read only as read as zero */ ? IOW I suspect it is the + which has confused you, especially since it is used differently in the first vs the second two. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 7/8] raisin: Rework component specification
On Thu, 16 Apr 2015, George Dunlap wrote:
> Allow COMPONENTS to be specified in the config (or on the command-line)
>
> Now you can keep all components enabled in your config but build only
> one like so:
>
> COMPONENTS="xen" ./raise build
>
> Signed-off-by: George Dunlap
Good idea, I wanted to fix the way we disable components for a while now
> CC: Stefano Stabellini
> ---
> defconfig | 5 +
> lib/common-functions.sh | 49
> +++--
> 2 files changed, 40 insertions(+), 14 deletions(-)
>
> diff --git a/defconfig b/defconfig
> index 23c76eb..4ec8a0b 100644
> --- a/defconfig
> +++ b/defconfig
> @@ -1,5 +1,10 @@
> # Config variables for raisin
>
> +# Components
> +# All components: xen grub libvirt
> +# Core xen functionality: xen
> +DEFAULT_COMPONENTS="xen grub libvirt"
I would just call this COMPONENTS, also see below.
Also please update the other comment in this file on how to disable components.
> # Build config
> ## Make command to run
> MAKE="make -j2"
> diff --git a/lib/common-functions.sh b/lib/common-functions.sh
> index e66c6f4..42406e9 100644
> --- a/lib/common-functions.sh
> +++ b/lib/common-functions.sh
> @@ -31,13 +31,41 @@ function common_init() {
>
> get_distro
> get_arch
> +get_components
>
> -for f in `cat "$BASEDIR"/components/series`
> +echo "Distro: $DISTRO"
> +echo "Arch: $ARCH"
> +echo "Components: $COMPONENTS"
if [[ $VERBOSE -eq 1 ]]
then
echo stuff
fi
To make the code nicer to read, we could have a function called
verbose_echo:
function verbose_echo() {
if [[ $VERBOSE -eq 1 ]]
then
echo $*
fi
}
> +for f in $COMPONENTS
> do
> source "$BASEDIR"/components/"$f"
> done
> }
>
> +function get_components() {
> +if [[ -z "$COMPONENTS" ]]
> +then
> + COMPONENTS="$DEFAULT_COMPONENTS"
Stray tab.
I would call our internal components variable RAISIN_COMPONENTS and the
one in the config and exposed to users COMPONENTS.
> +fi
> +
> +if [[ -z "$COMPONENTS" ]]
> +then
> + local component
> + for component in `cat "$BASEDIR"/components/series`
> + do
> + local capital
> +capital=`echo $component | tr '[:lower:]' '[:upper:]'`
> +if eval [[ ! -z \$"$capital"_UPSTREAM_REVISION ]]
please rebase: _UPSTREAM is gone
> +then
> + COMPONENTS="$COMPONENTS $component"
> + echo "Found component $component"
verbose_echo
> +fi
> + done
> + export COMPONENTS
a bad mix of spaces and tabs in this function
> +fi
> +}
> +
> function get_distro() {
> if [[ -x "`which lsb_release 2>/dev/null`" ]]
> then
> @@ -222,20 +250,13 @@ function stop_initscripts() {
> }
>
> function for_each_component () {
> -for component in `cat "$BASEDIR"/components/series`
> +local component
> +
> +for component in $COMPONENTS
> do
> -capital=`echo $component | tr '[:lower:]' '[:upper:]'`
> -if [[ $VERBOSE -eq 1 ]]
> -then
> -echo -n "$capital"_REVISION =" "
> -eval echo \$"$capital"_REVISION
> -fi
> -if eval [[ ! -z \$"$capital"_REVISION ]]
> -then
> -[[ $VERBOSE -eq 0 ]] || echo calling "$component"_"$1"
> -"$component"_"$1"
> -[[ $VERBOSE -eq 0 ]] || echo "$component"_"$1" done
> -fi
> +[[ $VERBOSE -eq 0 ]] || echo calling "$component"_"$1"
> +"$component"_"$1"
> +[[ $VERBOSE -eq 0 ]] || echo "$component"_"$1" done
> done
> }
>
> --
> 1.9.1
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 7/8] raisin: Rework component specification
On Thu, 16 Apr 2015, George Dunlap wrote:
> Allow COMPONENTS to be specified in the config (or on the command-line)
>
> Now you can keep all components enabled in your config but build only
> one like so:
>
> COMPONENTS="xen" ./raise build
>
> Signed-off-by: George Dunlap
> ---
> CC: Stefano Stabellini
> ---
> defconfig | 5 +
> lib/common-functions.sh | 49
> +++--
> 2 files changed, 40 insertions(+), 14 deletions(-)
>
> diff --git a/defconfig b/defconfig
> index 23c76eb..4ec8a0b 100644
> --- a/defconfig
> +++ b/defconfig
> @@ -1,5 +1,10 @@
> # Config variables for raisin
>
> +# Components
> +# All components: xen grub libvirt
> +# Core xen functionality: xen
> +DEFAULT_COMPONENTS="xen grub libvirt"
> +
> # Build config
> ## Make command to run
> MAKE="make -j2"
> diff --git a/lib/common-functions.sh b/lib/common-functions.sh
> index e66c6f4..42406e9 100644
> --- a/lib/common-functions.sh
> +++ b/lib/common-functions.sh
> @@ -31,13 +31,41 @@ function common_init() {
>
> get_distro
> get_arch
> +get_components
>
> -for f in `cat "$BASEDIR"/components/series`
> +echo "Distro: $DISTRO"
> +echo "Arch: $ARCH"
> +echo "Components: $COMPONENTS"
> +
> +for f in $COMPONENTS
> do
> source "$BASEDIR"/components/"$f"
> done
> }
>
> +function get_components() {
> +if [[ -z "$COMPONENTS" ]]
> +then
> + COMPONENTS="$DEFAULT_COMPONENTS"
> +fi
> +
> +if [[ -z "$COMPONENTS" ]]
> +then
> + local component
> + for component in `cat "$BASEDIR"/components/series`
> + do
> + local capital
> +capital=`echo $component | tr '[:lower:]' '[:upper:]'`
> +if eval [[ ! -z \$"$capital"_UPSTREAM_REVISION ]]
> +then
> + COMPONENTS="$COMPONENTS $component"
> + echo "Found component $component"
> +fi
> + done
> + export COMPONENTS
> +fi
> +}
> +
> function get_distro() {
> if [[ -x "`which lsb_release 2>/dev/null`" ]]
> then
> @@ -222,20 +250,13 @@ function stop_initscripts() {
> }
>
> function for_each_component () {
> -for component in `cat "$BASEDIR"/components/series`
> +local component
One important thing here is that the order is important: xen is the
first item in the series file for a reason. I think we should use the
COMPONENTS variable to check for what components are enabled, but then
still use the series file for the ordering.
> +for component in $COMPONENTS
> do
> -capital=`echo $component | tr '[:lower:]' '[:upper:]'`
> -if [[ $VERBOSE -eq 1 ]]
> -then
> -echo -n "$capital"_REVISION =" "
> -eval echo \$"$capital"_REVISION
> -fi
> -if eval [[ ! -z \$"$capital"_REVISION ]]
> -then
> -[[ $VERBOSE -eq 0 ]] || echo calling "$component"_"$1"
> -"$component"_"$1"
> -[[ $VERBOSE -eq 0 ]] || echo "$component"_"$1" done
> -fi
> +[[ $VERBOSE -eq 0 ]] || echo calling "$component"_"$1"
> +"$component"_"$1"
> +[[ $VERBOSE -eq 0 ]] || echo "$component"_"$1" done
> done
> }
>
> --
> 1.9.1
>
___
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 : []lr :
> > []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 [ 1
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
Re: [Xen-devel] kernel BUG at drivers/xen/grant-table.c:923!
On Fri, 2015-04-17 at 11:45 +0100, Wei Liu wrote:
> 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.
Based on r0 I think -EFAULT.
Ian.
___
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
> ---
> 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
> ---
> 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"
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
> ---
> 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
> ---
> 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 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
[Xen-devel] crash in efi_runtime_call
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 (XEN)[] efi_runtime_call+0x7f0/0x890 (XEN)[] do_platform_op+0x679/0x1670 (XEN)[] 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 (XEN) (XEN) Manual reset required ('noreboot' specified) Xen 4.6.30679-3.testing_xen_unstable (XEN) Xen version 4.6.30679-3.testing_xen_unstable (abuild@) (gcc (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388]) debug=n Tue Apr 14 16:51:18 UTC 2015 (XEN) Latest ChangeSet: Tue Apr 14 16:51:18 2015 +0200 hg: 30679:cfe3e7adf842 (XEN) Console output is synchronous. (XEN) Bootloader: EFI (XEN) Command line: console=vga,com1 com1=115200 guest_loglvl=all loglvl=all noreboot sync_console (XEN) Video information: (XEN) VGA is text mode 128x40, font 8x16 (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 1 EDD information structures (XEN) EFI RAM map: (XEN) - 000a (usable) (XEN) 0010 - ac356000 (usable) (XEN) ac356000 - ac586000 (reserved) (XEN) ac586000 - aebec000 (usable) (XEN) aebec000 - af3ac000 (reserved) (XEN) af3ac000 - af4ac000 (ACPI NVS) (XEN) af4ac000 - afbff000 (ACPI data) (XEN) afbff000 - afc0 (usable) (XEN) fec1 - fec11000 (reserved) (XEN) fff4 - fff47000 (reserved) (XEN) 0001 - 00024000 (usable) (XEN) ACPI: RSDP AFBFE000, 0014 (r0 HPQOEM) (XEN) ACPI: RSDT AFBFE038, 0044 (r1 HPQOEM SLIC-MPC3 113) (XEN) ACPI: FACP AFBFD000, 0074 (r1 HPQOEM 307E3 HP 1) (XEN) ACPI Warning (tbfadt-0464): Optional field "Pm2ControlBlock" has zero address or length: /1 [20070126] (XEN) ACPI: DSDT AFBDD000, 1C447 (r1 HPQOEM SB700 1 INTL 20060912) (XEN) ACPI: FACS AF45B000, 0040 (XEN) ACPI: APIC AFBFC000, 0084 (r1 HPQOEM 307E1 HP 1) (XEN) ACPI: MCFG AFBFB000, 003C (r1 HPQOEM 307E1 HP 1) (XEN) ACPI: SLIC AFBFA000, 0176 (r1 HPQOEM SLIC-MPC1 HP 1) (XEN) ACPI: SSDT AFBDC000, 005F (r1 HPQOEM HPQNLP1 INTL 20060912) (XEN) ACPI: TCPA AFBDB000, 0032 (r2 HPQOEM 307E0 HP 1) (XEN) ACPI: HPET AFBDA000, 0038 (r1 HPQOEM 307E1 HP 1) (XEN) ACPI: SSDT AFBD9000, 07AD (r1 AMDPOWERNOW1 AMD 1) (XEN) System RAM: 7913MB (8103284kB) (XEN) No NUMA configuration found (XEN) Faking a node at -00024000 (XEN) Domain heap initialised (XEN) SMBIOS 2.6 present. (XEN) DMI 2.6 present. (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x408 (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:404,1:0], pm1x_evt[1:400,1:0] (XEN) ACPI: wakeup_vec[af45b00c], vec_size[20] (XEN) ACPI: Local APIC address 0xfee0 (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) (XEN) Processor #0 0:5 APIC version 16 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) (XEN) Processor #1 0:5 APIC version 16 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled) (XEN) Processor #2 0:5 APIC version 16 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x00] disabled) (XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1]) (XEN) ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 4, version 33, address 0xfec0, GSI 0-23 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) ACPI: IRQ9 used by override. (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) ACPI: HPET id: 0x43538301 base: 0xfed0 (XEN) ERST table was not found (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 4 CPUs (1 hotplug CPUs) (XEN) IRQ limits: 24 GSI, 568 MSI/MSI-X (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2094.790 MHz processor. (XEN) EFI memory map: (XEN) 0-00fff type=3 attr=000f (XEN) 01000-79fff type=7 attr=000f (XEN) 7a000-7cfff type=2 attr=000f (XEN) 7d000-7dfff type=4 attr=000f (XEN) 7e000-9 type=3 attr=000f (XEN) 00010-000bf type=7 attr=000f (XEN) 000c0-000ff type=3 attr=
[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 Ian Campbell Ian Jackson Jan Beulich Konrad Rzeszutek Wilk 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 pass test-amd64-amd64-xl-qemut-debianhvm-amd64pass test-amd64-i386-xl-qem
[Xen-devel] Question about DMA on 1:1 mapping dom0 of arm64
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 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. 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. If I set dom0_mem to a small value (e.g. 512M), which makes all physical memory of dom0 below 4G, everything goes fine. 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
[Xen-devel] [PATCH] libxl: use DEBUG log level instead of INFO
Make libxl less noisy when destroying a domain. Signed-off-by: Wei Liu Cc: Ian Campbell Cc: Ian Jackson --- tools/libxl/libxl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 511eef1..c106756 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -1698,7 +1698,7 @@ static void devices_destroy_cb(libxl__egc *egc, _exit(-1); } } -LOG(INFO, "forked pid %ld for destroy of domain %d", (long)rc, domid); +LOG(DEBUG, "forked pid %ld for destroy of domain %d", (long)rc, domid); return; -- 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 > > > > Other than the possible typoes above: > > > > Reviewed-by: Julien Grall > > Acked-by: Ian Campbell > > 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] Commit 1aeb1156fa43fe2cd2b5003995b20466cd19a622: "x86 don't change affinity with interrupt unmasked", APCI errors and assorted pci trouble
>>> On 14.04.15 at 14:46, wrote:
> I just had a hunch .. could it be related to the kernel apci/irq refactoring
> series of Jiang Liu, that already caused a lot of trouble in 3.17, 3.18 and
> 3.19
> with Xen. And yes that seems to be the case:
>
> On Xen without "x86 don't change affinity with interrupt unmasked"
> - 3.16 && 3.19 && 4.0 all work fine
>
> On Xen with "x86 don't change affinity with interrupt unmasked"
> - 3.16 (which is before that kernel refactoring series) works fine.
> - 3.19, 4.0 both give the dom0 kernel hangs and the :
> (XEN) [2015-03-26 20:35:42.205] APIC error on CPU0: 00(40)
> (XEN) [2015-03-26 20:35:42.372] APIC error on CPU0: 40(40)
>
> (haven't tested 3.17 and 3.18 because these have asorted problems due that
> series that weren't fixed in time before stable updates ended.)
>
> So it seems Jan's patch seems to interfere with that patch series.
That's rather odd a finding - the patch in question in fact uncovered
a bug introduced in 2ca9fbd739 ("AMD IOMMU: allocate IRTE entries
instead of using a static mapping") in that IO-APIC RTE reads would
unconditionally translate the data (i.e. regardless of whether the
entry was already in translated format). The patch below fixes this
for me - can you please give this a try too?
Thanks, Jan
--- unstable.orig/xen/drivers/passthrough/amd/iommu_intr.c
+++ unstable/xen/drivers/passthrough/amd/iommu_intr.c
@@ -365,15 +365,17 @@ unsigned int amd_iommu_read_ioapic_from_
unsigned int apic, unsigned int reg)
{
unsigned int val = __io_apic_read(apic, reg);
+unsigned int pin = (reg - 0x10) / 2;
+unsigned int offset = ioapic_sbdf[IO_APIC_ID(apic)].pin_2_idx[pin];
-if ( !(reg & 1) )
+if ( !(reg & 1) && offset < INTREMAP_ENTRIES )
{
-unsigned int offset = val & (INTREMAP_ENTRIES - 1);
u16 bdf = ioapic_sbdf[IO_APIC_ID(apic)].bdf;
u16 seg = ioapic_sbdf[IO_APIC_ID(apic)].seg;
u16 req_id = get_intremap_requestor_id(seg, bdf);
const u32 *entry = get_intremap_entry(seg, req_id, offset);
+ASSERT(offset == (val & (INTREMAP_ENTRIES - 1)));
val &= ~(INTREMAP_ENTRIES - 1);
val |= get_field_from_reg_u32(*entry,
INT_REMAP_ENTRY_INTTYPE_MASK,
___
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
> > ---
> > 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] crash in efi_runtime_call
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 > (XEN)[] efi_runtime_call+0x7f0/0x890 > (XEN)[] do_platform_op+0x679/0x1670 > (XEN)[] 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. > (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-cacheability.patch is the XenServer fix. ~Andrew ___ 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 > > --- > > 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, > > + *DBGBXVR > > + *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] [PATCH 18/19] xen: arm: Annotate registers trapped when CNTHCTL_EL2.EL1PCEN == 0
On Mon, 2015-04-06 at 15:58 +0200, Julien Grall wrote:
> Hi Ian,
>
> On 31/03/2015 12:07, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell
> > ---
> > xen/arch/arm/traps.c | 20 ++--
> > 1 file changed, 18 insertions(+), 2 deletions(-)
> >
> > diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> > index 1c9cf21..cc5b8dd 100644
> > --- a/xen/arch/arm/traps.c
> > +++ b/xen/arch/arm/traps.c
> > @@ -1642,6 +1642,12 @@ static void do_cp15_32(struct cpu_user_regs *regs,
> >
> > switch ( hsr.bits & HSR_CP32_REGS_MASK )
> > {
> > +/*
> > + * !CNTHCTL_EL2.EL1PCEN / !CNTHCTL.PL1PCEN
>
> I will be picky. The listing here is ARMv8 (AArch64) / ARMv7, but below
> it's ARMv7 / ARMv8.
I'm not spotting the "below", which one did you mean?
I was trying to use the AArch64 names only when they were reasonably
similar (i.e. just differing in H prefix vs _EL2 suffix or otherwise
fairly obvious) and only use both names if there was some potentially
confusing difference in the naming.
>
> > + *
> > + * ARMv7 (DDI 0406C.b): B4.1.22
> > + * ARMv8 (DDI 0487A.d): D1-1510 Table D1-60
> > + */
> > case HSR_CPREG32(CNTP_CTL):
> > case HSR_CPREG32(CNTP_TVAL):
> > if ( !vtimer_emulate(regs, hsr) )
> > @@ -1757,6 +1763,12 @@ static void do_cp15_64(struct cpu_user_regs *regs,
> >
> > switch ( hsr.bits & HSR_CP64_REGS_MASK )
> > {
> > +/*
> > + * !CNTHCTL_EL2.EL1PCEN / !CNTHCTL.PL1PCEN
> > + *
> > + * ARMv7 (DDI 0406C.b): B4.1.22
> > + * ARMv8 (DDI 0487A.d): D1-1510 Table D1-60
> > + */
> > case HSR_CPREG64(CNTP_CVAL):
> > if ( !vtimer_emulate(regs, hsr) )
> > return inject_undef_exception(regs, hsr);
> > @@ -2120,14 +2132,18 @@ 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: */
> > -
>
> This comment should have been dropped in patch #14.
Moved.
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 Thu, 2015-04-16 at 16:28 +0100, Jan Beulich wrote: > >>> On 10.04.15 at 16:19, 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 13:32, Ian Campbell wrote: > On Thu, 2015-04-16 at 16:28 +0100, Jan Beulich wrote: > On 10.04.15 at 16:19, 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, 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, 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 >> (XEN)[] efi_runtime_call+0x7f0/0x890 >> (XEN)[] do_platform_op+0x679/0x1670 >> (XEN)[] 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, 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 >>> (XEN)[] efi_runtime_call+0x7f0/0x890 >>> (XEN)[] do_platform_op+0x679/0x1670 >>> (XEN)[] 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 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, 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 to the patch below. commit b08cf3fa4791d7ff0d01fb932192e02078ce670a Author: David Vrabel 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 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
---
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
[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
---
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
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 Thanks, Ian! David ___ 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, 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 > >>> (XEN)[] efi_runtime_call+0x7f0/0x890 > >>> (XEN)[] do_platform_op+0x679/0x1670 > >>> (XEN)[] 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 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 --- 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
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
> > ---
> > 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
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, 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 > (XEN)[] efi_runtime_call+0x7f0/0x890 > (XEN)[] do_platform_op+0x679/0x1670 > (XEN)[] 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, 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 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
Reviewed-by: Julien Grall
---
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 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
---
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
[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
---
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 HSR_SYSREG_PMCR_EL0:
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, wrote:
> On Mon, Apr 13, 2015 at 10:05:14AM +0100, Jan Beulich wrote:
>> >>> On 10.04.15 at 22:02, 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
---
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
[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 --- 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
---
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 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
Reviewed-by: Julien Grall
---
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
Reviewed-by: Julien Grall
---
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);
inject_iabt_exception(regs, addr, hsr.len);
}
static void d
[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
Reviewed-by: Julien Grall
---
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 00/19] xen: arm: cleanup traps.c
While working on reenabling 32-bit user space on arm63 I concluded that
the trap handling in traps.c had grown into a twisty confusing mess.
Lets try and sort that out.
This series contains two halves (after a couple of preparatory
cleanups).
First clean up the goto maze which we've found ourselves in, by
providing a selection of handle_* helpers e.g. for raz/ro etc and by
calling those and the existing inject_* helpers directly instead of
trying to have only one call to each of the latter by using goto. The
handle_* helpers can also deal with the minimum allowable exception
level, which simplifies things further.
To keep things simpler I've used "return handle_..." when the caller and
callee both return void, since that avoids the need for 3 more lines (2
braces and the return), I think this improves clarity.
Second go through init_traps and for each bit there consolidate the
handling for each type of trap (e.g. do_cp15_32, do_cp15_64, do_sysreg
etc) such that all the registers whose traps are associated with that
bit are kept together beneath a comment which documents why those bits
are trapped, references the appropriate section of the ARMv7 and ARMv8
ARM (the v8 one in particular has a series of very useful tables per
bit) and notes which registers are not explicitly handled (and therefore
take the default case).
For traps which have no explicit handling (i.e. those which trap
implementation defined registers) and which always hit the default case
add the comment above that instead.
Do the same for the GICv3 ICC traps and timer traps.
There is probably scope for doing more, i.e. refactoring related
functionality into subsystem helpers (like we do for vtimer) and even
moving into separate files, but I think this is a good start.
This is a lot of patches, sorry, because I wanted to mostly go through
the trap bits one at a time per patch to keep each one manageable,
although I did end up compressing some of the more obvious ones.
Since last time I've addressed all (I hope!) of Julien's comments.
(R)eviewed
R xen: arm: constify union hsr and struct hsr_* where possible.
R xen: arm: Fix handling of ICC_{SGI1R,SGI0R,ASGI1R}_EL1
R xen: arm: call inject_undef_exception directly
M xen: arm: provide and use a handle_raz_wi helper
M xen: arm: Add and use r/o+raz and w/o+wi helpers
M xen: arm: add minimum exception level argument to trap handler helpers
M xen: arm: Annotate trap handler for HSR_EL2.{TWI,TWE,TSC}
M xen: arm: implement handling of ACTLR_EL1 trap
RM xen: arm: Annotate registers trapped by HCR_EL1.TIDCP
M xen: arm: implement handling of registers trapped by CPTR_EL2.TTA
M xen: arm: Annotate handlers for CPTR_EL2.Tx
M xen: arm: Annotate the handlers for HSTR_EL2.T15
M xen: arm: Annotate registers trapped by MDCR_EL2.TDRA
M xen: arm: Annotate registers trapped by MDCR_EL2.TDOSA
xen: arm: Annotate registers trapped by MDCR_EL2.TDA
xen: arm: Annotate registers trapped by MDCR_EL2.TPM and TPMCR
R xen: arm: Remove CNTPCT_EL0 trap handling.
xen: arm: Annotate registers trapped when CNTHCTL_EL2.EL1PCEN == 0
R xen: arm: Annotate source of ICC SGI register trapping
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 03/19] xen: arm: call inject_undef_exception directly
Reducing the amount of goto maze considerably.
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
---
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 do_cp14_32(struct cpu_user_regs *regs,
[Xen-devel] [PATCH v2 05/19] xen: arm: Add and use r/o+raz and w/o+wi helpers
Signed-off-by: Ian Campbell
---
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
---
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
---
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);
-return handle_wo_
[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
Reviewed-by: Julien Grall
---
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 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
---
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) HSR_SYSREG(2,0,c0,c##n,4)
[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
---
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, ®s->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 --- 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: + *PMEVCNTR + *PMEVTYPER + *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: + *PMEVCNTR_EL0 + *PMEVTYPER_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 --- 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, + *DBGBXVR + *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
