Re: [Xen-devel] [PATCHv3 5/6] evtchn: remove the locking when unmasking an event channel
On 18/06/15 13:08, Jan Beulich wrote: On 18.06.15 at 13:36, david.vra...@citrix.com wrote: On 18/06/15 12:30, Jan Beulich wrote: On 17.06.15 at 14:03, david.vra...@citrix.com wrote: --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -978,8 +978,6 @@ int evtchn_unmask(unsigned int port) struct domain *d = current-domain; struct evtchn *evtchn; -ASSERT(spin_is_locked(d-event_lock)); - if ( unlikely(!port_is_valid(d, port)) ) return -EINVAL; @@ -1146,9 +1144,7 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) struct evtchn_unmask unmask; if ( copy_from_guest(unmask, arg, 1) != 0 ) return -EFAULT; -spin_lock(current-domain-event_lock); rc = evtchn_unmask(unmask.port); -spin_unlock(current-domain-event_lock); And, looking particularly at evtchn_fifo_unmask() (and its descendant evtchn_fifo_set_pending()), you get away without acquiring the port lock in or around evtchn_port_unmask()? If indeed so, this one would again be independent on 1, 2, and 4, i.e. could go in together with 3. Yes. This is only dependent on #3 (simplify port_is_valid()). I'm still not convinced that not taking the port lock is correct: It is my understanding that e.g. the (last_vcpu_id,last_priority) pair needs to be updated atomically. Yet nothing prevents the (notify_vcpu_id,priority) pair now from getting updated in the middle of it being snapshot in evtchn_fifo_set_pending(). Are you saying this is no problem? This is serialized by the q lock. evtchn_fifo_set_pending() has never been serialized by the event lock because concurrent evtchn_send() calls with two interdomain channels from different domains would have taken different event locks. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API
On 06/17/2015 12:24 PM, Ian Campbell wrote: On Tue, 2015-06-16 at 12:44 +0100, Ian Jackson wrote: George Dunlap writes (Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API): On Tue, Jun 16, 2015 at 12:19 PM, Juergen Gross jgr...@suse.com wrote: I'm pretty sure this is just a matter of timing during boot: the busses are all (or at least some of them) queried at the same time and the first answering gets number 1, the next 2, and so on. And timing seems to be different enough to result in unstable bus numbers. Right -- I meant stable in topology within one boot, but at least two of you have now understood me to mean across reboots by default, so that's obviously a detail that needs to be specified. :-) I think stable in topology within one boot is nearly vacuous (or are we expecting buses or devices to spontaneously renumber themselves for no reason) and also nearly useless. We definitely need _some_ way for a user to identify a specific device uniquely in a way that is reliable from one boot to the next. vid:pid is one way to do this, but not always sufficient. We should perhaps separate out the end user from the libxl user (i.e. the toolstack application) in our deliberations here. We have the option of settling on a single way of describing a device to libxl in the libxl API but allowing the toolstack to choose to present the user with multiple different ways to specify things by providing a suitable set of helper functions (in either libxlu or libxl proper) from a variety of schemes to the one true way of describing a device. That sounds better to me than having the libxl API consist of the union of all potentially useful ways to refer to a device. I'm not sure whether that also gives us the freedom to use something which is only stable for a given boot at the libxl API layer though. [snip] As a slight aside to this, can't libxl use libusb for a lot of this stuff and therefore avoid being Linux specific? http://libusb.info/ claims to support Linux, OS X, Windows, Windows CE, Android, OpenBSD/NetBSD, Haiku.. Interestingly FreeBSD is missing there but I don't think that need to be a blocker. I don't see a problem with adding libusb to our set of dependencies, and it's certainly got to be better than (re)implementing a bunch of sysfs stuff (which I presume is what libusb does under the hood anyway). OK, so we have three interfaces: * User - toolstack * toolstack - libxl * libxl - underlying functionality (Linux pvusbback and qemu, at the moment) And we're also now considering whether to do a minimal interface in libxl (i.e., only accept one kind of specification and make the toolstack do the conversion from a more useful spec) or do a rich interface (i.e., accept many different kinds of specification, allowing the toolstack to just pass things through). qemu already uses libusb, and so can already do almost everything that libxl could use libusb to accomplish. The only things it doesn't do that we've talked about doing are the bus-ports specification, and the vendorid:deviceid:serialno specification; both of which would be trivial (and probably useful) to add. So for all the things libusb can be used to convert between, we don't actually need to do any conversion when speaking to qemu (unless we want to be backwards compatible with older versions). The udev id_path specification isn't something that libusb can handle; we'd have to mess around with sysfs and/or udev-created device nodes / symbolic links into sysfs anyway. So for the qemu side of things, libusb is mostly useless. We can't get around using sysfs to talk to pvusbback -- that's how it works. At the moment, the pvusbback interface requires sysfs strings, which happen to be described in the bus-ports:interface format. So the main reason we're messing around with sysfs at the moment is to convert other specifications into the sysfs strings suitable for using with pvusb. To convert into a sysfs string ourselves: * readdir on /sys/bus/usb/devices * for each entry, look inside to see if it matches the specification (i.e., bus==busnum, addr==devnum, c) * take the directory name of the entry that matches * look inside that directory for all the interfaces for that device (so we can assign each one to pvusbback). * Write the strings you read from sysfs into the appropriate bind nodes in pvusbback To convert bus.addr into a sysfs string with libusb: * libusb_get_device_list [1] * for each entry, call libusb_get_device_descriptor and see if it matches the specification (i.e., bus==bus, addr==addr, c) * Call libusb_get_ports to get an array of the port numbers * Construct a sysfs string from the bus number and the array of port numbers (i.e., %d-%d[.%d.%d]) * Get information about all the interfaces, and construct sysfs strings from those as well * Write the constructed strings into the pciback sysfs nodes A couple of points: 1. The second is certainly not simpler than the first 2. The only
[Xen-devel] [PATCH] xen/HVM: atomically access pointers in bufioreq handling
The number of slots per page being 511 (i.e. not a power of two) means
that the (32-bit) read and write indexes going beyond 2^32 will likely
disturb operation. The hypervisor side gets I/O req server creation
extended so we can indicate that we're using suitable atomic accesses
where needed (not all accesses to the two pointers really need to be
atomic), allowing it to atomically canonicalize both pointers when both
have gone through at least one cycle.
The Xen side counterpart (which is not a functional prereq to this
change, albeit a build one) can be found at e.g.
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg02996.html
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -981,19 +981,30 @@ static void handle_ioreq(XenIOState *sta
static int handle_buffered_iopage(XenIOState *state)
{
+buffered_iopage_t *buf_page = state-buffered_io_page;
buf_ioreq_t *buf_req = NULL;
ioreq_t req;
int qw;
-if (!state-buffered_io_page) {
+if (!buf_page) {
return 0;
}
memset(req, 0x00, sizeof(req));
-while (state-buffered_io_page-read_pointer !=
state-buffered_io_page-write_pointer) {
-buf_req = state-buffered_io_page-buf_ioreq[
-state-buffered_io_page-read_pointer % IOREQ_BUFFER_SLOT_NUM];
+for (;;) {
+uint32_t rdptr = buf_page-read_pointer, wrptr;
+
+xen_rmb();
+wrptr = buf_page-write_pointer;
+xen_rmb();
+if (rdptr != buf_page-read_pointer) {
+continue;
+}
+if (rdptr == wrptr) {
+break;
+}
+buf_req = buf_page-buf_ioreq[rdptr % IOREQ_BUFFER_SLOT_NUM];
req.size = 1UL buf_req-size;
req.count = 1;
req.addr = buf_req-addr;
@@ -1005,15 +1016,14 @@ static int handle_buffered_iopage(XenIOS
req.data_is_ptr = 0;
qw = (req.size == 8);
if (qw) {
-buf_req = state-buffered_io_page-buf_ioreq[
-(state-buffered_io_page-read_pointer + 1) %
IOREQ_BUFFER_SLOT_NUM];
+buf_req = buf_page-buf_ioreq[(rdptr + 1) %
+ IOREQ_BUFFER_SLOT_NUM];
req.data |= ((uint64_t)buf_req-data) 32;
}
handle_ioreq(state, req);
-xen_mb();
-state-buffered_io_page-read_pointer += qw ? 2 : 1;
+atomic_add(buf_page-read_pointer, qw + 1);
}
return req.count;
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -370,7 +370,8 @@ static inline void xen_unmap_pcidev(XenX
static inline int xen_create_ioreq_server(XenXC xc, domid_t dom,
ioservid_t *ioservid)
{
-int rc = xc_hvm_create_ioreq_server(xc, dom, 1, ioservid);
+int rc = xc_hvm_create_ioreq_server(xc, dom, HVM_IOREQSRV_BUFIOREQ_ATOMIC,
+ioservid);
if (rc == 0) {
trace_xen_ioreq_server_create(*ioservid);
xen/HVM: atomically access pointers in bufioreq handling
The number of slots per page being 511 (i.e. not a power of two) means
that the (32-bit) read and write indexes going beyond 2^32 will likely
disturb operation. The hypervisor side gets I/O req server creation
extended so we can indicate that we're using suitable atomic accesses
where needed (not all accesses to the two pointers really need to be
atomic), allowing it to atomically canonicalize both pointers when both
have gone through at least one cycle.
The Xen side counterpart (which is not a functional prereq to this
change, albeit a build one) can be found at e.g.
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg02996.html
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -981,19 +981,30 @@ static void handle_ioreq(XenIOState *sta
static int handle_buffered_iopage(XenIOState *state)
{
+buffered_iopage_t *buf_page = state-buffered_io_page;
buf_ioreq_t *buf_req = NULL;
ioreq_t req;
int qw;
-if (!state-buffered_io_page) {
+if (!buf_page) {
return 0;
}
memset(req, 0x00, sizeof(req));
-while (state-buffered_io_page-read_pointer !=
state-buffered_io_page-write_pointer) {
-buf_req = state-buffered_io_page-buf_ioreq[
-state-buffered_io_page-read_pointer % IOREQ_BUFFER_SLOT_NUM];
+for (;;) {
+uint32_t rdptr = buf_page-read_pointer, wrptr;
+
+xen_rmb();
+wrptr = buf_page-write_pointer;
+xen_rmb();
+if (rdptr != buf_page-read_pointer) {
+continue;
+}
+if (rdptr == wrptr) {
+break;
+}
+buf_req = buf_page-buf_ioreq[rdptr % IOREQ_BUFFER_SLOT_NUM];
req.size = 1UL buf_req-size;
req.count = 1;
req.addr = buf_req-addr;
@@ -1005,15 +1016,14 @@ static int handle_buffered_iopage(XenIOS
req.data_is_ptr = 0;
qw = (req.size == 8);
if (qw) {
-
Re: [Xen-devel] [PATCHv3 6/6] evtchn: pad struct evtchn to 64 bytes
On 17.06.15 at 14:03, david.vra...@citrix.com wrote: The number of struct evtchn in a page must be a power of two. Under some workloads performance is improved slightly by padding struct evtchn to 64 bytes (a typical cache line size), thus putting the fewer per-channel locks into each cache line. This does not decrease the number of struct evtchn's per-page. Signed-off-by: David Vrabel david.vra...@citrix.com Acked-by: Jan Beulich jbeul...@suse.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] stable trees (was: [xen-4.2-testing test] 58584: regressions)
On 17.06.15 at 12:26, ian.jack...@eu.citrix.com wrote: Jan Beulich writes (stable trees (was: [xen-4.2-testing test] 58584: regressions)): Which leaves several options: - the problem was always there, but hidden by some factor in the old osstest instance, I think this is most likely. The old system had much older hosts. I think this is a race that we now happen to lose most of the time. For verification purposes, would it be possible to set up a couple of flights on the old instance for one of the stable trees? One aspect making me indeed consider the build (or less likely runtime) aspect is that we're seeing the frequent migration failures in the stable trees only - other than unstable they're all getting built with debug=n. Races frequently come and go with that kind of change. True. Question then still is who will try to look into the issue (as right now it is quite harmful to the progress the stable trees can make towards getting pushed). Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv3 5/6] evtchn: remove the locking when unmasking an event channel
On 18/06/15 12:30, Jan Beulich wrote: On 17.06.15 at 14:03, david.vra...@citrix.com wrote: --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -978,8 +978,6 @@ int evtchn_unmask(unsigned int port) struct domain *d = current-domain; struct evtchn *evtchn; -ASSERT(spin_is_locked(d-event_lock)); - if ( unlikely(!port_is_valid(d, port)) ) return -EINVAL; @@ -1146,9 +1144,7 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) struct evtchn_unmask unmask; if ( copy_from_guest(unmask, arg, 1) != 0 ) return -EFAULT; -spin_lock(current-domain-event_lock); rc = evtchn_unmask(unmask.port); -spin_unlock(current-domain-event_lock); And, looking particularly at evtchn_fifo_unmask() (and its descendant evtchn_fifo_set_pending()), you get away without acquiring the port lock in or around evtchn_port_unmask()? If indeed so, this one would again be independent on 1, 2, and 4, i.e. could go in together with 3. Yes. This is only dependent on #3 (simplify port_is_valid()). David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 58714: tolerable FAIL - PUSHED
flight 58714 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58714/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 58681
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 58681
version targeted for testing:
ovmf 35bc88dddc79103e6ab8d87932b4e877582a2bc5
baseline version:
ovmf cc63add853d4b5c16b74b4d4ceb59c015a2adcc4
People who touched revisions under test:
Wu Jiaxin jiaxin...@intel.com
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=35bc88dddc79103e6ab8d87932b4e877582a2bc5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
35bc88dddc79103e6ab8d87932b4e877582a2bc5
+ branch=ovmf
+ revision=35bc88dddc79103e6ab8d87932b4e877582a2bc5
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{OsstestUpstream} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print
Re: [Xen-devel] [PATCHv3 5/6] evtchn: remove the locking when unmasking an event channel
On 17.06.15 at 14:03, david.vra...@citrix.com wrote: --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -978,8 +978,6 @@ int evtchn_unmask(unsigned int port) struct domain *d = current-domain; struct evtchn *evtchn; -ASSERT(spin_is_locked(d-event_lock)); - if ( unlikely(!port_is_valid(d, port)) ) return -EINVAL; @@ -1146,9 +1144,7 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) struct evtchn_unmask unmask; if ( copy_from_guest(unmask, arg, 1) != 0 ) return -EFAULT; -spin_lock(current-domain-event_lock); rc = evtchn_unmask(unmask.port); -spin_unlock(current-domain-event_lock); And, looking particularly at evtchn_fifo_unmask() (and its descendant evtchn_fifo_set_pending()), you get away without acquiring the port lock in or around evtchn_port_unmask()? If indeed so, this one would again be independent on 1, 2, and 4, i.e. could go in together with 3. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] FW: VT-d async invalidation for Device-TLB.
On June 18, 2015 5:19 PM, jbeul...@suse.com wrote: On 18.06.15 at 10:09, quan...@intel.com wrote: On 16.06.15 09:59, mailto:jbeul...@suse.com wrote: On 16.06.15 at 09:59, yang.z.zh...@intel.com wrote: Jan Beulich wrote on 2015-06-16: On 16.06.15 at 05:07, yang.z.zh...@intel.com wrote: Jan Beulich wrote on 2015-06-15: On 13.06.15 at 16:44, quan...@intel.com wrote: On 12.06.15 at 14:47, jbeul...@suse.com wrote: On 12.06.15 at 04:40, quan...@intel.com wrote: which one? 1.4us for sync case and 4.3us for async case? The difference between the two (i.e. why is the async variant three times as long). I have tested iotlb async/sync invalidation to get another data. Also I disabled 'P State' / 'C State' in bios. For async invalidation: about 2.67 us. For sync invalidation: about 1.28 us. I also tested VCPU_KICK_SOFTIRQ irq cost. When hypervisor calls cpu_raise_softirq(..VCPU_KICK_SOFTIRQ) to raise an VCPU_KICK_SOFTIRQ irq, and vcpu_kick_softirq() is the VCPU_KICK_SOFTIRQ interrupt handler. I got the cost between cpu_raise_softirq(..VCPU_KICK_SOFTIRQ) and vcpu_kick_softirq(). It is about 1.21 us. I think the difference is interrupt cost between async invalidation and sync invalidation. Which contradicts what I think Yang said in an earlier reply. Talked with Yang who is confused at what he said. :( Could you share more? 2.67us is almost ideal for async invalidation cost. There are 4 reasons to cost much more time: 1. If enable 'P State' / 'C State' in bios. 2. Hypervisor is running in No-root mode. 3. The time doesn't include the cost of handling of interrupt. I just record it at the entry of interrupt handler. 4. More pass-through VMs runs. So there are maybe some performance issues when we replace the current spinning for the non-ATS case. We can start from ATS case firstly, And apply it to non-ATS case later if the async approach performance is acceptable. Jan, Do you agree with this? No, I'm still not convinced that leaving the non-ATS case alone initially is the right approach. But maybe I'm the only one? I hope for someone else to give some comments. I tried to replace the current spinning for the non-ATS case, but Xen crashed. Based on dmesg, it seems that VT-d is enabled before enabling IO-APIC IRQs. I can send out two serious of patch: 1st: VT-d async invalidation for ATS case. 2nd: VT-d async invalidation for non-ATS case. I think the 1st serious of patch is high priority, as it is not correct to spin 1 second for ATS case. I can implement these source code and send out ASAP. 2nd serious of patch is low priority, as it's optimization. Also I can provide a serious of patch to fix it later. Agree? Quan 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] [qemu-mainline bisection] complete build-amd64
osstest service user writes ([qemu-mainline bisection] complete build-amd64): branch xen-unstable xen branch xen-unstable job build-amd64 test xen-build Tree: qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git Tree: qemuu git://git.qemu.org/qemu.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** ... *** Found and reproduced problem changeset *** This report has fingered _two_ commits. One is a merge which brings in the other. None of this is actually incorrect, but this is a rather odd way for the bisector to operate. I will investigate. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.2-testing test] 58711: FAIL
flight 58711 xen-4.2-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/58711/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 3 host-install(3) broken in 58584 REGR. vs. 58411 Tests which are failing intermittently (not blocking): test-i386-i386-libvirt3 host-install(3) broken in 58584 pass in 58711 test-amd64-i386-pair 4 host-install/dst_host(4) broken in 58584 pass in 58711 test-amd64-i386-qemuu-freebsd10-amd64 3 host-install(3) broken in 58584 pass in 58711 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 58584 pass in 58711 test-amd64-i386-xl-win7-amd64 3 host-install(3) broken in 58584 pass in 58711 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 58584 pass in 58711 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 58584 pass in 58711 test-i386-i386-xl-qemut-winxpsp3 3 host-install(3) broken in 58616 pass in 58711 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail in 58584 pass in 58711 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail in 58584 pass in 58711 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 58631 pass in 58616 test-i386-i386-libvirt9 debian-install fail in 58631 pass in 58711 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-localmigrate fail in 58678 pass in 58711 test-amd64-amd64-xl-win7-amd64 16 guest-stopfail pass in 58584 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail pass in 58631 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail pass in 58678 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 58411 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 58411 test-amd64-i386-xl-win7-amd64 16 guest-stop fail like 58411 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1)blocked in 58584 n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-i386-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail in 58616 never pass test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass build-amd64-rumpuserxen 5 rumpuserxen-buildfail never pass build-i386-rumpuserxen5 rumpuserxen-buildfail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-i386-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 20 leak-check/check fail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass version targeted for testing: xen 97134c441d6d81ba0d7cdcfdc4d8315115b99dce baseline version: xen 21a8344ca38a2797a13b4bf57031b6f49ae12ccb People who touched revisions under test: Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com Stefano Stabellini stefano.stabell...@eu.citrix.com jobs: build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xlpass 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-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
Re: [Xen-devel] [PATCH] x86/HVM: EOI handling function adjustments
On 18/06/15 13:51, Jan Beulich wrote:
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -421,18 +421,17 @@ void vlapic_EOI_set(struct vlapic *vlapi
if ( hvm_funcs.handle_eoi )
hvm_funcs.handle_eoi(vector);
-if ( vlapic_test_and_clear_vector(vector, vlapic-regs-data[APIC_TMR])
)
-vioapic_update_EOI(vlapic_domain(vlapic), vector);
-
-hvm_dpci_msi_eoi(current-domain, vector);
+vlapic_handle_EOI(vlapic, vector);
}
-void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
+void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)
{
+struct domain *d = vlapic_domain(vlapic);
+
if ( vlapic_test_and_clear_vector(vector, vlapic-regs-data[APIC_TMR])
)
-vioapic_update_EOI(vlapic_domain(vlapic), vector);
+vioapic_update_EOI(d, vector);
-hvm_dpci_msi_eoi(current-domain, vector);
+hvm_dpci_msi_eoi(d, vector);
It might be worth retaining an ASSERT(current-domain == d) at this point.
Otherwise, Reviewed-by: Andrew Cooper andrew.coop...@citrix.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv3 4/6] evtchn: use a per-event channel lock for sending events
On 18/06/15 12:20, Jan Beulich wrote: On 17.06.15 at 14:03, david.vra...@citrix.com wrote: When sending an event, use a new per-event channel lock to safely validate the event channel state. This new lock must be held when changing event channel state. Note that the event channel lock must also be held when changing state from ECS_FREE or it will race with a concurrent get_free_port() call. To avoid having to take the remote event channel locks when sending to an interdomain event channel, the local and remote channel locks are both held when binding or closing an interdomain event channel. This significantly increases the number of events that can be sent from multiple VCPUs. But struct evtchn increases in size, reducing the number that fit into a single page to 64 (instead of 128). Signed-off-by: David Vrabel david.vra...@citrix.com Reviewed-by: Jan Beulich jbeul...@suse.com But iiuc this functionally depends on the earlier patches, and hence can't go in without the issues there addressed. Yes, this depends on #1, #2 and #3. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] x86/HVM: avoid pointer wraparound in bufioreq handling
On 18/06/15 14:14, Jan Beulich wrote: The number of slots per page being 511 (i.e. not a power of two) means that the (32-bit) read and write indexes going beyond 2^32 will likely disturb operation. Extend I/O req server creation so the caller can indicate that it is using suitable atomic accesses where needed (not all accesses to the two pointers really need to be atomic), allowing the hypervisor to atomically canonicalize both pointers when both have gone through at least one cycle. Signed-off-by: Jan Beulich jbeul...@suse.com Acked-by: Ian Campbell ian.campb...@citrix.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 58713: tolerable FAIL - PUSHED
flight 58713 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58713/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt-xsm 11 guest-start fail like 58643
test-amd64-i386-libvirt 11 guest-start fail like 58643
test-armhf-armhf-libvirt 11 guest-start fail like 58643
test-amd64-amd64-libvirt 11 guest-start fail like 58643
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass
version targeted for testing:
libvirt 307081796ee07d5f47e1fef66766de82d5fce642
baseline version:
libvirt c132b1b6e622b685b52e3150bdd0688968d1e1e5
People who touched revisions under test:
Laine Stump la...@laine.org
Maxim Nestratov mnestra...@parallels.com
Michal Privoznik mpriv...@redhat.com
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-armhf-pvopspass
build-i386-pvops pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm fail
test-amd64-amd64-libvirt fail
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt fail
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=libvirt
+ revision=307081796ee07d5f47e1fef66766de82d5fce642
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push libvirt
307081796ee07d5f47e1fef66766de82d5fce642
+ branch=libvirt
+ revision=307081796ee07d5f47e1fef66766de82d5fce642
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=libvirt
+ xenbranch=xen-unstable
+ '[' xlibvirt = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{OsstestUpstream} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
Re: [Xen-devel] [OSSTEST PATCH 00/25] Reporting improvements
Ian Campbell writes (Re: [OSSTEST PATCH 00/25] Reporting improvements): On Wed, 2015-06-17 at 17:44 +0100, Ian Jackson wrote: Most of the early part of this series is straightforward (and acked) and could go in whenever. Agreed. Do you happen to have a convenient directory with the new output? (I'm happy to just wait for it to happen too). I have mostly run it on my workstation on the Cambridge instance. Here is an example that I have lying about, copied to a public webserver: http://www.chiark.greenend.org.uk/~ijackson/quicksand/2015/grain-weevil.html Patches 15-24 introduce sg-report-host-history. It's probably easiest to simply review the final version of the script, which can be found below. The history is preserved mostly for archeological purposes. Sure. Thanks. #!/usr/bin/perl -w # This is part of osstest, an automated testing framework for Xen. # Copyright (C) 2009-2013 Citrix Inc. Date ;-) I couldn't spot anything else, FWIW. I think if you are happy with the output there's no reason not to just run with it. I'll give you a chance to look at the output URL above. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] x86/HVM: avoid pointer wraparound in bufioreq handling
The number of slots per page being 511 (i.e. not a power of two) means
that the (32-bit) read and write indexes going beyond 2^32 will likely
disturb operation. Extend I/O req server creation so the caller can
indicate that it is using suitable atomic accesses where needed (not
all accesses to the two pointers really need to be atomic), allowing
the hypervisor to atomically canonicalize both pointers when both have
gone through at least one cycle.
Signed-off-by: Jan Beulich jbeul...@suse.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
v2: Limit canonicalization loop to IOREQ_BUFFER_SLOT_NUM iterations.
Adjust xc_hvm_create_ioreq_server() documentation.
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1933,7 +1933,8 @@ int xc_get_hvm_param(xc_interface *handl
*
* @parm xch a handle to an open hypervisor interface.
* @parm domid the domain id to be serviced
- * @parm handle_bufioreq should the IOREQ Server handle buffered requests?
+ * @parm handle_bufioreq how should the IOREQ Server handle buffered requests
+ * (HVM_IOREQSRV_BUFIOREQ_*)?
* @parm id pointer to an ioservid_t to receive the IOREQ Server id.
* @return 0 on success, -1 on failure.
*/
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -1411,7 +1411,7 @@ int xc_hvm_create_ioreq_server(xc_interf
hypercall.arg[1] = HYPERCALL_BUFFER_AS_ARG(arg);
arg-domid = domid;
-arg-handle_bufioreq = !!handle_bufioreq;
+arg-handle_bufioreq = handle_bufioreq;
rc = do_xen_hypercall(xch, hypercall);
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -921,7 +921,7 @@ static void hvm_ioreq_server_disable(str
static int hvm_ioreq_server_init(struct hvm_ioreq_server *s, struct domain *d,
domid_t domid, bool_t is_default,
- bool_t handle_bufioreq, ioservid_t id)
+ int bufioreq_handling, ioservid_t id)
{
struct vcpu *v;
int rc;
@@ -938,7 +938,11 @@ static int hvm_ioreq_server_init(struct
if ( rc )
return rc;
-rc = hvm_ioreq_server_setup_pages(s, is_default, handle_bufioreq);
+if ( bufioreq_handling == HVM_IOREQSRV_BUFIOREQ_ATOMIC )
+s-bufioreq_atomic = 1;
+
+rc = hvm_ioreq_server_setup_pages(
+ s, is_default, bufioreq_handling != HVM_IOREQSRV_BUFIOREQ_OFF);
if ( rc )
goto fail_map;
@@ -997,12 +1001,15 @@ static ioservid_t next_ioservid(struct d
}
static int hvm_create_ioreq_server(struct domain *d, domid_t domid,
- bool_t is_default, bool_t handle_bufioreq,
+ bool_t is_default, int bufioreq_handling,
ioservid_t *id)
{
struct hvm_ioreq_server *s;
int rc;
+if ( bufioreq_handling HVM_IOREQSRV_BUFIOREQ_ATOMIC )
+return -EINVAL;
+
rc = -ENOMEM;
s = xzalloc(struct hvm_ioreq_server);
if ( !s )
@@ -1015,7 +1022,7 @@ static int hvm_create_ioreq_server(struc
if ( is_default d-arch.hvm_domain.default_ioreq_server != NULL )
goto fail2;
-rc = hvm_ioreq_server_init(s, d, domid, is_default, handle_bufioreq,
+rc = hvm_ioreq_server_init(s, d, domid, is_default, bufioreq_handling,
next_ioservid(d));
if ( rc )
goto fail3;
@@ -2560,7 +2567,7 @@ int hvm_buffered_io_send(ioreq_t *p)
spin_lock(s-bufioreq_lock);
-if ( (pg-write_pointer - pg-read_pointer) =
+if ( (pg-ptrs.write_pointer - pg-ptrs.read_pointer) =
(IOREQ_BUFFER_SLOT_NUM - qw) )
{
/* The queue is full: send the iopacket through the normal path. */
@@ -2568,17 +2575,29 @@ int hvm_buffered_io_send(ioreq_t *p)
return 0;
}
-pg-buf_ioreq[pg-write_pointer % IOREQ_BUFFER_SLOT_NUM] = bp;
+pg-buf_ioreq[pg-ptrs.write_pointer % IOREQ_BUFFER_SLOT_NUM] = bp;
if ( qw )
{
bp.data = p-data 32;
-pg-buf_ioreq[(pg-write_pointer+1) % IOREQ_BUFFER_SLOT_NUM] = bp;
+pg-buf_ioreq[(pg-ptrs.write_pointer+1) % IOREQ_BUFFER_SLOT_NUM] = bp;
}
/* Make the ioreq_t visible /before/ write_pointer. */
wmb();
-pg-write_pointer += qw ? 2 : 1;
+pg-ptrs.write_pointer += qw ? 2 : 1;
+
+/* Canonicalize read/write pointers to prevent their overflow. */
+while ( s-bufioreq_atomic qw++ IOREQ_BUFFER_SLOT_NUM
+pg-ptrs.read_pointer = IOREQ_BUFFER_SLOT_NUM )
+{
+union bufioreq_pointers old = pg-ptrs, new;
+unsigned int n = old.read_pointer / IOREQ_BUFFER_SLOT_NUM;
+
+new.read_pointer = old.read_pointer - n * IOREQ_BUFFER_SLOT_NUM;
+new.write_pointer = old.write_pointer - n * IOREQ_BUFFER_SLOT_NUM;
+cmpxchg(pg-ptrs.full, old.full, new.full);
+}
notify_via_xen_event_channel(d, s-bufioreq_evtchn);
spin_unlock(s-bufioreq_lock);
@@ -5446,7 +5465,7 @@ static int
Re: [Xen-devel] FW: VT-d async invalidation for Device-TLB.
On 18.06.15 at 13:31, quan...@intel.com wrote: On June 18, 2015 5:19 PM, jbeul...@suse.com wrote: On 18.06.15 at 10:09, quan...@intel.com wrote: On 16.06.15 09:59, mailto:jbeul...@suse.com wrote: On 16.06.15 at 09:59, yang.z.zh...@intel.com wrote: Jan Beulich wrote on 2015-06-16: On 16.06.15 at 05:07, yang.z.zh...@intel.com wrote: Jan Beulich wrote on 2015-06-15: On 13.06.15 at 16:44, quan...@intel.com wrote: On 12.06.15 at 14:47, jbeul...@suse.com wrote: On 12.06.15 at 04:40, quan...@intel.com wrote: which one? 1.4us for sync case and 4.3us for async case? The difference between the two (i.e. why is the async variant three times as long). I have tested iotlb async/sync invalidation to get another data. Also I disabled 'P State' / 'C State' in bios. For async invalidation: about 2.67 us. For sync invalidation: about 1.28 us. I also tested VCPU_KICK_SOFTIRQ irq cost. When hypervisor calls cpu_raise_softirq(..VCPU_KICK_SOFTIRQ) to raise an VCPU_KICK_SOFTIRQ irq, and vcpu_kick_softirq() is the VCPU_KICK_SOFTIRQ interrupt handler. I got the cost between cpu_raise_softirq(..VCPU_KICK_SOFTIRQ) and vcpu_kick_softirq(). It is about 1.21 us. I think the difference is interrupt cost between async invalidation and sync invalidation. Which contradicts what I think Yang said in an earlier reply. Talked with Yang who is confused at what he said. :( Could you share more? Upon me asking, he specifically indicated the numbers do _not_ include interrupt handling overhead. 2.67us is almost ideal for async invalidation cost. There are 4 reasons to cost much more time: 1. If enable 'P State' / 'C State' in bios. 2. Hypervisor is running in No-root mode. 3. The time doesn't include the cost of handling of interrupt. I just record it at the entry of interrupt handler. 4. More pass-through VMs runs. So there are maybe some performance issues when we replace the current spinning for the non-ATS case. We can start from ATS case firstly, And apply it to non-ATS case later if the async approach performance is acceptable. Jan, Do you agree with this? No, I'm still not convinced that leaving the non-ATS case alone initially is the right approach. But maybe I'm the only one? I hope for someone else to give some comments. I tried to replace the current spinning for the non-ATS case, but Xen crashed. Based on dmesg, it seems that VT-d is enabled before enabling IO-APIC IRQs. I can send out two serious of patch: 1st: VT-d async invalidation for ATS case. 2nd: VT-d async invalidation for non-ATS case. I think the 1st serious of patch is high priority, as it is not correct to spin 1 second for ATS case. I can implement these source code and send out ASAP. 2nd serious of patch is low priority, as it's optimization. Also I can provide a serious of patch to fix it later. That's fine as long as the second series won't arrive only months later. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 01/44] kernel: Add support for poweroff handler call chain
On 06/17/2015 11:53 PM, Frans Klaver wrote: On Thu, Jun 18, 2015 at 3:04 AM, Stephen Boyd sb...@codeaurora.org wrote: On 10/06/2014 10:28 PM, Guenter Roeck wrote: Various drivers implement architecture and/or device specific means to remove power from the system. For the most part, those drivers set the global variable pm_power_off to point to a function within the driver. This mechanism has a number of drawbacks. Typically only one scheme to remove power is supported (at least if pm_power_off is used). At least in theory there can be multiple means remove power, some of which may be less desirable. For example, some mechanisms may only power off the CPU or the CPU card, while another may power off the entire system. Others may really just execute a restart sequence or drop into the ROM monitor. Using pm_power_off can also be racy if the function pointer is set from a driver built as module, as the driver may be in the process of being unloaded when pm_power_off is called. If there are multiple poweroff handlers in the system, removing a module with such a handler may inadvertently reset the pointer to pm_power_off to NULL, leaving the system with no means to remove power. Introduce a system poweroff handler call chain to solve the described problems. This call chain is expected to be executed from the architecture specific machine_power_off() function. Drivers providing system poweroff functionality are expected to register with this call chain. By using the priority field in the notifier block, callers can control poweroff handler execution sequence and thus ensure that the poweroff handler with the optimal capabilities to remove power for a given system is called first. What happened to this series? I want to add shutdown support to my platform and I need to write a register on the PMIC in one driver to configure it for shutdown instead of restart and then write an MMIO register to tell the PMIC to actually do the shutdown in another driver. It seems that the notifier solves this case for me, albeit with the slight complication that I need to order the two with some priority. I was wondering the same thing. I did find out that things kind of stalled after Linus cast doubt on the chosen path [1]. I'm not sure there's any consensus on what would be best to do instead. Linus cast doubt on it, then the maintainers started picking it apart. At the end, trying not to use notifier callbacks made the code so complicated that even I didn't understand it anymore. With no consensus in sight, I abandoned it. Problem is really that the notifier call chain would be perfect to solve the problem, yet Linus didn't like priorities (which are essential), and the power maintainers didn't like that a call chain is supposed to execute _all_ callbacks, which would not be the case here. If I were to start again, I would insist to use notifiers. However, I don't see a chance to get that accepted, so I won't. Feel free to pick it up and give it a try yourself. Thanks, Guenter ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] FW: VT-d async invalidation for Device-TLB.
June 18, 2015 7:39 PM, jbeul...@suse.com wrote: On 18.06.15 at 13:31, quan...@intel.com wrote: On June 18, 2015 5:19 PM, jbeul...@suse.com wrote: On 18.06.15 at 10:09, quan...@intel.com wrote: On 16.06.15 09:59, mailto:jbeul...@suse.com wrote: On 16.06.15 at 09:59, yang.z.zh...@intel.com wrote: Jan Beulich wrote on 2015-06-16: On 16.06.15 at 05:07, yang.z.zh...@intel.com wrote: Jan Beulich wrote on 2015-06-15: On 13.06.15 at 16:44, quan...@intel.com wrote: On 12.06.15 at 14:47, jbeul...@suse.com wrote: On 12.06.15 at 04:40, quan...@intel.com wrote: I can send out two series of patch: 1st: VT-d async invalidation for ATS case. 2nd: VT-d async invalidation for non-ATS case. I think the 1st series of patch is high priority, as it is not correct to spin 1 second for ATS case. I can implement these source code and send out ASAP. 2nd series of patch is low priority, as it's optimization. Also I can provide a serious of patch to fix it later. That's fine as long as the second series won't arrive only months later. I am starting to implement the 1st series -- VT-d async invalidation for ATS case. Quan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API
On 06/17/2015 12:24 PM, Ian Campbell wrote: On Tue, 2015-06-16 at 12:44 +0100, Ian Jackson wrote: George Dunlap writes (Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API): On Tue, Jun 16, 2015 at 12:19 PM, Juergen Gross jgr...@suse.com wrote: I'm pretty sure this is just a matter of timing during boot: the busses are all (or at least some of them) queried at the same time and the first answering gets number 1, the next 2, and so on. And timing seems to be different enough to result in unstable bus numbers. Right -- I meant stable in topology within one boot, but at least two of you have now understood me to mean across reboots by default, so that's obviously a detail that needs to be specified. :-) I think stable in topology within one boot is nearly vacuous (or are we expecting buses or devices to spontaneously renumber themselves for no reason) and also nearly useless. We definitely need _some_ way for a user to identify a specific device uniquely in a way that is reliable from one boot to the next. vid:pid is one way to do this, but not always sufficient. We should perhaps separate out the end user from the libxl user (i.e. the toolstack application) in our deliberations here. We have the option of settling on a single way of describing a device to libxl in the libxl API but allowing the toolstack to choose to present the user with multiple different ways to specify things by providing a suitable set of helper functions (in either libxlu or libxl proper) from a variety of schemes to the one true way of describing a device. That sounds better to me than having the libxl API consist of the union of all potentially useful ways to refer to a device. This was my original design. :-) I'm not sure whether that also gives us the freedom to use something which is only stable for a given boot at the libxl API layer though. I'm not sure why it doesn't -- as long as things don't change between the time the toostack converts a stable name into a specification and the time libxl uses it, it should be fine. One advantage of having a richer interface that Juergen pointed out previously was the ability to specify attaching devices automatically when they show yp; i.e., If a device with this vendorid:deviceid:serialnumber shows up, please attach it to this VM. But we don't have that functionality now; and there's no reason we couldn't add extra ways of specifying devices in the future. This usb interface stuff is really becoming a morass. The core functionality is fairly independent of the interface. I'm inclined to say that we should start with a simple specification (only bus.addr), and try to get both pvusb and hvmusb in. Then we can talk about where to add additional specifications (including cross-boot stable specifcations). -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv3 5/6] evtchn: remove the locking when unmasking an event channel
On 18.06.15 at 13:36, david.vra...@citrix.com wrote: On 18/06/15 12:30, Jan Beulich wrote: On 17.06.15 at 14:03, david.vra...@citrix.com wrote: --- a/xen/common/event_channel.c +++ b/xen/common/event_channel.c @@ -978,8 +978,6 @@ int evtchn_unmask(unsigned int port) struct domain *d = current-domain; struct evtchn *evtchn; -ASSERT(spin_is_locked(d-event_lock)); - if ( unlikely(!port_is_valid(d, port)) ) return -EINVAL; @@ -1146,9 +1144,7 @@ long do_event_channel_op(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg) struct evtchn_unmask unmask; if ( copy_from_guest(unmask, arg, 1) != 0 ) return -EFAULT; -spin_lock(current-domain-event_lock); rc = evtchn_unmask(unmask.port); -spin_unlock(current-domain-event_lock); And, looking particularly at evtchn_fifo_unmask() (and its descendant evtchn_fifo_set_pending()), you get away without acquiring the port lock in or around evtchn_port_unmask()? If indeed so, this one would again be independent on 1, 2, and 4, i.e. could go in together with 3. Yes. This is only dependent on #3 (simplify port_is_valid()). I'm still not convinced that not taking the port lock is correct: It is my understanding that e.g. the (last_vcpu_id,last_priority) pair needs to be updated atomically. Yet nothing prevents the (notify_vcpu_id,priority) pair now from getting updated in the middle of it being snapshot in evtchn_fifo_set_pending(). Are you saying this is no problem? Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API
On 06/18/2015 02:08 PM, George Dunlap wrote: On 06/17/2015 12:24 PM, Ian Campbell wrote: On Tue, 2015-06-16 at 12:44 +0100, Ian Jackson wrote: George Dunlap writes (Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API): On Tue, Jun 16, 2015 at 12:19 PM, Juergen Gross jgr...@suse.com wrote: I'm pretty sure this is just a matter of timing during boot: the busses are all (or at least some of them) queried at the same time and the first answering gets number 1, the next 2, and so on. And timing seems to be different enough to result in unstable bus numbers. Right -- I meant stable in topology within one boot, but at least two of you have now understood me to mean across reboots by default, so that's obviously a detail that needs to be specified. :-) I think stable in topology within one boot is nearly vacuous (or are we expecting buses or devices to spontaneously renumber themselves for no reason) and also nearly useless. We definitely need _some_ way for a user to identify a specific device uniquely in a way that is reliable from one boot to the next. vid:pid is one way to do this, but not always sufficient. We should perhaps separate out the end user from the libxl user (i.e. the toolstack application) in our deliberations here. We have the option of settling on a single way of describing a device to libxl in the libxl API but allowing the toolstack to choose to present the user with multiple different ways to specify things by providing a suitable set of helper functions (in either libxlu or libxl proper) from a variety of schemes to the one true way of describing a device. That sounds better to me than having the libxl API consist of the union of all potentially useful ways to refer to a device. This was my original design. :-) I'm not sure whether that also gives us the freedom to use something which is only stable for a given boot at the libxl API layer though. I'm not sure why it doesn't -- as long as things don't change between the time the toostack converts a stable name into a specification and the time libxl uses it, it should be fine. One advantage of having a richer interface that Juergen pointed out previously was the ability to specify attaching devices automatically when they show yp; i.e., If a device with this vendorid:deviceid:serialnumber shows up, please attach it to this VM. But we don't have that functionality now; and there's no reason we couldn't add extra ways of specifying devices in the future. This usb interface stuff is really becoming a morass. The core functionality is fairly independent of the interface. I'm inclined to say that we should start with a simple specification (only bus.addr), and try to get both pvusb and hvmusb in. Then we can talk about where to add additional specifications (including cross-boot stable specifcations). +1 Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API
On 06/18/2015 10:50 AM, Ian Campbell wrote: On Thu, 2015-06-18 at 09:02 +0200, Juergen Gross wrote: On 06/18/2015 08:20 AM, Chun Yan Liu wrote: On 6/17/2015 at 07:34 PM, in message 1434540857.13744.334.ca...@citrix.com, Ian Campbell ian.campb...@citrix.com wrote: On Tue, 2015-06-16 at 16:20 +0200, Juergen Gross wrote: My point was to avoid the sysfs accesses in libxl in order to support BSD as well and to reduce the complexity. As a slight aside to this, can't libxl use libusb for a lot of this stuff and therefore avoid being Linux specific? http://libusb.info/ claims to support Linux, OS X, Windows, Windows CE, Android, OpenBSD/NetBSD, Haiku.. Interestingly FreeBSD is missing there but I don't think that need to be a blocker. I don't see a problem with adding libusb to our set of dependencies, and it's certainly got to be better than (re)implementing a bunch of sysfs stuff (which I presume is what libusb does under the hood anyway). Using libusb is certainly good and can save effort to implement things by ourself. Only one concern: some functions require newer version of libusb. For example, functions to get port (quite like busid) information libusb_get_port_numbers or libusb_get_port_path need libusb version = 1.0.12. If libusb version is not satisfied, the whole pvusb work might be blocked. Is this really a problem? lubusb version 1.0.12 is out for three years now. Would we really need to support pvUSB on dom0 not being capable to install a more recent libusb? Of interest would be which distro versions have = 1.0.12 i.e. for common things like Debian, SuSE, SLE, Fedora etc. openSUSE since 13.2 (13.1 has 1.0.9) SLE since 12 Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv3 4/6] evtchn: use a per-event channel lock for sending events
On 17.06.15 at 14:03, david.vra...@citrix.com wrote: When sending an event, use a new per-event channel lock to safely validate the event channel state. This new lock must be held when changing event channel state. Note that the event channel lock must also be held when changing state from ECS_FREE or it will race with a concurrent get_free_port() call. To avoid having to take the remote event channel locks when sending to an interdomain event channel, the local and remote channel locks are both held when binding or closing an interdomain event channel. This significantly increases the number of events that can be sent from multiple VCPUs. But struct evtchn increases in size, reducing the number that fit into a single page to 64 (instead of 128). Signed-off-by: David Vrabel david.vra...@citrix.com Reviewed-by: Jan Beulich jbeul...@suse.com But iiuc this functionally depends on the earlier patches, and hence can't go in without the issues there addressed. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/HVM: EOI handling function adjustments
The vector parameters are more usefully u8 right away. This is
particularly important for the vioapic_update_EOI() invocation from
vioapic_write() (which luckily is only a latent issue, as
VIOAPIC_VERSION_ID is still hard coded to 0x11 right now). But it at
once allows simplifying VMX's EXIT_REASON_EOI_INDUCED handling (the
kind of pointless helper function should have been static anyway; not
being use for anything else, it gets removed altogether).
Plus vlapic_handle_EOI() (now renamed for that purpose) can be used as
the tail of vlapic_EOI_set() instead of duplicating that code.
Finally replace a stray current-domain use in vlapic_handle_EOI().
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -386,7 +386,7 @@ void vioapic_irq_positive_edge(struct do
}
}
-void vioapic_update_EOI(struct domain *d, int vector)
+void vioapic_update_EOI(struct domain *d, u8 vector)
{
struct hvm_hw_vioapic *vioapic = domain_vioapic(d);
struct hvm_irq *hvm_irq = d-arch.hvm_domain.irq;
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -421,18 +421,17 @@ void vlapic_EOI_set(struct vlapic *vlapi
if ( hvm_funcs.handle_eoi )
hvm_funcs.handle_eoi(vector);
-if ( vlapic_test_and_clear_vector(vector, vlapic-regs-data[APIC_TMR]) )
-vioapic_update_EOI(vlapic_domain(vlapic), vector);
-
-hvm_dpci_msi_eoi(current-domain, vector);
+vlapic_handle_EOI(vlapic, vector);
}
-void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
+void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)
{
+struct domain *d = vlapic_domain(vlapic);
+
if ( vlapic_test_and_clear_vector(vector, vlapic-regs-data[APIC_TMR]) )
-vioapic_update_EOI(vlapic_domain(vlapic), vector);
+vioapic_update_EOI(d, vector);
-hvm_dpci_msi_eoi(current-domain, vector);
+hvm_dpci_msi_eoi(d, vector);
}
static bool_t is_multicast_dest(struct vlapic *vlapic, unsigned int short_hand,
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2683,17 +2683,6 @@ static int vmx_handle_apic_write(void)
return vlapic_apicv_write(current, exit_qualification 0xfff);
}
-/*
- * When Virtual Interrupt Delivery is enabled, this function is used
- * to handle EOI-induced VM exit
- */
-void vmx_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
-{
-ASSERT(cpu_has_vmx_virtual_intr_delivery);
-
-vlapic_handle_EOI_induced_exit(vlapic, vector);
-}
-
void vmx_vmexit_handler(struct cpu_user_regs *regs)
{
unsigned long exit_qualification, exit_reason, idtv_info, intr_info = 0;
@@ -3127,15 +3116,12 @@ void vmx_vmexit_handler(struct cpu_user_
break;
case EXIT_REASON_EOI_INDUCED:
-{
-int vector;
-
__vmread(EXIT_QUALIFICATION, exit_qualification);
-vector = exit_qualification 0xff;
-vmx_handle_EOI_induced_exit(vcpu_vlapic(v), vector);
+ASSERT(cpu_has_vmx_virtual_intr_delivery);
+
+vlapic_handle_EOI(vcpu_vlapic(v), exit_qualification);
break;
-}
case EXIT_REASON_IO_INSTRUCTION:
__vmread(EXIT_QUALIFICATION, exit_qualification);
--- a/xen/include/asm-x86/hvm/vioapic.h
+++ b/xen/include/asm-x86/hvm/vioapic.h
@@ -62,6 +62,6 @@ int vioapic_init(struct domain *d);
void vioapic_deinit(struct domain *d);
void vioapic_reset(struct domain *d);
void vioapic_irq_positive_edge(struct domain *d, unsigned int irq);
-void vioapic_update_EOI(struct domain *d, int vector);
+void vioapic_update_EOI(struct domain *d, u8 vector);
#endif /* __ASM_X86_HVM_VIOAPIC_H__ */
--- a/xen/include/asm-x86/hvm/vlapic.h
+++ b/xen/include/asm-x86/hvm/vlapic.h
@@ -127,7 +127,7 @@ uint32_t vlapic_set_ppr(struct vlapic *v
void vlapic_adjust_i8259_target(struct domain *d);
void vlapic_EOI_set(struct vlapic *vlapic);
-void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector);
+void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector);
void vlapic_ipi(struct vlapic *vlapic, uint32_t icr_low, uint32_t icr_high);
x86/HVM: EOI handling function adjustments
The vector parameters are more usefully u8 right away. This is
particularly important for the vioapic_update_EOI() invocation from
vioapic_write() (which luckily is only a latent issue, as
VIOAPIC_VERSION_ID is still hard coded to 0x11 right now). But it at
once allows simplifying VMX's EXIT_REASON_EOI_INDUCED handling (the
kind of pointless helper function should have been static anyway; not
being use for anything else, it gets removed altogether).
Plus vlapic_handle_EOI() (now renamed for that purpose) can be used as
the tail of vlapic_EOI_set() instead of duplicating that code.
Finally replace a stray current-domain use in vlapic_handle_EOI().
Signed-off-by: Jan Beulich jbeul...@suse.com
--- a/xen/arch/x86/hvm/vioapic.c
+++ b/xen/arch/x86/hvm/vioapic.c
@@ -386,7 +386,7 @@ void vioapic_irq_positive_edge(struct do
}
}
-void
Re: [Xen-devel] [PATCH] x86/HVM: EOI handling function adjustments
On 18.06.15 at 15:29, andrew.coop...@citrix.com wrote:
On 18/06/15 13:51, Jan Beulich wrote:
-void vlapic_handle_EOI_induced_exit(struct vlapic *vlapic, int vector)
+void vlapic_handle_EOI(struct vlapic *vlapic, u8 vector)
{
+struct domain *d = vlapic_domain(vlapic);
+
if ( vlapic_test_and_clear_vector(vector,
vlapic-regs-data[APIC_TMR]) )
-vioapic_update_EOI(vlapic_domain(vlapic), vector);
+vioapic_update_EOI(d, vector);
-hvm_dpci_msi_eoi(current-domain, vector);
+hvm_dpci_msi_eoi(d, vector);
It might be worth retaining an ASSERT(current-domain == d) at this point.
For one, there would be many more places where this should then
be added. And then, even with the current (unpatched) code things
would go wrong if that wasn't already the case.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] performace issue when turn on apicv
Hi, I'm John's colleague. We looked into the details of the tracing data, and found that the number of MSR_IA32_APICTMICT_MSR event is quite high when apic-v is enabled(about 9x more compared with apic-v disabled). Below is the details: EXIT_REASON_MSR_WRITE apicv on: MSR= 0x0838(MSR_IA32_APICTMICT_MSR) count= 111480 MSR= 0x0830(x2APIC Interrupt Command Register)count= 350 Total count = 111830 apicv off: MSR= 0x0838(MSR_IA32_APICTMICT_MSR) count= 13595 MSR= 0x0830(x2APIC Interrupt Command Register)count= 254 MSR= 0x080b(MSR_IA32_APICEOI_MSR)count= 215760 Total count = 229609 If there is anything need to get, pls let me know. Thanks. Regards Yifei jiang -Original Message- Date: Thu, 18 Jun 2015 09:20:39 +0100 From: Jan Beulich jbeul...@suse.com To: Liuqiming (John) john.liuqim...@huawei.com Cc: Yang Z Zhang yang.z.zh...@intel.com, xen-de...@lists.xensource.com xen-de...@lists.xensource.com, peter.huangp...@huawei.com peter.huangp...@huawei.com Subject: Re: [Xen-devel] performace issue when turn on apicv Message-ID: 55829b77027800086...@mail.emea.novell.com Content-Type: text/plain; charset=US-ASCII On 18.06.15 at 10:02, john.liuqim...@huawei.com wrote: When using FIO to test the performance of SSD passthroughed in vm the result show that: When the apicv is on, each EXIT_REASON_MSR_WRITE event spent more time than apicv is off. Following is the xentrace result: apicv on: VMExitCodeVMExitReason VMExitCnt VMExitTicksVMExitTicks/VMExitCnt 0x01 EXIT_REASON_EXTERNAL_INTERRUPT 270334 2730912532 10101.99432 0x12 EXIT_REASON_VMCALL 20 438736 21936.8 0x1c EXIT_REASON_CR_ACCESS 381340 1096174160 2874.532333 0x1e EXIT_REASON_IO_INSTRUCTION413 32958356 79802.31477 0x20 EXIT_REASON_MSR_WRITE 111830 818317724 7317.515193 0x2d EXIT_REASON_EOI_INDUCED 58944 234914864 3985.390608 0x30 EXIT_REASON_EPT_VIOLATION 10 298368 29836.8 Total 822891 4914014740 apicv off: VMExitCodeVMExitReason VMExitCnt VMExitTicks VMExitTicks/VMExitCnt 0x01 EXIT_REASON_EXTERNAL_INTERRUPT 237100 2419717824 10205.47374 0x07 EXIT_REASON_PENDING_VIRT_INTR792 2324824 2935.383838 0x12 EXIT_REASON_VMCALL 19 415168 21850.94737 0x1c EXIT_REASON_CR_ACCESS 406848 1075393292 2643.231113 0x1e EXIT_REASON_IO_INSTRUCTION413 39433068 95479.58354 0x1fEXIT_REASON_MSR_READ 48 1505283136 0x20 EXIT_REASON_MSR_WRITE 229609 1004844372.651264 0x30 EXIT_REASON_EPT_VIOLATION 10 249172 24917.2 Total874839 4541683960 And did you drill into _which_ MSR(s) are requiring this much longer to have their writes handled? After all, that's the relevant thing, provided the increase of this indeed has anything to do with the performance issue you're seeing (the absolute increase of 200M ticks there doesn't mean much for the performance effect without knowing what the total execution time was). Apart from that I notice that the EXIT_REASON_EOI_INDUCED handling also adds about the same number of ticks... Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 00/25] Reporting improvements
On Thu, 2015-06-18 at 12:21 +0100, Ian Jackson wrote: Ian Campbell writes (Re: [OSSTEST PATCH 00/25] Reporting improvements): On Wed, 2015-06-17 at 17:44 +0100, Ian Jackson wrote: Most of the early part of this series is straightforward (and acked) and could go in whenever. Agreed. Do you happen to have a convenient directory with the new output? (I'm happy to just wait for it to happen too). I have mostly run it on my workstation on the Cambridge instance. Here is an example that I have lying about, copied to a public webserver: http://www.chiark.greenend.org.uk/~ijackson/quicksand/2015/grain-weevil.html [...] I'll give you a chance to look at the output URL above. Looks good, thanks. OOI what is the expected usefulness of the alloc testid column? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc
On 18/06/15 15:09, Peng Fan wrote: Hi, Hi, /bin/sh: can't access tty; job control turned off / # mmcblk2: p1 p2 mmcblk2boot1: unknown partition table mmcblk2boot0: unknown partition table (XEN) imx-uart.c:72: uart: rxfifo overrun It seems that you ported a new UART driver. My feeling is the error in DOM0 is related to this message. The Dom0 kernel is also configured with CONFIG_ARM_ARCH_TIMER=y, will this incur errors? Or should Dom0 kernel not use arm arch timer? DOM0 should use the generic timer too. Regards, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 02/11] x86/intel_pstate: add some calculation related support
On 11.06.15 at 10:26, wei.w.w...@intel.com wrote:
The added calculation related functions will be used in the intel_pstate.c.
They are copied from the kernel(commit 2418f4f2, f3002134, eb18cba7).
The _Linux_ kernel I assume?
--- a/xen/include/asm-x86/div64.h
+++ b/xen/include/asm-x86/div64.h
@@ -11,4 +11,76 @@
__rem; \
})
+static inline uint64_t div_u64_rem(uint64_t dividend, uint32_t divisor,
+ uint32_t *remainder)
+{
+*remainder = do_div(dividend, divisor);
+return dividend;
+}
+
+static inline uint64_t div_u64(uint64_t dividend, uint32_t divisor)
+{
+uint32_t remainder;
+return div_u64_rem(dividend, divisor, remainder);
+}
+
+/*
+ * div64_u64 - unsigned 64bit divide with 64bit divisor
+ * @dividend:64bit dividend
+ * @divisor:64bit divisor
+ *
+ * This implementation is a modified version of the algorithm proposed
+ * by the book 'Hacker's Delight'. The original source and full proof
+ * can be found here and is available for use without restriction.
+ *
+ * 'http://www.hackersdelight.org/HDcode/newCode/divDouble.c.txt'
+ */
+static inline uint64_t div64_u64(uint64_t dividend, uint64_t divisor)
+{
+uint32_t high = divisor 32;
+uint64_t quot;
+
+if (high == 0) {
+quot = div_u64(dividend, divisor);
+} else {
You have changed indentation to be Xen-like (and match the little
bit of code that was here before) - thanks. But once you do that,
you should fully convert to code to Xen style, i.e. (just for the
above):
if ( high == 0 )
quot = div_u64(dividend, divisor);
else
{
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 03/11] x86/intel_pstate: add new policy fields and a new driver interface
On 11.06.15 at 10:26, wei.w.w...@intel.com wrote:
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -457,6 +457,12 @@ int __cpufreq_set_policy(struct cpufreq_policy *data,
data-min = policy-min;
data-max = policy-max;
+if (cpufreq_driver-setpolicy) {
+data-limits.min_perf_pct = policy-limits.min_perf_pct;
+data-limits.max_perf_pct = policy-limits.max_perf_pct;
For one you leave all other data-limits fields uninitialized - please
use data-limits = policy-limits. And then I don't see why this
should be done inside the if() - there's no obvious connection
between -setpolicy being non-NULL and -limits having meaning
to the driver - this is solely your intended _use_ model.
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -41,6 +41,18 @@ struct cpufreq_cpuinfo {
unsigned inttransition_latency; /* in 10^(-9) s = nanoseconds */
};
+struct perf_limits {
+int no_turbo;
+int turbo_disabled;
Both bool_t I suppose.
@@ -52,6 +64,8 @@ struct cpufreq_policy {
unsigned intmax;/* in kHz */
unsigned intcur;/* in kHz, only needed if cpufreq
* governors are used */
+unsigned intpolicy;
This field isn't being used anywhere here. Please add it upon first use.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 08/11] x86/intel_pstate: add a booting param to select the driver to load
On 11.06.15 at 10:28, wei.w.w...@intel.com wrote:
--- a/xen/arch/x86/acpi/cpufreq/intel_pstate.c
+++ b/xen/arch/x86/acpi/cpufreq/intel_pstate.c
@@ -749,6 +749,9 @@ static struct cpufreq_driver intel_pstate_driver = {
.name = intel_pstate,
};
+static bool_t __initdata load_intel_pstate;
+boolean_param(intel_pstate, load_intel_pstate);
+
static int intel_pstate_msrs_not_valid(void)
{
if (!pstate_funcs.get_max() ||
Please move this immediately ahead of the (only) function you need
it in, or even inside that function. With that and with patch 9 folded
into this one
Acked-by: Jan Beulich jbeul...@suse.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 01/11] x86/acpi: add a common interface for x86 cpu matching
On 11.06.15 at 10:25, wei.w.w...@intel.com wrote: Add a common interface for matching the current cpu against an array of x86_cpu_ids. Also change mwait-idle.c to use it. Signed-off-by: Wei Wang wei.w.w...@intel.com --- There's a summary of the changes in v3 missing here (and it looks like everywhere in the series). Putting change info in the overview mail is nice, but the really useful thing for reviewing purposes is it to be in each patch. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] stable trees (was: [xen-4.2-testing test] 58584: regressions)
On Thu, 2015-06-18 at 12:37 +0100, Jan Beulich wrote: On 17.06.15 at 12:26, ian.jack...@eu.citrix.com wrote: Jan Beulich writes (stable trees (was: [xen-4.2-testing test] 58584: regressions)): Which leaves several options: - the problem was always there, but hidden by some factor in the old osstest instance, I think this is most likely. The old system had much older hosts. I think this is a race that we now happen to lose most of the time. For verification purposes, would it be possible to set up a couple of flights on the old instance for one of the stable trees? I can try and run something adhoc on the old system if you can let me know exactly which jobs (test-*-*-*) and branches you are interested in. Ian. One aspect making me indeed consider the build (or less likely runtime) aspect is that we're seeing the frequent migration failures in the stable trees only - other than unstable they're all getting built with debug=n. Races frequently come and go with that kind of change. True. Question then still is who will try to look into the issue (as right now it is quite harmful to the progress the stable trees can make towards getting pushed). 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] [OSSTEST PATCH 00/25] Reporting improvements
Ian Campbell writes (Re: [OSSTEST PATCH 00/25] Reporting improvements): On Thu, 2015-06-18 at 12:21 +0100, Ian Jackson wrote: I'll give you a chance to look at the output URL above. Looks good, thanks. OOI what is the expected usefulness of the alloc testid column? With the system as it currently exists, it will always say hosts-allocate. But that's not a fixed assumption of the overall resource allocation design. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Dom0 kernel panic when porting xen to new arm soc
Hi,
I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have
no clear idea about why Dom0 kernel panic.
Detail log see below:
U-Boot 2015.04-rc4-00145-gf12a16e (Jun 18 2015 - 10:38:06)
CPU: Freescale i.MX7D rev1.0 at 792 MHz
CPU: Thermal invalid data, fuse: 0x1b800
CPU: Temperature: Can't find sensor device
Reset cause: POR
Board: MX7D 12x12 LPDDR3 ARM2
I2C: ready
DRAM: 2 GiB
PMIC: PFUZE300 DEV_ID=0x30 REV_ID=0x10
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
Display: MCIMX28LCD (800x480)
Video: 800x480x24
In: serial
Out: serial
Err: serial
switch to partitions #0, OK
mmc0 is current device
Net: FEC0
Error: FEC0 address not set.
Normal Boot
Hit any key to stop autoboot: 0
= setenv xen_addr_r 0x8000
= setenv bootargs console=dtuart
dtuart=/soc/aips-bus@3080/serial@3086 dom0_mem=128M
= fatload mmc 0:1 0x8000 xen.image
reading xen.image
754544 bytes read in 129 ms (5.6 MiB/s)
= fatload mmc 0:1 0x8300 imx7d-12x12-arm2.dtb
reading imx7d-12x12-arm2.dtb
37498 bytes read in 21 ms (1.7 MiB/s)
= fatload mmc 0:1 0x8400 zImage
reading zImage
9307256 bytes read in 420 ms (21.1 MiB/s)
= setenv kernel_addr_r 0x8400
= setenv fdt_high 0x
= setenv fdt_addr 0x8300
= fdt addr ${fdt_addr} 0x4
= fdt resize
= fdt chosen
= fdt set /chosen \#address-cells 1
= fdt set /chosen \#size-cells 1
= fdt mknod /chosen module@0
= fdt set /chosen/module@0 compatible xen,linux-zimage
xen,multiboot-module
= fdt set /chosen/module@0 reg ${kernel_addr_r} 0x${filesize}
= fdt set /chosen/module@0 bootargs console=hvc0 ro
root=/dev/mmcblk0p2 clk_ignore_unused uart_from_osc
= bootz ${xen_addr_r} - ${fdt_addr}
Kernel image @ 0x8000 [ 0x00 - 0x101700 ]
## Flattened Device Tree blob at 8300
Booting using the fdt blob at 0x8300
reserving fdt memory region: addr=8300 size=a000
Using Device Tree in place at 8300, end 8300cfff
Starting kernel ...
Xen 4.6-unstable
(XEN) Xen version 4.6-unstable (Freenix@(none))
(arm-poky-linux-gnueabi-gcc (GCC) 4.8.2) debug=y Thu Jun 18 12:32:18 CST
2015
(XEN) Latest ChangeSet: Mon Jun 15 18:25:34 2015 +0800 git:c01e139-dirty
(XEN) Processor: 410fc075: ARM Limited, variant: 0x0, part 0xc07, rev 0x5
(XEN) 32-bit Execution:
(XEN) Processor Features: 1131:00011011
(XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle
(XEN) Extensions: GenericTimer Security
(XEN) Debug Features: 02010555
(XEN) Auxiliary Features:
(XEN) Memory Model Features: 10101105 4000 0124 02102211
(XEN) ISA Features: 02101110 13112111 21232041 2131 10011142
(XEN) Set Secondary entry to ffe0004c (0020004c)
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8000 KHz
(XEN) GICv2 initialization:
(XEN) gic_dist_addr=31001000
(XEN) gic_cpu_addr=31002000
(XEN) gic_hyp_addr=31004000
(XEN) gic_vcpu_addr=31006000
(XEN) gic_maintenance_irq=25
(XEN) GICv2: 160 lines, 2 cpus, secure (IID 0100143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) imx-uart.c:117: imx_uart_init_postirq
(XEN) Allocated console ring of 16 KiB.
(XEN) VFP implementer 0x41 architecture 2 part 0x30 variant 0x7 rev 0x5
(XEN) Brought up 1 CPUs
(XEN) P2M: 40-bit IPA
(XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558
(XEN) I/O virtualisation disabled
(XEN) *** LOADING DOMAIN 0 ***
(XEN) domain_build.c:1383: idle loop
(XEN) Loading kernel from boot module @ 8400
(XEN) Allocating 1:1 mappings totalling 128MB for dom0:
(XEN) BANK[0] 0x008800-0x009000 (128MB)
(XEN) Loading zImage from 8400 to
8f60-8fee0478
(XEN) Allocating PPI 16 for event channel interrupt
(XEN) Loading dom0 DTB to 0x8f40-0x8f409239
(XEN) regs - pc = 0x8f60
(XEN) it is 32 bit machine
(XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs
(XEN) done.
(XEN) Initial low memory virq threshold set at 0x4000 pages.
(XEN) Std. Loglevel: All
(XEN) Guest Loglevel: All
(XEN) *** Serial input - DOM0 (type 'CTRL-a' three times to switch
input to Xen)
(XEN) Freed 284kB init memory.
Booting Linux on physical CPU 0x0
Linux version 3.14.28-01780-g281e5c1-dirty (Freenix@linux-vaa1) (gcc
version 4.8.2 (GCC) ) #269 SMP PREEMPT Thu Jun 18 17:30:11 CST 2015
CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: Freescale i.MX7 LPDDR3 12x12 ARM2 Board
cma: CMA: failed to reserve 320 MiB
Memory policy: Data cache writealloc
psci: probing function IDs from device-tree
PERCPU: Embedded 8 pages/cpu @87ee1000 s9600 r8192 d14976 u32768
Built 1 zonelists in Zone order, mobility grouping off. Total pages: 32512
Kernel command line: console=hvc0 ro root=/dev/mmcblk0p2
clk_ignore_unused uart_from_osc
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768
Re: [Xen-devel] [PATCH v3 04/11] x86/intel_pstate: relocate the driver register function
On 11.06.15 at 10:27, wei.w.w...@intel.com wrote:
Register the CPU hotplug notifier when the driver is
registered, and move the driver register function to
the cpufreq.c.
The first half of the sentence fails to say why. And I suppose if you
explained that (to yourself) you'd figure that the change is wrong (or
at least altering behavior in a way that needs more explanation to
be verifiably correct): The calls to cpufreq_register_driver() sit in
__initcall handlers, yet what you replace is a presmp_initcall. I.e. all
APs being brought up at boot time won't get the callback invoked for
them anymore.
I suppose you tested your series on a system where the new driver
will kick in. You of course also need to test the case where this isn't
the case - everything needs to continue to function there.
--- a/xen/drivers/cpufreq/cpufreq.c
+++ b/xen/drivers/cpufreq/cpufreq.c
@@ -630,12 +630,21 @@ static struct notifier_block cpu_nfb = {
.notifier_call = cpu_callback
};
-static int __init cpufreq_presmp_init(void)
+int cpufreq_register_driver(struct cpufreq_driver *driver_data)
{
void *cpu = (void *)(long)smp_processor_id();
cpu_callback(cpu_nfb, CPU_ONLINE, cpu);
+if (!driver_data || !driver_data-init
+|| !driver_data-verify || !driver_data-exit
+|| (!driver_data-target == !driver_data-setpolicy))
Do you really want/need to enforce this policy (target set if and only
if setpolicy is not set) here? And if that's to uniformly hold, the two
could be put into a union...
Also - coding style.
--- a/xen/include/acpi/cpufreq/cpufreq.h
+++ b/xen/include/acpi/cpufreq/cpufreq.h
@@ -171,32 +171,8 @@ struct cpufreq_driver {
extern struct cpufreq_driver *cpufreq_driver;
-static __inline__
-int cpufreq_register_driver(struct cpufreq_driver *driver_data)
-{
-if (!driver_data ||
-!driver_data-init ||
-!driver_data-exit ||
-!driver_data-verify ||
-!driver_data-target)
-return -EINVAL;
-
-if (cpufreq_driver)
-return -EBUSY;
-
-cpufreq_driver = driver_data;
-return 0;
-}
-
-static __inline__
-int cpufreq_unregister_driver(struct cpufreq_driver *driver)
-{
-if (!cpufreq_driver || (driver != cpufreq_driver))
-return -EINVAL;
-
-cpufreq_driver = NULL;
-return 0;
-}
+extern int cpufreq_register_driver(struct cpufreq_driver *driver_data);
+extern int cpufreq_unregister_driver(struct cpufreq_driver *driver);
What's this declaration good for when there's no implementation?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 01/44] kernel: Add support for poweroff handler call chain
On Wed, Jun 17, 2015 at 06:04:54PM -0700, Stephen Boyd wrote: [ ... ] What happened to this series? I want to add shutdown support to my platform and I need to write a register on the PMIC in one driver to configure it for shutdown instead of restart and then write an MMIO register to tell the PMIC to actually do the shutdown in another driver. It seems that the notifier solves this case for me, albeit with the slight complication that I need to order the two with some priority. Can you use the .shutdown driver callback instead ? I see other drivers use that, and check for system_state == SYSTEM_POWER_OFF to power off the hardware. Guenter ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH 01/25] Osstest.pm: Provide new db_prepare helper with built-in debugging
Ian Jackson writes ([OSSTEST PATCH 01/25] Osstest.pm: Provide new db_prepare
helper with built-in debugging):
No callers, so no functional change, as yet.
+sub db_prepare ($) {
+# caller must ensure global filehandle DEBUG is open
+my ($stmt) = @_;
+print ::DEBUG DB PREPARING:\n$stmt\n;
+return $dbh_tests-prepare($stmt);
This generates:
Name main::DEBUG used only once: possible typo at Osstest.pm line
274.
Here is a v2 of this patch which fixes it.
Ian.
commit bd7cf4f0f1a8c45d840528bc28dbd89b34732d7a
Author: Ian Jackson ian.jack...@eu.citrix.com
Date: Fri May 29 13:19:39 2015 +
Osstest.pm: Provide new db_prepare helper with built-in debugging
No callers, so no functional change, as yet.
Signed-off-by: Ian Jackson ian.jack...@eu.citrix.com
Acked-by: Ian Campbell ian.campb...@citrix.com
---
v2: Suppress used only once warning
diff --git a/Osstest.pm b/Osstest.pm
index e8bd77b..8948666 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -35,7 +35,7 @@ BEGIN {
getmethod
postfork
$dbh_tests db_retry db_retry_retry db_retry_abort
- db_begin_work
+ db_begin_work db_prepare
ensuredir get_filecontents_core_quiet system_checked
nonempty visible_undef show_abs_time
);
@@ -49,6 +49,10 @@ our $mjobdb;
our $dbh_tests;
+scalar *main::DEBUG;
+# declaration prevents `Name main::DEBUG used only once'
+# scalar prevents `useless use of a variable in void context'
+
#-- static default config settings --
our %c = qw(
@@ -268,6 +272,13 @@ sub db_retry ($$$;$$) {
return $r;
}
+sub db_prepare ($) {
+# caller must ensure global filehandle DEBUG is open
+my ($stmt) = @_;
+print ::DEBUG DB PREPARING:\n$stmt\n;
+return $dbh_tests-prepare($stmt);
+}
+
sub postfork () {
$mjobdb-jobdb_postfork();
}
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt test] 58119: regressions - FAIL
On Thu, 2015-06-18 at 16:18 +0100, Ian Campbell wrote: On Mon, 2015-06-15 at 15:30 +0100, Anthony PERARD wrote: The No response from client ... appear only on armhf as far as I can tell. Indeed, and I just noticed while developing osstest for arm64 that the daemon is segfaulting, and we even managed to collect a core dump, not this time but in: http://logs.test-lab.xenproject.org/osstest/logs/58693/test-armhf-armhf-libvirt/info.html Although the core and the build stuff is all there it was a bit easier to just install gdb on the arm64 system in my hands, it reports: Fwiw the arm32 one from 48693 looked a bit different, but was ultimately some sort of heap corruption I would say: Using host libthread_db library /lib/arm-linux-gnueabihf/libthread_db.so.1. Core was generated by `/usr/local/sbin/libvirtd -d'. Program terminated with signal 6, Aborted. #0 __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S:44 44 ../ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S: No such file or directory. (gdb) bt #0 __libc_do_syscall () at ../ports/sysdeps/unix/sysv/linux/arm/eabi/libc-do-syscall.S:44 #1 0xb694af8a in __GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:67 #2 0xb694d428 in __GI_abort () at abort.c:92 #3 0xb69722f6 in __libc_message (do_abort=2, fmt=0xb69f25d8 *** glibc detected *** %s: %s: 0x%s ***\n) at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #4 0xb6978fbe in malloc_printerr (action=optimized out, str=0xb69f2604 munmap_chunk(): invalid pointer, ptr=optimized out) at malloc.c:6312 #5 0xb6ab27c0 in virFree () from /local/scratch/ianc/tmp/usr/local/lib/libvirt.so.0 #6 0xb149b0bc in libxlDomainSetVcpuAffinities () from /local/scratch/ianc/tmp/usr/local/lib/libvirt/connection-driver/libvirt_driver_libxl.so #7 0xb149b8ce in libxlDomainStart () from /local/scratch/ianc/tmp/usr/local/lib/libvirt/connection-driver/libvirt_driver_libxl.so #8 0xb149db34 in libxlDomainCreateXML () from /local/scratch/ianc/tmp/usr/local/lib/libvirt/connection-driver/libvirt_driver_libxl.so #9 0xb6bce870 in virDomainCreateXML () from /local/scratch/ianc/tmp/usr/local/lib/libvirt.so.0 #10 0xb6f254a6 in remoteDispatchDomainCreateXML () #11 0xb6f253d6 in remoteDispatchDomainCreateXMLHelper () #12 0xb6f69732 in virNetServerProgramDispatchCall () #13 0xb6f6937e in virNetServerProgramDispatch () #14 0xb6f6353c in virNetServerProcessMsg () #15 0xb6f635f4 in virNetServerHandleJob () #16 0xb6b1d878 in virThreadPoolWorker () from /local/scratch/ianc/tmp/usr/local/lib/libvirt.so.0 #17 0xb6b1cd56 in virThreadHelper () from /local/scratch/ianc/tmp/usr/local/lib/libvirt.so.0 #18 0xb6a10ebc in start_thread (arg=0xb4ea63e0) at pthread_create.c:306 #19 0xb69b8cc8 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:116 from /lib/arm-linux-gnueabihf/libc.so.6 #20 0xb69b8cc8 in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:116 from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 19/19] Debian: Arrange to be able to chainload a xen.efi from grub2
Xen cannot (currently) be booted directly via the usual multiboot
path on EFI systems of any arch. Instead it is necessary to either
launch xen.efi direct from the UEFI shell or to chainload it from
grub. In both cases the Xen command line as well as what would
normally be the multiboot modules (kernel+command line, XSM policy,
initrd) must be configured in a Xen configuration file.
By patching overlay/etc/grub.d/20_linux_xen that if a suitable xen.efi
is found in the EFI System Partition (as arrange by a previous patch)
a suitable entry is created in grub.cfg as well.
When parsing the grub.cfg look for such an entry into addition to the
regular/multiboot one and when necessary write the configuration file
based on the regular entry and return the chainload one such that it
gets booted.
This is currently enabled only for Jessie ARM64 systems.
Note that the 20_linux_xen change here is a bit specific to us and not
really generic enough to go upstream IMHO, hence I haven't.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
Osstest/Debian.pm | 75 +++--
overlay/etc/grub.d/20_linux_xen | 19 +++
2 files changed, 92 insertions(+), 2 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index d342103..c89a362 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -400,12 +400,18 @@ sub setupboot_grub2 () {
my $rmenu= '/boot/grub/grub.cfg';
my $kernkey= (defined $xenhopt ? 'KernDom0' : 'KernOnly');
-
+
+# Grub2 on Jessie/arm* doesn't do multiboot, so we must chainload.
+my $need_uefi_chainload =
+get_host_property($ho, firmware) eq uefi
+$ho-{Suite} =~ m/jessie/ $r{arch} =~ m/^arm/;
+
my $parsemenu= sub {
my $f= bl_getmenu_open($ho, $rmenu, $stash/$ho-{Name}--grub.cfg.1);
my @offsets = (0);
my $entry;
+my $chainentry;
my $submenu;
while ($f) {
next if m/^\s*\#/ || !m/\S/;
@@ -424,7 +430,13 @@ sub setupboot_grub2 () {
(defined $xenhopt
? qw(Title Hv KernDom0 KernVer)
: qw(Title Hv KernOnly KernVer));
- if (@missing) {
+ if ($need_uefi_chainload $entry-{Chainload}) {
+ # Needs to be before check of @missing, since a
+ # chained entry doesn't have anything useful in it
+ logm(Found chainload entry at $entry-{StartLine}..$.);
+ die already got one if $chainentry;
+ $chainentry = $entry;
+ } elsif (@missing) {
logm((skipping entry at $entry-{StartLine}..$.;.
no @missing));
} elsif ($entry-{Hv} =~ m/xen-syms/) {
@@ -456,9 +468,15 @@ sub setupboot_grub2 () {
$submenu={ StartLine =$., MenuEntryPath = join , @offsets
};
push @offsets,(0);
}
+if (m/^\s*chainloader\s*\/EFI\/osstest\/xen.efi/) {
+die unless $entry;
+$entry-{Hv}= $1;
+$entry-{Chainload} = 1;
+}
if (m/^\s*multiboot\s*(?:\/boot)?\/(xen\S+)/) {
die unless $entry;
$entry-{Hv}= $1;
+$entry-{Chainload} = 0;
}
if (m/^\s*multiboot\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))\s+(.*)/) {
die unless $entry;
@@ -490,13 +508,66 @@ sub setupboot_grub2 () {
die unless $entry-{Hv};
}
+ if ($need_uefi_chainload) {
+ die 'chainload entry not found' unless $chainentry;
+
+# Propagate relevant fields of the main entry over to the
+# chain entry for use of subsequent code.
+foreach (qw(KernVer KernDom0 KernOnly KernOpts Initrd Xenpolicy)) {
+ next unless $entry-{$_};
+ die if $chainentry-{$_};
+ $chainentry-{$_} = $entry-{$_};
+}
+
+$entry = $chainentry;
+ }
+
return $entry;
};
$bl-{UpdateConfig}= sub {
my ( $ho ) = @_;
+
+target_editfile_root($ho, '/etc/default/grub', sub {
+while (::EI) {
+next if m/^export GRUB_ENABLE_XEN_UEFI_CHAINLOAD\=/;
+print ::EO;
+}
+ print ::EO export GRUB_ENABLE_XEN_UEFI_CHAINLOAD=\osstest\\n
+ if $need_uefi_chainload;
+ });
+
target_cmd_root($ho, update-grub);
+
+ if ($need_uefi_chainload) {
+ my $entry= $parsemenu-();
+ my $xencfg = END;
+[global]
+default=osstest
+
+[osstest]
+options=$xenhopt
+kernel=vmlinuz $entry-{KernOpts}
+END
+$xencfg .= ramdisk=initrd.gz\n if $entry-{Initrd};
+$xencfg .= xsm=xenpolicy\n if $entry-{Xenpolicy};
+
+
target_putfilecontents_root_stash($ho,30,$xencfg,/boot/efi/EFI/osstest/xen.cfg);
+
+
[Xen-devel] [PATCH OSSTEST v2 06/19] ts-host-install: Support UEFI PXE boot using grub.efi
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
Osstest/TestSupport.pm | 37 -
README | 1 +
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 622f44d..1164a11 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -898,7 +898,7 @@ sub selecthost ($) {
$ho-{Tftp} = { };
$ho-{Tftp}{$_} = $c{Tftp${_}_${tftpscope}} || $c{Tftp${_}}
foreach qw(Path TmpDir PxeDir PxeGroup PxeTemplates PxeTemplatesReal
- DiBase);
+ DiBase GrubBase);
#- finalise -
@@ -2138,6 +2138,41 @@ END
sub setup_uboot_pxeboot ($;%) { return setup_bios_pxeboot; }
sub setup_uboot_pxeboot_local ($) { return setup_bios_pxeboot_local; }
+sub setup_grub_efi_bootcfg ($$) {
+my ($ho, $bootfile) = @_;
+my $f = grub.cfg-$ho-{Ether};
+my $grub=
$ho-{Tftp}{Path}.'/'.$ho-{Tftp}{GrubBase}.'/'.$c{TftpGrubVersion}.
+ /pxegrub-$r{arch}.efi;
+my $pxe=$ho-{Tftp}{Path}.'/'.$ho-{Name}.'/pxe.img';
+
+logm(Copy $grub = $pxe);
+copy($grub, $pxe) or die Copy $grub to $pxe failed: $!;
+
+logm(grub_efi bootcfg into $f);
+file_link_contents($ho-{Tftp}{Path}$ho-{Tftp}{TmpDir}$f, $bootfile,
+ $ho-{Name}-pxegrub.cfg);
+}
+
+# UEFI systems PXE boot using grub.efi
+sub setup_uefi_pxeboot ($;%) {
+my ($ho,$kern,$initrd,$dicmd,$hocmd,%xopts) = @_;
+setup_grub_efi_bootcfg($ho, END);
+set default=0
+set timeout=5
+menuentry 'overwrite' {
+ linux $kern $dicmd -- $hocmd
+ initrd $initrd
+}
+END
+}
+
+sub setup_uefi_pxeboot_local ($) {
+my ($ho) = @_;
+setup_grub_efi_bootcfg($ho, END);
+echo Should do a local boot here, somehow
+END
+}
+
sub setup_pxeboot_local ($) {
my ($ho) = @_;
my $firmware = get_host_property($ho, firmware, bios);
diff --git a/README b/README
index 503d15d..1351f49 100644
--- a/README
+++ b/README
@@ -455,6 +455,7 @@ TftpFoo_scope and TftpFoo
DiBaseThe path under `Path' to the root of the debian installer
images.
+GrubBase The path under `Path' to the root of the grub EFI PXE
images.
For hosts in scope default, TftpFoo_default (if set) takes
precedence over TftpFoo. TftpFoo is used when the setting Foo is
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 04/19] ts-host-install: split the di from the host command line
(i.e. the bit before/after the -- marker). When abstracting over
different bootloaders in a future patch this will be convenient since
it allows the code to add to either.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
ts-host-install | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/ts-host-install b/ts-host-install
index 04f065f..57a6b3f 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -175,8 +175,8 @@ sub setup_pxeboot_firstboot($) {
my $d_i=
$ho-{Tftp}{DiBase}.'/'.$r{arch}.'/'.$c{TftpDiVersion}.'-'.$ho-{Suite};
-my @installcmdline= qw(vga=normal);
-push @installcmdline, di_installcmdline_core($ho, $ps_url, %xopts);
+my @dicmdline= qw(vga=normal);
+push @dicmdline, di_installcmdline_core($ho, $ps_url, %xopts);
my $src_initrd= $d_i/initrd.gz;
my @initrds= $ho-{Tftp}{Path}/$src_initrd;
@@ -265,26 +265,27 @@ END
my $initrd= $ho-{Tftp}{TmpDir}$ho-{Name}--initrd.gz;
system_checked(cat -- @initrds $ho-{Tftp}{Path}$initrd);
-push @installcmdline, domain=$c{TestHostDomain};
-push @installcmdline,
+push @dicmdline, domain=$c{TestHostDomain};
+push @dicmdline,
get_host_property($ho, install-append $ho-{Suite}, ''),
get_host_property($ho, install-append $ho-{Suite} $r{arch}, '');
my $console = get_host_native_linux_console($ho);
-push @installcmdline, console=$console unless $console eq NONE;
+push @dicmdline, console=$console unless $console eq NONE;
-push @installcmdline, qw(--);
+my @hocmdline;
# See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762007 for
# why this is repeated.
-push @installcmdline, console=$console unless $console eq NONE;
+push @hocmdline, console=$console unless $console eq NONE;
-push @installcmdline,
+push @hocmdline,
get_host_property($ho, linux-boot-append $ho-{Suite}, ''),
get_host_property($ho, linux-boot-append $ho-{Suite} $r{arch}, '');
-my $installcmdline= join ' ', @installcmdline;
+my $dicmd= join ' ', @dicmdline;
+my $hocmd= join ' ', @hocmdline;
setup_pxeboot($ho, END);
serial 0 $c{Baud}
@@ -293,7 +294,7 @@ label overwrite
menu label ^Overwrite
menu default
kernel $kernel
- append initrd=/$initrd $installcmdline
+ append initrd=/$initrd $dicmd -- $hocmd
ipappend $ipappend
$dtbs
default overwrite
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v3 12/11] toolstack/libvirt: install libnl-3-200 on Jessie
Signed-off-by: Wei Liu wei.l...@citrix.com
---
An additional patch to deal with new package name in libvirt toolstack code.
---
Osstest/Toolstack/libvirt.pm | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Osstest/Toolstack/libvirt.pm b/Osstest/Toolstack/libvirt.pm
index e7f4860..c71f88a 100644
--- a/Osstest/Toolstack/libvirt.pm
+++ b/Osstest/Toolstack/libvirt.pm
@@ -24,11 +24,15 @@ use Osstest::TestSupport;
sub new {
my ($class, $ho, $methname,$asset) = @_;
+my @extra_packages = qw(libavahi-client3);
+my $nl_lib = libnl-3-200;
+$nl_lib = libnl1 if ($ho-{Suite} =~ m/wheezy/);
+push(@extra_packages, $nl_lib);
return bless { Name = libvirt,
Host = $ho,
NewDaemons = [qw(libvirtd)],
Dom0MemFixed = 1,
- ExtraPackages = [qw(libnl1 libavahi-client3)],
+ ExtraPackages = [@extra_packages],
}, $class;
}
--
1.9.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/2] Add xen-hyp-rw
On 18/06/15 16:55, Don Slutz wrote: This allows reading and writing of variables in the hypervisor. for example (read case -- default 4 bytes): xen-hyp-rw /boot/System.map-xen* opt_hvm_debug_level opt_hvm_debug_level @ 0x82d080285610 is 0x0(0) Write case: xen-hyp-rw /boot/System.map-xen* opt_hvm_debug_level 4 -1 opt_hvm_debug_level @ 0x82d080285610 is 0x0(0) opt_hvm_debug_level @ 0x82d080285610 set to 0x(4294967295) Signed-off-by: Don Slutz dsl...@verizon.com CC: Don Slutz don.sl...@gmail.com As a crazy thought... Would it not be easier to modify gdbsx to allow gdb to connect remotely to the hypervisor context? That way, any gdb-like tools could consume an appropriate xen-syms and make changes like this. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] libxc: delete sent_last_iter
It's set in code but never used. Detected by -Wunused-but-set-variable. Signed-off-by: Wei Liu wei.l...@citrix.com --- tools/libxc/xc_domain_save.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c index 301e770..3222473 100644 --- a/tools/libxc/xc_domain_save.c +++ b/tools/libxc/xc_domain_save.c @@ -811,7 +811,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter int live = (flags XCFLAGS_LIVE); int debug = (flags XCFLAGS_DEBUG); int superpages = !!hvm; -int race = 0, sent_last_iter, skip_this_iter = 0; +int race = 0, skip_this_iter = 0; unsigned int sent_this_iter = 0; int tmem_saved = 0; @@ -1014,9 +1014,6 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter last_iter = !live; -/* pretend we sent all the pages last iteration */ -sent_last_iter = dinfo-p2m_size; - /* Setup to_send / to_fix and to_skip bitmaps */ to_send = xc_hypercall_buffer_alloc_pages(xch, to_send, NRPAGES(bitmap_size(dinfo-p2m_size))); to_skip = xc_hypercall_buffer_alloc_pages(xch, to_skip, NRPAGES(bitmap_size(dinfo-p2m_size))); @@ -1586,8 +1583,6 @@ int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t max_iter goto out; } -sent_last_iter = sent_this_iter; - print_stats(xch, dom, sent_this_iter, time_stats, shadow_stats, 1); } -- 1.9.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv4 0/4] evtchn: Improve scalebility
The per-domain event channel lock limits scalability when many VCPUs are trying to send interdomain events. A per-channel lock is introduced eliminating any lock contention when sending an event. See this graph for the performance improvements: http://xenbits.xen.org/people/dvrabel/evtchn-scalability.png A different test (using Linux's evtchn device which masks/unmasks event channels) showed the following lock profile improvements: Per-domain lock: (XEN) lock:69267976(0004:19830041), block: 2407(0002:3C7C5C96) Per-event channel lock (XEN) lock: 686530(:076AF5F6), block: 1787(:000B4D22) Locking removed from evtchn_unmask(): (XEN) lock: 10769(:00512999), block: 99(:9491) v4: - consumer_is_xen() check in __evtchn_close() is only valid when guest requested the close. - Re-add BUG_ON(!port_is_valid()) to free_xen_event_channel(). v3: - Clear xen_consumer when clearing state. - Defer freeing struct evtchn's until evtchn_destroy_final(). - Remove redundant d-evtchn test from port_is_valid(). - Use port_is_valid() again. - Drop event lock from notify_via_xen_event_channel(). v2: - Use unsigned int for d-valid_evtchns. - Compare channel pointers in double_evtchn_lock(). David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv4 2/4] evtchn: defer freeing struct evtchn's until evtchn_destroy_final()
notify_via_xen_event_channel() and free_xen_event_channel() had to
check if the domain was dying because they may be called while the
domain is being destroyed and the struct evtchn's are being freed.
By deferring the freeing of the struct evtchn's until all references
to the domain are dropped, these functions can rely on the channel
state being present and valid.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
v4:
- Re-add BUG_ON(!port_is_valid()).
---
xen/common/event_channel.c | 46
1 file changed, 12 insertions(+), 34 deletions(-)
diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c
index 26870b6..4ee65e6 100644
--- a/xen/common/event_channel.c
+++ b/xen/common/event_channel.c
@@ -1173,21 +1173,7 @@ int alloc_unbound_xen_event_channel(
void free_xen_event_channel(struct domain *d, int port)
{
-struct evtchn *chn;
-
-spin_lock(d-event_lock);
-
-if ( unlikely(d-is_dying) )
-{
-spin_unlock(d-event_lock);
-return;
-}
-
BUG_ON(!port_is_valid(d, port));
-chn = evtchn_from_port(d, port);
-BUG_ON(!consumer_is_xen(chn));
-
-spin_unlock(d-event_lock);
(void)__evtchn_close(d, port, 0);
}
@@ -1200,18 +1186,12 @@ void notify_via_xen_event_channel(struct domain *ld,
int lport)
spin_lock(ld-event_lock);
-if ( unlikely(ld-is_dying) )
-{
-spin_unlock(ld-event_lock);
-return;
-}
-
ASSERT(port_is_valid(ld, lport));
lchn = evtchn_from_port(ld, lport);
-ASSERT(consumer_is_xen(lchn));
if ( likely(lchn-state == ECS_INTERDOMAIN) )
{
+ASSERT(consumer_is_xen(lchn));
rd= lchn-u.interdomain.remote_dom;
rchn = evtchn_from_port(rd, lchn-u.interdomain.remote_port);
evtchn_port_set_pending(rd, rchn-notify_vcpu_id, rchn);
@@ -1278,7 +1258,7 @@ int evtchn_init(struct domain *d)
void evtchn_destroy(struct domain *d)
{
-unsigned int i, j;
+unsigned int i;
/* After this barrier no new event-channel allocations can occur. */
BUG_ON(!d-is_dying);
@@ -1288,8 +1268,17 @@ void evtchn_destroy(struct domain *d)
for ( i = 0; port_is_valid(d, i); i++ )
(void)__evtchn_close(d, i, 0);
+clear_global_virq_handlers(d);
+
+evtchn_fifo_destroy(d);
+}
+
+
+void evtchn_destroy_final(struct domain *d)
+{
+unsigned int i, j;
+
/* Free all event-channel buckets. */
-spin_lock(d-event_lock);
for ( i = 0; i NR_EVTCHN_GROUPS; i++ )
{
if ( !d-evtchn_group[i] )
@@ -1297,20 +1286,9 @@ void evtchn_destroy(struct domain *d)
for ( j = 0; j BUCKETS_PER_GROUP; j++ )
free_evtchn_bucket(d, d-evtchn_group[i][j]);
xfree(d-evtchn_group[i]);
-d-evtchn_group[i] = NULL;
}
free_evtchn_bucket(d, d-evtchn);
-d-evtchn = NULL;
-spin_unlock(d-event_lock);
-
-clear_global_virq_handlers(d);
-evtchn_fifo_destroy(d);
-}
-
-
-void evtchn_destroy_final(struct domain *d)
-{
#if MAX_VIRT_CPUS BITS_PER_LONG
xfree(d-poll_mask);
d-poll_mask = NULL;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCHv4 4/4] evtchn: pad struct evtchn to 64 bytes
The number of struct evtchn in a page must be a power of two. Under some workloads performance is improved slightly by padding struct evtchn to 64 bytes (a typical cache line size), thus putting the fewer per-channel locks into each cache line. This does not decrease the number of struct evtchn's per-page. Signed-off-by: David Vrabel david.vra...@citrix.com Acked-by: Jan Beulich jbeul...@suse.com --- v2: - Use __attribute__((aligned(64))) for the padding. --- xen/include/xen/sched.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 44ea92d..a0ff9d2 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -129,7 +129,7 @@ struct evtchn #endif } ssid; #endif -}; +} __attribute__((aligned(64))); int evtchn_init(struct domain *d); /* from domain_create */ void evtchn_destroy(struct domain *d); /* from domain_kill */ -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Dom0 kernel panic when porting xen to new arm soc
On Thu, 2015-06-18 at 22:09 +0800, Peng Fan wrote: Hi, I am porting xen to an Cortex-A7 soc and met Dom0 kernel panic. I have no clear idea about why Dom0 kernel panic. Have you confirmed that this same kernel runs reliably natively on this platform? [...] / # Unable to handle kernel NULL pointer dereference at virtual address pgd = 84f1c000 [] *pgd=8cf15831, *pte=, *ppte= Internal error: Oops: 8007 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 89 Comm: sh Not tainted 3.14.28-01780-g281e5c1-dirty #269 task: 84c07a80 ti: 84f02000 task.ti: 84f02000 PC is at 0x0 LR is at call_timer_fn.isra.33+0x24/0x88 pc : []lr : [80038b38]psr: 2113 Your kernel has jumped to address 0x0 for some reason. You should use gdb or something to examine you vmlinux file and try and figure out what LR is doing, which may give you a hint as to why it is apparently jumping to address zero. (XEN) Latest ChangeSet: Mon Jun 15 18:25:34 2015 +0800 git:c01e139-dirty What changes have you made to your version of Xen? c01e139 is not an upstream commit. I am not sure whether this realted to timer, the timer dts: I think it looks like a software timer thing in the kernel rather than a h/w timer thing. The Dom0 kernel is also configured with CONFIG_ARM_ARCH_TIMER=y, will this incur errors? Or should Dom0 kernel not use arm arch timer? Guests on Xen (including dom0) _should_ be using the arch timer. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 14/19] Debian: grub2: Log full line range of menuentry and submenu entries
Is useful when debugging.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
Osstest/Debian.pm | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index c6687db..d2a7be9 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -412,8 +412,7 @@ sub setupboot_grub2 () {
if (m/^\s*\}\s*$/) {
die unless $entry || $submenu;
if (!defined $entry defined $submenu) {
-logm(Met end of a submenu starting from .
-$submenu-{StartLine}. .
+logm(Met end of a submenu $submenu-{StartLine}..$.. .
Our want kern is $want_kernver);
$submenu=undef;
pop @offsets;
@@ -426,14 +425,14 @@ sub setupboot_grub2 () {
? qw(Title Hv KernDom0 KernVer)
: qw(Title Hv KernOnly KernVer));
if (@missing) {
- logm((skipping entry at $entry-{StartLine};.
+ logm((skipping entry at $entry-{StartLine}..$.;.
no @missing));
} elsif (defined $want_kernver
$entry-{KernVer} ne $want_kernver) {
- logm((skipping entry at $entry-{StartLine};.
+ logm((skipping entry at $entry-{StartLine}..$.;.
kernel $entry-{KernVer}, not $want_kernver));
} elsif ($want_xsm !defined $entry-{Xenpolicy}) {
- logm((skipping entry at $entry-{StartLine};.
+ logm((skipping entry at $entry-{StartLine}..$.;.
XSM policy file not present));
} else {
# yes!
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 02/19] Debian: Preseed a EFI system partition during host install
AIUI the runes used will only result in an ESP if the system was
booted via UEFI. IOW I don't think there should be any change for
existing systems.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
Osstest.pm| 1 +
Osstest/Debian.pm | 6 ++
2 files changed, 7 insertions(+)
diff --git a/Osstest.pm b/Osstest.pm
index e668b3c..172f904 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -67,6 +67,7 @@ our %c = qw(
TestHostKeypairPath id_rsa_osstest
HostProp_GenEtherPrefixBase 5e:36:0e:f5
+HostDiskESP300
HostDiskBoot 300
HostDiskRoot 1
HostDiskSwap 2000
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 929d22e..ded8575 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -987,6 +987,12 @@ d-i partman-basicmethods/method_only boolean false
d-i partman-auto/expert_recipe string \\
boot-root ::\\
+ $c{HostDiskESP} 60 $c{HostDiskESP} free \\
+ \$iflabel{ gpt }\\
+ reusemethod{ } \\
+ method{ efi } \\
+ format{ } \\
+ . \\
$c{HostDiskBoot} 50 $c{HostDiskBoot} ext3 \\
\$primary{ } \$bootable{ } \\
method{ format } format{ } \\
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH 2/2] Add xen-hyp-rw
This allows reading and writing of variables in the hypervisor.
for example (read case -- default 4 bytes):
xen-hyp-rw /boot/System.map-xen* opt_hvm_debug_level
opt_hvm_debug_level @ 0x82d080285610 is 0x0(0)
Write case:
xen-hyp-rw /boot/System.map-xen* opt_hvm_debug_level 4 -1
opt_hvm_debug_level @ 0x82d080285610 is 0x0(0)
opt_hvm_debug_level @ 0x82d080285610 set to 0x(4294967295)
Signed-off-by: Don Slutz dsl...@verizon.com
CC: Don Slutz don.sl...@gmail.com
---
.gitignore | 1 +
tools/debugger/gdbsx/Makefile | 7 +-
tools/debugger/gdbsx/xen-hyp-rw.c | 209
tools/debugger/gdbsx/xg/xg_main.c | 28 +
tools/debugger/gdbsx/xg/xg_public.h | 2 +
5 files changed, 246 insertions(+), 1 deletion(-)
create mode 100644 tools/debugger/gdbsx/xen-hyp-rw.c
diff --git a/.gitignore b/.gitignore
index 3f42ded..73dce09 100644
--- a/.gitignore
+++ b/.gitignore
@@ -104,6 +104,7 @@ tools/debugger/gdb/gdb-6.2.1-linux-i386-xen/*
tools/debugger/gdb/gdb-6.2.1/*
tools/debugger/gdb/gdb-6.2.1.tar.bz2
tools/debugger/gdbsx/gdbsx
+tools/debugger/gdbsx/xen-hyp-rw
tools/debugger/xenitp/xenitp
tools/firmware/*/biossums
tools/firmware/*.bin
diff --git a/tools/debugger/gdbsx/Makefile b/tools/debugger/gdbsx/Makefile
index 4ed6d76..6a8c4ac 100644
--- a/tools/debugger/gdbsx/Makefile
+++ b/tools/debugger/gdbsx/Makefile
@@ -6,10 +6,11 @@ all:
$(MAKE) -C gx
$(MAKE) -C xg
$(MAKE) gdbsx
+ $(MAKE) xen-hyp-rw
.PHONY: clean
clean:
- rm -f xg_all.a gx_all.a gdbsx
+ rm -f xg_all.a gx_all.a gdbsx xen-hyp-rw
set -e; for d in xg gx; do $(MAKE) -C $$d clean; done
.PHONY: distclean
@@ -20,10 +21,14 @@ distclean: clean
install: all
[ -d $(DESTDIR)$(sbindir) ] || $(INSTALL_DIR) $(DESTDIR)$(sbindir)
$(INSTALL_PROG) gdbsx $(DESTDIR)$(sbindir)/gdbsx
+ $(INSTALL_PROG) xen-hyp-rw $(DESTDIR)$(sbindir)/xen-hyp-rw
gdbsx: gx/gx_all.a xg/xg_all.a
$(CC) -o $@ $^
+xen-hyp-rw: xen-hyp-rw.c gx/gx_all.a xg/xg_all.a
+ $(CC) $(CFLAGS) $(CFLAGS_xeninclude) -o $@ $^
+
xg/xg_all.a:
$(MAKE) -C xg
gx/gx_all.a:
diff --git a/tools/debugger/gdbsx/xen-hyp-rw.c
b/tools/debugger/gdbsx/xen-hyp-rw.c
new file mode 100644
index 000..ee10fe9
--- /dev/null
+++ b/tools/debugger/gdbsx/xen-hyp-rw.c
@@ -0,0 +1,209 @@
+/**
+ * tools/debugger/gdbsx/xen-hyp-rw.c
+ *
+ * read and write hypervisor memory.
+ *
+ * Copyright (C) 2014 by Verizon.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include stdio.h
+#include stdint.h
+#include stdlib.h
+#include unistd.h
+#include string.h
+#include errno.h
+#include assert.h
+#include signal.h
+#include ctype.h
+
+#include xen/xen.h
+
+typedef unsigned char uchar;
+typedef long long unsigned int u64;
+
+#include xg/xg_public.h
+
+void gxprt(const char *fmt, ...);
+
+static u64 read_symbol_table(const char *symtab, const char *who)
+{
+u64 ret = 0;
+char type, line[256];
+char *p;
+FILE *f;
+u64 address;
+
+f = fopen(symtab, r);
+if ( f == NULL )
+{
+fprintf(stderr, failed to open symbol table %s\n, symtab);
+exit(-1);
+}
+
+while ( !feof(f) )
+{
+if ( fgets(line, 256, f) == NULL )
+break;
+
+/* need more checks for syntax here... */
+address = strtoull(line, p, 16);
+if ( !isspace((uint8_t)*p++) )
+continue;
+type = *p++;
+if ( !isalpha((uint8_t)type) type != '?' )
+continue;
+if ( !isspace((uint8_t)*p++) )
+continue;
+
+/* in the future we should handle the module name
+ * being appended here, this would allow us to use
+ * /proc/kallsyms as our symbol table
+ */
+if ( p[strlen(p) - 1] == '\n' )
+p[strlen(p) - 1] = '\0';
+
+switch ( type )
+{
+case 'A': /* global absolute */
+case 'a': /* local absolute */
+break;
+case 'U': /* undefined */
+case 'v': /* undefined weak object */
+case 'w': /* undefined weak function */
+continue;
+default:
+break;
+}
+
+if ( strcmp(p, who) == 0 )
+ret = address;
+}
[Xen-devel] [PATCH 1/2] gdbsx_guestmemio: Allow it to check domain.
gdbsx_guest_mem_io() does not get d passed, it expects to handle the domain lookup itself. Signed-off-by: Don Slutz dsl...@verizon.com CC: Don Slutz don.sl...@gmail.com --- xen/common/domctl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/common/domctl.c b/xen/common/domctl.c index ce517a7..2a2d203 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -443,6 +443,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) case XEN_DOMCTL_createdomain: case XEN_DOMCTL_getdomaininfo: case XEN_DOMCTL_test_assign_device: +case XEN_DOMCTL_gdbsx_guestmemio: d = NULL; break; default: -- 1.8.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] 4.5 qemu tree tagging
Jan Beulich writes (4.5 qemu tree tagging): could you please tag the respective qemu trees for 4.5.1? Considering the little (if any at all) testing feedback we've been getting on stable RCs, and considering how late we are with it, I actually see no point in doing another RC, so unless one of you heavily objects I'd like the tags to be done for the actual release. Tagged. Will you be wanting me to make the release tarballs etc. ? Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt test] 58119: regressions - FAIL
On Mon, 2015-06-15 at 15:30 +0100, Anthony PERARD wrote: The No response from client ... appear only on armhf as far as I can tell. Indeed, and I just noticed while developing osstest for arm64 that the daemon is segfaulting, and we even managed to collect a core dump, not this time but in: http://logs.test-lab.xenproject.org/osstest/logs/58693/test-armhf-armhf-libvirt/info.html Although the core and the build stuff is all there it was a bit easier to just install gdb on the arm64 system in my hands, it reports: Program terminated with signal SIGSEGV, Segmentation fault. #0 malloc_consolidate (av=av@entry=0x7fa020) at malloc.c:4151 4151malloc.c: No such file or directory. (gdb) bt #0 malloc_consolidate (av=av@entry=0x7fa020) at malloc.c:4151 #1 0x007faf2adc50 in _int_malloc (av=av@entry=0x7fa020, bytes=bytes@entry=1100) at malloc.c:3423 #2 0x007faf2afc20 in __GI___libc_malloc (bytes=bytes@entry=1100) at malloc.c:2891 #3 0x007faf2b0580 in __GI___libc_realloc (oldmem=0x0, bytes=1100) at malloc.c:2972 #4 0x007faf434d98 in virReallocN () from /usr/local/lib/libvirt.so.0 #5 0x007faf438f34 in virBufferGrow () from /usr/local/lib/libvirt.so.0 #6 0x007faf4397b8 in virBufferVasprintf () from /usr/local/lib/libvirt.so.0 #7 0x007faf439700 in virBufferAsprintf () from /usr/local/lib/libvirt.so.0 #8 0x007faf51b7f0 in virDomainObjFormat () from /usr/local/lib/libvirt.so.0 #9 0x007faf51c078 in virDomainSaveStatus () from /usr/local/lib/libvirt.so.0 #10 0x007fac510d88 in libxlDomainStart () from /usr/local/lib/libvirt/connection-driver/libvirt_driver_libxl.so #11 0x007fac5136c4 in libxlDomainCreateXML () from /usr/local/lib/libvirt/connection-driver/libvirt_driver_libxl.so #12 0x007faf5977c0 in virDomainCreateXML () from /usr/local/lib/libvirt.so.0 #13 0x0055887730c8 in remoteDispatchDomainCreateXML () #14 0x005588772fb8 in remoteDispatchDomainCreateXMLHelper () #15 0x0055887cb694 in virNetServerProgramDispatchCall () #16 0x0055887cb220 in virNetServerProgramDispatch () #17 0x0055887c2810 in virNetServerProcessMsg () #18 0x0055887c2910 in virNetServerHandleJob () #19 0x007faf4ba738 in virThreadPoolWorker () from /usr/local/lib/libvirt.so.0 #20 0x007faf4b989c in virThreadHelper () from /usr/local/lib/libvirt.so.0 #21 0x007faf388e34 in start_thread (arg=0x7fae6540c0) at pthread_create.c:311 #22 0x007faf2ff7c0 in clone () at ../ports/sysdeps/unix/sysv/linux/aarch64/nptl/../clone.S:96 Maybe that means something to someone, if not I'll try and make time to look at it. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 15/19] Debian: grub2: Use GRUB_CMDLINE_LINUX_XEN_REPLACE(_DEFAULT)
This overrides GRUB_CMDLINE_LINUX(_DEFAULT) which we were previously
editing but only for the Xen entries, meaning that we don't switch to
console=hvc0 for the native cases (i.e. don't break them).
We do however want to edit GRUB_CMDLINE_LINUX(_DEFAULT) to remove
quiet if present, since it is useful to people, especially those
using standalone mode as a provisioning tool, wanting to e.g. compare
a boot under Xen with the native case.
This has been supported since Wheezy but in any case we supply our own
20_linux_xen grub generator based on Wheezy which supports this.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
Osstest/Debian.pm | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index d2a7be9..31aa1e6 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -507,7 +507,7 @@ sub setupboot_grub2 () {
$v =~ s/^\s*([\'\])(.*)\1\s*$/$2/;
$k{$k}= $v;
}
-next if m/^GRUB_CMDLINE_(?:XEN|LINUX).*\=|^GRUB_DEFAULT.*\=/;
+next if
m/^GRUB_CMDLINE_(?:XEN|LINUX(?:_XEN_REPLACE)?(?:_DEFAULT)?).*\=|^GRUB_DEFAULT.*\=/;
print ::EO;
}
print ::EO END or die $!;
@@ -521,11 +521,20 @@ GRUB_CMDLINE_XEN=$xenhopt
END
foreach my $k (qw(GRUB_CMDLINE_LINUX GRUB_CMDLINE_LINUX_DEFAULT)) {
my $v= $k{$k};
+
+# Tailor native case
$v =~ s/\bquiet\b//;
+print ::EO $k=\$v\\n or die $!;
+
+# Xen overrides
$v =~ s/\b(?:console|xencons)=[0-9A-Za-z,]+//;
$v .= $xenkopt if $k eq 'GRUB_CMDLINE_LINUX';
-print ::EO $k=\$v\\n or die $!;
-}
+# Ensure variable isn't zero length, or 20_linux_xen will
ignore it.
+$v .= ;
+my $rk = $k;
+$rk =~ s/LINUX/LINUX_XEN_REPLACE/;
+print ::EO $rk=\$v\\n or die $!;
+ }
});
};
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 12/19] ts-kernel-build: Support --reuse to keep same build tree
This is very useful when iterating over kernel configurations, since
it avoids blowing away the build tree and all the existing built
objects. The Linux build system does the right thing when .config
changes and only rebuilds the affected bits.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
ts-kernel-build | 14 ++
1 file changed, 14 insertions(+)
diff --git a/ts-kernel-build b/ts-kernel-build
index 4014a6c..55c8acf 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -22,6 +22,18 @@ use Osstest::TestSupport;
use Osstest::BuildSupport;
tsreadconfig();
+
+our $reuse = 0;
+while (@ARGV and $ARGV[0] =~ m/^-/) {
+$_= shift @ARGV;
+last if m/^--$/;
+if (m/^--reuse$/) {
+ $reuse = 1;
+} else {
+ die $_ ?;
+}
+}
+
selectbuildhost(\@ARGV);
builddirsprops();
@@ -35,6 +47,8 @@ my $archparms = {
sub enable_xen_config ();
sub checkout () {
+return if $reuse;
+
prepbuilddirs();
build_clone($ho, 'linux', $builddir, 'linux');
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 05/19] Refactor pxelinux configuration
The mechanism used to PXE boot can differ depending on the firmware
type. Therefore refactor into Osstest::TestSupport and key off a new
host property firmware.
Currently supported is bios (the default) and uboot, both of which
use pxelinux.cfg style files.
The default for the firmware property is bios, hence no change for
any existing system (including those which use uboot, regardless of
whether they are now configured with the firmware proprty or not)
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
Osstest/TestSupport.pm | 44 +---
ts-host-install| 19 +--
2 files changed, 46 insertions(+), 17 deletions(-)
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 66a0d81..622f44d 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -2098,16 +2098,34 @@ sub host_pxefile ($;$) {
(join ,, sort keys %v). ?;
}
-sub setup_pxeboot ($$) {
+sub setup_pxelinux_bootcfg ($$) {
my ($ho, $bootfile) = @_;
my $f= host_pxefile($ho);
file_link_contents($ho-{Tftp}{Path}$ho-{Tftp}{PxeDir}$f, $bootfile,
$ho-{Name}-pxelinux.cfg);
}
-sub setup_pxeboot_local ($) {
+# Systems using BIOS are configured to use pxelinux
+sub setup_bios_pxeboot ($;%) {
+my ($ho,$kern,$initrd,$dicmd,$hocmd,%xopts) = @_;
+my $dtbs = fdtdir $xopts{dtbs} if $xopts{dtbs};
+setup_pxelinux_bootcfg($ho, END);
+serial 0 $c{Baud}
+timeout 5
+label overwrite
+ menu label ^Overwrite
+ menu default
+ kernel $kern
+ append $dicmd initrd=$initrd -- $hocmd
+ ipappend $xopts{ipappend}
+ $dtbs
+default overwrite
+END
+}
+
+sub setup_bios_pxeboot_local ($) {
my ($ho) = @_;
-setup_pxeboot($ho, END);
+setup_pxelinux_bootcfg($ho, END);
serial 0 $c{Baud}
timeout 5
label local
@@ -2116,6 +2134,26 @@ default local
END
}
+# uboot emulates pxelinux, so reuse BIOS stuff
+sub setup_uboot_pxeboot ($;%) { return setup_bios_pxeboot; }
+sub setup_uboot_pxeboot_local ($) { return setup_bios_pxeboot_local; }
+
+sub setup_pxeboot_local ($) {
+my ($ho) = @_;
+my $firmware = get_host_property($ho, firmware, bios);
+$firmware =~ s/-/_/g;
+no strict qw(refs);
+return {setup_${firmware}_pxeboot_local}($ho);
+}
+
+sub setup_pxeboot ($;%) {
+my ($ho,$kern,$initrd,$dicmd,$hocmd,%xopts) = @_;
+my $firmware = get_host_property($ho, firmware, bios);
+$firmware =~ s/-/_/g;
+no strict qw(refs);
+return
{setup_${firmware}_pxeboot}($ho,$kern,$initrd,$dicmd,$hocmd,%xopts);
+}
+
#-- ISO images --
sub iso_create_genisoimage (;@) {
my ($ho,$iso,$dir,$isotimeout,@xopts) = @_;
diff --git a/ts-host-install b/ts-host-install
index 57a6b3f..4e60e6e 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -244,13 +244,14 @@ SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==$ho-{Ether}, A
END
}
-my $dtbs = ;
+my %xopts;
+
foreach my $kp (keys %{ $ho-{Flags} }) {
# Backwards compatibility
$kp = need-kernel-deb-wheezy-backports if $kp eq
need-kernel-deb-armmp;
$kp =~ s/need-kernel-deb-$ho-{Suite}-// or next;
- $dtbs = fdtdir /$d_i/$kp-dtbs
+ $xopts{dtbs} = /$d_i/$kp-dtbs
if -e $ho-{Tftp}{Path}/$d_i/$kp-dtbs;
}
@@ -287,18 +288,8 @@ END
my $dicmd= join ' ', @dicmdline;
my $hocmd= join ' ', @hocmdline;
-setup_pxeboot($ho, END);
-serial 0 $c{Baud}
-timeout 5
-label overwrite
- menu label ^Overwrite
- menu default
- kernel $kernel
- append initrd=/$initrd $dicmd -- $hocmd
- ipappend $ipappend
- $dtbs
-default overwrite
-END
+$xopts{ipappend} = $ipappend;
+setup_pxeboot($ho, $kernel, /$initrd, $dicmd, $hocmd, %xopts);
}
install();
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 13/19] standalone: Prefer ./standalone.config to $HOME/.xen-osstest/config
OSSTEST_CONFIG still trumps both.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
standalone | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/standalone b/standalone
index 17fa40c..ad12bad 100755
--- a/standalone
+++ b/standalone
@@ -68,7 +68,13 @@ TEMP=$(getopt -o c:f:h:rRs --long
config:,flight:,host:,reuse,noreuse,reinstall,
eval set -- $TEMP
-config=${OSSTEST_CONFIG-$HOME/.xen-osstest/config}
+if [ -n ${OSSTEST_CONFIG} ]; then
+config=${OSSTEST_CONFIG}
+elif [ -f standalone.config ]; then
+config=standalone.config
+else
+config=$HOME/.xen-osstest/config
+fi
flight=standalone
host=
reuse=1 # Don't blow away machines by default
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 08/19] Add arm64 build and test jobs
Runvars: build-arm64 arch arm64 build-arm64 build_lvextend_max 50 build-arm64 enable_ovmf true build-arm64 enable_xend false build-arm64 enable_xsm false build-arm64 host_hostflags share-build-jessie-arm64,arch-arm64,suite-jessie,purpose-build build-arm64 revision_ovmf build-arm64 revision_qemu build-arm64 revision_qemuu b2da824bc5ad35fb9f1e74a203d7be96a7b0345e build-arm64 revision_seabios build-arm64 revision_xen e13013dbf1d5997915548a3b5f1c39594d8c1d7b build-arm64 tree_ovmf build-arm64 tree_qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git build-arm64 tree_qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git build-arm64 tree_seabios build-arm64 tree_xen git://xenbits.xen.org/xen.git build-arm64-libvirt arch arm64 build-arm64-libvirt build_lvextend_max 50 build-arm64-libvirt buildjob build-arm64 build-arm64-libvirt host_hostflags share-build-jessie-arm64,arch-arm64,suite-jessie,purpose-build build-arm64-libvirt revision_libvirt fd74e231751334b64af0934b680c5cc62f652453 build-arm64-libvirt tree_libvirt git://xenbits.xen.org/libvirt.git build-arm64-libvirt tree_xen git://xenbits.xen.org/xen.git build-arm64-pvops arch arm64 build-arm64-pvops build_lvextend_max 50 build-arm64-pvops host_hostflags share-build-jessie-arm64,arch-arm64,suite-jessie,purpose-build build-arm64-pvops kconfig_override_y CONFIG_EXT4_FS build-arm64-pvops kconfighow xen-enable-xen-config build-arm64-pvops revision_linux ec18c9fc039971041d854e0d58551f1f1a32ff8f build-arm64-pvops revision_linuxfirmware c530a75c1e6a472b0eb9558310b518f0dfcd8860 build-arm64-pvops tree_linux git://xenbits.xen.org/linux-pvops.git build-arm64-pvops tree_linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git build-arm64-pvops treevcs_linux git build-arm64-xsm arch arm64 build-arm64-xsm build_lvextend_max 50 build-arm64-xsm enable_ovmf true build-arm64-xsm enable_xend false build-arm64-xsm enable_xsm true build-arm64-xsm host_hostflags share-build-jessie-arm64,arch-arm64,suite-jessie,purpose-build build-arm64-xsm revision_ovmf build-arm64-xsm revision_qemu build-arm64-xsm revision_qemuu b2da824bc5ad35fb9f1e74a203d7be96a7b0345e build-arm64-xsm revision_seabios build-arm64-xsm revision_xen e13013dbf1d5997915548a3b5f1c39594d8c1d7b build-arm64-xsm tree_ovmf build-arm64-xsm tree_qemu git://xenbits.xen.org/staging/qemu-xen-unstable.git build-arm64-xsm tree_qemuu git://xenbits.xen.org/staging/qemu-upstream-unstable.git build-arm64-xsm tree_seabios build-arm64-xsm tree_xen
[Xen-devel] [PATCH OSSTEST v2 00/19] Initial support for ARM64
The following makes a start on support for arm64 systems. Since arm64 was only added in Debian Jessie this requires Wei's Debian Jessie patches as a base line, I'm using v3 of those (note that these have picked up some of the patches which I previously included in this series, since they belong there more). The main development here is support for UEFI PXE booting, which is not particular to arm64, but is more prominent there. Hopefully this work would be useful for UEFI only x86 systems too. Since last time the Debian kernel has been updated and now reboots, so build-* works. I've also added support for test-*. This mainly involved plumbing in UEFI chainloading into the grub handling, which is was bit fiddly but worked out ok in the end, I think. test-arm64-arm64-xl works ok. test-arm64-arm64-libvirt needs a hack to work on Jessie (differingly library name) for which I don't yet have a clean solution. And then libvirtd SEGVs, like it seems to on armhf at the moment too. 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 OSSTEST v2 17/19] Debian: Ignore xen-syms entries in grub.cfg.
These can't (in general?) actually be booted.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
Osstest/Debian.pm | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 31aa1e6..8f4c4ea 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -427,6 +427,9 @@ sub setupboot_grub2 () {
if (@missing) {
logm((skipping entry at $entry-{StartLine}..$.;.
no @missing));
+ } elsif ($entry-{Hv} =~ m/xen-syms/) {
+ logm((skipping entry at $entry-{StartLine}..$.;.
+ is xen-syms));
} elsif (defined $want_kernver
$entry-{KernVer} ne $want_kernver) {
logm((skipping entry at $entry-{StartLine}..$.;.
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 07/19] Enable chain loading to local disk for UEFI PXE systems.
First arrange for bootloader to be installed to removable media path,
by using a new in Jessie preseed option. Then use that to chainload a
bootloader from the disk.
The removable media path is well known (part of the UEFI spec) which
saves us having to worry about which OS is on the host (so long as the
OS can be configured to populate the removable media path)
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
Osstest/Debian.pm | 2 ++
Osstest/TestSupport.pm | 18 +-
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index ded8575..9e1e69e 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -757,6 +757,8 @@ d-i apt-setup/contrib boolean false
d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool,
chiark-utils-bin, $extra_packages
+d-i grub-installer/force-efi-extra-removable boolean true
+
$xopts{ExtraPreseed}
END
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index 1164a11..5eeb907 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -2168,8 +2168,24 @@ END
sub setup_uefi_pxeboot_local ($) {
my ($ho) = @_;
+my %efi_archs = qw(amd64 X64
+ arm32 ARM
+ arm64 AARCH64
+ i386 IA32);
+die EFI arch unless $efi_archs{ $r{arch} };
+my $efi = $efi_archs{ $r{arch} };
setup_grub_efi_bootcfg($ho, END);
-echo Should do a local boot here, somehow
+set default=0
+set timeout=5
+menuentry 'local' {
+ insmod chain
+ insmod part_gpt
+ insmod part_msdos
+ set root=(hd0,gpt1)
+ echo Chainloading (\${root})/EFI/BOOT/BOOTAA64.EFI
+ chainloader (\${root})/EFI/BOOT/BOOTAA64.EFI
+ boot
+}
END
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 10/19] ts-host-install: Set dtbs in the non-special kernel case too.
XXX fold somewhere?
---
ts-host-install | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ts-host-install b/ts-host-install
index 4e60e6e..6b18800 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -255,6 +255,9 @@ END
if -e $ho-{Tftp}{Path}/$d_i/$kp-dtbs;
}
+$xopts{dtbs} = /$d_i/dtbs
+ if !$xopts{dtbs} -e $ho-{Tftp}{Path}/$d_i/dtbs;
+
file_simple_write_contents($initrd_overlay.cpio, sub {
contents_make_cpio($_[0], 'newc', $initrd_overlay.d);
});
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot order during install
Debian inserts itself before any existing entries, including the PXE
one, meaning we otherwise cannot remotely regroove the box. Preseed
some commands to reset the boot order to BootCurrent i.e. how we
booted (so the PXE entry).
There is still a window between the Debian entry being added (by
grub-installer.udeb) and us removing it, a failure (e.g. power cycle)
in that interval would require manual action to fixup.
This is triggered by a new quirk-uefi-bootorder-reset how flag.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
This seems to just be normal/expected behaviour for UEFI installs (not
just of Debian), so perhaps the quirk is unneeded.
---
Osstest/Debian.pm | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 9e1e69e..c6687db 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -1018,6 +1018,21 @@ END
preseed_microcode($ho,$sfx);
+if (get_host_property($ho, firmware) eq uefi
+$ho-{Flags}{'quirk-uefi-bootorder-reset'}) {
+ # Disable any new Debian boot entry, so we reboot from PXE.
+preseed_hook_command($ho, 'late_command', $sfx, 'END');
+#!/bin/sh
+set -ex
+
+entry=`in-target --pass-stdout bash -c 'efibootmgr -v | sed -ne
s/BootCurrent: \([0-9]\+\)/\1/p'` #/
+in-target efibootmgr -o $entry
+
+#in-target bash -c 'efibootmgr -o `efibootmgr -v | sed -ne s/BootCurrent:
\([0-9]\+\)/\1/p`' #/
+
+END
+}
+
$preseed_file .= preseed_hook_cmds();
if ($ho-{Flags}{'no-di-kernel'}) {
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 09/19] ts-kernel-build: Additional kernel options for Mustang
XXX We probably need a newer kernel to actually be useful.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
ts-kernel-build | 12
1 file changed, 12 insertions(+)
diff --git a/ts-kernel-build b/ts-kernel-build
index 47ddf6f..4014a6c 100755
--- a/ts-kernel-build
+++ b/ts-kernel-build
@@ -526,6 +526,18 @@ setopt CONFIG_FUSION_LOGGING n
setopt CONFIG_BLK_CPQ_CISS_DA m
+setopt CONFIG_FHANDLE y
+
+# APM XGENE
+setopt CONFIG_PHY_XGENE y
+#setopt CONFIG_NET_XGENE y
+setopt CONFIG_AHCI_XGENE y
+setopt CONFIG_POWER_RESET_XGENE y
+setopt CONFIG_RTC_DRV_XGENE y
+
+#arm64 crashes without -- determine why
+setopt CONFIG_SPARSEMEM_VMEMMAP y
+
case ${XEN_TARGET_ARCH} in
x86_32) setopt CONFIG_64BIT n ;;
x86_64)
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 16/19] Collect xen.efi into xendist and install in appropriate place
Previously these binaries would have been included in the regular
(tools) dist file, whereas they really belong in the xen one.
Install into /boot/efi/EFI/osstest ready for use when chainloading.
Note that /boot/efi is (or should be) a VFAT filesystem. So a bit of
care is needed WRT symlinks etc. This is also what prevents us from
just including /boot/efi/EFI/osstest/xen.efi in the dist tarball since
untarring over a VFAT needs a little care WRT the case of directories
etc.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
ts-xen-build | 7 +++
ts-xen-install | 7 +++
2 files changed, 14 insertions(+)
diff --git a/ts-xen-build b/ts-xen-build
index 353a82c..cebfaf3 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -172,6 +172,13 @@ sub divide () {
mv \$mvfiles xeninstall/boot/.
fi
fi
+ if test -d install/usr/lib64/efi/; then
+if test -f install/usr/lib64/efi/xen.efi; then
+mkdir -p xeninstall/usr/lib64/efi
+mvfiles=`find install/usr/lib64/efi -name 'xen[a-z]*' -prune
-o -name 'xen*' -print`
+mv \$mvfiles xeninstall/usr/lib64/efi/.
+fi
+ fi
END
}
diff --git a/ts-xen-install b/ts-xen-install
index d55401c..83fa143 100755
--- a/ts-xen-install
+++ b/ts-xen-install
@@ -74,6 +74,13 @@ sub extract () {
target_extract_jobdistpath($ho, $part, path_${part}dist,
$r{${part}buildjob}, \%distpath);
}
+if (target_file_exists($ho, /usr/lib64/efi/xen.efi)) {
+ target_cmd_root($ho,END);
+ mkdir -p /boot/efi/EFI/osstest
+ # /boot/efi is VFAT, so dereference the symlink
+ cp -vL /usr/lib64/efi/xen.efi /boot/efi/EFI/osstest
+END
+}
target_cmd_root($ho, '/sbin/ldconfig');
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v2 01/19] Introduce mg-pxe-loader-update
The story for PXE booting via UEFI (at least on arm64) is not so
straightforward as with pxelinux on x86. There seems to no good
bootloader to launch via UEFI+pxe, in fact all I could find was grub
(syslinux, and by extension pxelinux.efi, is x86 only).
Add mg-pxe-loader-update modelled on mg-debian-installer-update which
will download the necessary grub binaries and produce a grub image
which can be used to pxe boot.
grub lacks the convenient ability to search for config file based on
(substrings of) the MAC or IP address. So we arrange for the grub.cfg
in TftpGrubBase to chain load another config file from
TftpTmpDir/'$net_default_mac' where $net_default_mac is a grub
variable which is substituted at boot time.
Actually using this requires that bootp/dhcp provide a next-file so
UEFI knows what to boot (usually this would be pxelinux.0 which we
can't use here). Locally we have configured this as $name/pxe.img, so
we can use different loaders.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
Osstest.pm | 3 ++
README | 4 ++-
mg-pxe-loader-update | 89
production-config| 5 +++
4 files changed, 100 insertions(+), 1 deletion(-)
create mode 100755 mg-pxe-loader-update
diff --git a/Osstest.pm b/Osstest.pm
index e8bd77b..e668b3c 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -199,6 +199,9 @@ sub readglobalconfig () {
$c{TftpDiBase} ||= $c{TftpPlayDir}debian-installer;
$c{TftpDiVersion} ||= 'current';
+$c{TftpGrubBase} ||= $c{TftpPlayDir}grub;
+$c{TftpGrubVersion} ||= 'current';
+
$c{WebspaceFile} ||= $ENV{'HOME'}/public_html/;
$c{WebspaceUrl} ||= http://$myfqdn/~$whoami/;;
$c{WebspaceCommon} ||= 'osstest/';
diff --git a/README b/README
index 44e2989..503d15d 100644
--- a/README
+++ b/README
@@ -206,7 +206,9 @@ To run osstest in standalone mode:
netcat
chiark-utils-bin
- - Optional: ipmitool
+ - Optional:
+ ipmitool -- for hosts which use IPMI for power control
+ grub-common -- for mg-pxe-loader-update
- Write a config file
~/.xen-osstest/config
diff --git a/mg-pxe-loader-update b/mg-pxe-loader-update
new file mode 100755
index 000..b336fdb
--- /dev/null
+++ b/mg-pxe-loader-update
@@ -0,0 +1,89 @@
+#!/bin/bash
+# usage
+# ./mg-pxe-loader-update jessie
+#
+# Requires grub-mkimage (Debian package: grub-common)
+
+# This is part of osstest, an automated testing framework for Xen.
+# Copyright (C) 2015 Citrix Inc.
+#
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU Affero General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU Affero General Public License for more details.
+#
+# You should have received a copy of the GNU Affero General Public License
+# along with this program. If not, see http://www.gnu.org/licenses/.
+
+
+set -e
+
+. cri-getconfig
+
+suite=$1
+
+fail () { echo 2 $0: $1; exit 1; }
+
+site=http://ftp.debian.org/debian/
+sbase=$site/dists/$suite
+
+archs=amd64 i386 arm64
+
+dstroot=`getconfig TftpPath`/`getconfig TftpGrubBase`/
+date=`date +%Y-%m-%d`
+dst=$date
+
+grubpfx=`getconfig TftpGrubBase`/$date/grub
+grubcfg=`getconfig TftpTmpDir`/grub.cfg-'$net_default_mac'
+
+mkdir -p $dstroot
+cd $dstroot
+mkdir -p $dst
+cd $dst
+rm -rf grub
+mkdir grub
+
+cat grub/grub.cfg EOF
+set stage1=yes
+configfile $grubcfg
+EOF
+for arch in $archs ; do
+case $arch in
+ amd64) grubdeb=grub-efi-amd64-bin; platform=x86_64-efi;;
+ i386) grubdeb=grub-efi-ia32-bin; platform=i386-efi;;
+ arm64) grubdeb=grub-efi-arm64-bin; platform=arm64-efi;;
+ *) echo No grub on $arch 2; exit 0;;
+esac
+
+pfile=$sbase/main/binary-$arch/Packages.gz
+
+curl -s $pfile Packages.gz
+
+echo 2 collecting $grubdeb
+pkgfile=`zcat Packages.gz | grep-dctrl -PX $grubdeb -nsFilename | sort -n
-r | head -n1`
+rc=$?
+set -e
+if [ $rc -ne 0 ] || [ x$pkgfile = x ]; then fail $grubdeb package not
found; fi
+curl -s $site/$pkgfile $grubdeb.deb
+
+dpkg-deb -x $grubdeb.deb x
+
+mv x/usr/lib/grub/* grub/
+
+rm -rf x
+
+rm Packages.gz
+
+grub-mkimage -O $platform \
+-d ./grub/$platform \
+-o pxegrub-$arch.efi -p $grubpfx \
+search configfile normal efinet tftp net
+done
+
+echo $date
+echo 2 downloaded $dstroot/$date
diff --git a/production-config b/production-config
index 47c0c4c..46fedc9 100644
--- a/production-config
+++ b/production-config
@@ -85,12 +85,17 @@ TftpPxeTemplates %name%/pxelinux.cfg
TftpPxeTemplatesReal pxelinux.cfg/%ipaddrhex%
TftpPxeGroup osstest
+# Update with
[Xen-devel] [PATCH OSSTEST v2 03/19] ts-host-install: Split initrd out of @installcmdline
Other bootloaders handle this with an explicit separate option rather
than parsing it out of the command line as pxelinux does. Prepare for
supporting these.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
ts-host-install | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/ts-host-install b/ts-host-install
index 04d5487..04f065f 100755
--- a/ts-host-install
+++ b/ts-host-install
@@ -265,9 +265,7 @@ END
my $initrd= $ho-{Tftp}{TmpDir}$ho-{Name}--initrd.gz;
system_checked(cat -- @initrds $ho-{Tftp}{Path}$initrd);
-push @installcmdline, (initrd=/$initrd,
- domain=$c{TestHostDomain},
- );
+push @installcmdline, domain=$c{TestHostDomain};
push @installcmdline,
get_host_property($ho, install-append $ho-{Suite}, ''),
get_host_property($ho, install-append $ho-{Suite} $r{arch}, '');
@@ -295,7 +293,7 @@ label overwrite
menu label ^Overwrite
menu default
kernel $kernel
- append $installcmdline
+ append initrd=/$initrd $installcmdline
ipappend $ipappend
$dtbs
default overwrite
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 58716: regressions - FAIL
flight 58716 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/58716/ 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. 58663 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 58693 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 58618 test-amd64-i386-libvirt-xsm 11 guest-start fail like 58663 test-amd64-i386-libvirt 11 guest-start fail like 58663 test-amd64-amd64-libvirt-xsm 11 guest-start fail like 58663 test-amd64-amd64-libvirt 11 guest-start fail like 58663 test-armhf-armhf-libvirt-xsm 11 guest-start fail like 58663 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 58663 test-armhf-armhf-libvirt 11 guest-start fail like 58663 Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen c6ef839d84726cf420a0381174f0f8ffac6ffd84 baseline version: xen fcbfaf9d260adbdb9352d6300b9f63c4ed443d49 People who touched revisions under test: David Scott dave.sc...@citrix.com Ian Campbell ian.campb...@citrix.com Roger Pau Monne roger@citrix.com Roger Pau Monné roger@citrix.com Ross Lagerwall ross.lagerw...@citrix.com Wei Liu wei.l...@citrix.com jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-oldkern pass build-i386-oldkern pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsmpass test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm fail test-amd64-amd64-libvirt-xsm fail test-armhf-armhf-libvirt-xsm fail test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm pass test-armhf-armhf-xl-xsm pass test-amd64-i386-xl-xsm pass test-amd64-amd64-xl-pvh-amd fail test-amd64-i386-qemut-rhel6hvm-amd
[Xen-devel] [PATCH OSSTEST v2 18/19] Debian: Collect kernel command line from grub.cfg
I'm going to want it in a subsequent patch
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
Osstest/Debian.pm | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 8f4c4ea..d342103 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -460,15 +460,17 @@ sub setupboot_grub2 () {
die unless $entry;
$entry-{Hv}= $1;
}
-if (m/^\s*multiboot\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))/) {
+if (m/^\s*multiboot\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))\s+(.*)/) {
die unless $entry;
$entry-{KernOnly}= $1;
$entry-{KernVer}= $2;
+$entry-{KernOpts}= $3;
}
-if (m/^\s*module\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))/) {
+if (m/^\s*module\s*(?:\/boot)?\/(vmlinu[xz]-(\S+))\s+(.*)/) {
die unless $entry;
$entry-{KernDom0}= $1;
$entry-{KernVer}= $2;
+$entry-{KernOpts}= $3;
}
if (m/^\s*module\s*(?:\/boot)?\/(initrd\S+)/) {
$entry-{Initrd}= $1;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [RFC 22/23] xen/privcmd: Add support for Linux 64KB page granularity
Hi David,
On 19/05/15 16:39, David Vrabel wrote:
On 14/05/15 18:01, Julien Grall wrote:
The hypercall interface (as well as the toolstack) is always using 4KB
page granularity. When the toolstack is asking for mapping a series of
guest PFN in a batch, it expects to have the page map contiguously in
its virtual memory.
When Linux is using 64KB page granularity, the privcmd driver will have
to map multiple Xen PFN in a single Linux page.
Note that this solution works on page granularity which is a multiple of
4KB.
[...]
--- a/drivers/xen/xlate_mmu.c
+++ b/drivers/xen/xlate_mmu.c
@@ -63,6 +63,7 @@ static int map_foreign_page(unsigned long lpfn, unsigned
long fgmfn,
struct remap_data {
xen_pfn_t *fgmfn; /* foreign domain's gmfn */
+xen_pfn_t *egmfn; /* end foreign domain's gmfn */
I don't know what you mean by end foreign domain.
I meant the last gmfn to map. This is because the Linux page may not be
fully mapped.
pgprot_t prot;
domid_t domid;
struct vm_area_struct *vma;
@@ -78,17 +79,23 @@ static int remap_pte_fn(pte_t *ptep, pgtable_t token,
unsigned long addr,
{
struct remap_data *info = data;
struct page *page = info-pages[info-index++];
-unsigned long pfn = page_to_pfn(page);
-pte_t pte = pte_mkspecial(pfn_pte(pfn, info-prot));
+unsigned long pfn = xen_page_to_pfn(page);
+pte_t pte = pte_mkspecial(pfn_pte(page_to_pfn(page), info-prot));
int rc;
-
-rc = map_foreign_page(pfn, *info-fgmfn, info-domid);
-*info-err_ptr++ = rc;
-if (!rc) {
-set_pte_at(info-vma-vm_mm, addr, ptep, pte);
-info-mapped++;
+uint32_t i;
+
+for (i = 0; i XEN_PFN_PER_PAGE; i++) {
+if (info-fgmfn == info-egmfn)
+break;
+
+rc = map_foreign_page(pfn++, *info-fgmfn, info-domid);
+*info-err_ptr++ = rc;
+if (!rc) {
+set_pte_at(info-vma-vm_mm, addr, ptep, pte);
+info-mapped++;
+}
+info-fgmfn++;
This doesn't make any sense to me. Don't you need to gather the foreign
GFNs into batches of PAGE_SIZE / XEN_PAGE_SIZE and map these all at once
into a 64 KiB page? I don't see how you can have a set_pte_at() for
each foreign GFN.
I will see to rework this code. I've noticed few others error in the
privcmd code too.
Regards,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested test job
-Original Message-
From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
Sent: Friday, June 12, 2015 11:27 PM
To: Pang, LongtaoX
Cc: xen-devel@lists.xen.org; ian.campb...@citrix.com; wei.l...@citrix.com; Hu,
Robert
Subject: RE: [OSSTEST Nested PATCH v11 6/7] Compose the main recipe of nested
test job
Pang, LongtaoX writes (RE: [OSSTEST Nested PATCH v11 6/7] Compose the main
recipe of nested test job):
From: Ian Jackson [mailto:ian.jack...@eu.citrix.com]
...
leak-check compares the set of objects present at the `leak-check
check' step with the set of objects present at the `basis' step, and
the check fails if there are any new objects. For this purpose,
objects includes domains, corefiles, etc.
OK, so the recipe in sg-run-job should be like below, please correct me if
something wrong.
proc need-hosts/test-nested {} {return host}
proc run-job/test-nested {} {
This is roughly right, but thinking about it, you want ts-logs-capture
to run even if the previous steps fail.
I think it might be better to reuse (subvert?) the existing machinery
in sg-run-job, by adding the l1 to need_xen_hosts.
Maybe something like
proc add-xen-host-retrospectively {ident} {
global need_xen_hosts
ts-leak-check $ident + basis
lappend need_xen_hosts $ident
}
?
And then call
add-xen-host-retrospectively l1
at the appropriate point.
If you do this then the main run-job proc will automatically do the
leak-check and the logs-capture for you.
I have tried your suggestion, call 'add-xen-host- retrospectively l1' just
after L1 has booted into XEN.
leak-check and logs-capture will be done automatically at final stage, but this
happened after L1 guest destroyed
and it will failed obviously(I have mentioned this in previous mail).
So, may I implement these action via below recipe in sg-run-job? Since, this
would be less code to
be changed and we want to avoid to involve tcl plumbing in sg-run-job. Also, I
think there is no harmful.
proc need-hosts/test-nested {} {return host}
proc run-job/test-nested {} {
run-ts . = ts-debian-hvm-install + host l1
run-ts . = ts-nested-setup + host l1
run-ts . = ts-xen-install l1
run-ts . = ts-host-reboot l1
run-ts . = ts-leak-check basis l1
run-ts . = ts-debian-hvm-install l1 l2
run-ts . = ts-guest-stop l1 l2
run-ts . = ts-leak-check check l1
run-ts . = ts-logs-capture l1
run-ts . = ts-guest-destroy + host l1
}
Thinking about this leads me to ask another question. Suppose that a
bug causes the l1 to lock up completely. ts-logs-capture will attempt
to hard reboot a locked-up host. If it can't fetch any logs, it calls
target_reboot_hard($ho);
What will that do if $ho refers to the l1 ? It relies on the power
method. Does your nested l1 host have a power method ?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.2-testing test] 58722: FAIL
flight 58722 xen-4.2-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/58722/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-libvirt 3 host-install(3) broken in 58584 REGR. vs. 58411 Tests which are failing intermittently (not blocking): test-i386-i386-libvirt3 host-install(3) broken in 58584 pass in 58722 test-amd64-i386-pair 4 host-install/dst_host(4) broken in 58584 pass in 58722 test-amd64-amd64-pair 3 host-install/src_host(3) broken in 58584 pass in 58722 test-amd64-i386-qemuu-freebsd10-amd64 3 host-install(3) broken in 58584 pass in 58722 test-amd64-i386-xl-win7-amd64 3 host-install(3) broken in 58584 pass in 58722 test-amd64-i386-xl-winxpsp3-vcpus1 3 host-install(3) broken in 58584 pass in 58722 test-amd64-amd64-xl-qemut-winxpsp3 3 host-install(3) broken in 58584 pass in 58722 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail in 58584 pass in 58722 test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail in 58584 pass in 58722 test-amd64-amd64-xl-win7-amd64 16 guest-stopfail pass in 58584 Regressions which are regarded as allowable (not blocking): test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 58411 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 58411 test-amd64-i386-xl-win7-amd64 16 guest-stop fail like 58411 Tests which did not succeed, but are not blocking: test-amd64-amd64-libvirt 1 build-check(1)blocked in 58584 n/a test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-i386-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass build-amd64-rumpuserxen 5 rumpuserxen-buildfail never pass build-i386-rumpuserxen5 rumpuserxen-buildfail never pass test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-i386-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xend-winxpsp3 20 leak-check/check fail never pass test-amd64-i386-xend-qemut-winxpsp3 20 leak-check/checkfail never pass version targeted for testing: xen 97134c441d6d81ba0d7cdcfdc4d8315115b99dce baseline version: xen 21a8344ca38a2797a13b4bf57031b6f49ae12ccb People who touched revisions under test: Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com Stefano Stabellini stefano.stabell...@eu.citrix.com jobs: build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-xl pass test-amd64-i386-xl pass test-i386-i386-xlpass 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-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-qemuu-freebsd10-amd64pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64
Re: [Xen-devel] [v3][PATCH 07/16] hvmloader/pci: skip reserved ranges
On 2015/6/18 16:05, Jan Beulich wrote: On 18.06.15 at 09:01, tiejun.c...@intel.com wrote: On 2015/6/18 14:29, Jan Beulich wrote: On 18.06.15 at 08:17, tiejun.c...@intel.com wrote: On 2015/6/17 17:24, Jan Beulich wrote: On 17.06.15 at 11:18, tiejun.c...@intel.com wrote: On 2015/6/17 17:02, Jan Beulich wrote: On 17.06.15 at 10:26, tiejun.c...@intel.com wrote: Something hits me to generate another idea, #1. Still allocate all devices as before. #2. Lookup all actual bars to check if they're conflicting RMRR We can skip these bars to keep zero. Then later it would make lookup easily. #3. Need to reallocate these conflicting bars. #3.1 Trying to reallocate them with the remaining resources #3.2 If the remaining resources aren't enough, we need to allocate them from high_mem_resource. That's possible onyl for 64-bit BARs. You're right so this means its not proper to adjust mmio_total to include conflicting reserved ranges and finally moved all conflicting bars to high_mem_resource as Kevin suggested previously, so i high level, we still need to decrease pci_mem_start to populate more RAM to compensate them as I did, right? You probably should do both: Prefer moving things beyond 4Gb, but if not possible increase the MMIO hole. I'm trying to figure out a better solution. Perhaps we can allocate 32-bit bars and 64-bit bars orderly. This may help us bypass those complicated corner cases. Dealing with 32- and 64-bit BARs separately won't help at all, as More precisely I'm saying to deal with them orderly. there may only be 32-bit ones, or the set of 32-bit ones may already require you to do re-arrangements. Plus, for compatibility Yes but I don't understand they are specific cases to my idea. Perhaps the problem is that you don't say what orderly is supposed to mean here? You're right. Here when separately vs orderly, I should definitely use orderly to make more understandable. reasons (just like physical machines' BIOSes do) avoiding to place MMIO above 4Gb where possible is still a goal. So are you sure you see my idea completely? I don't intend to expand pci memory above 4GB. Let me clear this simply, #1. I'm still trying to allocate all 32bit bars from [pci_mem_start,pci_mem_end] as before. #2. But [pci_mem_start,pci_mem_end] mightn't enough cover all 32bit-bars again because of RMRR, right? So I will populate RAM to push downward at cur_pci_mem_start ( = pci_mem_start - reserved device memory), then allocate the remaining 32bit-bars from [cur_pci_mem_start , pci_mem_start] #3. Then I'm still trying to allocate 64bit-bars from [pci_mem_start,pci_mem_end], unless its not enough. This is just going to follow the original. So anything is breaking that goal? Maybe not, from the above. And overall, its same as the original. If the model follows the original, what's the point of outlining supposed changes to the model? All I'm trying to understand is how Its not same completely, or let me change this statement, same - similar. you want to change the current code to accommodate the not aligned reserved memory regions. If everything is the same as before, this can't have been taken care of. If something is different from the original, that's what needs spelling out (and nothing else, as that would only clutter the picture). Doesn't look like the right approach to me. As said before, I think Could you see what I'm saying again? I just feel you don't understand what you mean. If you still think I'm wrong let me know. I think I understand what _I_ mean, but I'm indeed unsure I see what _you_ mean. Part of the problem is that you toggle between sending (incomplete) patches, code fragments, and discussing the approach verbally. I'd much prefer if either you started with a clear picture of what you intend to implement, or with an implementation that at least attempts to take care of all the corner cases (showing that you understand what the corner cases are, which so far I'm getting the - perhaps false - impression that you don't). Based on my previous recognition and our recent discussion, my current understanding can be summarized as follows; #1. Goal MMIO region should exclude all reserved device memory #2. Requirements #2.1 Still need to make sure MMIO region is fit all pci devices as before #2.2 Accommodate the not aligned reserved memory regions If I'm missing something let me know. #3. How to #3.1 Address #2.1 We need to either of populating more RAM, or of expanding more highmem. But we should know just 64bit-bar can work with highmem, and as you mentioned we also should avoid expanding highmem as possible. So my implementation is to allocate 32bit-bar and 64bit-bar orderly. 1. The first allocation round just to 32bit-bar If we can finish allocating all 32bit-bar, we just go to allocate 64bit-bar with all remaining resources including low pci memory. If not, we need to calculate how much RAM should be populated to allocate the
[Xen-devel] [ovmf test] 58723: tolerable FAIL - PUSHED
flight 58723 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/58723/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 58714
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 58714
version targeted for testing:
ovmf 6ef586442e03f183fb0e93177f32ad541119adb6
baseline version:
ovmf 35bc88dddc79103e6ab8d87932b4e877582a2bc5
People who touched revisions under test:
Ruiyu Ni ruiyu...@intel.com
Star Zeng star.z...@intel.com
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3pass
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=ovmf
+ revision=6ef586442e03f183fb0e93177f32ad541119adb6
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
6ef586442e03f183fb0e93177f32ad541119adb6
+ branch=ovmf
+ revision=6ef586442e03f183fb0e93177f32ad541119adb6
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{Repos} or die $!;
'
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case $branch in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ : tested/2.6.39.x
+ . ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{OsstestUpstream} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
Re: [Xen-devel] [v3][PATCH 03/16] xen/vtd: create RMRR mapping
On 2015/6/18 18:07, Tim Deegan wrote:
At 14:13 +0800 on 12 Jun (1434118407), Chen, Tiejun wrote:
could you explain why existing guest_physmap_remove_page can't
serve the purpose so you need invent a new identity mapping
specific one? For unmapping suppose it should be common regardless
of whether it's identity-mapped or not. :-)
I have some concerns here:
#1. guest_physmap_remove_page() is a void function without a returning
value, so you still need a little change.
I'd be happy with adding a return value to it -- even if other callers
don't check it yet it's better to have errors ignored by callers than
ignored inside the function. :)
#2. guest_physmap_remove_page() doesn't make readable in such a code
context;
rmrr_identity_mapping()
{
...
guest_physmap_remove_page()
...
}
I think it's fine there.
In general I'd prefer to avoid the code duplication of another helper
function if we can.
Fine to me.
Thanks
Tiejun
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/2] gdbsx_guestmemio: Allow it to check domain.
On 18/06/15 16:55, Don Slutz wrote: gdbsx_guest_mem_io() does not get d passed, it expects to handle the domain lookup itself. Signed-off-by: Don Slutz dsl...@verizon.com CC: Don Slutz don.sl...@gmail.com As for the change itself, Reviewed-by: Andrew Cooper andrew.coop...@citrix.com However, I think the commit message needs improving. Specifically, the caller of XEN_DOMCTL_gdbsx_guestmemio is expected to use DOMID_IDLE to interact with the hypervisor, rather than a domain, which doesn't interact well with with the domain rcu lock. --- xen/common/domctl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/xen/common/domctl.c b/xen/common/domctl.c index ce517a7..2a2d203 100644 --- a/xen/common/domctl.c +++ b/xen/common/domctl.c @@ -443,6 +443,7 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl) case XEN_DOMCTL_createdomain: case XEN_DOMCTL_getdomaininfo: case XEN_DOMCTL_test_assign_device: +case XEN_DOMCTL_gdbsx_guestmemio: d = NULL; break; default: ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 05/19] Refactor pxelinux configuration
Ian Campbell writes ([PATCH OSSTEST v2 05/19] Refactor pxelinux
configuration):
The mechanism used to PXE boot can differ depending on the firmware
type. Therefore refactor into Osstest::TestSupport and key off a new
host property firmware.
Currently supported is bios (the default) and uboot, both of which
use pxelinux.cfg style files.
The default for the firmware property is bios, hence no change for
any existing system (including those which use uboot, regardless of
whether they are now configured with the firmware proprty or not)
+return
{setup_${firmware}_pxeboot}($ho,$kern,$initrd,$dicmd,$hocmd,%xopts);
Are you expecting to introduce setup_FIRMWARE_SOMETHINGELSE ?
AFIACT not, in which case this name is quite confusing. Putting the
variable part at the end would be much clearer:
setup_pxeboot_${firmware}.
@@ -287,18 +288,8 @@ END
my $dicmd= join ' ', @dicmdline;
my $hocmd= join ' ', @hocmdline;
...
+$xopts{ipappend} = $ipappend;
+setup_pxeboot($ho, $kernel, /$initrd, $dicmd, $hocmd, %xopts);
Perhaps setup_pxeboot (which maybe should be renamed?) should do the
joining ? You could pass \@dicmdline and \@hocmdline.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 13/19] standalone: Prefer ./standalone.config to $HOME/.xen-osstest/config
Ian Campbell writes ([PATCH OSSTEST v2 13/19] standalone: Prefer ./standalone.config to $HOME/.xen-osstest/config): OSSTEST_CONFIG still trumps both. This results in us having standalone-config-example production-config production-config-cambridge but standalone.config is actually read by default. Perhaps the latter should be local-config ? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing test] 58717: regressions - trouble: broken/fail/pass
flight 58717 xen-4.5-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/58717/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail REGR. vs. 58528 test-amd64-i386-xl-qemuu-win7-amd64 14 guest-localmigrate.2 fail REGR. vs. 58528 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate/x10 fail REGR. vs. 58528 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 3 host-install(3) broken REGR. vs. 58528 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 58528 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail 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-xl 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-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass version targeted for testing: xen a24672752214b07661db594921ba70c0ee3066c5 baseline version: xen d963f64ba322731bc73d71adb589f361c1f8123c People who touched revisions under test: Alan Robinson alan.robin...@ts.fujitsu.com Andrew Cooper andrew.coop...@citrix.com Dario Faggioli dario.faggi...@citrix.com Dietmar Hahn dietmar.h...@ts.fujitsu.com Don Dugger donald.d.dug...@intel.com George Dunlap george.dun...@eu.citrix.com Ian Campbell ian.campb...@citrix.com Jan Beulich jbeul...@suse.com Kevin Tian kevin.t...@intel.com Konrad Rzeszutek Wilk konrad.w...@oracle.com Roger Pau Monné roger@citrix.com Ross Lagerwall ross.lagerw...@citrix.com jobs: 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 pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-pvh-amd fail 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-qemut-debianhvm-amd64 pass test-amd64-amd64-xl-qemuu-debianhvm-amd64pass test-amd64-i386-xl-qemuu-debianhvm-amd64 pass test-amd64-i386-freebsd10-amd64 pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass test-amd64-amd64-rumpuserxen-amd64 pass test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 fail test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-i386-xl-qemuu-win7-amd64 fail test-armhf-armhf-xl-arndale pass test-amd64-amd64-xl-credit2 pass test-armhf-armhf-xl-credit2 pass test-armhf-armhf-xl-cubietruck pass test-amd64-i386-freebsd10-i386 pass test-amd64-i386-rumpuserxen-i386 pass test-amd64-amd64-xl-pvh-intelfail test-amd64-i386-qemut-rhel6hvm-intel
Re: [Xen-devel] [PATCH] libxc: delete sent_last_iter
On 18/06/15 17:37, Wei Liu wrote: It's set in code but never used. Detected by -Wunused-but-set-variable. Signed-off-by: Wei Liu wei.l...@citrix.com Reviewed-by: Andrew Cooper andrew.coop...@citrix.com Having said this, I am about to archive this entire file in /dev/null when I respin the libxl migration v2 series. ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot order during install
Ian Campbell writes ([PATCH OSSTEST v2 11/19] Debian: Fixup UEFI boot order during install): Debian inserts itself before any existing entries, including the PXE one, meaning we otherwise cannot remotely regroove the box. Preseed some commands to reset the boot order to BootCurrent i.e. how we booted (so the PXE entry). There is still a window between the Debian entry being added (by grub-installer.udeb) and us removing it, a failure (e.g. power cycle) in that interval would require manual action to fixup. This seems a pretty serious bug. Is there a way to avoid it ? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 10/19] ts-host-install: Set dtbs in the non-special kernel case too.
Ian Campbell writes ([PATCH OSSTEST v2 10/19] ts-host-install: Set dtbs in the non-special kernel case too.): XXX fold somewhere? I don't mind it being in a patch by itself, but I do want a commit message that tells me why, not just what. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Newbie
On 06/18/2015 09:40 PM, Abhinav Gupta wrote: Hello Xen developers, I'm new here. I'm not able to find any link for bugs/issues or development environment setup for xen. Please can anyone help me with this. http://wiki.xenproject.org/wiki/Compiling_Xen_From_Source HTH, Razvan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Newbie
On 06/18/2015 09:46 PM, Abhinav Gupta wrote: Thanks for the reply Razvan, but I meant how will i test my code, when I make some changes ? I was answering what I thought was your question about not being able to find any link for [...] development environment setup. If you mean you'd like to know about the OSSTEST Xen test system, there's some information (and links) here: https://blog.xenproject.org/2013/02/02/xen-automatic-test-system-osstest/ but unfortunately I haven't used it yet so somebody more knowledgeable would need to step in if you need more information. Cheers, Razvan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 06/19] ts-host-install: Support UEFI PXE boot using grub.efi
Ian Campbell writes ([PATCH OSSTEST v2 06/19] ts-host-install: Support UEFI
PXE boot using grub.efi):
Signed-off-by: Ian Campbell ian.campb...@citrix.com
+sub setup_grub_efi_bootcfg ($$) {
+my ($ho, $bootfile) = @_;
+my $f = grub.cfg-$ho-{Ether};
+my $grub= $ho-{Tftp}{Path}.'/'.$ho-{Tftp}{GrubBase}.'/'.$c{Tftp\
GrubVersion}.
+ /pxegrub-$r{arch}.efi;
You've wrapped this but in the wrong place!
The README has a long line in it too. DiBase is already too long but
that is no excuse.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 12/19] ts-kernel-build: Support --reuse to keep same build tree
Ian Campbell writes ([PATCH OSSTEST v2 12/19] ts-kernel-build: Support --reuse to keep same build tree): This is very useful when iterating over kernel configurations, since it avoids blowing away the build tree and all the existing built objects. The Linux build system does the right thing when .config changes and only rebuilds the affected bits. Acked-by: Ian Jackson ian.jack...@eu.citrix.com This one should perhaps be considered for bundling into some other bunch of stuff, as AFAICT there is no reason for it to wait. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 19/19] Debian: Arrange to be able to chainload a xen.efi from grub2
Ian Campbell writes ([PATCH OSSTEST v2 19/19] Debian: Arrange to be able to
chainload a xen.efi from grub2):
Xen cannot (currently) be booted directly via the usual multiboot
path on EFI systems of any arch. Instead it is necessary to either
launch xen.efi direct from the UEFI shell or to chainload it from
grub. In both cases the Xen command line as well as what would
normally be the multiboot modules (kernel+command line, XSM policy,
initrd) must be configured in a Xen configuration file.
By patching overlay/etc/grub.d/20_linux_xen that if a suitable xen.efi
is found in the EFI System Partition (as arrange by a previous patch)
a suitable entry is created in grub.cfg as well.
Urgh. How horrible. I don't object to your patch, except that
there's some linewrap or reformatting needed.
+ if ($need_uefi_chainload) {
+ die 'chainload entry not found' unless $chainentry;
+
+# Propagate relevant fields of the main entry over to the
+# chain entry for use of subsequent code.
+foreach (qw(KernVer KernDom0 KernOnly KernOpts Initrd Xenp\
olicy)) {
Wrapping and indentation problems here ?
+target_cmd_root($ho,
+
END.($entry-{Initrd}?END:).($entry-{Xenpolicy}?END:));
+set -ex
+cp -vL /boot/$entry-{KernDom0} /boot/efi/EFI/osstest/vml\
inuz #/
It would IMO be better to align the shell at the lhs if there isn't
another way to avoid these overlong lines.
Thanks,
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 01/19] Introduce mg-pxe-loader-update
Ian Campbell writes ([PATCH OSSTEST v2 01/19] Introduce mg-pxe-loader-update): The story for PXE booting via UEFI (at least on arm64) is not so straightforward as with pxelinux on x86. There seems to no good bootloader to launch via UEFI+pxe, in fact all I could find was grub (syslinux, and by extension pxelinux.efi, is x86 only). Add mg-pxe-loader-update modelled on mg-debian-installer-update which will download the necessary grub binaries and produce a grub image which can be used to pxe boot. grub lacks the convenient ability to search for config file based on (substrings of) the MAC or IP address. So we arrange for the grub.cfg in TftpGrubBase to chain load another config file from TftpTmpDir/'$net_default_mac' where $net_default_mac is a grub variable which is substituted at boot time. Actually using this requires that bootp/dhcp provide a next-file so UEFI knows what to boot (usually this would be pxelinux.0 which we can't use here). Locally we have configured this as $name/pxe.img, so we can use different loaders. ... +curl -s $pfile Packages.gz + +echo 2 collecting $grubdeb +pkgfile=`zcat Packages.gz | grep-dctrl -PX $grubdeb -nsFilename | sort -n -r | head -n1` +rc=$? +set -e +if [ $rc -ne 0 ] || [ x$pkgfile = x ]; then fail $grubdeb package not found; fi +curl -s $site/$pkgfile $grubdeb.deb This is indeed _very_ similar to parts of mg-debian-installer-update. Perhaps some of this should be made common ? You may need to invent a new file. I notice that mg-debian-installer-update has `fetch' which uses a Pragma: to try to avoid proxies. Do we need the same here ? Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 09/19] ts-kernel-build: Additional kernel options for Mustang
Ian Campbell writes ([PATCH OSSTEST v2 09/19] ts-kernel-build: Additional kernel options for Mustang): XXX We probably need a newer kernel to actually be useful. This doesn't seem quite finished ? +setopt CONFIG_FHANDLE y What does this do and do we care about it on other platforms ? +# APM XGENE +setopt CONFIG_PHY_XGENE y +#setopt CONFIG_NET_XGENE y +setopt CONFIG_AHCI_XGENE y +setopt CONFIG_POWER_RESET_XGENE y +setopt CONFIG_RTC_DRV_XGENE y These are fine. +#arm64 crashes without -- determine why +setopt CONFIG_SPARSEMEM_VMEMMAP y Ummm. Thanks, Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 17/19] Debian: Ignore xen-syms entries in grub.cfg.
Ian Campbell writes ([PATCH OSSTEST v2 17/19] Debian: Ignore xen-syms entries in grub.cfg.): These can't (in general?) actually be booted. They can't be booted at all. That they are included in the menu is a bug in something. Acked-by: Ian Jackson ian.jack...@eu.citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 04/19] ts-host-install: split the di from the host command line
Ian Campbell writes ([PATCH OSSTEST v2 04/19] ts-host-install: split the di from the host command line): (i.e. the bit before/after the -- marker). When abstracting over different bootloaders in a future patch this will be convenient since it allows the code to add to either. Acked-by: Ian Jackson ian.jack...@eu.citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 03/19] ts-host-install: Split initrd out of @installcmdline
Ian Campbell writes ([PATCH OSSTEST v2 03/19] ts-host-install: Split initrd out of @installcmdline): Other bootloaders handle this with an explicit separate option rather than parsing it out of the command line as pxelinux does. Prepare for supporting these. Acked-by: Ian Jackson ian.jack...@eu.citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 07/19] Enable chain loading to local disk for UEFI PXE systems.
Ian Campbell writes ([PATCH OSSTEST v2 07/19] Enable chain loading to local disk for UEFI PXE systems.): First arrange for bootloader to be installed to removable media path, by using a new in Jessie preseed option. Then use that to chainload a bootloader from the disk. The `removable media path' is a UEFI path that refers to part of the fixed disk drive ? Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2 15/19] Debian: grub2: Use GRUB_CMDLINE_LINUX_XEN_REPLACE(_DEFAULT)
Ian Campbell writes ([PATCH OSSTEST v2 15/19] Debian: grub2: Use GRUB_CMDLINE_LINUX_XEN_REPLACE(_DEFAULT)): This overrides GRUB_CMDLINE_LINUX(_DEFAULT) which we were previously editing but only for the Xen entries, meaning that we don't switch to console=hvc0 for the native cases (i.e. don't break them). We do however want to edit GRUB_CMDLINE_LINUX(_DEFAULT) to remove quiet if present, since it is useful to people, especially those using standalone mode as a provisioning tool, wanting to e.g. compare a boot under Xen with the native case. This has been supported since Wheezy but in any case we supply our own 20_linux_xen grub generator based on Wheezy which supports this. Acked-by: Ian Jackson ian.jack...@eu.citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 01/44] kernel: Add support for poweroff handler call chain
On Thu, Jun 18, 2015 at 1:54 PM, Guenter Roeck li...@roeck-us.net wrote: On 06/17/2015 11:53 PM, Frans Klaver wrote: On Thu, Jun 18, 2015 at 3:04 AM, Stephen Boyd sb...@codeaurora.org wrote: On 10/06/2014 10:28 PM, Guenter Roeck wrote: Various drivers implement architecture and/or device specific means to remove power from the system. For the most part, those drivers set the global variable pm_power_off to point to a function within the driver. This mechanism has a number of drawbacks. Typically only one scheme to remove power is supported (at least if pm_power_off is used). At least in theory there can be multiple means remove power, some of which may be less desirable. For example, some mechanisms may only power off the CPU or the CPU card, while another may power off the entire system. Others may really just execute a restart sequence or drop into the ROM monitor. Using pm_power_off can also be racy if the function pointer is set from a driver built as module, as the driver may be in the process of being unloaded when pm_power_off is called. If there are multiple poweroff handlers in the system, removing a module with such a handler may inadvertently reset the pointer to pm_power_off to NULL, leaving the system with no means to remove power. Introduce a system poweroff handler call chain to solve the described problems. This call chain is expected to be executed from the architecture specific machine_power_off() function. Drivers providing system poweroff functionality are expected to register with this call chain. By using the priority field in the notifier block, callers can control poweroff handler execution sequence and thus ensure that the poweroff handler with the optimal capabilities to remove power for a given system is called first. What happened to this series? I want to add shutdown support to my platform and I need to write a register on the PMIC in one driver to configure it for shutdown instead of restart and then write an MMIO register to tell the PMIC to actually do the shutdown in another driver. It seems that the notifier solves this case for me, albeit with the slight complication that I need to order the two with some priority. I was wondering the same thing. I did find out that things kind of stalled after Linus cast doubt on the chosen path [1]. I'm not sure there's any consensus on what would be best to do instead. Linus cast doubt on it, then the maintainers started picking it apart. At the end, trying not to use notifier callbacks made the code so complicated that even I didn't understand it anymore. With no consensus in sight, I abandoned it. Problem is really that the notifier call chain would be perfect to solve the problem, yet Linus didn't like priorities (which are essential), and the power maintainers didn't like that a call chain is supposed to execute _all_ callbacks, which would not be the case here. If I were to start again, I would insist to use notifiers. However, I don't see a chance to get that accepted, so I won't. Feel free to pick it up and give it a try yourself. How about having two phases? One where all interested parts of the system get notified, one that does the final shutdown. It's a slightly different approach than you took, but does use the notifier chains as expected, and can be used to prepare peripherals for shutdown, if there's a use case for it. The two-stage approach does keep the single place to power down. I expect it would become more obvious that it would be silly to have more than one actual system power down sequence and hiding pm_power_off and unifying setting of it should become more straight forward as well. Thoughts? Thanks, Frans ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] Newbie
Hello Xen developers, I'm new here. I'm not able to find any link for bugs/issues or development environment setup for xen. Please can anyone help me with this. Thanks, Abhinav ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
