Re: [Xen-devel] [PATCH v2 for Xen 4.6 1/4] xen: enabling XL to set per-VCPU parameters of a domain for RTDS scheduler
On Mon, May 25, 2015 at 07:05:52PM -0500, Chong Li wrote:
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -841,6 +841,11 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
copyback = 1;
break;
+case XEN_DOMCTL_scheduler_vcpu_op:
+ret = sched_adjust_vcpu(d, op-u.scheduler_vcpu_op);
+copyback = 1;
I didn't see any fields you need to copy back here ('vcpus' were copied back
in rt_vcpu_cntl() already).
+{
+struct rt_private *prv = rt_priv(ops);
+struct rt_dom * const sdom = rt_dom(d);
+struct rt_vcpu *svc;
+struct list_head *iter;
+unsigned long flags;
+int rc = 0;
+xen_domctl_sched_rtds_params_t local_sched;
+unsigned int vcpuid;
+unsigned int i;
'vcpuid' is only used in 'get' path once while 'i' is used in 'set' path
only, perhaps merge the two variables?
+
+switch ( op-cmd )
+{
+case XEN_DOMCTL_SCHEDOP_getvcpuinfo:
+spin_lock_irqsave(prv-lock, flags);
+list_for_each( iter, sdom-vcpu )
+{
+svc = list_entry(iter, struct rt_vcpu, sdom_elem);
+vcpuid = svc-vcpu-vcpu_id;
+
+local_sched.budget = svc-budget / MICROSECS(1);
+local_sched.period = svc-period / MICROSECS(1);
+if ( copy_to_guest_offset(op-u.rtds.vcpus, vcpuid,
+local_sched, 1) )
+{
+spin_unlock_irqrestore(prv-lock, flags);
+return -EFAULT;
^Double spaces.
+}
+hypercall_preempt_check();
The check itself does nothing for preemption, you need return –ERESTART
or call hypercall_create_continuation to make the preemption happen.
+}
+spin_unlock_irqrestore(prv-lock, flags);
+break;
'nr_vcpus' is not actually used untile now but in xc side you do pass
that in.
Regards
Chao
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for Xen 4.6 1/4] xen: enabling XL to set per-VCPU parameters of a domain for RTDS scheduler
On 26.05.15 at 19:18, lichong...@gmail.com wrote:
On Tue, May 26, 2015 at 4:08 AM, Jan Beulich jbeul...@suse.com wrote:
On 26.05.15 at 02:05, lichong...@gmail.com wrote:
Add two hypercalls(XEN_DOMCTL_SCHEDOP_getvcpuinfo/putvcpuinfo) to get/set a
domain's
per-VCPU parameters. Hypercalls are handled by newly added hook
(.adjust_vcpu) in the
scheduler interface.
Add a new data structure (struct xen_domctl_scheduler_vcpu_op) for
transferring data
between tool and hypervisor.
Signed-off-by: Chong Li chong...@wustl.edu
Signed-off-by: Meng Xu men...@cis.upenn.edu
Signed-off-by: Sisu Xi xis...@gmail.com
---
Missing brief description of changes in v2 here.
Based on Dario's suggestion in PATCH v1, we think it would be better
to make the per-vcpu get/set functionalities more general, rather than
just serving for rtds scheduler. So, the changes in v2 are:
1) Add a new hypercall, XEN_DOMCTL_scheduler_vcpu_op. Any scheduler
can use it for per-vcpu get/set. There is a new data structure (struct
xen_domctl_scheduler_vcpu_op), which helps transferring data (per-vcpu
params) between tool and hypervisor when the hypercall is invoked.
2) The new hypercall is handled by function sched_adjust_vcpu (in
schedule.c), which would call a newly added hook (named as
.adjust_vcpu, added to the scheduler interface (struct scheduler)).
3) In RTDS scheduler, .adjust_vcpu hooks a function defined in
sched_rt.c, named as rt_vcpu_cntl. This function gets/sets the
per-vcpu params.
No, that looks to be the description of the patch as a whole, not
one of the delta between v1 and v2 (which is what I was asking for).
+
+switch ( op-cmd )
+{
+case XEN_DOMCTL_SCHEDOP_getvcpuinfo:
+spin_lock_irqsave(prv-lock, flags);
+list_for_each( iter, sdom-vcpu )
+{
+svc = list_entry(iter, struct rt_vcpu, sdom_elem);
+vcpuid = svc-vcpu-vcpu_id;
+
+local_sched.budget = svc-budget / MICROSECS(1);
+local_sched.period = svc-period / MICROSECS(1);
+if ( copy_to_guest_offset(op-u.rtds.vcpus, vcpuid,
What makes you think that the caller has provided enough slots?
This code works in a similar way as the one for XEN_SYSCTL_numainfo.
So if there is no enough slot in guest space, en error code is
returned.
I don't think I saw any place you returned an error here. The
only error being returned is -EFAULT when the copy-out fails.
+local_sched, 1) )
You're leaking hypervisor stack contents here, but by reading
the structure from guest memory first to honor its vcpuid field
(this making get match put) you'd avoid this anyway.
The structure in guest memory has nothing, and it will hold per-vcpu
params after this XEN_DOMCTL_SCHEDOP_getvcpuinfo hypercall is well
served.
Does leaking hypervisor stack mean that I need to call
local_sched.vcpuid = vcpuid before copying this local_sched to the
guest memory?
Not just that. You'd also need to make sure padding space is
cleared. But as said, I suppose you want to copy in what the
guest provided anyway, in which case the leak is implicitly
gone.
+}
+hypercall_preempt_check();
???
We've talked about this in patch v1
(http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg01152.html).
When a domain has too many VCPUs, we need to make sure the spin lock
does not last for too long.
Right, but the call above does nothing like that. Please look at other
uses of it to understand what needs to be done here.
+}
+spin_unlock_irqrestore(prv-lock, flags);
+break;
+case XEN_DOMCTL_SCHEDOP_putvcpuinfo:
+spin_lock_irqsave(prv-lock, flags);
+for( i = 0; i op-u.rtds.nr_vcpus; i++ )
+{
+if ( copy_from_guest_offset(local_sched,
+op-u.rtds.vcpus, i, 1) )
+{
+spin_unlock_irqrestore(prv-lock, flags);
+return -EFAULT;
+}
+if ( local_sched.period = 0 || local_sched.budget = 0 )
+{
+spin_unlock_irqrestore(prv-lock, flags);
+return -EINVAL;
+}
+svc = rt_vcpu(d-vcpu[local_sched.vcpuid]);
You mustn't assume local_sched.vcpuid to represent a valid array
index.
Do you mean that I locate the vcpu by comparing the local_sched.vcpuid
with the IDs of each element in the vcpu array?
No, you have to bound check it (against array bounds) before using
it as an array index.
--- a/xen/common/schedule.c
+++ b/xen/common/schedule.c
@@ -1104,6 +1104,30 @@ long sched_adjust(struct domain *d, struct
xen_domctl_scheduler_op *op)
return ret;
}
+/* Adjust scheduling parameter for the vcpus of a given domain. */
+long sched_adjust_vcpu(
+struct domain *d,
+struct xen_domctl_scheduler_vcpu_op *op)
+{
+long ret;
I see no reason for this and the function return type to be
Re: [Xen-devel] [PATCH 2/3] xen/flask: change bool_maxstr to PAGE_SIZE
On Tue, 2015-05-26 at 14:13 -0400, Daniel De Graaf wrote:
When FLASK_{GET,SET}BOOL is called with a named boolean, the call to
flask_security_resolve_bool is made prior to bool_maxstr being populated
by flask_security_make_bools. This results in the maximum string length
being specified as zero, which is not useful. While it would be
possible to initialize bool_maxstr correctly prior to its use, it is
simpler to use a fixed maximum of PAGE_SIZE as is done for the other
calls to safe_copy_string_from_guest.
Signed-off-by: Daniel De Graaf dgde...@tycho.nsa.gov
Acked-by: Ian Campbell ian.campb...@citrix.com
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] flask/policy: updates from osstest runs
On Tue, 2015-05-26 at 14:13 -0400, Daniel De Graaf wrote: Migration and HVM domain creation both trigger AVC denials that should be allowed in the default policy; add these rules. Guest console writes need to be either allowed or denied without audit depending on the decision of the local administrator; introduce a policy boolean to switch between these possibilities. Reported-by: Wei Liu wei.l...@citrix.com Signed-off-by: Daniel De Graaf dgde...@tycho.nsa.gov Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/3] libxc: add missing xc_hypercall_bounce_pre calls
On Tue, 2015-05-26 at 14:13 -0400, Daniel De Graaf wrote: Signed-off-by: Daniel De Graaf dgde...@tycho.nsa.gov Acked-by: Ian Campbell ian.campb...@citrix.com ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH net v2] xen/netback: Properly initialize credit_bytes
Commit e9ce7cb6b107 (xen-netback: Factor queue-specific data into queue struct) introduced a regression when moving queue-specific data into the queue struct by failing to set the credit_bytes field. This prevented bandwidth limiting from working. Initialize the field as it was done before multiqueue support was added. Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com --- Changed in v2: Fixed multiple-assignment. drivers/net/xen-netback/xenbus.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index 3d8dbf5..fee0241 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -793,6 +793,7 @@ static void connect(struct backend_info *be) goto err; } + queue-credit_bytes = credit_bytes; queue-remaining_credit = credit_bytes; queue-credit_usec = credit_usec; -- 2.1.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Earlier embargoed pre-disclosure without patches
(Just adding Lars so he is aware and can run the formal vote once we have consensus on a proposal for new text) On Tue, 2015-05-26 at 15:38 +, Major Hayden wrote: On 05/26/2015 07:15 AM, Stefano Stabellini wrote: On Fri, 22 May 2015, Major Hayden wrote: On 05/22/2015 09:04 AM, Jan Beulich wrote: If you were to ask for this only if the time gap until embargo expiry was less than the default of two weeks, maybe I would buy this. I'm good with that as well. I think we're saying: if embargo_length 14d: # XSA-133 situation send_pre_disclosure_draft() wait_for_patches() elif embargo_length = 14d and not patches_ready: wait_for_patches() else: send_pre_disclosure_full() Forgive my awful pseudo code. My coffee buffer is not yet full. ;) It makes sense to me. I can see the value for an organization with thousands of servers to know about it in advance, regardless of the patches, so that it can schedule the update work appropriately. Thanks for the help, folks. I've tossed a proposed security policy change into a Github gist[1]. My proposal is to add this paragraph to the Embargo and disclosure schedule section of the Xen Security Policy[2]: In the event that a two week embargo cannot be guaranteed, we will send a draft with information about the vulnerability to the pre-disclosure list as soon as possible, even if patches have not yet been written or tested. An updated draft will be sent to the pre-disclosure list once patches become available. I welcome any and all feedback. Thanks! [1] https://gist.github.com/major/1a4f7ba7787b754845e9 [2] http://www.xenproject.org/security-policy.html -- Major Hayden ___ 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] [linux-3.4 test] 57351: regressions - FAIL
flight 57351 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/57351/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect test-amd64-amd64-pair 15 debian-install/dst_host fail REGR. vs. 52715-bisect test-amd64-i386-pair15 debian-install/dst_host fail REGR. vs. 56366-bisect Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 9 debian-installfail blocked in 56366-bisect test-amd64-amd64-libvirt 9 debian-installfail blocked in 56366-bisect test-amd64-i386-libvirt 9 debian-installfail blocked in 56366-bisect test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-multivcpu 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-freebsd10-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-libvirt-xsm 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl9 debian-installfail blocked in 56366-bisect test-amd64-i386-rumpuserxen-i386 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-sedf-pin 9 debian-installfail blocked in 56366-bisect test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-rumpuserxen-amd64 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-freebsd10-i386 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-bootfail blocked in 56366-bisect test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemut-winxpsp3 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-bootfail like 53709-bisect Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-credit2 9 debian-install fail never pass test-amd64-i386-xl-xsm9 debian-install fail never pass test-amd64-amd64-xl-pvh-amd 9 debian-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-libvirt-xsm 9 debian-install fail never pass test-amd64-amd64-xl-pvh-intel 9 debian-install fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-xsm 9 debian-install fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: linux56b48fcda5076d4070ab00df32ff5ff834e0be86 baseline version: linuxbb4a05a0400ed6d2f1e13d1f82f289ff74300a70 370 people touched revisions under test, not listing them all 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 build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail
Re: [Xen-devel] [PATCH v2][RFC] libxl: Add AHCI support for upstream qemu
On Mon, May 25, 2015 at 11:48 AM, Wei Liu wei.l...@citrix.com wrote: On Mon, May 25, 2015 at 12:41:48PM +0200, Fabio Fantoni wrote: Ping... Any review and/or comment about AHCI support patch is appreciated. Stefano and Anthony were away last week and today is a UK public holiday, so please be patient. Just to be clear, pinging is helpful, but maybe a 2-3 week timeout would be a bit better than 1 week. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
George, I'm on vacation this and the next week with only limited email access. So please don't expect fast reaction on any further questions during this time. :-) On 05/26/2015 07:56 PM, George Dunlap wrote: On Fri, May 22, 2015 at 5:21 AM, Juergen Gross jgr...@suse.com wrote: On 05/21/2015 07:07 PM, George Dunlap wrote: We have several outstanding patch series which add devices that have two levels: a controller and individual devices attached to that controller. In the interest of consistency, this patch introduces a section that sketches out a template for interfaces for such devices. Signed-off-by: George Dunlap george.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Juergen Gross jgr...@suse.com CC: Chun Yan Liu cy...@suse.com CC: Olaf Hering o...@aepfle.de So, this is definitely RFC -- I tried to spec things out in a way that made sense, but I often just chose something that I thought would be a sensible starting point for discussion. This spec looks a lot more like the PVUSB spec than the PVSCSI spec, in part because I think the PVUSB spec has already had a lot more thought that's gone into it. A couple of random points to discuss: * Calling things controllers, using typectrl for the device name, and using ctrl as the field name for the devid of the controller in the individual devices. Hmm, what about device group (typedevgoup)? In the scsi world controller would be one level higher in the hierarchy. And the scsi controller is at least visible in the configuration syntax h:c:t:l. Using controller for the c in this item and for the t internally could lead to confusion. OK, so I looked it up[1] and the full address seems to be: * adapter number / host * channel number / bus * id number / target * LUN In which case, controller would correspond to adapter / host, right? In the vscsi world, what levels of what can you make? I know you mentioned before that some devices have multiple LUNs, and those need to be grouped together, with the same LUNs as they do on real hardware, to work properly -- is that right? Not all of the devices have this requirement, but some. The USB case actually has something somewhat similar: * USB controller * USB bus * USB device * USB function So far, there's not really a controller/bus distinction: each controller has exactly one bus. When we assign a USB device to a bus, we automatically go through and assign each function fo that device individually. Would it make sense to treat vscsi the same way -- i.e., to make a bus, and then attach targetss to it, and have the LUNs for any given target automatically assigned when the target is assigned? As long as it is still possible to assign individual LUNs as well. If dom0 is controlling e.g. a RAID system you might want to assign one LUN of a target to domU A and one LUN of the same target to domU B. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH net v2] xen/netback: Properly initialize credit_bytes
On Wed, May 27, 2015 at 11:44:32AM +0100, Ross Lagerwall wrote: Commit e9ce7cb6b107 (xen-netback: Factor queue-specific data into queue struct) introduced a regression when moving queue-specific data into the queue struct by failing to set the credit_bytes field. This prevented bandwidth limiting from working. Initialize the field as it was done before multiqueue support was added. Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com Acked-by: Wei Liu wei.l...@citrix.com --- Changed in v2: Fixed multiple-assignment. drivers/net/xen-netback/xenbus.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/xen-netback/xenbus.c b/drivers/net/xen-netback/xenbus.c index 3d8dbf5..fee0241 100644 --- a/drivers/net/xen-netback/xenbus.c +++ b/drivers/net/xen-netback/xenbus.c @@ -793,6 +793,7 @@ static void connect(struct backend_info *be) goto err; } + queue-credit_bytes = credit_bytes; queue-remaining_credit = credit_bytes; queue-credit_usec = credit_usec; -- 2.1.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [Draft C] Xen on ARM vITS Handling
Here follows draft C based on previous feedback.
Also at:
http://xenbits.xen.org/people/ianc/vits/draftC.{pdf,html}
I think I've captured most of the previous discussion, except where
explicitly noted by XXX or in other replies, but please do point out
places where I've missed something.
One area where I am pretty sure I've dropped the ball is on the
completion and update of `CREADR`. That conversation ended up
bifurcating along the 1:N vs N:N mapping scheme lines, and I didn't
manage to get the various proposals straight. Since we've now agreed on
N:N hopefully we can reach a conclusion (no pun intended) on the
completion aspect too (sorry that this probably means rehasing at least
a subset of the previous thread).
Ian.
% Xen on ARM vITS Handling
% Ian Campbell ian.campb...@citrix.com
% Draft C
# Changelog
## Since Draft B
* Details of command translation (thanks to Julien and Vijay)
* Added background on LPI Translation and Pending tablesd
* Added background on Collections
* Settled on `N:N` scheme for vITS:pITS mapping.
* Rejigged section nesting a bit.
* Since we now thing translation should be cheap, settle on
translation at scheduling time.
* Lazy `INVALL` and `SYNC`
## Since Draft A
* Added discussion of when/where command translation occurs.
* Contention on scheduler lock, suggestion to use SOFTIRQ.
* Handling of domain shutdown.
* More detailed discussion of multiple vs single vits pros/cons.
# Introduction
ARM systems containing a GIC version 3 or later may contain one or
more ITS logical blocks. An ITS is used to route Message Signalled
interrupts from devices into an LPI injection on the processor.
The following summarises the ITS hardware design and serves as a set
of assumptions for the vITS software design. (XXX it is entirely
possible I've horribly misunderstood how this stuff fits
together). For full details of the ITS see the GIC Architecture
Specification.
## Device Identifiers
Each device using the ITS is associated with a unique identifier.
The device IDs are typically described via system firmware, e.g. the
ACPI IORT table or via device tree.
The number of device ids is variable and can be discovered via
`GITS_TYPER.Devbits`. This field allows an ITS to have up to 2^32
device.
## Interrupt Collections
Each interrupt is a member of an Interrupt Collection. This allows
software to manage large numbers of physical interrupts with a small
number of commands rather than issuing one command per interrupt.
On a system with N processors, the ITS must provide at least N+1
collections.
## Target Addresses
The Target Address correspond to a specific GIC re-distributor. The format
of this field depends on the value of the `GITS_TYPER.PTA` bit:
* 1: the base address of the re-distributor target is used
* 0: a unique processor number is used. The mapping between the
processor affinity value (`MPIDR`) and the processor number is
discoverable via `GICR_TYPER.ProcessorNumber`.
## ITS Translation Table
Message signalled interrupts are translated into an LPI via an ITS
translation table which must be configured for each device which can
generate an MSI.
The ITS translation table maps the device id of the originating devic
into an Interrupt Collection and then into a target address.
## ITS Configuration
The ITS is configured and managed, including establishing and
configuring Translation Table for each device, via an in memory ring
shared between the CPU and the ITS controller. The ring is managed via
the `GITS_CBASER` register and indexed by `GITS_CWRITER` and
`GITS_CREADR` registers.
A processor adds commands to the shared ring and then updates
`GITS_CWRITER` to make them visible to the ITS controller.
The ITS controller processes commands from the ring and then updates
`GITS_CREADR` to indicate the the processor that the command has been
processed.
Commands are processed sequentially.
Commands sent on the ring include operational commands:
* Routing interrupts to processors;
* Generating interrupts;
* Clearing the pending state of interrupts;
* Synchronising the command queue
and maintenance commands:
* Map device/collection/processor;
* Map virtual interrupt;
* Clean interrupts;
* Discard interrupts;
The field `GITS_CBASER.Size` encodes the number of 4KB pages minus 0
consisting of the command queue. This field is 8 bits which means the
maximum size is 2^8 * 4KB = 1MB. Given that each command is 32 bytes,
there is a maximum of 32768 commands in the queue.
The ITS provides no specific completion notification
mechanism. Completion is monitored by a combination of a `SYNC`
command and either polling `GITS_CREADR` or notification via an
interrupt generated via the `INT` command.
Note that the interrupt generation via `INT` requires an originating
device ID to be supplied (which is then translated via the ITS into an
LPI). No specific device ID is defined for this purpose and so the OS
software is expected to fabricate one.
Possible ways of inventing such a
[Xen-devel] question on xen-blkback: enlarge the array size of blkback name
Hello, looking at this once again now that it's upstream, I still can't see what this is good for: The only use the produced string has is to be passed to kthread_run(), i.e. ultimately to be stored in a task's -comm. That, however, continues to be limited to 16 characters, so blkback.domid.xvd[a-z] being up to 18 characters I don't understand how the change results in the full name being shown. What am I missing? Why aren't you instead shortening the string to e.g. blkbk.domid.xvd[a-z] (which still is 16 characters, i.e. the last character would still be chopped off for 5 digit domain IDs; perhaps the first dot should then also be dropped). Thanks, Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1 0/5] Misc cleanups for libxl
ping... On 05/20/2015 06:01 PM, Yang Hongyang wrote: This patchset mainly focus on libxl save, most of the patches are simply move codes out of libxl_dom.c, no functional changes, may conflict with Andrew Cooper's libxl work for migration v2, so CCed Andrew for comments. For convenience, my previous sent patch [PATCH v1] libxl/save: Refactor libxl__domain_suspend_state is included in this series because all the other patches in this series are based on that. Please see individual patch for detail. Can get the whole patchset from: https://github.com/macrosheep/xen/tree/misc-libxl-v1 Yang Hongyang (5): libxl/save: Refactor libxl__domain_suspend_state tools/libxl: move domain suspend codes into a separate file tools/libxl: move remus codes into libxl_remus.c tools/libxl: move toolstack code into libxl_toolstack.c tools/libxl: move domain save codes into libxl_dom_save.c tools/libxl/Makefile |5 +- tools/libxl/libxl.c | 67 +-- tools/libxl/libxl_dom.c | 1202 -- tools/libxl/libxl_dom_save.c | 493 tools/libxl/libxl_dom_suspend.c | 400 + tools/libxl/libxl_internal.h | 62 +- tools/libxl/libxl_netbuffer.c|2 +- tools/libxl/libxl_remus.c| 306 ++ tools/libxl/libxl_save_callout.c |2 +- tools/libxl/libxl_toolstack.c| 196 +++ 10 files changed, 1452 insertions(+), 1283 deletions(-) create mode 100644 tools/libxl/libxl_dom_save.c create mode 100644 tools/libxl/libxl_dom_suspend.c create mode 100644 tools/libxl/libxl_remus.c create mode 100644 tools/libxl/libxl_toolstack.c -- Thanks, Yang. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen on ARM vITS Handling Draft B (Was Re: Xen/arm: Virtual ITS command queue handling)
On Sun, 2015-05-24 at 11:35 +0100, Julien Grall wrote: [...] I wrote my though for the validation bits (see below) and add some definitions useful for people which don't have the spec. Thanks for this. Emulation of ITS commands = # Introduction This document is based on the section 5.13 of GICv3 specification (PRD03-GENC-010745 24.0). The goal is to provide insight of the cost to emulate ITS commands in Xen. The ITS provides 12 commands in order to manage interrupt collection, device and interrupts. # Definitions I tried to integrate your text here into the introduction section of the VITs doc. [...] # Validation of the parameters And this bit I used as the basis for a new ITS Command Translation chapter. I have some questions which I have inserted into the next draft of the doc with XXX markers. I intend to post a new draft very soon, rather than wait for any discussion, so you might prefer to wait and answer them in that thread. Each command contains parameters that needs to be validated before any usage in Xen or passing to the hardware. This section will describe the validation of the main parameters. ## Device ID This parameter is used in commands which manage the device and the interrupts associated to this device. Checking if a device is present and retrieving the data structure must be fast. The device identifiers may not be assigned contiguously and the maximum number is very high (2^32). That's true for the host, but I think the lookup here needs to be based on the virtual device id, not necessarily the physical one, so we have the opportunity to arrange things for our convenience. In particular we could arrange for device ids to be contiguous (or in a small number of ranges) and we know that N is going to be much lower that 2^32 in practice. So I think we could almost get away with either a simple array or a much simpler M-level look up (for small M, say 2). Or is there some constraint which means we cannot virtualise the device id? The possible efficient data structure would be: 1) List: The lookup/deletion is in O(n) and the insertion will depend if the device should be sort following their identifier. The memory overhead is 18 bytes per element. 2) Red-black tree: All the operations are O(log(n)). The memory overhead is 24 bytes per element. The solution 2) seems the more suitable for having fast deviceID validation even though the memory overhead is a bit higher compare to the list. Vijay's text discussed Event ID too. I've added some words about that, they may be rubbish, please check the next draft. ## Collection This parameter is used in commands which manage collections and interrupt in order to move them for one CPU to another. The ITS is only mandatory to implement N + 1 collections where N is the number of processor on the platform. Furthermore, the identifier are always contiguous. If we decide to implement the strict minimum (i.e N + 1), an array is enough and will allow operations in O(1). May not even need that since [0..NR_CPUS+1] would allow us to go straight to either vcpu-collection_id or domain-collection_id (the latter being the +1). ## Target Address This parameter is used in commands to manage collection. It's also, I think, the output of the ITS Translation table? It's a unique identifier per processor. The format is different following the value of the bit GITS_TYPER.PTA (see definition). The value of the field pre-defined by the ITS and the software has to handle the 2 cases. IOW the bit is r/o and fixed by the ITS implementor? The solution with GITS_TYPER.PTA set to one will require some computation in order to find the VCPU associated with the redistributor address. It will be similar to get_vcpu_from_rdist in the vGICv3 emulation (xen/arch/arm/vgic-v3.c). On another hand, setting GITS_TYPER.PTA to zero will give us control to decide the linear process number which could simply be the vcpu_id (always linear). Does this get more complicated with large numbers of vcpus on gic v3 (i.e. once AFFR0 gets involved)? ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Xen on ARM vITS Handling Draft B (Was Re: Xen/arm: Virtual ITS command queue handling)
On Fri, 2015-05-22 at 17:46 +0530, Vijay Kilari wrote: OK, Vijay could you make a proposal here please. __text__ Thanks, I tried to incorporate / merge this with the stuff Julien proposed later, and to update based on the discussion in this thread. Please check the next draft since I'm sure I must have either missed something or mismerged concepts etc. I've also left some XXX where I wasn't sure what the conclusion was. I think the main suggestion was to allocate various data structures at passthrough setup time rather than at command xlate time. Please check draft C, which I hope to post shortly. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v1] x86/pvh: disable posted interrupts
El 22/05/15 a les 12.20, Roger Pau Monne ha escrit: Enabling posted interrupts requires the virtual interrupt delivery feature, which is disabled for PVH guests, so make sure posted interrupts are also disabled or else vmlaunch will fail. Signed-off-by: Roger Pau Monné roger@citrix.com Reported-and-Tested-by: Lars Eggert l...@netapp.com Acked-by: Kevin Tian kevin.t...@intel.com Cc: Jun Nakajima jun.nakaj...@intel.com Cc: Eddie Dong eddie.d...@intel.com Cc: Kevin Tian kevin.t...@intel.com Cc: Jan Beulich jbeul...@suse.com Cc: Andrew Cooper andrew.coop...@citrix.com --- xen/arch/x86/hvm/vmx/vmcs.c | 4 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index a714549..9827a8e 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -980,6 +980,10 @@ static int construct_vmcs(struct vcpu *v) v-arch.hvm_vmx.secondary_exec_control = ~SECONDARY_EXEC_UNRESTRICTED_GUEST; +/* Disable posted interrupts */ Looks like I didn't refresh the patch before sending it, new version coming (hopefully with the proper version number and comment this time). Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] question on xen-blkback: enlarge the array size of blkback name
On Wed, 2015-05-27 at 10:28 +0100, Roger Pau Monné wrote: El 27/05/15 a les 9.47, Jan Beulich ha escrit: Hello, looking at this once again now that it's upstream, I still can't see what this is good for: The only use the produced string has is to be passed to kthread_run(), i.e. ultimately to be stored in a task's -comm. That, however, continues to be limited to 16 characters, so blkback.domid.xvd[a-z] being up to 18 characters I don't understand how the change results in the full name being shown. What am I missing? Right, I didn't realize there was a length limitation in task_struct. How did you manage to get it working Chentao? Why aren't you instead shortening the string to e.g. blkbk.domid.xvd[a-z] (which still is 16 characters, i.e. the last character would still be chopped off for 5 digit domain IDs; perhaps the first dot should then also be dropped). That sounds right. If you are pressed for space then the xvd is probably a bit redundant in a string which starts blkbk. The guest may not even call the device xvdN (iirc BSD has another prefix) any how, so having blkback say so seems of limited use anyway. Since this seems to not include a partition number how does this work in the split partition scheme? (i.e. one where the guest is given xvda1 and xvda2 rather than xvda with a partition table) Perhaps something derived from one of the schemes in http://xenbits.xen.org/docs/unstable/misc/vbd-interface.txt might be a better fit? Ian. Roger. ___ 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 V6] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
As suggested by Andrew Cooper, this patch attempts to remove
some redundancy and allow for an easier time when adding vm_events
for new control registers in the future, by having a single
VM_EVENT_REASON_WRITE_CTRLREG vm_event type, meant to serve CR0,
CR3, CR4 and (newly introduced) XCR0. The actual control register
will be deduced by the new .index field in vm_event_write_ctrlreg
(renamed from vm_event_mov_to_cr). The patch has also modified
the xen-access.c test - it is now able to log CR3 events.
Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com
Reviewed-by: Tim Deegan t...@xen.org
---
Changes since V5:
- Put vm_event_write_ctrlreg's _pad in its proper place.
- Moved wrapping hvm_event_cr() macro to header.
- asm/ includes follow xen/ ones.
---
tools/libxc/include/xenctrl.h |9 ++---
tools/libxc/xc_monitor.c| 40 +++---
tools/tests/xen-access/xen-access.c | 30 +++--
xen/arch/x86/hvm/event.c| 54 --
xen/arch/x86/hvm/hvm.c | 11 +++---
xen/arch/x86/hvm/vmx/vmx.c |6 ++--
xen/arch/x86/monitor.c | 63 +--
xen/include/asm-x86/domain.h| 12 ++-
xen/include/asm-x86/hvm/event.h |6 ++--
xen/include/asm-x86/monitor.h |2 ++
xen/include/public/domctl.h | 12 +++
xen/include/public/vm_event.h | 29
12 files changed, 114 insertions(+), 160 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 09a7450..83fd289 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2375,12 +2375,9 @@ int xc_mem_access_disable_emulate(xc_interface *xch,
domid_t domain_id);
void *xc_monitor_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
int xc_monitor_disable(xc_interface *xch, domid_t domain_id);
int xc_monitor_resume(xc_interface *xch, domid_t domain_id);
-int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly);
-int xc_monitor_mov_to_cr3(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly);
-int xc_monitor_mov_to_cr4(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly);
+int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
+ uint16_t index, bool enable, bool sync,
+ bool onchangeonly);
int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, bool enable,
bool extended_capture);
int xc_monitor_singlestep(xc_interface *xch, domid_t domain_id, bool enable);
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 87ad968..63013de 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -45,8 +45,9 @@ int xc_monitor_resume(xc_interface *xch, domid_t domain_id)
NULL);
}
-int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly)
+int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
+ uint16_t index, bool enable, bool sync,
+ bool onchangeonly)
{
DECLARE_DOMCTL;
@@ -54,39 +55,8 @@ int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t
domain_id, bool enable,
domctl.domain = domain_id;
domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
: XEN_DOMCTL_MONITOR_OP_DISABLE;
-domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR0;
-domctl.u.monitor_op.u.mov_to_cr.sync = sync;
-domctl.u.monitor_op.u.mov_to_cr.onchangeonly = onchangeonly;
-
-return do_domctl(xch, domctl);
-}
-
-int xc_monitor_mov_to_cr3(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly)
-{
-DECLARE_DOMCTL;
-
-domctl.cmd = XEN_DOMCTL_monitor_op;
-domctl.domain = domain_id;
-domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
-: XEN_DOMCTL_MONITOR_OP_DISABLE;
-domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR3;
-domctl.u.monitor_op.u.mov_to_cr.sync = sync;
-domctl.u.monitor_op.u.mov_to_cr.onchangeonly = onchangeonly;
-
-return do_domctl(xch, domctl);
-}
-
-int xc_monitor_mov_to_cr4(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly)
-{
-DECLARE_DOMCTL;
-
-domctl.cmd = XEN_DOMCTL_monitor_op;
-domctl.domain = domain_id;
-domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
-: XEN_DOMCTL_MONITOR_OP_DISABLE;
-domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR4;
+
[Xen-devel] [PATCH v3] x86/pvh: disable posted interrupts
Enabling posted interrupts requires the virtual interrupt delivery feature, which is disabled for PVH guests, so make sure posted interrupts are also disabled or else vmlaunch will fail. Signed-off-by: Roger Pau Monné roger@citrix.com Reported-and-Tested-by: Lars Eggert l...@netapp.com Acked-by: Kevin Tian kevin.t...@intel.com Cc: Jun Nakajima jun.nakaj...@intel.com Cc: Eddie Dong eddie.d...@intel.com Cc: Kevin Tian kevin.t...@intel.com Cc: Jan Beulich jbeul...@suse.com Cc: Andrew Cooper andrew.coop...@citrix.com --- Changes since v2: - Move the code so it's closer to virtual interrupt delivery disabling. - Update comment. --- xen/arch/x86/hvm/vmx/vmcs.c | 4 1 file changed, 4 insertions(+) diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c index a714549..f585883 100644 --- a/xen/arch/x86/hvm/vmx/vmcs.c +++ b/xen/arch/x86/hvm/vmx/vmcs.c @@ -976,6 +976,10 @@ static int construct_vmcs(struct vcpu *v) | SECONDARY_EXEC_VIRTUAL_INTR_DELIVERY); v-arch.hvm_vmx.exec_control = ~CPU_BASED_TPR_SHADOW; +/* In turn, disable posted interrupts. */ +__vmwrite(PIN_BASED_VM_EXEC_CONTROL, +vmx_pin_based_exec_control ~PIN_BASED_POSTED_INTERRUPT); + /* Unrestricted guest (real mode for EPT) */ v-arch.hvm_vmx.secondary_exec_control = ~SECONDARY_EXEC_UNRESTRICTED_GUEST; -- 1.9.5 (Apple Git-50.3) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] question on xen-blkback: enlarge the array size of blkback name
El 27/05/15 a les 9.47, Jan Beulich ha escrit: Hello, looking at this once again now that it's upstream, I still can't see what this is good for: The only use the produced string has is to be passed to kthread_run(), i.e. ultimately to be stored in a task's -comm. That, however, continues to be limited to 16 characters, so blkback.domid.xvd[a-z] being up to 18 characters I don't understand how the change results in the full name being shown. What am I missing? Right, I didn't realize there was a length limitation in task_struct. How did you manage to get it working Chentao? Why aren't you instead shortening the string to e.g. blkbk.domid.xvd[a-z] (which still is 16 characters, i.e. the last character would still be chopped off for 5 digit domain IDs; perhaps the first dot should then also be dropped). That sounds right. Roger. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86: Don't crash when mapping a page using EFI runtime page tables
On 05/18/2015 03:58 PM, Jan Beulich wrote: On 15.05.15 at 18:08, ross.lagerw...@citrix.com wrote: --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -32,20 +32,25 @@ static inline struct vcpu *mapcache_current_vcpu(void) return NULL; /* + * When using efi runtime page tables, we have the equivalent of the idle + * domain's page tables but current may point at another domain's VCPU. + * Return NULL as though current is not properly set up yet. + */ +if ( efi_enabled read_cr3() == efi_rs_page_table() ) +return NULL; I'm okay with the patch in principle; what worries me is the CR3 read that is now going to be necessary even in non-debug builds. With this code being the only user of efi_rs_page_table(), I wonder if it wouldn't make sense to alter that function to return non-zero only when spin_is_locked(efi_rs_lock), and then alter the code above such that the CR3 read would happen only when we got a non-zero value back. mapcache_current_vcpu() appears to be called from IRQ-enabled and IRQ-disabled callers which prevents us from using the spinlock. Is reading cr3 that bad, given that this is a slow path anyway? And with that I would then also like to fold the potential double CR3 reads in debug builds to at most one. CR3 needs to be re-read after the lazy context switch to the idle domain is completed. -- Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for Xen 4.6 1/4] xen: enabling XL to set per-VCPU parameters of a domain for RTDS scheduler
On 27.05.15 at 07:33, lichong...@gmail.com wrote:
On Tue, May 26, 2015 at 12:18 PM, Chong Li lichong...@gmail.com wrote:
On Tue, May 26, 2015 at 4:08 AM, Jan Beulich jbeul...@suse.com wrote:
On 26.05.15 at 02:05, lichong...@gmail.com wrote:
+/* Adjust scheduling parameter for the vcpus of a given domain. */
+long sched_adjust_vcpu(
+struct domain *d,
+struct xen_domctl_scheduler_vcpu_op *op)
+{
+long ret;
I see no reason for this and the function return type to be long.
The reason is stated in the begining.
Sorry for missing some details in the last reply.
sched_adjust_vcpu is added here because I need a seperate function to
handle XEN_DOMCTL_scheduler_vcpu_op, which is a new hypercall
dedicated for per-vcpu get/set. This function is actually based on
sched_adjust (which is dedicated for per-dom get/set in rtds), so the
return type is also the same.
You explain why you need the function, but I asked about why the
function return type and the quoted variable's types are long.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86: Don't crash when mapping a page using EFI runtime page tables
On 27.05.15 at 12:23, ross.lagerw...@citrix.com wrote: On 05/18/2015 03:58 PM, Jan Beulich wrote: On 15.05.15 at 18:08, ross.lagerw...@citrix.com wrote: --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -32,20 +32,25 @@ static inline struct vcpu *mapcache_current_vcpu(void) return NULL; /* + * When using efi runtime page tables, we have the equivalent of the idle + * domain's page tables but current may point at another domain's VCPU. + * Return NULL as though current is not properly set up yet. + */ +if ( efi_enabled read_cr3() == efi_rs_page_table() ) +return NULL; I'm okay with the patch in principle; what worries me is the CR3 read that is now going to be necessary even in non-debug builds. With this code being the only user of efi_rs_page_table(), I wonder if it wouldn't make sense to alter that function to return non-zero only when spin_is_locked(efi_rs_lock), and then alter the code above such that the CR3 read would happen only when we got a non-zero value back. mapcache_current_vcpu() appears to be called from IRQ-enabled and IRQ-disabled callers which prevents us from using the spinlock. I didn't suggest to use any spin lock; I merely suggested checking whether that particular one is being held by someone (to avoid the CR3 read if that's not the case). Is reading cr3 that bad, given that this is a slow path anyway? I never easily agree to making a code path slower that may be executed frequently. And looking at the most likely path through the function, I don't think it's all that slow anyway. And with that I would then also like to fold the potential double CR3 reads in debug builds to at most one. CR3 needs to be re-read after the lazy context switch to the idle domain is completed. That's a good point. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v22 02/14] x86/VPMU: Add public xenpmu.h
On 05/27/2015 08:28 AM, Jan Beulich wrote:
On 26.05.15 at 19:50, boris.ostrov...@oracle.com wrote:
On 05/26/2015 12:13 PM, Jan Beulich wrote:
On 21.05.15 at 19:57, boris.ostrov...@oracle.com wrote:
+ * guest when PMU_CACHED bit in pmu_flags is set (which is done by the
+ * hypervisor during PMU interrupt). Hypervisor will read updated data in
+ * XENPMU_flush hypercall and clear PMU_CACHED bit.
+ */
+struct xen_pmu_arch {
+union {
+/*
+ * Processor's registers at the time of interrupt.
+ * WO for hypervisor, RO for guests.
+ */
+struct xen_pmu_regs regs;
+/* Padding for adding new registers to xen_pmu_regs in the future
*/
+#define XENPMU_REGS_PAD_SZ 64
+uint8_t pad[XENPMU_REGS_PAD_SZ];
+} r;
+
+/* WO for hypervisor, RO for guest */
+uint64_t pmu_flags;
+
+/*
+ * APIC LVTPC register.
+ * RW for both hypervisor and guest.
+ * Only APIC_LVT_MASKED bit is loaded by the hypervisor into hardware
+ * during XENPMU_flush or XENPMU_lvtpc_set.
+ */
+union {
+uint32_t lapic_lvtpc;
Considering this isn't being used in this patch, could I ask you to
move it where it is being used (keeping only the pad member and
perhaps a placeholder comment here), so verifying that the
read-once requirement for the hypervisor side is met becomes
more obvious?
I can certainly delay defining this field until later patch but how is
this filed different from xen_pmu_arch (not seen here) which is also
read-once? Wouldn't you then want to have that definition deferred as well?
I'm confused - the only xen_pmu_arch I see in this patch is
struct xen_pmu_arch (and its uses), which the field above is
actually part of, and which is also visible in the context above. So
I doubt that's what you're referring to. But yes, fields with read-
once requirements would better be defined in the patch(es) using
them, so reviewers don't need to hunt them down.
Sorry, I meant amd/intel members of the union below (I forgot we were
already in the arch header file):
+/*
+ * Vendor-specific PMU registers.
+ * RW for both hypervisor and guest.
+ * Guest's updates to this field are verified and then loaded by the
+ * hypervisor into hardware during XENPMU_flush
+ */
+union {
+struct xen_pmu_amd_ctxt amd;
+struct xen_pmu_intel_ctxt intel;
+
+/*
+ * Padding for contexts (fixed parts only, does not include MSR
banks
+ * that are specified by offsets)
+ */
+#define XENPMU_CTXT_PAD_SZ 128
+uint8_t pad[XENPMU_CTXT_PAD_SZ];
+} c;
+};
I think they are first used in patch 11 so I assume you also want me to
just keep the pad here (with a comment explaining why it is here) until
that patch.
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v7 10/15] ts-debian-di-install: Refactor root_disk specification
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v4: new patch
---
ts-debian-di-install | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/ts-debian-di-install b/ts-debian-di-install
index da6ab73..bb2d2d2 100755
--- a/ts-debian-di-install
+++ b/ts-debian-di-install
@@ -195,12 +195,14 @@ END
OnPowerOff = preserve
);
+my $root_disk = 'phy:$gho-{Lvdev},xvda,w';
+
prepareguest_part_xencfg($ho, $gho, $ram_mb, \%install_xopts, END);
$method_cfg
extra = $cmdline
#
disk= [
-$extra_disk 'phy:$gho-{Lvdev},xvda,w'
+$extra_disk $root_disk
]
END
@@ -224,7 +226,7 @@ END
$blcfg
#
disk= [
-'phy:$gho-{Lvdev},xvda,w'
+$root_disk
]
END
return;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v7 05/15] distros: support PV guest install from Debian netinst media.
The netinst media are iso images containing a base Debian install and
some (image size dependent) additional tasks.
On x86 the multiarch iso flavour contains a Xen capable kernel for
both i386 and amd64 so use that.
This adds support for two classes of ISO, the CD sized ones which are
built nightly and the DVD sized ones which are built weekly.
The images are downloaded using jigdo which sources the majority of
the data from a local Debian mirror, for this reason I have not
worried about the fact that the i386 and amd64 tests are downloading
the same thing (adding a specific download job would require finding
up to 4GB of scratch space for each flight).
The ISOs booted using pygrub which can extract the kernel and initrd
from a ISO image. The resulting guests are also booted with pygrub
since the pv-grub-menu package is not available on the ISO images and
we have pvgrub coverage from the netboot tests.
This is configured from make*flight using runvars:
- gident_netinst_baseurl:
Base URL of directory containing the netinst jigdo images.
- gident_netinst_filere:
Regular expression to match actual file within baseurl to use
(without .jigdo suffix)
gident_netinst_kernel:
Path to kernel within the netinst image
gident_netinst_ramdisk
Path to ramdisk within the netinst image
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v7: Use {Guest}_suite not {Guest}_dist as runvar to choose version.
Use shorter lined method for $arch_props definition
Switch to flight-per-suite model
Handle lack of both $c{DebianMirrorProxy} and $c{HttpProxy}
Construct URLs in make-distros-flight
v4: Support http_proxy in jigdo download
v3:
- Indent jigdo-lite script line to improve readability
- Wrap bootloader_args
- Fetch URL on target, to get a timeout. Use wget since that is arranged to
be present.
- include bootloader in test name.
---
Osstest/Debian.pm| 7 --
make-distros-flight | 54
ts-debian-di-install | 64
3 files changed, 123 insertions(+), 2 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 0975e73..30b1b3a 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -623,8 +623,6 @@ sub preseed_base (;@) {
preseed_hook_overlay($ho, $sfx, $c{OverlayLocal}, 'overlay-local.tar');
my $preseed = END;
-d-i mirror/suite string $suite
-
d-i debian-installer/locale string en_GB
d-i console-keymaps-at/keymap select gb
d-i keyboard-configuration/xkb-keymap string en_GB
@@ -696,6 +694,11 @@ END
d-i clock-setup/ntp-server string $ntpserver
END
+# For CDROM the suite is part of the image
+$preseed .= END unless $xopts{CDROM};
+d-i mirror/suite string $suite
+END
+
$preseed .= END;
### END OF DEBIAN PRESEED BASE
diff --git a/make-distros-flight b/make-distros-flight
index 06b14f2..4b9f100 100755
--- a/make-distros-flight
+++ b/make-distros-flight
@@ -115,6 +115,48 @@ test_do_one_netboot () {
all_hostflags=$most_hostflags
}
+test_do_one_netinst () {
+ local path_arch
+ case $domU in
+amd64|i386) path_arch=multi-arch; file_arch=amd64-i386;;
+*) path_arch=$domU; file_arch=$domU;;
+ esac
+ case $domU in
+amd64) iso_path=/install.amd/xen;;
+i386) iso_path=/install.386/xen;;
+*) iso_path=/install.$domU;;
+ esac
+
+ local cdurl=
+ case $cd in
+current)
+ cdurl=http://cdimage.debian.org/debian-cd/current/${path_arch}/jigdo-cd;
+ ;;
+weekly)
+
cdurl=http://cdimage.debian.org/cdimage/weekly-builds/${path_arch}/jigdo-cd;
+ ;;
+*)
+ echo cd $cd?
+ exit 1
+ ;;
+ esac
+
+ # Always pygrub since no pv-grub-menu on CD
+ job_create_test \
+ test-$xenarch$kern-$dom0arch-$domU-$cd-netinst-pygrub\
+test-debian-di xl $xenarch $dom0arch\
+ kernbuildjob=${bfi}build-$dom0arch-$kernbuild \
+ debian_arch=$domU \
+ debian_method=netinst \
+ debian_netinst_baseurl=$cdurl \
+ debian_netinst_filere=debian-.*-${file_arch}-netinst\
+ debian_netinst_kernel=${iso_path}/vmlinuz \
+ debian_netinst_ramdisk=${iso_path}/initrd.gz\
+ debian_bootloader=pygrub \
+ all_hostflags=$most_hostflags
+
+}
+
test_matrix_do_one () {
case ${xenarch} in
amd64) domUarches=amd64 i386;;
@@ -130,6 +172,18 @@ test_matrix_do_one () {
fi
+if [ $debian_suite = snapshot ]; then
+gsuite=sid
+for cd in current weekly ; do
+ case ${domU}_${gsuite} in
+armhf_*) continue;; # No iso targets for armhf
+*) ;;
+ esac
+
+ test_do_one_netinst
+
+done
+fi
Re: [Xen-devel] Earlier embargoed pre-disclosure without patches
On 05/26/15 16:34, Major Hayden wrote: On 05/26/2015 11:50 AM, Stefano Stabellini wrote: I would go for: In the event that public disclosure is less than 15 days away, we will send a draft with information about the vulnerability to the pre-disclosure list as soon as possible, even if patches have not yet been written or tested. An updated draft will be sent to the pre-disclosure list once patches become available. No objections here. +1 Also looks good to me. +1 -Don Slutz ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel signature.asc Description: OpenPGP digital signature ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 26/41] arm : acpi add xen environment table
On 26.05.15 at 19:34, stefano.stabell...@eu.citrix.com wrote: On Thu, 21 May 2015, Jan Beulich wrote: On 21.05.15 at 12:34, julien.gr...@citrix.com wrote: ACPI 6.0 has been released few months after Parth and Naresh began to implement ACPI for Xen. We could take advantage of this new field. If at all possible - yes please, in favor of any custom tables. Let me give you some more context. As Julien pointed out, neither the cpuid like mechanism nor the existing ACPI tables seemed to fit the bill, so we thought that the best way forward was to simply add one more ACPI table to advertise the presence of Xen on the platform. Since we have a table in our hands, we might as well use it to pass some useful information, specifically we thought that the existing information passed via device tree would be a good place to start. This is how we got to the XENV table that we have now. In general I think that passing information via tables or data trees, that are made for this purpose, is nicer compared to using hypercalls. There are certainly up and down sides to each of them. For ACPI tables, I'm particularly puzzled by the need to re-write XSDT/RSDT if you want to add a table of your own to what came from firmware. Which in turn requires the EFI configuration table to be modified or replaced. Doable, but I doubt this is a very clean approach. If this was only for DomU (where the tables gets crafted from scratch anyway) it would be a different thing. But my understanding so far was that this is particularly also (if not exclusively) for Dom0. Regarding stable vs non-stable, the discussion is off point. What matters is the version number. We can implement the current version of the spec, v0.2, or we can make changes to it, introduce a new version and implement that one instead. We can pick any version number we like. Prior to a first consumer implementation - yes. But afterwards you need to remain backwards compatible. I am biased because I contributed to the current spec, so I think that the version we have is reasonable, but if we want to change it that's also OK for me. In fact if you like it, I guess we could try to make it arch-independent and use it on x86 too. As you may already have guessed from my earlier response - I'd rather not, unless unavoidable. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86: Don't crash when mapping a page using EFI runtime page tables
On 27.05.15 at 14:03, ross.lagerw...@citrix.com wrote: On 05/27/2015 12:59 PM, Jan Beulich wrote: On 27.05.15 at 12:23, ross.lagerw...@citrix.com wrote: On 05/18/2015 03:58 PM, Jan Beulich wrote: On 15.05.15 at 18:08, ross.lagerw...@citrix.com wrote: --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -32,20 +32,25 @@ static inline struct vcpu *mapcache_current_vcpu(void) return NULL; /* + * When using efi runtime page tables, we have the equivalent of the idle + * domain's page tables but current may point at another domain's VCPU. + * Return NULL as though current is not properly set up yet. + */ +if ( efi_enabled read_cr3() == efi_rs_page_table() ) +return NULL; I'm okay with the patch in principle; what worries me is the CR3 read that is now going to be necessary even in non-debug builds. With this code being the only user of efi_rs_page_table(), I wonder if it wouldn't make sense to alter that function to return non-zero only when spin_is_locked(efi_rs_lock), and then alter the code above such that the CR3 read would happen only when we got a non-zero value back. mapcache_current_vcpu() appears to be called from IRQ-enabled and IRQ-disabled callers which prevents us from using the spinlock. I didn't suggest to use any spin lock; I merely suggested checking whether that particular one is being held by someone (to avoid the CR3 read if that's not the case). spin_is_locked() calls check_lock() which causes a BUG_ON() even though you're not actually using the lock. Then some other mechanism - spin_is_locked() would have produced false positives anyway. E.g. storing the CPU which managed to acquire the lock in efi_rs_enter(), and clearing it in efi_rs_leave() before dropping the lock. efi_rs_page_table() could then return non-zero on only this one CPU. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V6] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
On 05/27/2015 04:12 PM, Jan Beulich wrote: On 27.05.15 at 10:17, rcojoc...@bitdefender.com wrote: As suggested by Andrew Cooper, this patch attempts to remove some redundancy and allow for an easier time when adding vm_events for new control registers in the future, by having a single VM_EVENT_REASON_WRITE_CTRLREG vm_event type, meant to serve CR0, CR3, CR4 and (newly introduced) XCR0. The actual control register will be deduced by the new .index field in vm_event_write_ctrlreg (renamed from vm_event_mov_to_cr). The patch has also modified the xen-access.c test - it is now able to log CR3 events. Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com Reviewed-by: Tim Deegan t...@xen.org Can this really still be considered applicable, with there having been changes that surely weren't just cosmetic? I thought so, but obviously it wasn't a good call - I'll remove Reviewed-by tags from future patches that go beyond the most trivial kind of changes (and of course, for this one in V7). @@ -88,55 +89,28 @@ static int hvm_event_traps(uint8_t sync, vm_event_request_t *req) return 1; } -static inline -void hvm_event_cr(uint32_t reason, unsigned long value, - unsigned long old, bool_t onchangeonly, bool_t sync) +void hvm_event_cr(unsigned int index, unsigned long value, unsigned long old) If this builds then there is a (pre-existing) problem: The header declaring a function should be included by the source file defining it. And if that was the case, the function name should require parenthesization to suppress macro expansion. By not dealing with this now the patch would introduce a latent issue (surfacing as soon as the header, perhaps indirectly, gets included). It did, I always check that at least make dist works before submitting my patches. Indeed it compiled because event.c did not include event.h, and it ceased to compile as soon as it was included. Will fix it in V7. --- a/xen/include/asm-x86/hvm/event.h +++ b/xen/include/asm-x86/hvm/event.h @@ -19,14 +19,14 @@ #define __ASM_X86_HVM_EVENT_H__ /* Called for current VCPU on crX/MSR changes by guest */ -void hvm_event_cr0(unsigned long value, unsigned long old); -void hvm_event_cr3(unsigned long value, unsigned long old); -void hvm_event_cr4(unsigned long value, unsigned long old); +void hvm_event_cr(unsigned int index, unsigned long value, unsigned long old); void hvm_event_msr(unsigned int msr, uint64_t value); /* Called for current VCPU: returns -1 if no listener */ int hvm_event_int3(unsigned long gla); int hvm_event_single_step(unsigned long gla); +#define hvm_event_cr(what, new, old) hvm_event_cr(VM_EVENT_X86_##what, new, old) I would have wished for the macro to be immediately adjacent to the function declaration, so that the whole picture of what works how is visible at once. Ack. Thanks, Razvan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v7 09/15] Debian: Handle lack of bootloader support in d-i on ARM.
Debian doesn't currently know what bootloader to install in a Xen
guest on ARM. We install pv-grub-menu above which actually does what
we need, but the installer doesn't treat that as a bootloader.
Most ARM platforms end up installing a u-boot boot.scr, based on a
platform whitelist. This doesn't seem appropriate for us. Grub is not
available for arm32. For arm64 we will eventually end up with in-guest
UEFI and therefore grub-efi and things will work normally. I'm not
sure what the answer is going to be for arm32.
This patch enables the workaround for Wheezy, Jessie and Sid,
post-Jessie should be enabled as we add them. (Pre-wheezy does not
support running as a Xen guest on ARM so we don't test them at all).
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v4: Handle sid too
v3: New
---
Osstest/Debian.pm| 14 --
ts-debian-di-install | 6 --
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 30b1b3a..ee24e4e 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -707,8 +707,8 @@ END
return $preseed;
}
-sub preseed_create_guest ($$;@) {
-my ($ho, $sfx, %xopts) = @_;
+sub preseed_create_guest ($$$;@) {
+my ($ho, $arch, $sfx, %xopts) = @_;
my $suite= $xopts{Suite} || $c{DebianSuite};
@@ -755,6 +755,16 @@ d-i grub-installer/bootdev string /dev/xvda
END
+# Debian doesn't currently know what bootloader to install in a
+# Xen guest on ARM. We install pv-grub-menu above which actually
+# does what we need, but the installer doesn't treat that as a
+# bootloader.
+logm(\$arch is $arch, \$suite is $suite);
+$preseed_file.= (END) if $arch =~ /^arm/ $suite =~
/wheezy|jessie|sid/;
+d-i nobootloader/confirmation_common boolean true
+
+END
+
$preseed_file .= preseed_hook_cmds();
return create_webfile($ho, preseed$sfx, $preseed_file);
diff --git a/ts-debian-di-install b/ts-debian-di-install
index 22c1930..da6ab73 100755
--- a/ts-debian-di-install
+++ b/ts-debian-di-install
@@ -158,7 +158,9 @@ END
$method_cfg = setup_netboot($tmpdir, $arch, $suite);
- $ps_url = preseed_create_guest($gho, '', Suite=$suite, PvMenuLst=($bl
eq pvgrub));
+ $ps_url = preseed_create_guest($gho, $arch, '',
+ Suite=$suite,
+ PvMenuLst=($bl eq pvgrub));
$extra_disk = ;
}
@@ -170,7 +172,7 @@ END
($method_cfg,$extra_disk) = setup_netinst($tmpdir, $arch, $cd);
- $ps_url = preseed_create_guest($gho, '', CDROM=1);
+ $ps_url = preseed_create_guest($gho, $arch, '', CDROM=1);
}
else
{
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v7 04/15] distros: Support pvgrub for Wheezy too.
This requires us to install pv-grub-menu from backports, which we do
using a late_command.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v7:
- Remove vestigial attempts to enable -backports via d-i preseeding.
v3:
- Remove spurious () from (END) (and the prexisting too)
- Remove $xopts{EnableBackports} and automatically handle the need to add
backports in preseed_base.
- Install via late_command not apt-setup, since the former has
issues, hence subject drops attempt to...
---
Osstest/Debian.pm | 33 -
make-distros-flight | 4 ++--
2 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index a3c5244..0975e73 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -709,7 +709,38 @@ sub preseed_create_guest ($$;@) {
my $suite= $xopts{Suite} || $c{DebianSuite};
-my $extra_packages = pv-grub-menu if $xopts{PvMenuLst};
+my $extra_packages = ;
+if ($xopts{PvMenuLst}) {
+if ($suite =~ m/wheezy/) {
+# pv-grub-menu/wheezy-backports + using apt-setup to add
+# backports results in iproute, ifupdown and
+# isc-dhcp-client getting removed because tasksel's
+# invocation of apt-get install somehow decides the
+# iproute2 from wheezy-backports is a thing it wants to
+# install. So instead lets fake it with a late command...
+#
+# This also has the bonus of working round an issue with
+# 1.2.1~bpo70+1 which created an invalid menu.lst using
+# root(/dev/xvda,0) which pvgrub cannot parse because
+# the Grub device.map isn't present at pkgsel/include time
+# but it is by late_command time. This was fixed by
+# version 1.3 which is in Jessie onwards.
+preseed_hook_command($ho, 'late_command', $sfx, END);
+#!/bin/sh
+set -ex
+
+(
+echo
+echo \\\# $suite backports
+echo deb http://$c{DebianMirrorHost}/$c{DebianMirrorSubpath}
$suite-backports main
+) /target/etc/apt/sources.list
+in-target apt-get update
+in-target apt-get install -y -t wheezy-backports pv-grub-menu
+END
+} else {
+$extra_packages = pv-grub-menu;
+}
+}
my $preseed_file= preseed_base($ho, $suite, $sfx, $extra_packages, %xopts);
$preseed_file.= (END);
diff --git a/make-distros-flight b/make-distros-flight
index 5fc8552..06b14f2 100755
--- a/make-distros-flight
+++ b/make-distros-flight
@@ -94,9 +94,9 @@ test_do_one_netboot () {
arm*_arm*_*) bootloader=pygrub;; # no pvgrub for arm
# Needs a menu.lst, not present in Squeeze+ due to switch to grub2,
-# workedaround in Jessie+ with pv-grub-menu package.
+# workedaround in Wheezy+ with pv-grub-menu package (backports in Wheezy,
+# in Jessie+ main).
*_squeeze) bootloader=pygrub;;
-*_wheezy) bootloader=pygrub;;
# pv-grub-x86_64.gz is not built by 32-bit dom0 userspace build.
i386_amd64_*) bootloader=pygrub;;
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v7 01/15] TestSupport: Add helper to fetch a URL on a host
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v7: Quote $url and $path, switch to a heredoc to avoid resulting over
long line
v5: Support http_proxy via $c{HttpProxy}
v3: Make sure wget is installed
---
Osstest/Debian.pm | 2 +-
Osstest/TestSupport.pm | 12 +++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 537ccbe..673ceba 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -685,7 +685,7 @@ d-i apt-setup/another boolean false
d-i apt-setup/non-free boolean false
d-i apt-setup/contrib boolean false
-d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool,
chiark-utils-bin, $extra_packages
+d-i pkgsel/include string openssh-server, ntp, ntpdate, ethtool,
chiark-utils-bin, wget, $extra_packages
$xopts{ExtraPreseed}
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index abb3195..d84ca51 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -55,7 +55,7 @@ BEGIN {
target_putfilecontents_stash
target_putfilecontents_root_stash
target_put_guest_image target_editfile
- target_editfile_cancel
+ target_editfile_cancel target_fetchurl
target_editfile_root target_file_exists
target_editfile_kvp_replace
target_run_apt
@@ -1589,6 +1589,16 @@ END
return $cfgpath;
}
+sub target_fetchurl($$$;$) {
+my ($ho, $url, $path, $timeo) = @_;
+$timeo ||= 2000;
+my $useproxy = export http_proxy=$c{HttpProxy}; if $c{HttpProxy};
+target_cmd_root($ho, END, $timeo);
+$useproxy wget --progress=dot:mega -O \$path\ \$url\
+END
+}
+
+
sub target_put_guest_image ($$;$) {
my ($ho, $gho, $default) = @_;
my $specimage = $r{$gho-{Guest}_image};
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v7 00/16] add distro domU testing flight
Hi, Since v6 I've refactored into multiple flights (one per Debian release) as well as moving all the configuration of URLs etc into make flight, so the test scripts are now generic. I also defaulted to running on the Cambridge instance as discussed. I think I've dropped the acks where appropriate, since some of those involved some bigger refactoring. More details in the individual patches. An initial portion of cleanup/refactoring has been applied so it's a shorter series this time. Summary of (A)cks, (M)odified and (N)ew (NM==Replaced something): M TestSupport: Add helper to fetch a URL on a host M distros: add support for installing Debian PV guests via d-i, flight and jobs AM distros: support booting Debian PV (d-i installed) guests with pvgrub. M distros: Support pvgrub for Wheezy too. M distros: support PV guest install from Debian netinst media. AM Test pygrub and pvgrub on the regular flights M distros: add branch infrastructure MN distros: Run one suite per day on a weekly basis Debian: Handle lack of bootloader support in d-i on ARM. ts-debian-di-install: Refactor root_disk specification make-flight: refactor PV debian tests M Add testing of non-LVM/phy disk backends. mfi-common: Allow make-*flight to filter the set of build jobs to include make-distros-flight: don't bother building for XSM or libvirt. make-distros-flight: Use ftp.debian.org directly Ian. adhoc xen-unstable test result, followed by one for distros-debian-wheezy as an example (which reused a build job due to the way in invoked it, by default it would build too, but I wanted to save time). --8- 37589: regressions - FAIL flight 37589 xen-unstable play [play] http://osstest.xs.citrite.net/~osstest/testlogs/logs/37589/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 37590 test-amd64-amd64-xl-qemut-winxpsp3 9 windows-install fail REGR. vs. 37590 test-amd64-amd64-xl-qemuu-winxpsp3 9 windows-install fail REGR. vs. 37590 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-xsm 11 guest-start fail never pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass 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-xsm 11 guest-start fail never pass test-amd64-amd64-xl-xsm 11 guest-start fail never pass test-amd64-i386-xl-xsm 11 guest-start fail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 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-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-raw 9 debian-di-installfail never pass test-amd64-amd64-xl-raw 16 guest-localmigrate/x10 fail never pass test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail never pass test-amd64-amd64-pygrub 10 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-i386-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-amd64-i386-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-check
[Xen-devel] [PATCH OSSTEST v7 02/15] distros: add support for installing Debian PV guests via d-i, flight and jobs
This patch introduces ts-debian-di-install which can install Debian
from a netboot (PXE) debian installer image. By default it installs
from the d-i image used by osstest (using the special Xen PV guest
enabled flavour where necessary) but it can also fetch the kernel and
ramdisk from URLs specified in runvars. The resulting guests boot the
distro kernel using pygrub (pvgrub will follow).
The distros flights differ substantially from the existing flights.
Introduce make-distros-flight using the functionality previously
refactored into mfi-common. The new flight tests all versions of
Debian from Squeeze onward as an amd64, i386 and armhf guests (armhf
from Jessie onwards only) using the usual smoke tests.
Test names are suffixed -pygrub pending the addition of pvgrub
variants in a future commit.
Add the new cases to sg-run-job
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v7: Use {Guest}_suite as runvar. Also use $suite not $dist in
make-distros-flight for consistency.
Switch to a flight per Debian suite model rather than one
enourmous flight.
Switch to constructing the URLs in make-distros-flight
v6: Only apply -xen suffix to x86 images when doing a netboot using
the osstest version of d-i, since that is the only arch where we
create such files, other arches can use the bare names.
Use the guest $arch not the host $r{arch} when finding the
kernel+initrd to use for d-i install using the osstest d-i.
v4: use guest create
v3: $BUILD_LVEXTEND_MAX now handled in mfi-common
Consolidate setting of ruvars
Include $flight and $job in tmpdir name
Use Osstest::Debian::di_installcmdline_core
Document the usage of get_host_property on a guest object
Correct ARM netboot paths
Include bootloader in test name
Should include -pv too?
console= repetition for Jessie onwards.
Wait for up to an hour for the install. I'd seen timeouts right at
the end of the install with the previous value
---
Osstest/TestSupport.pm | 3 +
make-distros-flight| 126 ++
sg-run-job | 11
ts-debian-di-install | 161 +
4 files changed, 301 insertions(+)
create mode 100755 make-distros-flight
create mode 100755 ts-debian-di-install
diff --git a/Osstest/TestSupport.pm b/Osstest/TestSupport.pm
index d84ca51..1b29445 100644
--- a/Osstest/TestSupport.pm
+++ b/Osstest/TestSupport.pm
@@ -934,8 +934,11 @@ sub propname_massage ($) {
return $prop;
}
+# It is fine to call this on a guest object too, in which case it will
+# always return $defval.
sub get_host_property ($$;$) {
my ($ho, $prop, $defval) = @_;
+return $defval unless $ho-{Properties};
my $val = $ho-{Properties}{propname_massage($prop)};
return defined($val) ? $val : $defval;
}
diff --git a/make-distros-flight b/make-distros-flight
new file mode 100755
index 000..586737c
--- /dev/null
+++ b/make-distros-flight
@@ -0,0 +1,126 @@
+#!/bin/bash
+
+# This is part of osstest, an automated testing framework for Xen.
+# Copyright (C) 2009-2013 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
+
+branch=$1
+xenbranch=$2
+blessing=$3
+buildflight=$4
+
+flight=`./cs-flight-create $blessing $branch`
+
+. cri-common
+. ap-common
+. mfi-common
+
+defsuite=`getconfig DebianSuite`
+defguestsuite=`getconfig GuestDebianSuite`
+
+case $branch in
+ distros-debian-*) debian_suite=${branch#distros-debian-} ;;
+ *)echo $branch 2; exit 1 ;;
+esac
+
+if [ x$buildflight = x ]; then
+
+ WANT_XEND=false REVISION_LINUX_OLD=disable
+
+ create_build_jobs
+
+else
+
+ bfi=$buildflight.
+
+fi
+
+job_create_test_filter_callback () {
+ if [ $xenarch = i386 ]; then return 1; fi
+ return 0
+}
+
+test_matrix_branch_filter_callback () {
+:
+}
+
+test_do_one_netboot () {
+ local diurl=
+
+ if [ x$gsuite = xsnapshot ] ; then
+ diurl=http://d-i.debian.org/daily-images/$domU/daily/netboot;
+ gsuite=sid
+ gver=daily
+ else
+local mirror=http://`getconfig DebianMirrorHost`/`getconfig
DebianMirrorSubpath`
+diurl=$mirror/dists/$gsuite/main/installer-$domU/current/images/netboot
+gver=$gsuite
+ fi
+
+ case ${domU}_${gsuite} in
+armhf_squeeze) return;; # No armhf in Squeeze
+armhf_wheezy) return;; #
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
On 05/27/2015 11:09 AM, Juergen Gross wrote: George, I'm on vacation this and the next week with only limited email access. So please don't expect fast reaction on any further questions during this time. :-) Then quit reading your work e-mail and get back to the important stuff! :-) OK, so I looked it up[1] and the full address seems to be: * adapter number / host * channel number / bus * id number / target * LUN In which case, controller would correspond to adapter / host, right? In the vscsi world, what levels of what can you make? I know you mentioned before that some devices have multiple LUNs, and those need to be grouped together, with the same LUNs as they do on real hardware, to work properly -- is that right? Not all of the devices have this requirement, but some. The USB case actually has something somewhat similar: * USB controller * USB bus * USB device * USB function So far, there's not really a controller/bus distinction: each controller has exactly one bus. When we assign a USB device to a bus, we automatically go through and assign each function fo that device individually. Would it make sense to treat vscsi the same way -- i.e., to make a bus, and then attach targetss to it, and have the LUNs for any given target automatically assigned when the target is assigned? As long as it is still possible to assign individual LUNs as well. If dom0 is controlling e.g. a RAID system you might want to assign one LUN of a target to domU A and one LUN of the same target to domU B. OK, so it sounds like in the vscsi case, it would be useful to assign either an entire target, or an individual LUN. In the case of assigning a target, you'll want to assign all the LUNs as well, such that the virtual LUNs mirror the real LUNs. In the case of assigning a LUN, I assume you'll still need a virtual target. Will you be wanting an interface for creating virtual targets, so that you can assign several real LUNs to the same target? Or will you just want one virtual target per LUN if you're not assigning an entire target? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v22 02/14] x86/VPMU: Add public xenpmu.h
On 26.05.15 at 19:50, boris.ostrov...@oracle.com wrote:
On 05/26/2015 12:13 PM, Jan Beulich wrote:
On 21.05.15 at 19:57, boris.ostrov...@oracle.com wrote:
+ * guest when PMU_CACHED bit in pmu_flags is set (which is done by the
+ * hypervisor during PMU interrupt). Hypervisor will read updated data in
+ * XENPMU_flush hypercall and clear PMU_CACHED bit.
+ */
+struct xen_pmu_arch {
+union {
+/*
+ * Processor's registers at the time of interrupt.
+ * WO for hypervisor, RO for guests.
+ */
+struct xen_pmu_regs regs;
+/* Padding for adding new registers to xen_pmu_regs in the future
*/
+#define XENPMU_REGS_PAD_SZ 64
+uint8_t pad[XENPMU_REGS_PAD_SZ];
+} r;
+
+/* WO for hypervisor, RO for guest */
+uint64_t pmu_flags;
+
+/*
+ * APIC LVTPC register.
+ * RW for both hypervisor and guest.
+ * Only APIC_LVT_MASKED bit is loaded by the hypervisor into hardware
+ * during XENPMU_flush or XENPMU_lvtpc_set.
+ */
+union {
+uint32_t lapic_lvtpc;
Considering this isn't being used in this patch, could I ask you to
move it where it is being used (keeping only the pad member and
perhaps a placeholder comment here), so verifying that the
read-once requirement for the hypervisor side is met becomes
more obvious?
I can certainly delay defining this field until later patch but how is
this filed different from xen_pmu_arch (not seen here) which is also
read-once? Wouldn't you then want to have that definition deferred as well?
I'm confused - the only xen_pmu_arch I see in this patch is
struct xen_pmu_arch (and its uses), which the field above is
actually part of, and which is also visible in the context above. So
I doubt that's what you're referring to. But yes, fields with read-
once requirements would better be defined in the patch(es) using
them, so reviewers don't need to hunt them down.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [stable] config: Enable NEED_DMA_MAP_STATE by default when SWIOTLB is selected
On Mon, May 25, 2015 at 01:56:01AM +0100, Ben Hutchings wrote: This fix appears to be needed in all stable branches: commit a6dfa128ce5c414ab46b1d690f7a1b8decb8526d Author: Konrad Rzeszutek Wilk konrad.w...@oracle.com Date: Fri Apr 17 15:04:48 2015 -0400 config: Enable NEED_DMA_MAP_STATE by default when SWIOTLB is selected Thanks, queuing it for 3.16. Cheers, -- Luís For 3.2 and 3.4, the context needs to be fixed up. For 2.6.32, a similar change to config conditions should be made at line 93 of arch/x86/include/asm/pci.h. Ben. -- Ben Hutchings Design a system any fool can use, and only a fool will want to use it. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v22 11/14] x86/VPMU: Handle PMU interrupts for PV(H) guests
On 26.05.15 at 20:09, boris.ostrov...@oracle.com wrote:
On 05/26/2015 12:24 PM, Jan Beulich wrote:
On 21.05.15 at 19:57, boris.ostrov...@oracle.com wrote:
@@ -188,27 +189,52 @@ static inline void context_load(struct vcpu *v)
}
}
-static void amd_vpmu_load(struct vcpu *v)
+static int amd_vpmu_load(struct vcpu *v, bool_t from_guest)
{
struct vpmu_struct *vpmu = vcpu_vpmu(v);
-struct xen_pmu_amd_ctxt *ctxt = vpmu-context;
-uint64_t *ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
+struct xen_pmu_amd_ctxt *ctxt;
+uint64_t *ctrl_regs;
+unsigned int i;
vpmu_reset(vpmu, VPMU_FROZEN);
-if ( vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
+if ( !from_guest vpmu_is_set(vpmu, VPMU_CONTEXT_LOADED) )
{
-unsigned int i;
+ctxt = vpmu-context;
+ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
for ( i = 0; i num_counters; i++ )
wrmsrl(ctrls[i], ctrl_regs[i]);
-return;
+return 0;
+}
+
+if ( from_guest )
+{
+ASSERT(!is_hvm_vcpu(v));
+
+ctxt = vpmu-xenpmu_data-pmu.c.amd;
+ctrl_regs = vpmu_reg_pointer(ctxt, ctrls);
+for ( i = 0; i num_counters; i++ )
+{
+if ( is_pmu_enabled(ctrl_regs[i]) )
+{
+vpmu_set(vpmu, VPMU_RUNNING);
+break;
+}
+}
+
+if ( i == num_counters )
+vpmu_reset(vpmu, VPMU_RUNNING);
+
+memcpy(vpmu-context, vpmu-xenpmu_data-pmu.c.amd, ctxt_sz);
}
vpmu_set(vpmu, VPMU_CONTEXT_LOADED);
context_load(v);
+
+return 0;
}
So no verification needed at all on the AMD side? If so,
So I went back to BKDGs and it looks like some models of family 15
redefined one of the bits from Reserved to MBZ so I think I'll need to
verify that bit now.
It's rather strange that this bit (MSRC001_0200[19]) is reserved for
models 00h-0Fh and 30-3Fh but is MBZ for 10h-1Fh. It is also reserved
for families 10h and 16h. I don't have access to the MBZ models so I
can't test whether it is indeed MBZ or a typo in the spec (I can
certainly write it with 1 on family 10h and 15h/model2).
But no matter whether reserved or MBZ, you'd need to guard
against the guest writing values there anyway. The only
difference would be whether to expect zeros or no change.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v7 11/15] make-flight: refactor PV debian tests
No functional change, standalone-generate-dump-flight-runvars confirms
no change to the runvars.
Includes a hook which is not used yet, $recipe_sfx.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v4: new patch
---
make-flight | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/make-flight b/make-flight
index 99fb1ee..8206508 100755
--- a/make-flight
+++ b/make-flight
@@ -349,6 +349,17 @@ do_pvgrub_tests () {
all_hostflags=$most_hostflags
}
+do_pv_debian_test_one () {
+ testname=$1; shift
+ recipe_sfx=$1; shift
+ toolstack=$1; shift
+
+ job_create_test test-$xenarch$kern-$dom0arch-$testname\
+ test-debian$recipe_sfx $toolstack \
+$xenarch $dom0arch \
+$debian_runvars all_hostflags=$most_hostflags $@
+}
+
do_pv_debian_tests () {
xsms=$(xenbranch_xsm_variants)
@@ -364,20 +375,13 @@ do_pv_debian_tests () {
suffix=${platform:+-$platform}
hostflags=${most_hostflags}${platform:+,platform-$platform}
- job_create_test test-$xenarch$kern-$dom0arch-xl$suffix \
- test-debian xl \
- $xenarch $dom0arch \
- enable_xsm=$xsm \
- $debian_runvars all_hostflags=$hostflags
+ do_pv_debian_test_one xl$suffix '' xl enable_xsm=$xsm
+
done
done
for xsm in $xsms ; do
-job_create_test test-$xenarch$kern-$dom0arch-libvirt \
-test-debian libvirt \
-$xenarch $dom0arch \
-enable_xsm=$xsm \
-$debian_runvars all_hostflags=$most_hostflags
+do_pv_debian_test_one libvirt '' libvirt enable_xsm=$xsm
done
}
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v7 14/15] make-distros-flight: don't bother building for XSM or libvirt.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
make-distros-flight | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/make-distros-flight b/make-distros-flight
index c61f5c8..49f4b60 100755
--- a/make-distros-flight
+++ b/make-distros-flight
@@ -39,7 +39,15 @@ case $branch in
esac
job_create_build_filter_callback () {
-:
+ local job=$1; shift
+
+ case $job in
+build-*-libvirt) return 1;;
+ esac
+ case $* in
+* enable_xsm=true *) return 1;;
+ esac
+ return 0
}
if [ x$buildflight = x ]; then
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v7 07/15] distros: add branch infrastructure
Since the distro nightlies are not version controlled we cannot use
the usual mechanisms for detecting regressions. Special case things
appropriately. We use an OLD_REVISION of flight-NNN to signify that
the old revision is another flight and not a tree revision.
A grep over $NEW_REVISION needed adjusting since NEW_REVISION is empty
in this mode, leading to grep filename which hangs waiting for
stdin.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v7:
Handle empty $NEW_REVISION by quoting it instead of a needless test -n
Switch to flight-per-suite model
v3:
Handle within cr-daily-branch, since ap-fetch-version* don't make sense for
a branch such as this.
---
cr-daily-branch | 36
cri-common | 1 +
2 files changed, 29 insertions(+), 8 deletions(-)
diff --git a/cr-daily-branch b/cr-daily-branch
index c7d1071..99a2315 100755
--- a/cr-daily-branch
+++ b/cr-daily-branch
@@ -68,23 +68,34 @@ fetch_version () {
printf '%s\n' $fetch_version_result
}
-treeurl=`./ap-print-url $branch`
+case $branch in
+distros-*)
+ treeurl=none;;
+*)
+ treeurl=`./ap-print-url $branch`;;
+esac
force_baseline=false
skipidentical=true
wantpush=$OSSTEST_PUSH
-if [ x$OLD_REVISION = x ]; then
-OLD_REVISION=`./ap-fetch-version-old $branch`
-export OLD_REVISION
-fi
-
check_tested () {
./sg-check-tested --debug --branch=$branch \
--blessings=${DAILY_BRANCH_TESTED_BLESSING:-$OSSTEST_BLESSING} \
$@
}
+if [ x$OLD_REVISION = x ]; then
+case $branch in
+ distros-*)
+ OSSTEST_NO_BASELINE=y
+ OLD_REVISION=flight-`check_tested`
+ ;;
+ *) OLD_REVISION=`./ap-fetch-version-old $branch`;;
+esac
+export OLD_REVISION
+fi
+
if [ x$OSSTEST_NO_BASELINE != xy ] ; then
testedflight=`check_tested --revision-$tree=$OLD_REVISION`
@@ -227,6 +238,11 @@ if [ x$OLD_REVISION = xdetermine-late ]; then
OLD_REVISION=`./ap-fetch-version-baseline-late $branch $NEW_REVISION`
fi
+case $branch in
+distros-*) makeflight=./make-distros-flight ;;
+*) makeflight=./make-flight ;;
+esac
+
if [ x$NEW_REVISION = x$OLD_REVISION ]; then
wantpush=false
for checkbranch in x $BRANCHES_ALWAYS; do
@@ -241,7 +257,7 @@ if [ x$NEW_REVISION = x$OLD_REVISION ]; then
fi
$DAILY_BRANCH_PREMAKE_HOOK
-flight=`./make-flight $branch $xenbranch $OSSTEST_BLESSING $@`
+flight=`$makeflight $branch $xenbranch $OSSTEST_BLESSING $@`
$DAILY_BRANCH_POSTMAKE_HOOK
heading=tmp/$flight.heading-info
@@ -261,6 +277,10 @@ fi
revlog=tmp/$flight.revision-log
case $NEW_REVISION/$OLD_REVISION in
+/flight-[0-9]*)
+ echo 2 SGR COMPARISON AGAINST ${OLD_REVISION}
+ sgr_args+= --that-flight=${OLD_REVISION#flight-}
+ ;;
*/*[^0-9a-f]* | *[^0-9a-f]*/*)
echo 2 NO SGR COMPARISON badchar $NEW_REVISION/$OLD_REVISION
;;
@@ -321,7 +341,7 @@ start_email $flight $branch $sgr_args $subject_prefix
push=false
if grep '^tolerable$' $mrof /dev/null 21; then push=$wantpush; fi
if test -f $branch.force; then push=$OSSTEST_PUSH; fi
-if grep -xF $NEW_REVISION $branch.force-rev; then push=$OSSTEST_PUSH; fi
+if grep -xF $NEW_REVISION $branch.force-rev; then push=$OSSTEST_PUSH; fi
if test -f $branch.block; then push=false; fi
if test -e $mrof test -e $tree_bisect ! grep '^broken' $mrof; then
diff --git a/cri-common b/cri-common
index ad44546..58b08f2 100644
--- a/cri-common
+++ b/cri-common
@@ -72,6 +72,7 @@ select_xenbranch () {
rumpuserxen) tree=rumpuserxen; xenbranch=xen-unstable ;;
seabios)tree=seabios; xenbranch=xen-unstable ;;
ovmf) tree=ovmf; xenbranch=xen-unstable ;;
+ distros-*) tree=none; xenbranch=xen-unstable ;;
osstest)tree=osstest; xenbranch=xen-unstable ;;
esac
if [ x$tree = xlinux ]; then
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v7 06/15] Test pygrub and pvgrub on the regular flights
Since we now have the ability to test these drop one of each of
pygrub, pvgrub-32 and pvgrub-64 into the standard flights. Omitting
the {Guest}_diver runvar causes ts-debian-di-install to use the d-i
images in the location configured via TftpDiVersion, so they are
Version Controlled along with the d-i version used for the host.
This adds three new jobs:
+test-amd64-amd64-amd64-pvgrub all_hostflags
arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
+test-amd64-amd64-amd64-pvgrub archamd64
+test-amd64-amd64-amd64-pvgrub buildjob
build-amd64
+test-amd64-amd64-amd64-pvgrub debian_arch amd64
+test-amd64-amd64-amd64-pvgrub debian_bootloader
pvgrub
+test-amd64-amd64-amd64-pvgrub debian_method
netboot
+test-amd64-amd64-amd64-pvgrub debian_suite
wheezy
+test-amd64-amd64-amd64-pvgrub kernbuildjob
build-amd64-pvops
+test-amd64-amd64-amd64-pvgrub kernkindpvops
+test-amd64-amd64-amd64-pvgrub toolstack xl
+test-amd64-amd64-amd64-pvgrub xenbuildjob
build-amd64
+test-amd64-amd64-i386-pvgrub all_hostflags
arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
+test-amd64-amd64-i386-pvgrub archamd64
+test-amd64-amd64-i386-pvgrub buildjob
build-amd64
+test-amd64-amd64-i386-pvgrub debian_arch i386
+test-amd64-amd64-i386-pvgrub debian_bootloader
pvgrub
+test-amd64-amd64-i386-pvgrub debian_method
netboot
+test-amd64-amd64-i386-pvgrub debian_suite
wheezy
+test-amd64-amd64-i386-pvgrub kernbuildjob
build-amd64-pvops
+test-amd64-amd64-i386-pvgrub kernkindpvops
+test-amd64-amd64-i386-pvgrub toolstack xl
+test-amd64-amd64-i386-pvgrub xenbuildjob
build-amd64
+test-amd64-amd64-pygrub all_hostflags
arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
+test-amd64-amd64-pygrub archamd64
+test-amd64-amd64-pygrub buildjob
build-amd64
+test-amd64-amd64-pygrub debian_arch amd64
+test-amd64-amd64-pygrub debian_bootloader
pygrub
+test-amd64-amd64-pygrub debian_method
netboot
+test-amd64-amd64-pygrub debian_suite
wheezy
+test-amd64-amd64-pygrub kernbuildjob
build-amd64-pvops
+test-amd64-amd64-pygrub kernkindpvops
+test-amd64-amd64-pygrub toolstack xl
+test-amd64-amd64-pygrub xenbuildjob
build-amd64
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
---
v7: Use {Guest}_suite not {Guest}_dist as runvar to choose version.
Refreshed runvars i ncommit message.
v3: added runvar details
---
make-flight | 39 +++
1 file changed, 39 insertions(+)
diff --git a/make-flight b/make-flight
index 8a1fceb..99fb1ee 100755
--- a/make-flight
+++ b/make-flight
@@ -313,6 +313,42 @@ do_passthrough_tests () {
done
}
+do_pygrub_tests () {
+ if [ $xenarch != amd64 -o $dom0arch != amd64 -o $kern != ]; then
+return
+ fi
+
+ job_create_test test-$xenarch$kern-$dom0arch-pygrub \
+test-debian-di xl $xenarch $dom0arch\
+ debian_arch=amd64 \
+ debian_suite=$guestsuite \
+ debian_method=netboot \
+ debian_bootloader=pygrub \
+ all_hostflags=$most_hostflags
+}
+
+do_pvgrub_tests () {
+ if [ $xenarch != amd64 -o $dom0arch != amd64 -o $kern != ]; then
+return
+ fi
+
+ job_create_test test-$xenarch$kern-$dom0arch-amd64-pvgrub \
+test-debian-di xl $xenarch $dom0arch\
+ debian_arch=amd64 \
+ debian_suite=$guestsuite \
+ debian_method=netboot \
+ debian_bootloader=pvgrub \
+ all_hostflags=$most_hostflags \
+
+ job_create_test test-$xenarch$kern-$dom0arch-i386-pvgrub \
+test-debian-di xl $xenarch $dom0arch\
+
[Xen-devel] [PATCH OSSTEST v7 13/15] mfi-common: Allow make-*flight to filter the set of build jobs to include
By using the same job_create_build(_filter_callback) scheme used for
the test jobs.
Will be used in make-distros-flight.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
make-distros-flight | 4
make-flight | 4
mfi-common | 21 +++--
3 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/make-distros-flight b/make-distros-flight
index 4b9f100..c61f5c8 100755
--- a/make-distros-flight
+++ b/make-distros-flight
@@ -38,6 +38,10 @@ case $branch in
*)echo $branch 2; exit 1 ;;
esac
+job_create_build_filter_callback () {
+:
+}
+
if [ x$buildflight = x ]; then
WANT_XEND=false REVISION_LINUX_OLD=disable
diff --git a/make-flight b/make-flight
index 0313696..f97fb73 100755
--- a/make-flight
+++ b/make-flight
@@ -34,6 +34,10 @@ flight=`./cs-flight-create $blessing $branch`
defsuite=`getconfig DebianSuite`
defguestsuite=`getconfig GuestDebianSuite`
+job_create_build_filter_callback () {
+:
+}
+
if [ x$buildflight = x ]; then
create_build_jobs
diff --git a/mfi-common b/mfi-common
index a9e966f..a100afb 100644
--- a/mfi-common
+++ b/mfi-common
@@ -54,6 +54,15 @@ xenbranch_xsm_variants () {
esac
}
+job_create_build () {
+ job_create_build_filter_callback $@ || return 0
+
+ local job=$1; shift
+ local recipe=$1; shift
+
+ ./cs-job-create $flight $job $recipe $@
+}
+
create_build_jobs () {
local arch
@@ -164,7 +173,7 @@ create_build_jobs () {
else
xsm_suffix=
fi
- ./cs-job-create $flight build-$arch$xsm_suffix build \
+ job_create_build build-$arch$xsm_suffix build \
arch=$arch enable_xend=$build_defxend enable_ovmf=$enable_ovmf\
enable_xsm=$enable_xsm \
tree_qemu=$TREE_QEMU \
@@ -183,7 +192,7 @@ create_build_jobs () {
done
if [ $build_extraxend = true ] ; then
-./cs-job-create $flight build-$arch-xend build \
+job_create_build build-$arch-xend build \
arch=$arch enable_xend=true enable_ovmf=$enable_ovmf \
tree_qemu=$TREE_QEMU \
tree_qemuu=$TREE_QEMU_UPSTREAM \
@@ -196,7 +205,7 @@ create_build_jobs () {
revision_qemuu=$REVISION_QEMU_UPSTREAM
fi
-./cs-job-create $flight build-$arch-pvops build-kern \
+job_create_build build-$arch-pvops build-kern\
arch=$arch kconfighow=xen-enable-xen-config \
$RUNVARS $BUILD_RUNVARS $BUILD_LINUX_RUNVARS $arch_runvars \
$suite_runvars \
@@ -208,7 +217,7 @@ create_build_jobs () {
if [ x$REVISION_LIBVIRT != xdisable ]; then
-./cs-job-create $flight build-$arch-libvirt build-libvirt\
+job_create_build build-$arch-libvirt build-libvirt \
arch=$arch \
tree_xen=$TREE_XEN \
$RUNVARS $BUILD_RUNVARS $BUILD_LIBVIRT_RUNVARS $arch_runvars \
@@ -223,7 +232,7 @@ create_build_jobs () {
case $arch in
i386|amd64)
-./cs-job-create $flight build-$arch-rumpuserxen build-rumpuserxen\
+job_create_build build-$arch-rumpuserxen build-rumpuserxen \
arch=$arch \
tree_xen=$TREE_XEN \
$RUNVARS $BUILD_RUNVARS $BUILD_RUMPUSERXEN_RUNVARS
$arch_runvars \
@@ -252,7 +261,7 @@ create_build_jobs () {
if [ x$REVISION_LINUX_OLD != xdisable ]; then
- ./cs-job-create $flight build-$arch-oldkern build-kern\
+ job_create_build build-$arch-oldkern build-kern \
arch=$arch kconfighow=create-config-sh \
kimagefile=vmlinux \
$RUNVARS $BUILD_RUNVARS $BUILD_LINUX_OLD_RUNVARS\
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v7 03/15] distros: support booting Debian PV (d-i installed) guests with pvgrub.
This requires the use of the pv-grub-menu package which is in Jessie
onwards. (it is in wheezy-backports which is the subject of a
subsequent patch).
The bootloader to use is specified via a runvar {Guest}_bootloader.
Adjust make-distros-flight to use pvgrub for some subset of i386 and
amd64 guests to get coverage.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
Acked-by: Ian Jackson ian.jack...@eu.citrix.com
---
v7: Move definition of $extra_packages variable to here which is its
first usage.
Use {Guest}_suite not {Guest}_dist as runvar to choose version.
v3: Define and use arch_debian2xen and arch_xen2debian
Avoid pv-grub-x86_64.gz on i386 dom0, we don't built it there.
Fiddle with py vs pv grub stripy a bit.
---
Osstest.pm | 7 +++
Osstest/Debian.pm| 4 +++-
make-distros-flight | 20 +++-
ts-debian-di-install | 11 +--
4 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/Osstest.pm b/Osstest.pm
index e8bd77b..e189017 100644
--- a/Osstest.pm
+++ b/Osstest.pm
@@ -38,6 +38,7 @@ BEGIN {
db_begin_work
ensuredir get_filecontents_core_quiet system_checked
nonempty visible_undef show_abs_time
+ %arch_debian2xen %arch_xen2debian
);
%EXPORT_TAGS = ( );
@@ -49,6 +50,12 @@ our $mjobdb;
our $dbh_tests;
+our %arch_debian2xen = qw(i386 x86_32
+ amd64 x86_64
+ armhf armhf);
+our %arch_xen2debian;
+$arch_xen2debian{$arch_debian2xen{$_}} = $_ foreach keys %arch_debian2xen;
+
#-- static default config settings --
our %c = qw(
diff --git a/Osstest/Debian.pm b/Osstest/Debian.pm
index 673ceba..a3c5244 100644
--- a/Osstest/Debian.pm
+++ b/Osstest/Debian.pm
@@ -709,7 +709,9 @@ sub preseed_create_guest ($$;@) {
my $suite= $xopts{Suite} || $c{DebianSuite};
-my $preseed_file= preseed_base($ho, $suite, $sfx, '', %xopts);
+my $extra_packages = pv-grub-menu if $xopts{PvMenuLst};
+
+my $preseed_file= preseed_base($ho, $suite, $sfx, $extra_packages, %xopts);
$preseed_file.= (END);
d-i partman-auto/method string regular
d-i partman-auto/choose_recipe \\
diff --git a/make-distros-flight b/make-distros-flight
index 586737c..5fc8552 100755
--- a/make-distros-flight
+++ b/make-distros-flight
@@ -78,6 +78,11 @@ test_do_one_netboot () {
*) ;;
esac
+ stripy bootloader pvgrub pygrub \
+$xenarch amd64 \
+$dom0arch i386 \
+$domU amd64 \
+
case $domU in
i386|amd64)
diurl=$diurl/xen;;
@@ -85,8 +90,20 @@ test_do_one_netboot () {
diurl=$diurl/debian-installer/arm64;;
esac
+ case ${dom0arch}_${domU}_${gsuite} in
+arm*_arm*_*) bootloader=pygrub;; # no pvgrub for arm
+
+# Needs a menu.lst, not present in Squeeze+ due to switch to grub2,
+# workedaround in Jessie+ with pv-grub-menu package.
+*_squeeze) bootloader=pygrub;;
+*_wheezy) bootloader=pygrub;;
+
+# pv-grub-x86_64.gz is not built by 32-bit dom0 userspace build.
+i386_amd64_*) bootloader=pygrub;;
+ esac
+
job_create_test \
- test-$xenarch$kern-$dom0arch-$domU-$gver-netboot-pygrub \
+ test-$xenarch$kern-$dom0arch-$domU-$gver-netboot-$bootloader \
test-debian-di xl $xenarch $dom0arch\
kernbuildjob=${bfi}build-$dom0arch-$kernbuild \
debian_arch=$domU \
@@ -94,6 +111,7 @@ test_do_one_netboot () {
debian_method=netboot \
debian_netboot_kernel=$diurl/vmlinuz\
debian_netboot_ramdisk=$diurl/initrd.gz \
+ debian_bootloader=$bootloader \
all_hostflags=$most_hostflags
}
diff --git a/ts-debian-di-install b/ts-debian-di-install
index ed3c348..14167c8 100755
--- a/ts-debian-di-install
+++ b/ts-debian-di-install
@@ -88,6 +88,8 @@ sub ginstall () {
my $method= $r{$gho-{Guest}_method};
my $tmpdir= /root/$flight-$job-di;
+my $bl= $r{$gho-{Guest}_bootloader};
+
target_cmd_root($ho, END);
rm -rf $tmpdir
mkdir $tmpdir
@@ -102,7 +104,7 @@ END
$method_cfg = setup_netboot($tmpdir, $arch, $suite);
- $ps_url = preseed_create_guest($gho, '', Suite=$suite);
+ $ps_url = preseed_create_guest($gho, '', Suite=$suite, PvMenuLst=($bl
eq pvgrub));
$extra_disk = ;
}
@@ -143,7 +145,12 @@ END
guest_await_shutdown($ho,$gho,3600);
guest_destroy($gho);
-my $blcfg = END;
+my $xenarch = $arch_debian2xen{$arch};
+my $pvgrub = /usr/local/lib/xen/boot/pv-grub-$xenarch.gz;
+my $blcfg = $bl eq pvgrub ? END : END;
+kernel = $pvgrub
+extra = (hd0,0)/boot/grub/menu.lst
+END
bootloader = pygrub
END
--
2.1.4
___
Xen-devel mailing
[Xen-devel] [PATCH OSSTEST v7 12/15] Add testing of non-LVM/phy disk backends.
xen-create-image makes this tricky to do since it is rather LVM
centric. Now that we have the ability to install from d-i it's
possible to arrange fairly easily that they use non-LVM disk backend
arrangements.
Here we add support to the test script and infra and create a bunch of
new jobs testing the cross product of {xl,libvirt} x {raw,qcow2,vhd}.
The test scripts are modified such that when constructing a domain
with a non-LVM diskfmt runvar:
- the LVM device is slightly enlarged to account for file format
headers (1M should be plenty).
- the LVM device will have an ext3 filesystem created on it instead
of being used as a phy device for the guest. Reusing the LVM volume
in this way means we don't need to do more storage management in
dom0 (i.e. arranging for / to be large enough, or managing a
special images LV)
- the relevant type of container is created within the filesystem
using the appropriate tool.
- New properties Disk{fmt,spec} are added to all $gho, containing
the format used for the root disk and the xl diskspec to load it.
- lvm backed guests use a xend/xm compatible spec, everything
else uses the improved xl syntax which libvirt also supports.
We won't test non-LVM on xend.
- New properties Disk{mnt,img} are added to $gho which are not using
LVM. These contain the mount point to use (configurable via
OSSTEST_CONFIG and runvars) and the full path (including mount
point) to the image itself.
- When starting or stopping a guest we arrange for the filesystem to
be (u)mounted.
- The prepearation when starting a guest copes gracefully with
the disk already being prepared.
- Hooks are called from guest_create() and guest_destroy() to
manipulate the disk as needed.
Using standalong-generate-dump-flight-runvars a representative set of
runvars is:
+test-amd64-amd64-xl-qcow2 all_hostflags
arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
+test-amd64-amd64-xl-qcow2 archamd64
+test-amd64-amd64-xl-qcow2 buildjob
build-amd64
+test-amd64-amd64-xl-qcow2 debian_arch amd64
+test-amd64-amd64-xl-qcow2 debian_bootloader
pygrub
+test-amd64-amd64-xl-qcow2 debian_diskfmt qcow2
+test-amd64-amd64-xl-qcow2 debian_kernkind pvops
+test-amd64-amd64-xl-qcow2 debian_method
netboot
+test-amd64-amd64-xl-qcow2 debian_suite
wheezy
+test-amd64-amd64-xl-qcow2 kernbuildjob
build-amd64-pvops
+test-amd64-amd64-xl-qcow2 kernkindpvops
+test-amd64-amd64-xl-qcow2 toolstack xl
+test-amd64-amd64-xl-qcow2 xenbuildjob
build-amd64
Compared to test-amd64-amd64-pygrub (which is the most similar job) and
normalising the test name the difference is:
test-amd64-amd64-SUFFIX all_hostflags
arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
test-amd64-amd64-SUFFIX archamd64
test-amd64-amd64-SUFFIX buildjob
build-amd64
test-amd64-amd64-SUFFIX debian_arch amd64
test-amd64-amd64-SUFFIX debian_bootloader
pygrub
+test-amd64-amd64-SUFFIX debian_diskfmt qcow2
+test-amd64-amd64-SUFFIX debian_kernkind pvops
test-amd64-amd64-SUFFIX debian_method
netboot
test-amd64-amd64-SUFFIX debian_suite
wheezy
test-amd64-amd64-SUFFIX kernbuildjob
build-amd64-pvops
test-amd64-amd64-SUFFIX kernkindpvops
test-amd64-amd64-SUFFIX toolstack xl
test-amd64-amd64-SUFFIX xenbuildjob
build-amd64
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
v7: Use the right arch for tests, not always amd64 (doesn't work well
on arm!)
Defer guest_find_diskimg until _vg runvar and thence Lvdev are
setup:
selectguest calls guest_find_lv then guest_find_diskimg, using
preexisting runvars.
But prepare_guest calls selectguest before setting disk_lv, so
Lvdev ends up undefined, after setting disk_lv prepare_guest
calls guest_find_lv+guest_find_diskimg again and things get
configured.
This follows how guest_find_lv only sets Lvdev iff Vg and Lv
are both set.
Use {Guest}_suite not {Guest}_dist as runvar to choose version.
Assume slower dd for raw population,
[Xen-devel] [PATCH OSSTEST v7 15/15] make-distros-flight: Use ftp.debian.org directly
The local proxy seems to serve stale packages for Jessie etc, I blame
the intercepting cache on the way out of our network, similar to
b5f15136900d mg-debian-installer-update: workaround caching proxies,
except it is between the apt-cache and the world not the osstest vm
and the world.
Since the netboot kernel+initrd are reasonably small, these flights
are infrequent and they are intended to test the current upstream
version I think this is tollerable.
Signed-off-by: Ian Campbell ian.campb...@citrix.com
---
make-distros-flight | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/make-distros-flight b/make-distros-flight
index 49f4b60..d407fcb 100755
--- a/make-distros-flight
+++ b/make-distros-flight
@@ -79,7 +79,9 @@ test_do_one_netboot () {
gsuite=sid
gver=daily
else
-local mirror=http://`getconfig DebianMirrorHost`/`getconfig
DebianMirrorSubpath`
+#local mirror=http://`getconfig DebianMirrorHost`/`getconfig
DebianMirrorSubpath`
+# XXX local mirror seems to serve up stale files.
+local mirror=http://ftp.debian.org/debian;
diurl=$mirror/dists/$gsuite/main/installer-$domU/current/images/netboot
gver=$gsuite
fi
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86: Don't crash when mapping a page using EFI runtime page tables
On 05/27/2015 12:59 PM, Jan Beulich wrote: On 27.05.15 at 12:23, ross.lagerw...@citrix.com wrote: On 05/18/2015 03:58 PM, Jan Beulich wrote: On 15.05.15 at 18:08, ross.lagerw...@citrix.com wrote: --- a/xen/arch/x86/domain_page.c +++ b/xen/arch/x86/domain_page.c @@ -32,20 +32,25 @@ static inline struct vcpu *mapcache_current_vcpu(void) return NULL; /* + * When using efi runtime page tables, we have the equivalent of the idle + * domain's page tables but current may point at another domain's VCPU. + * Return NULL as though current is not properly set up yet. + */ +if ( efi_enabled read_cr3() == efi_rs_page_table() ) +return NULL; I'm okay with the patch in principle; what worries me is the CR3 read that is now going to be necessary even in non-debug builds. With this code being the only user of efi_rs_page_table(), I wonder if it wouldn't make sense to alter that function to return non-zero only when spin_is_locked(efi_rs_lock), and then alter the code above such that the CR3 read would happen only when we got a non-zero value back. mapcache_current_vcpu() appears to be called from IRQ-enabled and IRQ-disabled callers which prevents us from using the spinlock. I didn't suggest to use any spin lock; I merely suggested checking whether that particular one is being held by someone (to avoid the CR3 read if that's not the case). spin_is_locked() calls check_lock() which causes a BUG_ON() even though you're not actually using the lock. -- Ross Lagerwall ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V6] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
On 27.05.15 at 10:17, rcojoc...@bitdefender.com wrote: As suggested by Andrew Cooper, this patch attempts to remove some redundancy and allow for an easier time when adding vm_events for new control registers in the future, by having a single VM_EVENT_REASON_WRITE_CTRLREG vm_event type, meant to serve CR0, CR3, CR4 and (newly introduced) XCR0. The actual control register will be deduced by the new .index field in vm_event_write_ctrlreg (renamed from vm_event_mov_to_cr). The patch has also modified the xen-access.c test - it is now able to log CR3 events. Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com Reviewed-by: Tim Deegan t...@xen.org Can this really still be considered applicable, with there having been changes that surely weren't just cosmetic? @@ -88,55 +89,28 @@ static int hvm_event_traps(uint8_t sync, vm_event_request_t *req) return 1; } -static inline -void hvm_event_cr(uint32_t reason, unsigned long value, - unsigned long old, bool_t onchangeonly, bool_t sync) +void hvm_event_cr(unsigned int index, unsigned long value, unsigned long old) If this builds then there is a (pre-existing) problem: The header declaring a function should be included by the source file defining it. And if that was the case, the function name should require parenthesization to suppress macro expansion. By not dealing with this now the patch would introduce a latent issue (surfacing as soon as the header, perhaps indirectly, gets included). --- a/xen/include/asm-x86/hvm/event.h +++ b/xen/include/asm-x86/hvm/event.h @@ -19,14 +19,14 @@ #define __ASM_X86_HVM_EVENT_H__ /* Called for current VCPU on crX/MSR changes by guest */ -void hvm_event_cr0(unsigned long value, unsigned long old); -void hvm_event_cr3(unsigned long value, unsigned long old); -void hvm_event_cr4(unsigned long value, unsigned long old); +void hvm_event_cr(unsigned int index, unsigned long value, unsigned long old); void hvm_event_msr(unsigned int msr, uint64_t value); /* Called for current VCPU: returns -1 if no listener */ int hvm_event_int3(unsigned long gla); int hvm_event_single_step(unsigned long gla); +#define hvm_event_cr(what, new, old) hvm_event_cr(VM_EVENT_X86_##what, new, old) I would have wished for the macro to be immediately adjacent to the function declaration, so that the whole picture of what works how is visible at once. With those fixed, Acked-by: Jan Beulich jbeul...@suse.com Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH OSSTEST v7 08/15] distros: Run one suite per day on a weekly basis
Once a week should be sufficient for these tests. Perhaps in the future we will want to increase the frequency for the suites under active development (testing, unstable) For now run this on the Citrix Cambridge instance until the XenProject instance has sufficient capacity. Switch to tabs for alignment. Signed-off-by: Ian Campbell ian.campb...@citrix.com --- v7: Replaces distros: Run a flight over the weekend. Now run in Cambridge Run separate flight per-suite Dropped Ack --- crontab-cambridge | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/crontab-cambridge b/crontab-cambridge index 60bb4fd..7d3ed57 100644 --- a/crontab-cambridge +++ b/crontab-cambridge @@ -1,5 +1,10 @@ PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin MAILTO=ian.jack...@citrix.com,ian.campb...@eu.citrix.com -# mh dom mon dow command -4-59/30* * * * cd testing.git BRANCHES=osstest ./cr-for-branches branches -q ./cr-daily-branch --real -3 4 * * * savelog -c28 testing.git/tmp/cr-for-branches.log /dev/null +# mh dom mon dow command +4-59/30* * * * cd testing.git BRANCHES='osstest'./cr-for-branches branches -q ./cr-daily-branch --real +46 7 * * 6 cd testing.git BRANCHES='distros-debian-snapshot'./cr-for-branches branches -w ./cr-daily-branch --real +46 7 * * 5 cd testing.git BRANCHES='distros-debian-sid' ./cr-for-branches branches -w ./cr-daily-branch --real +46 7 * * 4 cd testing.git BRANCHES='distros-debian-jessie' ./cr-for-branches branches -w ./cr-daily-branch --real +46 7 * * 3 cd testing.git BRANCHES='distros-debian-wheezy' ./cr-for-branches branches -w ./cr-daily-branch --real +46 7 * * 2 cd testing.git BRANCHES='distros-debian-squeeze' ./cr-for-branches branches -w ./cr-daily-branch --real +3 4 * * * savelog -c28 testing.git/tmp/cr-for-branches.log /dev/null -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCHv1] xen-netfront: properly destroy queues when removing device
From: David Vrabel david.vra...@citrix.com Date: Wed, 27 May 2015 15:46:10 +0100 xennet_remove() freed the queues before freeing the netdevice which results in a use-after-free when free_netdev() tries to delete the napi instances that have already been freed. Fix this by fully destroy the queues (which includes deleting the napi instances) before freeing the netdevice. Signed-off-by: David Vrabel david.vra...@citrix.com Applied, thanks David. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 57375: regressions - trouble: broken/fail/pass
flight 57375 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/57375/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 3 host-install(3) broken REGR. vs. 56375 test-armhf-armhf-xl-multivcpu 17 leak-check/check fail in 57335 REGR. vs. 56375 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-sedf 3 host-install(3) broken in 57335 pass in 57375 test-armhf-armhf-xl-xsm 3 host-install(3) broken pass in 57335 test-armhf-armhf-xl-credit2 9 debian-install fail in 57335 pass in 57375 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail pass in 57335 test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail pass in 57335 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 56375 test-armhf-armhf-libvirt-xsm 8 leak-check/basis(8) fail blocked in 56375 test-amd64-i386-libvirt-xsm 11 guest-start fail like 56375 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 56375 test-amd64-i386-libvirt 11 guest-start fail like 56375 test-armhf-armhf-libvirt 11 guest-start fail like 56375 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 56375 test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail like 56948-bisect Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 11 guest-start fail in 57335 never pass test-armhf-armhf-xl-xsm 12 migrate-support-check fail in 57335 never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail in 57335 never pass test-amd64-amd64-xl-xsm 14 guest-localmigrate fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-xl-xsm 14 guest-localmigrate fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass version targeted for testing: xen 6b05648d12ea2a797d6ef9ebc074ee0c03646bce baseline version: xen e13013dbf1d5997915548a3b5f1c39594d8c1d7b People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Charles Arnold carn...@suse.com Chen Baozi baoz...@gmail.com Daniel De Graaf dgde...@tycho.nsa.gov David Vrabel david.vra...@citrix.com George Dunlap george.dun...@eu.citrix.com Huaitong Han huaitong@intel.com Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com Julien Grall julien.gr...@citrix.com Julien Grall julien.gr...@citrix.com (ARM) Julien Grall julien.gr...@linaro.org Kevin Tian kevin.t...@intel.com Konrad Rzeszutek Wilk konrad.w...@oracle.com Len Brown len.br...@intel.com Olaf Hering o...@aepfle.de Pranavkumar Sawargaonkar pranavku...@linaro.org Roger Pau Monné roger@citrix.com Tiejun Chen tiejun.c...@intel.com Tim Deegan t...@xen.org 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
[Xen-devel] [linux-3.18 test] 57378: regressions - trouble: broken/fail/pass
flight 57378 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/57378/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 3 host-install(3) broken in 57345 REGR. vs. 57312 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 57312 Tests which are failing intermittently (not blocking): test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail pass in 57345 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail pass in 57345 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-xsm 3 host-install(3) broken REGR. vs. 57312 test-armhf-armhf-libvirt 3 host-install(3) broken REGR. vs. 57312 test-armhf-armhf-xl-sedf-pin 6 xen-boot fail REGR. vs. 57312 test-armhf-armhf-xl-sedf 6 xen-boot fail REGR. vs. 57312 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked in 57345 n/a test-armhf-armhf-xl 1 build-check(1)blocked in 57345 n/a test-armhf-armhf-xl-sedf-pin 1 build-check(1)blocked in 57345 n/a test-armhf-armhf-xl-sedf 1 build-check(1)blocked in 57345 n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked in 57345 n/a test-armhf-armhf-xl-arndale 1 build-check(1)blocked in 57345 n/a build-armhf-libvirt 1 build-check(1)blocked in 57345 n/a test-armhf-armhf-xl-credit2 1 build-check(1)blocked in 57345 n/a test-armhf-armhf-libvirt-xsm 1 build-check(1)blocked in 57345 n/a test-armhf-armhf-libvirt 1 build-check(1)blocked in 57345 n/a test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemut-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-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-xsm 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-libvirt-xsm 11 guest-start fail never pass test-amd64-amd64-xl-xsm 11 guest-start fail never pass test-amd64-i386-freebsd10-i386 9 freebsd-install fail never pass test-amd64-i386-freebsd10-amd64 9 freebsd-install fail never pass test-armhf-armhf-xl-cubietruck 6 xen-boot fail never pass test-armhf-armhf-xl 6 xen-boot 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-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-credit2 6 xen-boot fail never pass test-armhf-armhf-xl-xsm 6 xen-boot fail never pass version targeted for testing: linux51af817611f2c0987030d024f24fc7ea95dd33e6 baseline version: linuxb2776bf7149bddd1f4161f14f79520f17fc1d71d 900 people touched revisions under test, not listing them all 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 build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl pass test-armhf-armhf-xl
Re: [Xen-devel] [PATCH v22 02/14] x86/VPMU: Add public xenpmu.h
On 27.05.15 at 17:18, boris.ostrov...@oracle.com wrote:
On 05/27/2015 10:26 AM, Jan Beulich wrote:
On 27.05.15 at 15:44, boris.ostrov...@oracle.com wrote:
Sorry, I meant amd/intel members of the union below (I forgot we were
already in the arch header file):
+/*
+ * Vendor-specific PMU registers.
+ * RW for both hypervisor and guest.
+ * Guest's updates to this field are verified and then loaded by the
+ * hypervisor into hardware during XENPMU_flush
+ */
+union {
+struct xen_pmu_amd_ctxt amd;
+struct xen_pmu_intel_ctxt intel;
+
+/*
+ * Padding for contexts (fixed parts only, does not include MSR
banks
+ * that are specified by offsets)
+ */
+#define XENPMU_CTXT_PAD_SZ 128
+uint8_t pad[XENPMU_CTXT_PAD_SZ];
+} c;
+};
I think they are first used in patch 11 so I assume you also want me to
just keep the pad here (with a comment explaining why it is here) until
that patch.
Ah, those ones I simply recalled having checked in the previous
version already.
But should they they also not be defined until later patch, to be
consistent with how lapic_lvtpc's definition is deferred?
I think that would be better.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [Patch V3 14/15] xen: allow more than 512 GB of RAM for 64 bit pv-domains
On 20/04/15 06:23, Juergen Gross wrote: 64 bit pv-domains under Xen are limited to 512 GB of RAM today. The main reason has been the 3 level p2m tree, which was replaced by the virtual mapped linear p2m list. Parallel to the p2m list which is being used by the kernel itself there is a 3 level mfn tree for usage by the Xen tools and eventually for crash dump analysis. For this tree the linear p2m list can serve as a replacement, too. As the kernel can't know whether the tools are capable of dealing with the p2m list instead of the mfn tree, the limit of 512 GB can't be dropped in all cases. This patch replaces the hard limit by a kernel parameter which tells the kernel to obey the 512 GB limit or not. The default is selected by a configuration parameter which specifies whether the 512 GB limit should be active per default for domUs (domain save/restore/migration and crash dump analysis are affected). Memory above the domain limit is returned to the hypervisor instead of being identity mapped, which was wrong anyway. The kernel configuration parameter to specify the maximum size of a domain can be deleted, as it is not relevant any more. Something in this patch breaks the hvc console in my test domU. kernel BUG at /local/davidvr/work/k.org/tip/drivers/tty/hvc/hvc_xen.c:153 Which suggests the hvc driver mapped the wrong console ring frame. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-linus test] 57367: trouble: blocked/broken/fail/pass
flight 57367 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/57367/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 3 host-install(3) broken REGR. vs. 57123 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 11 guest-start fail like 57123 test-amd64-amd64-libvirt 11 guest-start fail like 57123 test-amd64-i386-freebsd10-amd64 9 freebsd-install fail like 57123 test-amd64-i386-freebsd10-i386 9 freebsd-install fail like 57123 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 57123 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 57123 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-xl-sedf 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-sedf-pin 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-libvirt-xsm 11 guest-start fail never pass test-amd64-i386-xl-qemuu-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-xsm 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-amd64-i386-xl-xsm 11 guest-start fail never pass test-armhf-armhf-xl-xsm 11 guest-start fail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass version targeted for testing: linuxa8b253b9f253c05e5e10b829b8d1fb24556f4b56 baseline version: linuxc5db6a3bdeb72f4238e1faefa4ce4eab7a64baea People who touched revisions under test: Alexey Kardashevskiy a...@ozlabs.ru Carlo Caione ca...@endlessm.com Dick Kennedy dick.kenn...@avagotech.com Hannes Reinecke h...@suse.de James Bottomley jbottom...@odin.com James Smart james.sm...@avagotech.com James Smart james.sm...@emulex.com Jayamohan Kallickal jayamohan.kallic...@avagotech.com Johan Hovold jo...@kernel.org K. Y. Srinivasan k...@microsoft.com Linus Torvalds torva...@linux-foundation.org Linus Walleij linus.wall...@linaro.org Mark Hounschell dma...@cfl.rr.com Michael Brunner mi...@gmx.de Michael Brunner michael.brun...@kontron.com Mika Westerberg mika.westerb...@linux.intel.com Minh Tran minh.t...@avagotech.com Minh Tran minhduc.t...@avagotech.com Ray Jui r...@broadcom.com jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf broken build-i386 pass build-amd64-libvirt pass build-armhf-libvirt blocked 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 blocked test-amd64-i386-xl pass
Re: [Xen-devel] Tools backports for 4.5 [and 1 more messages]
Jan Beulich writes (Re: [Xen-devel] Tools backports for 4.5): Andrew Cooper writes (Tools backports for 4.5): From the XenServer patch queue, (Andrew forgot to CC xen-devel, doing that now:) 3380f5b6270e ocaml/xenctrl: Check return values from hypercalls c8945d516134 ocaml/xenctrl: Make failwith_xc() thread safe 1a010ca99e9b ocaml/xenctrl: Fix stub_xc_readconsolering() 96e0ee8386cf tools/hotplug: systemd: Don't ever kill xenstored 588df84c0d70 tools/xenconsoled: Increase file descriptor limit I have just pushed these to staging-4.5. Jim Fehlig writes (Re: [Xen-devel] Tools backports for 4.5): I responded to Jan's preparing for 4.5.1 mail with backport requests that I currently don't see in staging-4.5 http://lists.xen.org/archives/html/xen-devel/2015-04/msg00168.html Thanks, I have pushed those three to staging-4.5 too. The above backports (771f857e..9d5b2b01) need to go to 4.4 and earlier as applicable. I will look at that soon (probably tomorrow). I have also picked up the fix to XSA-133 into all the qemu-trad trees back to 4.2 inclusive. (4.1 is no longer receiving even security fixes and has had no commits since 2013.) I think that's all the outstanding tools backports for the 4.5 branch. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [xen-unstable test] 56759: regressions - FAIL
On Tue, 2015-05-26 at 14:29 +0100, Ian Campbell wrote: On Wed, 2015-05-20 at 10:56 +0100, Ian Campbell wrote: On Wed, 2015-05-20 at 09:34 +, osstest service user wrote: flight 56759 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/56759/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-multivcpu 17 leak-check/check fail REGR. vs. 56375 I'm pretty hard pressed to explain this from the set of commits currently under test, but it has happened a few times now (e.g. 56700 56576) so it does seem to be real. http://logs.test-lab.xenproject.org/osstest/results/bisect.xen-unstable.test-armhf-armhf-xl-multivcpu.leak-check--check.html is working on it and is currently consider the set of changes from: ianc@cosworth:xen.git$ git log --oneline 9ab42~1...45fcc4 45fcc45 use ticket locks for spin locks e13013d libxc/restore: add checkpointed flag to the restore context ce44b40 libxc/restore: introduce setup() and cleanup() on restore c5c5a04 libxc/restore: split read/handle qemu info 9ab42c9 libxc/restore: introduce process_record() where e13013d is current master which was pushed in by flight 56375. I think it unlikely the libxl stuff is responible, given we don't migrate on ARM, which would seem to point to the ticket locks... I've now managed to reproduce using the arndale on my desk. ... and now I've confirmed that reverting the spin lock change causes the issue to not happen any more. I'm just starting to dig in to the issue. So far the only thing I've concluded is that the message comes from netback try to read the script node for inclusion in the hotplug invocation's environment. I wonder if perhaps the spinlock change has just exposed a pre-existing race? I'm still confirming, but AFAICT libxl does the right thing and writes state=Closing and waits for it to hit state=Closed before tearing down the backend directory. AFAICS it is not timing out while waiting. Looking at the netback side though it seems like netback_remove is switching to state=Closed _before_ it calls kobject_uevent(..., KOBJ_OFFLINE) and it is this which generates the call to netback_uevent which tries and fails to read script and produces the error message. Since switching to state=Closed is what prompts libxl to go and delete the xenstore backend dir it seems like it would be possible that netback_uevent might not happen until the xenstore key was gone, prompting it to write the error nodes. Is there anything else which might prevent against that possibility? Handwaving a bit (ok, a lot) it's possible that the change of spinlocks has caused a commonly won race to become a commonly lost one at least under these circumstances. My theory is that this is exacerbated on arndale because the CPU is relatively slow (even compared to cubietruck which is the same core but faster DRAM etc) and the fact that it is dual core while the test case which is failing involves a 4 vcpu guest (which is a bit dumb but not invalid) is loading things even more. I'm still slightly concerned that perhaps the new spinlock stuff has some sort of bad behaviour either on arndale specifically or more generally for ARM systems which has pushed this particular case over the edge. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 03/10] xen: introduce DOMDYING_locked state
The new state is required as a prerequisite to implementing soft reset
operation for domains. In this operation we need to make sure that source
domain's mappings don't change while we are reassigning all its memory to
the destination domain. This new state indicates that the particular domain is
dying (so its mappings are locked and do not change) but the cleanup procedure
has not being started yet. It will be set from outside of the domain_kill()
function.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
xen/common/domain.c | 1 +
xen/include/xen/sched.h | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 6803c4d..7825c56 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -605,6 +605,7 @@ int domain_kill(struct domain *d)
switch ( d-is_dying )
{
case DOMDYING_alive:
+case DOMDYING_locked:
domain_pause(d);
d-is_dying = DOMDYING_dying;
spin_barrier(d-domain_lock);
diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h
index 80c6f62..f53b91d 100644
--- a/xen/include/xen/sched.h
+++ b/xen/include/xen/sched.h
@@ -354,7 +354,8 @@ struct domain
enum guest_type guest_type;
/* Is this guest dying (i.e., a zombie)? */
-enum { DOMDYING_alive, DOMDYING_dying, DOMDYING_dead } is_dying;
+enum { DOMDYING_alive, DOMDYING_locked, DOMDYING_dying, DOMDYING_dead }
+is_dying;
/* Domain is paused by controller software? */
int controller_pause_count;
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 00/10] toolstack-based approach to pvhvm guest kexec
This patch series provides x86 PVHVM domains with an ability to perform kexec/kdump-style operations. The main change in v7 is the XENMEM_soft_reset-XEN_DOMCTL_soft_reset change of the newly introduced hypercall. Changes are mentioned in individual patches. Here is the list of them grouped by the reviewer's name: Jan Beulich: - XENMEM_soft_reset-XEN_DOMCTL_soft_reset change - print a warning on !mfn_valid case - check PGC_allocated for pages - don't re-read page-count_info - minor structuring change - pause both source and destination domain while processing the hypercall - remove nr_transferred from public interface - other minor fixes in PATCH 04/10 - add a comment on why we don't do two XSM_TARGET checks in dummy.h Tim Deegan: - use get_gfn_type_access() in PoD case Wei Liu: - replace LIBXL_HAVE_SHUTDWON_REASON_SOFT_RESET with LIBXL_HAVE_SOFT_RESET Daniel De Graaf: - add reset_transfer vector to FLASK (I dropped Acked-by: on the patch because of the XENMEM_soft_reset-XEN_DOMCTL_soft_reset change.) Julien Grall: - check that xc_domain_getinfo() return the domain we asked for v6 of this series is available here: http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg01613.html v5 and all the history of the series is available here: http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01312.html Vitaly Kuznetsov (10): xen: introduce SHUTDOWN_soft_reset shutdown reason libxl: support SHUTDOWN_soft_reset shutdown reason xen: introduce DOMDYING_locked state xen: Introduce XEN_DOMCTL_soft_reset xsm: add XEN_DOMCTL_soft_reset support libxc: support XEN_DOMCTL_soft_reset operation libxc: introduce soft reset for HVM domains xl: introduce enum domain_restart_type libxc: add XC_DEVICE_MODEL_SAVE_FILE (lib)xl: soft reset support docs/man/xl.cfg.pod.5| 12 ++ tools/flask/policy/policy/modules/xen/xen.if | 3 +- tools/libxc/Makefile | 1 + tools/libxc/include/xenctrl.h| 4 + tools/libxc/include/xenguest.h | 22 +++ tools/libxc/xc_domain.c | 12 ++ tools/libxc/xc_soft_reset.c | 280 +++ tools/libxl/libxl.c | 4 + tools/libxl/libxl.h | 14 ++ tools/libxl/libxl_create.c | 119 +++- tools/libxl/libxl_dm.c | 2 +- tools/libxl/libxl_internal.h | 26 +++ tools/libxl/libxl_types.idl | 4 + tools/libxl/xl.h | 7 + tools/libxl/xl_cmdimpl.c | 58 -- tools/python/xen/lowlevel/xl/xl.c| 1 + xen/common/domain.c | 187 ++ xen/common/domctl.c | 79 xen/common/shutdown.c| 6 + xen/include/public/domctl.h | 28 +++ xen/include/public/sched.h | 3 +- xen/include/xen/sched.h | 9 +- xen/include/xsm/dummy.h | 12 ++ xen/include/xsm/xsm.h| 8 + xen/xsm/dummy.c | 2 + xen/xsm/flask/hooks.c| 18 ++ xen/xsm/flask/policy/access_vectors | 7 + 27 files changed, 899 insertions(+), 29 deletions(-) create mode 100644 tools/libxc/xc_soft_reset.c -- 1.9.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 02/10] libxl: support SHUTDOWN_soft_reset shutdown reason
Use letter 'S' to indicate a domain in such state.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
Changes in v7:
- Remove LIBXL_HAVE_SHUTDWON_REASON_SOFT_RESET, the functionality will be
advertised with LIBXL_HAVE_SOFT_RESET with the implementation [Wei Liu]
---
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 2 +-
tools/python/xen/lowlevel/xl/xl.c | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 65d479f..1aa90f5 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -177,6 +177,7 @@ libxl_shutdown_reason = Enumeration(shutdown_reason, [
(2, suspend),
(3, crash),
(4, watchdog),
+(5, soft_reset),
], init_val = LIBXL_SHUTDOWN_REASON_UNKNOWN)
libxl_vga_interface_type = Enumeration(vga_interface_type, [
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index 373aa37..7abac5d 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -3704,7 +3704,7 @@ static void list_domains(bool verbose, bool context, bool
claim, bool numa,
bool cpupool, const libxl_dominfo *info, int
nb_domain)
{
int i;
-static const char shutdown_reason_letters[]= -rscw;
+static const char shutdown_reason_letters[]= -rscwS;
libxl_bitmap nodemap;
libxl_physinfo physinfo;
diff --git a/tools/python/xen/lowlevel/xl/xl.c
b/tools/python/xen/lowlevel/xl/xl.c
index 32f982a..7c61160 100644
--- a/tools/python/xen/lowlevel/xl/xl.c
+++ b/tools/python/xen/lowlevel/xl/xl.c
@@ -784,6 +784,7 @@ PyMODINIT_FUNC initxl(void)
_INT_CONST_LIBXL(m, SHUTDOWN_REASON_SUSPEND);
_INT_CONST_LIBXL(m, SHUTDOWN_REASON_CRASH);
_INT_CONST_LIBXL(m, SHUTDOWN_REASON_WATCHDOG);
+_INT_CONST_LIBXL(m, SHUTDOWN_REASON_SOFT_RESET);
genwrap__init(m);
}
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 09/10] libxc: add XC_DEVICE_MODEL_SAVE_FILE
Use this in libxl_dm instead of hard-coding.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
tools/libxc/include/xenguest.h | 1 +
tools/libxl/libxl_dm.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index c71b423..98b3a37 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -168,6 +168,7 @@ int xc_soft_reset(xc_interface *xch, uint32_t source_dom,
unsigned long *console_mfn, domid_t store_domid,
unsigned long *store_mfn);
+#define XC_DEVICE_MODEL_SAVE_FILE /var/lib/xen/qemu-save
#define XC_DEVICE_MODEL_RESTORE_FILE /var/lib/xen/qemu-resume
/**
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 0c6408d..869f4cd 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -31,7 +31,7 @@ static const char *libxl_tapif_script(libxl__gc *gc)
const char *libxl__device_model_savefile(libxl__gc *gc, uint32_t domid)
{
-return libxl__sprintf(gc, /var/lib/xen/qemu-save.%d, domid);
+return libxl__sprintf(gc, XC_DEVICE_MODEL_SAVE_FILE.%d, domid);
}
static const char *qemu_xen_path(libxl__gc *gc)
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 07/10] libxc: introduce soft reset for HVM domains
Add new xc_soft_reset() function which performs so-called 'soft reset'
for an HVM domain. It is being performed in the following way:
- Save HVM context and all HVM params of the source domain;
- Transfer all the source domain's memory to the destinatio domain with
XEN_DOMCTL_soft_reset;
- Restore HVM context, HVM params, seed grant table for the new domain.
When the operation succeeds the source domain is being destroyed and the
destination domain is ready to proceed from where the source was stopped.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
Changes in v7:
- check that xc_domain_getinfo() return the domain we asked for [Julien Grall]
- xc_domain_soft_reset - xc_soft_reset
- xc_soft_reset destroys the source domain, no need to do it manually
- nr_transfered was removed from hypercall interface, use
xc_domain_get_pod_target for the source domain instead.
---
tools/libxc/Makefile | 1 +
tools/libxc/include/xenguest.h | 21
tools/libxc/xc_soft_reset.c| 280 +
3 files changed, 302 insertions(+)
create mode 100644 tools/libxc/xc_soft_reset.c
diff --git a/tools/libxc/Makefile b/tools/libxc/Makefile
index 63878ec..62bc21b 100644
--- a/tools/libxc/Makefile
+++ b/tools/libxc/Makefile
@@ -69,6 +69,7 @@ $(patsubst %.c,%.opic,$(GUEST_SRCS-y)): CFLAGS +=
-DXG_LIBXL_HVM_COMPAT
else
GUEST_SRCS-y += xc_nomigrate.c
endif
+GUEST_SRCS-y += xc_soft_reset.c
vpath %.c ../../xen/common/libelf
CFLAGS += -I../../xen/common/libelf
diff --git a/tools/libxc/include/xenguest.h b/tools/libxc/include/xenguest.h
index 7581263..c71b423 100644
--- a/tools/libxc/include/xenguest.h
+++ b/tools/libxc/include/xenguest.h
@@ -147,6 +147,27 @@ int xc_domain_restore2(xc_interface *xch, int io_fd,
uint32_t dom,
* of the new domain is automatically appended to the filename,
* separated by a ..
*/
+
+/**
+ * This function does soft reset for a domain. During soft reset all
+ * source domain's memory is being reassigned to the destination domain,
+ * HVM context and HVM params are being copied, source domain is being
+ * destroyed.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm source_dom the id of the source domain
+ * @parm dest_dom the id of the destination domain
+ * @parm console_domid the id of the domain handling console
+ * @parm console_mfn returned with the mfn of the console page
+ * @parm store_domid the id of the domain handling store
+ * @parm store_mfn returned with the mfn of the store page
+ * @return 0 on success, -1 on failure
+ */
+int xc_soft_reset(xc_interface *xch, uint32_t source_dom,
+ uint32_t dest_dom, domid_t console_domid,
+ unsigned long *console_mfn, domid_t store_domid,
+ unsigned long *store_mfn);
+
#define XC_DEVICE_MODEL_RESTORE_FILE /var/lib/xen/qemu-resume
/**
diff --git a/tools/libxc/xc_soft_reset.c b/tools/libxc/xc_soft_reset.c
new file mode 100644
index 000..ea07470
--- /dev/null
+++ b/tools/libxc/xc_soft_reset.c
@@ -0,0 +1,280 @@
+/**
+ * xc_soft_reset.c
+ *
+ * Do soft reset.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation;
+ * version 2.1 of the License.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA
+ */
+
+#include inttypes.h
+#include time.h
+#include stdlib.h
+#include unistd.h
+#include sys/time.h
+
+#include xc_private.h
+#include xc_core.h
+#include xc_bitops.h
+#include xc_dom.h
+#include xg_private.h
+#include xg_save_restore.h
+
+#include xen/hvm/params.h
+
+int xc_soft_reset(xc_interface *xch, uint32_t source_dom,
+ uint32_t dest_dom, domid_t console_domid,
+ unsigned long *console_mfn, domid_t store_domid,
+ unsigned long *store_mfn)
+{
+xc_dominfo_t old_info, new_info;
+int rc = 1;
+
+uint32_t hvm_buf_size = 0;
+uint8_t *hvm_buf = NULL;
+unsigned long console_pfn, store_pfn, io_pfn, buffio_pfn;
+uint64_t hvm_params[HVM_NR_PARAMS];
+uint64_t pod_info[3];
+xen_pfn_t sharedinfo_pfn;
+
+DPRINTF(%s: soft reset domid %u - %u, __func__, source_dom, dest_dom);
+
+if ( xc_domain_getinfo(xch, source_dom, 1, old_info) != 1 ||
+ old_info.domid != source_dom )
+{
+PERROR(Could not get old domain's info);
+return 1;
+}
+
+if ( xc_domain_get_pod_target(xch,
[Xen-devel] [PATCH v7 04/10] xen: Introduce XEN_DOMCTL_soft_reset
New operation reassigns all memory pages from source domain to the destination
domain mapping them at exactly the same GFNs. Pages mapped more than once (e.g.
grants) are being copied.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
Changes in v7:
- is_soft_reset flag added to struct domain to preserve destination domain's
paused state across possible hypercall preemption.
[Jan Beulich]
- XENMEM_soft_reset - XEN_DOMCTL_soft_reset
- domain_soft_reset() returns int
- no locking for is_dying as it is now proteced by domctl_lock
- print a warning on !mfn_valid case
- check PGC_allocated for pages
- no print on assign_pages failure (it prints error messages on both its
failure paths)
- don't re-read page-count_info, use copy_page flag
- minor stucturing change
- pause both source and destination domain while processing the hypercall
- remove nr_transferred from public interface
[Tim Deegan]
- use get_gfn_type_access() in PoD case (x86-only)
---
xen/common/domain.c | 186
xen/common/domctl.c | 72 +
xen/include/public/domctl.h | 28 +++
xen/include/xen/sched.h | 6 ++
4 files changed, 292 insertions(+)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 7825c56..824f325 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1006,6 +1006,192 @@ int domain_unpause_by_systemcontroller(struct domain *d)
return 0;
}
+int domain_soft_reset(struct domain *source_d, struct domain *dest_d,
+ xen_pfn_t *gmfn_start)
+{
+int rc = 0;
+unsigned long mfn, mfn_new, gmfn, last_gmfn, count;
+unsigned int order;
+p2m_type_t p2mt;
+struct page_info *page, *new_page, *next_page;
+int drop_dom_ref, copy_page;
+
+last_gmfn = domain_get_maximum_gpfn(source_d);
+gmfn = *gmfn_start;
+while ( gmfn = last_gmfn )
+{
+page = get_page_from_gfn(source_d, gmfn, p2mt, 0);
+if ( unlikely(page == NULL) )
+{
+#ifdef CONFIG_X86
+struct p2m_domain *p2m = p2m_get_hostp2m(source_d);
+p2m_access_t p2ma;
+mfn_t mfn_p2m;
+
+order = 0;
+mfn_p2m = get_gfn_type_access(p2m, gmfn,
+ p2mt, p2ma, 0, order);
+if ( p2m_is_pod(p2mt) )
+{
+rc = guest_physmap_mark_populate_on_demand(dest_d, gmfn,
+ order);
+if ( unlikely(rc) )
+{
+printk(XENLOG_G_ERR Failed to mark Dom%d's GFN %lx
+(order: %d) as PoD\n, source_d-domain_id,
+ gmfn, order);
+goto fail;
+}
+}
+put_gfn(source_d, gmfn);
+gmfn += 1ul order;
+#else
+gmfn++;
+#endif
+goto preempt_check;
+}
+
+mfn = page_to_mfn(page);
+if ( unlikely(!mfn_valid(mfn)) )
+{
+printk(XENLOG_G_WARNING Dom%d's GFN %lx points to invalid MFN\n,
+ source_d-domain_id, gmfn);
+put_page(page);
+gmfn++;
+goto preempt_check;
+}
+
+next_page = page;
+count = 0;
+copy_page = 0;
+while ( next_page !is_xen_heap_page(next_page)
+page_to_mfn(next_page) == mfn + count )
+{
+/*
+ * A normal page is supposed to be allocated and have count_info=2
+ * (1 from the domain and 1 from get_page_from_gfn() above).
+ * We should never see an unallocated page here and a page with
+ * count_info 2 has to be copied.
+ */
+if ( unlikely(!(next_page-count_info PGC_allocated)) )
+{
+printk(XENLOG_G_ERR Dom%d's page for GFN %lx is not
+allocated\n, source_d-domain_id, gmfn);
+put_page(next_page);
+rc = -EFAULT;
+goto fail;
+}
+else if ( (next_page-count_info PGC_count_mask) != 2 )
+{
+if ( !count )
+copy_page = 1;
+break;
+}
+
+count++;
+drop_dom_ref = 0;
+spin_lock(source_d-page_alloc_lock);
+page_set_owner(next_page, NULL);
+page_list_del(next_page, source_d-page_list);
+source_d-tot_pages--;
+if ( unlikely(source_d-tot_pages == 0) )
+drop_dom_ref = 1;
+spin_unlock(source_d-page_alloc_lock);
+put_page(next_page);
+if ( unlikely(drop_dom_ref) )
+put_domain(source_d);
+
+if ( unlikely(assign_pages(dest_d, next_page, 0, 0)) )
+{
+printk(XENLOG_G_ERR Failed to assign Dom%d's page (GFN %lx)
+to Dom %d
[Xen-devel] [PATCH v7 06/10] libxc: support XEN_DOMCTL_soft_reset operation
Introduce xc_domain_soft_reset() function supporting XEN_DOMCTL_soft_reset.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
Changes in v7:
- XENMEM_soft_reset - XEN_DOMCTL_soft_reset.
- xc_memory_soft_reset - xc_domain_soft_reset
---
tools/libxc/include/xenctrl.h | 4
tools/libxc/xc_domain.c | 12
2 files changed, 16 insertions(+)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 09a7450..ceb64d5 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1301,6 +1301,10 @@ int xc_domain_setvnuma(xc_interface *xch,
unsigned int *vcpu_to_vnode,
unsigned int *vnode_to_pnode);
+int xc_domain_soft_reset(xc_interface *xch,
+ uint32_t source_domid,
+ uint32_t dest_domid);
+
#if defined(__i386__) || defined(__x86_64__)
/*
* PC BIOS standard E820 types and structure.
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index a7079a1..51f2833 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2459,6 +2459,18 @@ int xc_domain_setvnuma(xc_interface *xch,
return rc;
}
+
+int xc_domain_soft_reset(xc_interface *xch,
+ uint32_t source_domid,
+ uint32_t dest_domid)
+{
+DECLARE_DOMCTL;
+domctl.cmd = XEN_DOMCTL_soft_reset;
+domctl.domain = (domid_t)source_domid;
+domctl.u.soft_reset.dest_domain = (domid_t)dest_domid;
+domctl.u.soft_reset.gmfn_start = 0;
+return do_domctl(xch, domctl);
+}
/*
* Local variables:
* mode: C
--
1.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 01/10] xen: introduce SHUTDOWN_soft_reset shutdown reason
This special type of shutdown is supposed to be used by PVHVM guests when they want to perform some sort of kexec/kdump. Toolstack will have to build a new domain with the memory content of the original domain and start executing the new one from the point where SHUTDOWN_soft_reset was called. This operation is not supported for PV domains including the hardware domain. Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com --- xen/common/shutdown.c | 6 ++ xen/include/public/sched.h | 3 ++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/xen/common/shutdown.c b/xen/common/shutdown.c index 9cfbf7a..03a8641 100644 --- a/xen/common/shutdown.c +++ b/xen/common/shutdown.c @@ -66,6 +66,12 @@ void hwdom_shutdown(u8 reason) machine_restart(0); break; /* not reached */ +case SHUTDOWN_soft_reset: +printk(Hardware domain %d did unsupported soft reset, rebooting.\n, + hardware_domain-domain_id); +machine_restart(0); +break; /* not reached */ + default: printk(Hardware Dom%u shutdown (unknown reason %u): , hardware_domain-domain_id, reason); diff --git a/xen/include/public/sched.h b/xen/include/public/sched.h index 4000ac9..800c808 100644 --- a/xen/include/public/sched.h +++ b/xen/include/public/sched.h @@ -159,7 +159,8 @@ DEFINE_XEN_GUEST_HANDLE(sched_watchdog_t); #define SHUTDOWN_suspend2 /* Clean up, save suspend info, kill. */ #define SHUTDOWN_crash 3 /* Tell controller we've crashed. */ #define SHUTDOWN_watchdog 4 /* Restart because watchdog time expired. */ -#define SHUTDOWN_MAX4 /* Maximum valid shutdown reason. */ +#define SHUTDOWN_soft_reset 5 /* Soft reset, rebuild keeping memory content */ +#define SHUTDOWN_MAX5 /* Maximum valid shutdown reason. */ /* ` } */ #endif /* __XEN_PUBLIC_SCHED_H__ */ -- 1.9.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 05/10] xsm: add XEN_DOMCTL_soft_reset support
Dummy policy just checks that the current domain is privileged. In the FLASK
policy two new vectors are added to the DOMAIN2 class: soft_reset and
reset_transfer. First one is being used to check that the domain making the
hypercall is allowed to do it, the second is being used that is's possible
to trasfer memory from source domain to destination domain. The default policy
requires their contexts to match.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
---
Changes in v7:
- Add reset_transfer vector to FLASK [Daniel De Graaf]
- XENMEM_soft_reset - XEN_DOMCTL_soft_reset
- Add a comment on why we don't do two XSM_TARGET checks in dummy.h [Jan
Beulich]
---
tools/flask/policy/policy/modules/xen/xen.if | 3 ++-
xen/common/domctl.c | 7 +++
xen/include/xsm/dummy.h | 12
xen/include/xsm/xsm.h| 8
xen/xsm/dummy.c | 2 ++
xen/xsm/flask/hooks.c| 18 ++
xen/xsm/flask/policy/access_vectors | 7 +++
7 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/tools/flask/policy/policy/modules/xen/xen.if
b/tools/flask/policy/policy/modules/xen/xen.if
index 620d151..0f6ed8a 100644
--- a/tools/flask/policy/policy/modules/xen/xen.if
+++ b/tools/flask/policy/policy/modules/xen/xen.if
@@ -51,13 +51,14 @@ define(`create_domain_common', `
getaffinity setaffinity setvcpuextstate };
allow $1 $2:domain2 { set_cpuid settsc setscheduler setclaim
set_max_evtchn set_vnumainfo get_vnumainfo cacheflush
- psr_cmt_op };
+ psr_cmt_op soft_reset };
allow $1 $2:security check_context;
allow $1 $2:shadow enable;
allow $1 $2:mmu { map_read map_write adjust memorymap physmap pinpage
mmuext_op updatemp };
allow $1 $2:grant setup;
allow $1 $2:hvm { cacheattr getparam hvmctl irqlevel pciroute sethvmc
setparam pcilevel trackdirtyvram nested };
+ allow $2 $2:domain2 reset_transfer;
')
# create_domain(priv, target)
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 2fd21cb..ea7994a 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -727,6 +727,13 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
u_domctl)
break;
}
+ret = xsm_soft_reset(XSM_PRIV, d, dest_d);
+if ( ret )
+{
+rcu_unlock_domain(dest_d);
+break;
+}
+
/*
* Mark the source domain as dying to prevent further changes of its
* mappings. is_dying flag is protected by domctl_lock.
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index f044c0f..ba44f87 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -193,6 +193,18 @@ static XSM_INLINE int xsm_memory_exchange(XSM_DEFAULT_ARG
struct domain *d)
return xsm_default_action(action, current-domain, d);
}
+static XSM_INLINE int xsm_soft_reset(XSM_DEFAULT_ARG struct domain *d1,
+struct domain *d2)
+{
+/*
+ * As it is not possible for a domain to have more than one target at a
+ * time the result of doing XSM_TARGET check for both domains would be
+ * equivalent to the XSM_PRIV check below.
+ */
+XSM_ASSERT_ACTION(XSM_PRIV);
+return xsm_default_action(action, current-domain, NULL);
+}
+
static XSM_INLINE int xsm_memory_adjust_reservation(XSM_DEFAULT_ARG struct
domain *d1,
struct domain *d2)
{
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index c872d44..6edddfa 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -102,6 +102,8 @@ struct xsm_operations {
int (*kexec) (void);
int (*schedop_shutdown) (struct domain *d1, struct domain *d2);
+int (*soft_reset) (struct domain *d1, struct domain *d2);
+
char *(*show_irq_sid) (int irq);
int (*map_domain_pirq) (struct domain *d);
int (*map_domain_irq) (struct domain *d, int irq, void *data);
@@ -351,6 +353,12 @@ static inline int xsm_memory_exchange (xsm_default_t def,
struct domain *d)
return xsm_ops-memory_exchange(d);
}
+static inline int xsm_soft_reset (xsm_default_t def, struct domain *d1,
+ struct domain *d2)
+{
+return xsm_ops-soft_reset(d1, d2);
+}
+
static inline int xsm_memory_adjust_reservation (xsm_default_t def, struct
domain *d1, struct
domain *d2)
{
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index e84b0e4..0f1158e 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -76,6 +76,8 @@ void xsm_fixup_ops (struct xsm_operations *ops)
set_to_dummy_if_null(ops, kexec);
set_to_dummy_if_null(ops, schedop_shutdown);
+set_to_dummy_if_null(ops, soft_reset);
[Xen-devel] [PATCHv1] xen-netfront: properly destroy queues when removing device
xennet_remove() freed the queues before freeing the netdevice which
results in a use-after-free when free_netdev() tries to delete the
napi instances that have already been freed.
Fix this by fully destroy the queues (which includes deleting the napi
instances) before freeing the netdevice.
Signed-off-by: David Vrabel david.vra...@citrix.com
---
drivers/net/xen-netfront.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 3f45afd..e031c94 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1698,6 +1698,7 @@ static void xennet_destroy_queues(struct netfront_info
*info)
if (netif_running(info-netdev))
napi_disable(queue-napi);
+ del_timer_sync(queue-rx_refill_timer);
netif_napi_del(queue-napi);
}
@@ -2102,9 +2103,6 @@ static const struct attribute_group xennet_dev_group = {
static int xennet_remove(struct xenbus_device *dev)
{
struct netfront_info *info = dev_get_drvdata(dev-dev);
- unsigned int num_queues = info-netdev-real_num_tx_queues;
- struct netfront_queue *queue = NULL;
- unsigned int i = 0;
dev_dbg(dev-dev, %s\n, dev-nodename);
@@ -2112,16 +2110,7 @@ static int xennet_remove(struct xenbus_device *dev)
unregister_netdev(info-netdev);
- for (i = 0; i num_queues; ++i) {
- queue = info-queues[i];
- del_timer_sync(queue-rx_refill_timer);
- }
-
- if (num_queues) {
- kfree(info-queues);
- info-queues = NULL;
- }
-
+ xennet_destroy_queues(info);
xennet_free_netdev(info-netdev);
return 0;
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 57369: regressions - trouble: broken/fail/pass
flight 57369 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/57369/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-libvirt 3 host-install(3) broken REGR. vs. 53854 test-armhf-armhf-libvirt-xsm 3 host-install(3) broken REGR. vs. 53854 test-amd64-i386-libvirt 11 guest-start fail REGR. vs. 53854 test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 53854 Tests which did not succeed, but are not blocking: test-amd64-i386-libvirt-xsm 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass version targeted for testing: libvirt e14cdeb44f1c902e9383327c828e799b452da1f6 baseline version: libvirt fd74e231751334b64af0934b680c5cc62f652453 People who touched revisions under test: Andrea Bolognani abolo...@redhat.com Boris Fiuczynski fiu...@linux.vnet.ibm.com Cole Robinson crobi...@redhat.com Daniel Hansel daniel.han...@linux.vnet.ibm.com Daniel P. Berrange berra...@redhat.com Eric Blake ebl...@redhat.com Erik Skultety eskul...@redhat.com Jim Fehlig jfeh...@suse.com Jiri Denemark jdene...@redhat.com John Ferlan jfer...@redhat.com Ján Tomko jto...@redhat.com Laine Stump la...@laine.org Luyao Huang lhu...@redhat.com Martin Kletzander mklet...@redhat.com Maxim Nestratov mnestra...@parallels.com Michal Privoznik mpriv...@redhat.com Nikolay Shirokovskiy nshirokovs...@parallels.com Pavel Fedin p.fe...@samsung.com Pavel Hrdina phrd...@redhat.com Peter Krempa pkre...@redhat.com Richard W.M. Jones rjo...@redhat.com Roman Bogorodskiy bogorods...@gmail.com Tony Krowiak aekro...@us.ibm.com Tony Krowiak akrow...@linux.vnet.ibm.com Viktor Mihajlovski mihaj...@linux.vnet.ibm.com Wang Yufei james.wangyu...@huawei.com Zhang Bo oscar.zhan...@huawei.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 fail test-armhf-armhf-libvirt-xsm broken test-amd64-i386-libvirt-xsm fail test-amd64-amd64-libvirt fail test-armhf-armhf-libvirt broken 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 broken-step test-armhf-armhf-libvirt host-install(3) broken-step test-armhf-armhf-libvirt-xsm host-install(3) Not pushing. (No revision log; it would be 1779 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v22 02/14] x86/VPMU: Add public xenpmu.h
On 27.05.15 at 15:44, boris.ostrov...@oracle.com wrote:
Sorry, I meant amd/intel members of the union below (I forgot we were
already in the arch header file):
+/*
+ * Vendor-specific PMU registers.
+ * RW for both hypervisor and guest.
+ * Guest's updates to this field are verified and then loaded by the
+ * hypervisor into hardware during XENPMU_flush
+ */
+union {
+struct xen_pmu_amd_ctxt amd;
+struct xen_pmu_intel_ctxt intel;
+
+/*
+ * Padding for contexts (fixed parts only, does not include MSR banks
+ * that are specified by offsets)
+ */
+#define XENPMU_CTXT_PAD_SZ 128
+uint8_t pad[XENPMU_CTXT_PAD_SZ];
+} c;
+};
I think they are first used in patch 11 so I assume you also want me to
just keep the pad here (with a comment explaining why it is here) until
that patch.
Ah, those ones I simply recalled having checked in the previous
version already.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH RFC v1] libxl: Introduce a template for devices with a controller
On Thu, 2015-05-21 at 18:07 +0100, George Dunlap wrote: We have several outstanding patch series which add devices that have two levels: a controller and individual devices attached to that controller. In the interest of consistency, this patch introduces a section that sketches out a template for interfaces for such devices. Thanks for taking this on! Signed-off-by: George Dunlap george.dun...@eu.citrix.com --- CC: Ian Campbell ian.campb...@citrix.com CC: Ian Jackson ian.jack...@citrix.com CC: Wei Liu wei.l...@citrix.com CC: Juergen Gross jgr...@suse.com CC: Chun Yan Liu cy...@suse.com CC: Olaf Hering o...@aepfle.de So, this is definitely RFC -- I tried to spec things out in a way that made sense, but I often just chose something that I thought would be a sensible starting point for discussion. This spec looks a lot more like the PVUSB spec than the PVSCSI spec, in part because I think the PVUSB spec has already had a lot more thought that's gone into it. A couple of random points to discuss: * Calling things controllers, using typectrl for the device name, and using ctrl as the field name for the devid of the controller in the individual devices. Controllers/ctrl is fine, as would Bus/bus. Or paint it pink ;-) * I've said that having an index (port, lun, whatever) is optional. Do we want to make that requred? Do we want it to have a consistent name? In the case of emulated USB, we can't really specify to qemu what port the device gets attached to, so I'm tempted to say it's not required; but even there we could always give it a port number just for name's sake. At the moment devid is not universally used, e.g. disk has (vdev, string), instead. For devices (or controllers) where a flat integer devid space doesn't make sense I think it would be fine to have something else, like a type-specific devid type and a corresponding typectrl specific ctrlid type, which might be a (small) struct in either case and need not be uniform across type and typectrl nor among different types. Having this option of a more structured type might also help with the conversation (in a subthread) regarding where in the controller/bus/device/function the split between the two id spaces is, since you aren't constrained to a single int at two levels trying to describe 4 levels. Using a string as disks do is probably best not considered as a precedent here, but could be appropriate on a device-by-device basis. * Naming sub-devices. We need to have a way to uniquely name both controllers and subdevices. Here I've said that we will have both typectrl and type devid namespaces, mainly because in the previous point I opted not to require an index. Another option would be not to have another devid namespace, but to use ctrl,index as the unique identifier. (This would mean requiring the index/port/lun specification above.) I'm not quite sure what you are getting at here, in particular where we will have both typectrl and type devid namespaces, in the structs or in the protoptyes. I was imaging that where the current templates have (ctx, domid, device) that a controller related function would be (ctx, domid, ctrl) and the device related function would become (ctx, domid, ctrlid, device). ctrl and device would contain their respective ctrlid and devid fields. Perhaps it might be clearer if the proposal included specific function prototype templates along the lines of the existing libxl_device_type_add(ctx, domid, device). I think you were trying to avoid duplication by presenting this new scheme as an extension to what is currently written there. It might be clearer to simply present it as a separate alternative or to list both possible prototypes next to the current section where things differ in the two schemes? (and describe it in the text) Or perhaps to insert some optional parameters into the existing ones where it makes sense: libxl_device_type_add(ctx, domid, [ctrlid, ]device) Not sure which would be least confusing... * libxl_device_type_list listing devices across all controllers. I think this is the most practical thing to do, but one could imagine wanting to query by controller ID instead. I agree with listing everything, I think. If we find a need to only list per controller ID then we can add an alternative (list_by_ctrl, device_typectrl_list_devices, or whatever). Feedback welcome. Having said all that I don't seem to have any more comments on the actual text itself, apart from one typo. --- tools/libxl/libxl.h | 46 ++ 1 file changed, 46 insertions(+) diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h index 2ed7194..d757845 100644 --- a/tools/libxl/libxl.h +++ b/tools/libxl/libxl.h @@ -1234,6 +1234,52 @@ void libxl_vtpminfo_list_free(libxl_vtpminfo *, int nr_vtpms); * * This function does not interact with the guest and therefore * cannot
[Xen-devel] [qemu-mainline test] 57362: regressions - trouble: broken/fail/pass
flight 57362 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/57362/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail REGR. vs. 56831 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-credit2 3 host-install(3) broken in 57315 pass in 57362 test-armhf-armhf-xl-cubietruck 3 host-install(3) broken pass in 57315 test-armhf-armhf-xl-sedf-pin 3 host-install(3) broken pass in 57315 test-armhf-armhf-xl-sedf 6 xen-boot fail in 57315 pass in 57362 test-amd64-i386-xl-qemuu-win7-amd64 9 windows-install fail in 57315 pass in 57362 test-amd64-i386-freebsd10-i386 6 xen-boot fail pass in 57315 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 11 guest-start fail like 56784 test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-installfail like 56784 test-amd64-i386-libvirt 11 guest-start fail like 56831 test-amd64-amd64-libvirt 11 guest-start fail like 56831 Tests which did not succeed, but are not blocking: test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail in 57315 never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-check fail in 57315 never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail in 57315 never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-libvirt-xsm 11 guest-start fail never pass test-amd64-amd64-xl-xsm 11 guest-start fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-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-xl-xsm 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-xsm 11 guest-start fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: qemuu0915aed5842bd4dbe396b92d4f3b846ae29ad663 baseline version: qemuueba05e922e8e7f307bc5d4104a78797e55124e97 People who touched revisions under test: Alberto Garcia be...@igalia.com Bastian Koppelmann kbast...@mail.uni-paderborn.de Christoph Hellwig h...@lst.de Cole Robinson crobi...@redhat.com Daniel P. Berrange berra...@redhat.com Denis V. Lunev d...@openvz.org Eric Blake ebl...@redhat.com Fam Zheng f...@redhat.com Gerd Hoffmann kra...@redhat.com John Snow js...@redhat.com Ján Tomko jto...@redhat.com Keith Busch keith.bu...@intel.com Kevin Wolf kw...@redhat.com Mark Cave-Ayland mark.cave-ayl...@ailande.co.uk Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Markus Armbruster arm...@redhat.com Paolo Bonzini pbonz...@redhat.com Peter Maydell peter.mayd...@linaro.org Richard Henderson r...@twiddle.net Richard W.M. Jones rjo...@redhat.com Roman Kagan rka...@parallels.com Stefan Hajnoczi stefa...@redhat.com jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm
Re: [Xen-devel] [PATCHv1] xen-netfront: properly destroy queues when removing device
On 05/27/2015 10:46 AM, David Vrabel wrote:
xennet_remove() freed the queues before freeing the netdevice which
results in a use-after-free when free_netdev() tries to delete the
napi instances that have already been freed.
Fix this by fully destroy the queues (which includes deleting the napi
instances) before freeing the netdevice.
Signed-off-by: David Vrabel david.vra...@citrix.com
Reviewed-by: Boris Ostrovsky boris.ostrov...@oracle.com
---
drivers/net/xen-netfront.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 3f45afd..e031c94 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1698,6 +1698,7 @@ static void xennet_destroy_queues(struct netfront_info
*info)
if (netif_running(info-netdev))
napi_disable(queue-napi);
+ del_timer_sync(queue-rx_refill_timer);
netif_napi_del(queue-napi);
}
@@ -2102,9 +2103,6 @@ static const struct attribute_group xennet_dev_group = {
static int xennet_remove(struct xenbus_device *dev)
{
struct netfront_info *info = dev_get_drvdata(dev-dev);
- unsigned int num_queues = info-netdev-real_num_tx_queues;
- struct netfront_queue *queue = NULL;
- unsigned int i = 0;
dev_dbg(dev-dev, %s\n, dev-nodename);
@@ -2112,16 +2110,7 @@ static int xennet_remove(struct xenbus_device *dev)
unregister_netdev(info-netdev);
- for (i = 0; i num_queues; ++i) {
- queue = info-queues[i];
- del_timer_sync(queue-rx_refill_timer);
- }
-
- if (num_queues) {
- kfree(info-queues);
- info-queues = NULL;
- }
-
+ xennet_destroy_queues(info);
xennet_free_netdev(info-netdev);
return 0;
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [Draft C] Xen on ARM vITS Handling
On Wed, May 27, 2015 at 5:18 PM, Ian Campbell ian.campb...@citrix.com wrote:
Here follows draft C based on previous feedback.
Also at:
http://xenbits.xen.org/people/ianc/vits/draftC.{pdf,html}
I think I've captured most of the previous discussion, except where
explicitly noted by XXX or in other replies, but please do point out
places where I've missed something.
One area where I am pretty sure I've dropped the ball is on the
completion and update of `CREADR`. That conversation ended up
bifurcating along the 1:N vs N:N mapping scheme lines, and I didn't
manage to get the various proposals straight. Since we've now agreed on
N:N hopefully we can reach a conclusion (no pun intended) on the
completion aspect too (sorry that this probably means rehasing at least
a subset of the previous thread).
Ian.
% Xen on ARM vITS Handling
% Ian Campbell ian.campb...@citrix.com
% Draft C
# Changelog
## Since Draft B
* Details of command translation (thanks to Julien and Vijay)
* Added background on LPI Translation and Pending tablesd
* Added background on Collections
* Settled on `N:N` scheme for vITS:pITS mapping.
* Rejigged section nesting a bit.
* Since we now thing translation should be cheap, settle on
translation at scheduling time.
* Lazy `INVALL` and `SYNC`
## Since Draft A
* Added discussion of when/where command translation occurs.
* Contention on scheduler lock, suggestion to use SOFTIRQ.
* Handling of domain shutdown.
* More detailed discussion of multiple vs single vits pros/cons.
# Introduction
ARM systems containing a GIC version 3 or later may contain one or
more ITS logical blocks. An ITS is used to route Message Signalled
interrupts from devices into an LPI injection on the processor.
The following summarises the ITS hardware design and serves as a set
of assumptions for the vITS software design. (XXX it is entirely
possible I've horribly misunderstood how this stuff fits
together). For full details of the ITS see the GIC Architecture
Specification.
## Device Identifiers
Each device using the ITS is associated with a unique identifier.
The device IDs are typically described via system firmware, e.g. the
ACPI IORT table or via device tree.
The number of device ids is variable and can be discovered via
`GITS_TYPER.Devbits`. This field allows an ITS to have up to 2^32
device.
## Interrupt Collections
Each interrupt is a member of an Interrupt Collection. This allows
software to manage large numbers of physical interrupts with a small
number of commands rather than issuing one command per interrupt.
On a system with N processors, the ITS must provide at least N+1
collections.
## Target Addresses
The Target Address correspond to a specific GIC re-distributor. The format
of this field depends on the value of the `GITS_TYPER.PTA` bit:
* 1: the base address of the re-distributor target is used
* 0: a unique processor number is used. The mapping between the
processor affinity value (`MPIDR`) and the processor number is
discoverable via `GICR_TYPER.ProcessorNumber`.
## ITS Translation Table
Message signalled interrupts are translated into an LPI via an ITS
translation table which must be configured for each device which can
generate an MSI.
The ITS translation table maps the device id of the originating devic
into an Interrupt Collection and then into a target address.
## ITS Configuration
The ITS is configured and managed, including establishing and
configuring Translation Table for each device, via an in memory ring
shared between the CPU and the ITS controller. The ring is managed via
the `GITS_CBASER` register and indexed by `GITS_CWRITER` and
`GITS_CREADR` registers.
A processor adds commands to the shared ring and then updates
`GITS_CWRITER` to make them visible to the ITS controller.
The ITS controller processes commands from the ring and then updates
`GITS_CREADR` to indicate the the processor that the command has been
processed.
Commands are processed sequentially.
Commands sent on the ring include operational commands:
* Routing interrupts to processors;
* Generating interrupts;
* Clearing the pending state of interrupts;
* Synchronising the command queue
and maintenance commands:
* Map device/collection/processor;
* Map virtual interrupt;
* Clean interrupts;
* Discard interrupts;
The field `GITS_CBASER.Size` encodes the number of 4KB pages minus 0
consisting of the command queue. This field is 8 bits which means the
maximum size is 2^8 * 4KB = 1MB. Given that each command is 32 bytes,
there is a maximum of 32768 commands in the queue.
The ITS provides no specific completion notification
mechanism. Completion is monitored by a combination of a `SYNC`
command and either polling `GITS_CREADR` or notification via an
interrupt generated via the `INT` command.
Note that the interrupt generation via `INT` requires an originating
device ID to be supplied (which is then
Re: [Xen-devel] Earlier embargoed pre-disclosure without patches
On 26 May 2015, at 17:34, Stefano Stabellini stefano.stabell...@eu.citrix.com wrote: Thanks for the help, folks. I've tossed a proposed security policy change into a Github gist[1]. My proposal is to add this paragraph to the Embargo and disclosure schedule section of the Xen Security Policy[2]: In the event that a two week embargo cannot be guaranteed, we will send a draft with information about the vulnerability to the pre-disclosure list as soon as possible, even if patches have not yet been written or tested. An updated draft will be sent to the pre-disclosure list once patches become available. I welcome any and all feedback. Thanks! I would go for: In the event that public disclosure is less than 15 days away, we will send a draft with information about the vulnerability to the pre-disclosure list as soon as possible, even if patches have not yet been written or tested. An updated draft will be sent to the pre-disclosure list once patches become available. I think the wording can be tightened. There appear to be two sections which are relevant in http://www.xenproject.org/security-policy.html --- == Embargo and disclosure schedule == If a vulnerability is not already public, we would like to notify significant distributors and operators of Xen so that they can prepare patched software in advance. This will help minimise the degree to which there are Xen users who are vulnerable but can't get patches. As discussed, we will negotiate with discoverers about disclosure schedule. Our usual starting point for that negotiation, unless there are reasons to diverge from this, would be: 1. One working week between notification arriving at security@xenproject and the issue of our own advisory to our predisclosure list. We will use this time to gather information and prepare our advisory, including required patches. 2. Two working weeks between issue of our advisory to our predisclosure list and publication. When a discoverer reports a problem to us and requests longer delays than we would consider ideal, we will honour such a request if reasonable. If a discoverer wants an accelerated disclosure compared to what we would prefer, we naturally do not have the power to insist that a discoverer waits for us to be ready and will honour the date specified by the discoverer. Naturally, if a vulnerability is being exploited in the wild we will make immediately public release of the advisory and patch(es) and expect others to do likewise. ... == Specific process == ... 4. Advisory pre-release: This occurs only if the advisory is embargoed (ie, the problem is not already public): As soon as our advisory is available, we will send it, including patches, to members of the Xen security pre-disclosure list. For more information about this list, see below. At this stage the advisory will be clearly marked with the embargo date. ... 6. Updates If new information or better patches become available, or we discover mistakes, we may issue an amended (revision 2 or later) public advisory. This will also be sent to the pre-disclosure list. ... --- I would want to propose to word the suggestion differently. Firstly: An updated draft will be sent to the pre-disclosure list once patches become available. is already covered by 6 and not necessary. I would also like to propose to stick with two working weeks for consistency reasons. The following change should suffice IMHO --- == Specific process == ... 4. Advisory pre-release: This occurs only if the advisory is embargoed (ie, the problem is not already public): As soon as our advisory is available, we will send it, including patches, to members of the Xen security pre-disclosure list. In the event that we do not have a patch available two working weeks before the disclosure date, we will aim to send a draft of the advisory to the Xen security pre-disclosure list instead of a full advisory, and publish an updated advisory as soon as available. --- Somebody may have to go over the new paragraph and fix grammar issues (sorry: very tired from long plane ride). We also have options: replace will aim to with may Regards Lars ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] Tools backports for 4.5 [and 1 more messages]
On 27/05/15 17:09, Ian Jackson wrote: Jan Beulich writes (Re: [Xen-devel] Tools backports for 4.5): Andrew Cooper writes (Tools backports for 4.5): From the XenServer patch queue, (Andrew forgot to CC xen-devel, doing that now:) 3380f5b6270e ocaml/xenctrl: Check return values from hypercalls c8945d516134 ocaml/xenctrl: Make failwith_xc() thread safe 1a010ca99e9b ocaml/xenctrl: Fix stub_xc_readconsolering() 96e0ee8386cf tools/hotplug: systemd: Don't ever kill xenstored 588df84c0d70 tools/xenconsoled: Increase file descriptor limit I have just pushed these to staging-4.5. Jim Fehlig writes (Re: [Xen-devel] Tools backports for 4.5): I responded to Jan's preparing for 4.5.1 mail with backport requests that I currently don't see in staging-4.5 http://lists.xen.org/archives/html/xen-devel/2015-04/msg00168.html Thanks, I have pushed those three to staging-4.5 too. The above backports (771f857e..9d5b2b01) need to go to 4.4 and earlier as applicable. I will look at that soon (probably tomorrow). I have also picked up the fix to XSA-133 into all the qemu-trad trees back to 4.2 inclusive. (4.1 is no longer receiving even security fixes and has had no commits since 2013.) I think that's all the outstanding tools backports for the 4.5 branch. There is still a build fix from XSA-125 which as still even not been accepted into staging. This has been outstanding for 6 weeks now. 1428940983-8709-1-git-send-email-andrew.coop...@citrix.com ~Andrew ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] Osstest: stop testing SEDF, start testing RTDS
On Fri, 2015-05-22 at 21:29 -0700, Meng Xu wrote: Hi Dario, Hi, 2015-05-22 3:19 GMT-07:00 Dario Faggioli dario.faggi...@citrix.com: On Fri, 2015-05-22 at 11:55 +0200, Dario Faggioli wrote: the SEDF scheduler is about to be deprecated and go away (see [1]). OTOH, the RTDS scheduler is here to stay. I'm not so familiar with osstest. (Maybe I should have a look at it so that we can know how to use it for some auto tests.) I just have a quick (probably dummy) question: Do we have any document that describes the coverage of the test? If, by document, you mean the documentation one would need to used OSSTest, do development on it, and maybe setup and run an instance of, there is some docs --certainly much more than even a few weeks before now: README files in the sources} https://blog.xenproject.org/2013/02/02/xen-automatic-test-system-osstest/ http://www.xenproject.org/component/allvideoshare/video/xpds13-osstest.html https://blog.xenproject.org/2013/09/30/osstest-standalone-mode-step-by-step/ Setting up your own instance would be rather tricky, though, at least untile you get used enough to it. The reason I asked this is: 1) The document could make it easier for users to know which functionalities of the feature (i.e., RTDS scheduler here) have been tested. I don't think that's how OSSTest works or how it should be used. OSSTest is meant for us developers, in order to be sure that we do not cause regressions. That's why it gates commits. Users, if we say (e.g., in some release notes), that a feature is 'ready'/\supported\/whatever should be able to use it fully, and complain if it doesn't work, regardless of what tests us developers or OSSTest have run! 2) I didn't see the toolstack functionality of RTDS scheduler is called in the test. So I'm wondering about the first question. :-) (probably I missed something?) The test does what it's being done already for other schedulers: sets RTDS as the default scheduler, boots Xen with it, then it creates a domain, and it starts and stop it a few times. If you want to have a look, check make-flight, sg-run-job, ts-guest-start and ts-guest-stop in OSSTest's codebase. We do not do any testing of changing scheduling parameters of a guest, if that was what you were referring to, for any of the schedulers. We of course can introduce that (and do it for everyone), but that would be another patch series. Regards, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] [DOCS/RFC]: Xen: Clarification to terms used in hypervisor memory management
RFC: All changes here are subject to my current understanding, which might be wrong Memory management is hard[citation needed]. Furthermore, it isn't helped by the inconsistent use of terms through the code. Describe the currently-used terms in more practical terms. Signed-off-by: Andrew Cooper andrew.coop...@citrix.com CC: Keir Fraser k...@xen.org CC: Jan Beulich jbeul...@suse.com CC: Tim Deegan t...@xen.org CC: Ian Campbell ian.campb...@citrix.com CC: Stefano Stabellini stefano.stabell...@citrix.com --- The term 'pfn' is most little awkward, as it currently has two uses in different areas of the code. I would argue that the caller of the pagetable code ought to know exactly if it dealing with an mfn or a gfn in the pagetables, at which point pfn from the old point of view becomes redundant. Alternatively, we could standardise on gmfn/gpfn with the g helping to clarify what is guest value, but those are longer to type. After we agree on exact terminology, I plan to introduce TYPE_SAFE()'s of all (most?) terms to the common code. From this point, cleanup can start to happen. --- xen/include/xen/mm.h | 50 +- 1 file changed, 29 insertions(+), 21 deletions(-) diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h index a066363..37bc706 100644 --- a/xen/include/xen/mm.h +++ b/xen/include/xen/mm.h @@ -1,28 +1,36 @@ /** * include/xen/mm.h - * + * * Definitions for memory pages, frame numbers, addresses, allocations, etc. - * - * Note that Xen must handle several different physical 'address spaces' and - * there is a consistent terminology for these: - * - * 1. gpfn/gpaddr: A guest-specific pseudo-physical frame number or address. - * 2. gmfn/gmaddr: A machine address from the p.o.v. of a particular guest. - * 3. mfn/maddr: A real machine frame number or address. - * 4. pfn/paddr: Used in 'polymorphic' functions that work across all - * address spaces, depending on context. See the pagetable - * conversion macros in asm-x86/page.h for examples. - * Also 'paddr_t' is big enough to store any physical address. - * - * This scheme provides consistent function and variable names even when - * different guests are running in different memory-management modes. - * 1. A guest running in auto-translated mode (e.g., shadow_mode_translate()) - *will have gpfn == gmfn and gmfn != mfn. - * 2. A paravirtualised x86 guest will have gpfn != gmfn and gmfn == mfn. - * 3. A paravirtualised guest with no pseudophysical overlay will have - *gpfn == gpmfn == mfn. - * + * * Copyright (c) 2002-2006, K A Fraser k...@xensource.com + * + * +-+ + * Xen Memory Management + * +-+ + * + * Xen has to handle many different address spaces. It is important not to + * get these spaces mixed up. The following is a consistent terminology which + * should be adhered to. + * + * mfn: Machine Frame Number + * The values Xen puts into its own pagetables. This is the host physical + * memory address space with RAM, MMIO etc. + * + * gfn: Guest Frame Number + * The values a guest puts in its own pagetables. For an auto-translated + * guest (hardware assisted with 2nd stage translation, or shadowed), gfn != + * mfn. For a non-translated guest which is aware of Xen, gfn == mfn. + * + * pfn: Pseduophysical Frame Number + * A linear idea of a guest physical address space. For an auto-translated + * guest, pfn == gfn while for a non-translated guest, pfn != gfn. + * + * NOTE: Areas of the code do not use these terms consistently/correctly. New + * code should use these terms as described here, and over time older code + * should be corrected to be consistent. (TODO: remove me when the code is + * believed to be consistent) + * */ #ifndef __XEN_MM_H__ -- 1.7.10.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH net v2] xen/netback: Properly initialize credit_bytes
From: Ross Lagerwall ross.lagerw...@citrix.com Date: Wed, 27 May 2015 11:44:32 +0100 Commit e9ce7cb6b107 (xen-netback: Factor queue-specific data into queue struct) introduced a regression when moving queue-specific data into the queue struct by failing to set the credit_bytes field. This prevented bandwidth limiting from working. Initialize the field as it was done before multiqueue support was added. Signed-off-by: Ross Lagerwall ross.lagerw...@citrix.com Applied, thanks Ross. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [Patch V3 14/15] xen: allow more than 512 GB of RAM for 64 bit pv-domains
On 27/05/15 17:25, David Vrabel wrote: On 20/04/15 06:23, Juergen Gross wrote: 64 bit pv-domains under Xen are limited to 512 GB of RAM today. The main reason has been the 3 level p2m tree, which was replaced by the virtual mapped linear p2m list. Parallel to the p2m list which is being used by the kernel itself there is a 3 level mfn tree for usage by the Xen tools and eventually for crash dump analysis. For this tree the linear p2m list can serve as a replacement, too. As the kernel can't know whether the tools are capable of dealing with the p2m list instead of the mfn tree, the limit of 512 GB can't be dropped in all cases. This patch replaces the hard limit by a kernel parameter which tells the kernel to obey the 512 GB limit or not. The default is selected by a configuration parameter which specifies whether the 512 GB limit should be active per default for domUs (domain save/restore/migration and crash dump analysis are affected). Memory above the domain limit is returned to the hypervisor instead of being identity mapped, which was wrong anyway. The kernel configuration parameter to specify the maximum size of a domain can be deleted, as it is not relevant any more. Something in this patch breaks the hvc console in my test domU. kernel BUG at /local/davidvr/work/k.org/tip/drivers/tty/hvc/hvc_xen.c:153 Which suggests the hvc driver mapped the wrong console ring frame. Sorry, it's patch #13 (xen: move p2m list if conflicting with e820 map) that seems to be bad. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 4/4] iommu: add rmrr Xen command line option for extra rmrrs
On Tue, May 26, 2015 at 01:02:27PM +0100, Jan Beulich wrote:
On 23.05.15 at 03:33, elena.ufimts...@oracle.com wrote:
--- a/docs/misc/xen-command-line.markdown
+++ b/docs/misc/xen-command-line.markdown
@@ -1185,6 +1185,19 @@ Specify the host reboot method.
'efi' instructs Xen to reboot using the EFI reboot call (in EFI mode by
default it will use that method first).
+### rmrr
+ '=
start-end=[s1]bdf1[,[s1]bdf2[,...]];start-end=[s2]bdf1[,[s2]bdf2[,...]]
+
+Define RMRRs units that are missing from ACPI table along with device
+they belong to and use them for 1:1 mapping. End addresses can be omitted
+and one page will be mapped. The ranges are inclusive when start and end
+are specified.If segement of the first device is not specified, the
default segment will be used.
Thanks for review Jan.
specified. If the segment ..., segment zero will be used.
+If segments are specified for every device and not equal, error will be
reported.
..., an error ...
--- a/xen/drivers/passthrough/vtd/dmar.c
+++ b/xen/drivers/passthrough/vtd/dmar.c
@@ -50,6 +50,7 @@ static LIST_HEAD_READ_MOSTLY(acpi_rhsa_units);
static struct acpi_table_header *__read_mostly dmar_table;
static int __read_mostly dmar_flags;
static u64 __read_mostly igd_drhd_address;
+static void __init add_extra_rmrr(void);
Why do you need this declaration? (And if you really need it - no
segment annotations on declarations please.)
@@ -856,6 +857,78 @@ out:
return ret;
}
+#define MAX_EXTRA_RMRR_PAGES 16
+#define MAX_EXTRA_RMRR 10
+static __initdata unsigned int nr_rmrr;
+static struct __initdata extra_rmrr_unit rmrru[MAX_EXTRA_RMRR];
+
+static void __init add_extra_rmrr(void)
+{
+struct acpi_rmrr_unit *rmrrn;
+unsigned int dev, seg, addr;
+
+for (unsigned int i = 0; i nr_rmrr; i++ )
No C++ style constructs like this please. Instead please add the
missing blank after the opening parenthesis.
+{
+rmrrn = xmalloc(struct acpi_rmrr_unit);
acpi_parse_one_rmrr() uses xzalloc() here. For the avoidance of
doubt, I'd be fine with you doing so provided this is correct (i.e. all
fields end up properly initialized, just like is the case with the
-scope.devices allocation), if this wasn't introducing a latent bug
(should a field get added).
Agree, will change this.
+if ( !rmrrn )
+return;
+
+rmrrn-scope.devices = xmalloc_array(typeof(*rmrrn-scope.devices),
I'm afraid I may have mislead you with comments elsewhere: In
xmalloc() invocations, considering the typeful result it produces,
using the spelled out type is preferred over typeof() like used
here.
Thanks for explanation, I did not know that.
+ rmrru[i].dev_count);
+if ( !rmrrn-scope.devices )
+{
+xfree(rmrrn);
+return;
+}
+
+if ( rmrru[i].end_address - rmrru[i].base_address
MAX_EXTRA_RMRR_PAGES )
Now this reads really odd: With the conversion to store page numbers
in these fields, they should have got renamed from _address (and
afaict no longer need to be of u64 type). Also note that you have an
off-by-one error here: The end address being inclusive, you want to
bail on = max.
I also fail to see end base being rejected somewhere. Nor are
overlaps being dealt with (see acpi_parse_one_rmrr()).
Somehow I skipped that, possibly wrong brnach.
Will fix this and add overlap check.
+{
+printk(XENLOG_ERR VTDPREFIX
+ RMRR range exceeds 16 pages [%PRIx64 - %PRIx64]\n,
+ rmrru[i].base_address, rmrru[i].end_address);
+xfree(rmrrn-scope.devices);
+xfree(rmrrn);
+return;
+}
+
+for ( addr = rmrru[i].base_address; addr = rmrru[i].end_address;
addr++ )
And the loop variable here shouldn't be addr then (and certainly not
of type unsigned int).
+{
+if ( iommu_verbose )
+printk(XENLOG_ERR VTDPREFIX
+ Invalid mfn in RMRR range [%PRIx64 -
%PRIx64]\n,
+ rmrru[i].base_address, rmrru[i].end_address);
+xfree(rmrrn-scope.devices);
+xfree(rmrrn);
+return;
+}
+
+seg = 0;
+for ( dev = 0; dev rmrru-dev_count; dev++ )
+{
+rmrrn-scope.devices[dev] = rmrru-sbdf[dev];
+seg = seg | (rmrru-sbdf[dev] 16);
|=
Also with you having added PCI_SBDF() in patch 1, you should add
the matched PCI_SEG() (or some such) instead of open coding it
here.
Yes, will be also useful.
+}
+if ( seg != (rmrru-sbdf[0] 16) )
+{
+printk(XENLOG_ERR VTDPREFIX
+ Segments are not equal for RMRR range [%PRIx64 -
%PRIx64]\n,
+
Re: [Xen-devel] [PATCH] dmar: device scope mem leak fix
On Tue, May 26, 2015 at 10:46:30AM +0100, Jan Beulich wrote:
On 23.05.15 at 03:27, elena.ufimts...@oracle.com wrote:
@@ -318,13 +321,13 @@ static int __init acpi_parse_dev_scope(
if ( (cnt = scope_device_count(start, end)) 0 )
return cnt;
-scope-devices_cnt = cnt;
if ( cnt 0 )
{
scope-devices = xzalloc_array(u16, cnt);
if ( !scope-devices )
return -ENOMEM;
}
+scope-devices_cnt = cnt;
Together with this, shouldn't you also clear -devices_cnt along
with freeing -devices on the error path at the end of the function?
Yes, absolutely.
@@ -658,6 +661,7 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
Ignore the RMRR (%PRIx64, %PRIx64) due to
devices under its scope are not PCI discoverable!\n,
rmrru-base_address, rmrru-end_address);
+xfree(rmrru-scope.devices);
xfree(rmrru);
Do you think the ret should be set in this case also?
}
else if ( base_addr end_addr )
@@ -665,6 +669,7 @@ acpi_parse_one_rmrr(struct acpi_dmar_header *header)
dprintk(XENLOG_WARNING VTDPREFIX,
The RMRR (%PRIx64, %PRIx64) is incorrect!\n,
rmrru-base_address, rmrru-end_address);
+xfree(rmrru-scope.devices);
xfree(rmrru);
ret = -EFAULT;
}
Why not also in acpi_parse_one_drhd() (and for consistency also
acpi_parse_one_atsr(), even if only being a latent issue there right
now)?
I missed that, will add as well.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH V2] libxl: support domainReset
Currently, libxl does not provide a reset function, but domainReset
can be implemented in the libxl driver by forcibly destroying the
domain and starting it again.
Signed-off-by: Jim Fehlig jfeh...@suse.com
---
This is essentially a V2 of a patch submitted quite some time ago
https://www.redhat.com/archives/libvir-list/2014-August/msg00077.html
The idea of implmenting domainReset in the libxl driver by forcibly
destroying the domain and starting it again was ACK'ed in principle
by Ian Campbell
https://www.redhat.com/archives/libvir-list/2014-August/msg00109.html
I never pushed the patch since it was not ACK'ed by a libvirt
maintainer and stumbled across it while cleaning up some of my
old branches. The only change here is rebase against current
libvirt.git master.
src/libxl/libxl_driver.c | 59
1 file changed, 59 insertions(+)
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 12be816..671d336 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -1237,6 +1237,64 @@ libxlDomainReboot(virDomainPtr dom, unsigned int flags)
}
static int
+libxlDomainReset(virDomainPtr dom, unsigned int flags)
+{
+libxlDriverPrivatePtr driver = dom-conn-privateData;
+libxlDriverConfigPtr cfg = libxlDriverConfigGet(driver);
+virDomainObjPtr vm;
+int ret = -1;
+
+virCheckFlags(0, -1);
+
+if (!(vm = libxlDomObjFromDomain(dom)))
+goto cleanup;
+
+if (virDomainResetEnsureACL(dom-conn, vm-def) 0)
+goto cleanup;
+
+if (libxlDomainObjBeginJob(driver, vm, LIBXL_JOB_MODIFY) 0)
+goto cleanup;
+
+if (!virDomainObjIsActive(vm)) {
+virReportError(VIR_ERR_OPERATION_INVALID,
+ %s, _(Domain is not running));
+goto endjob;
+}
+
+/*
+ * The semantics of reset can be achieved by forcibly destroying
+ * the domain and starting it again.
+ */
+if (libxl_domain_destroy(cfg-ctx, vm-def-id, NULL) 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+ _(Failed to destroy domain '%d' before reset),
+ vm-def-id);
+goto endjob;
+}
+
+libxlDomainCleanup(driver, vm, VIR_DOMAIN_SHUTOFF_DESTROYED);
+
+if (libxlDomainStart(driver, vm, false, -1) 0) {
+virReportError(VIR_ERR_INTERNAL_ERROR,
+ _(Failed to start domain '%d' after reset),
+ vm-def-id);
+goto endjob;
+}
+
+ret = 0;
+
+ endjob:
+if (!libxlDomainObjEndJob(driver, vm))
+vm = NULL;
+
+ cleanup:
+if (vm)
+virObjectUnlock(vm);
+virObjectUnref(cfg);
+return ret;
+}
+
+static int
libxlDomainDestroyFlags(virDomainPtr dom,
unsigned int flags)
{
@@ -5066,6 +5124,7 @@ static virHypervisorDriver libxlHypervisorDriver = {
.domainShutdown = libxlDomainShutdown, /* 0.9.0 */
.domainShutdownFlags = libxlDomainShutdownFlags, /* 0.9.10 */
.domainReboot = libxlDomainReboot, /* 0.9.0 */
+.domainReset = libxlDomainReset, /* 1.2.8 */
.domainDestroy = libxlDomainDestroy, /* 0.9.0 */
.domainDestroyFlags = libxlDomainDestroyFlags, /* 0.9.4 */
.domainGetOSType = libxlDomainGetOSType, /* 0.9.0 */
--
2.3.7
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v6 1/4] pci: add pci_iomap_wc() variants
On Tue, May 26, 2015 at 12:40:08PM -0500, Bjorn Helgaas wrote: On Fri, May 22, 2015 at 02:23:41AM +0200, Luis R. Rodriguez wrote: On Thu, May 21, 2015 at 05:33:21PM -0500, Bjorn Helgaas wrote: I tentatively put this (and the rest of the series) on a pci/resource branch. I'm hoping you'll propose some clarification about EXPORT_SYMBOL_GPL(). EXPORT_SYMBOL_GPL() also serves to ensure only GPL modules can only run that code. So for instance although we have Dual BSD/GPL tags for modules pure BSD tags do not exist for module tags and cannot run EXPORT_SYMBOL_GPL() code [0]. Also there is some folks who do believe tha at run time all kernel modules are GPL [1] [2]. And to be precise even though the FSF may claim a list of licenses are GPL-compatible we cannot rely on this list alone for our own goals and if folks want to use our EXPORT_SYMBOL_GPL()s they must discuss this on lkml [2]. By propose some clarification, I meant that I hoped you would propose a patch to Documentation/ that would give maintainers some guidance. I *really really* would hate to do so but only because you insist, I'll look into this... ASDF Luis ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 57380: regressions - FAIL
flight 57380 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/57380/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 56492 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass version targeted for testing: ovmf 0ad3c50558955afddcc03b5dfbce0b53665cbbff baseline version: ovmf f1f0f0deb6e64df6b7c04ead7330afecf5537e46 People who touched revisions under test: Mudusuru, Giri P giri.p.mudus...@intel.com Yao, Jiewen jiewen@intel.com Chao Zhang chao.b.zh...@intel.com Dandan Bi dandan...@intel.com Eric Dong eric.d...@intel.com Feng Tian feng.t...@intel.com Guo Dong guo.d...@intel.com Hao Wu hao.a...@intel.com Jeff Fan jeff@intel.com jiaxinwu jiaxin...@intel.com Liming Gao liming@intel.com Ludovic Rousseau ludovic.rouss...@gmail.com Mudusuru, Giri P giri.p.mudus...@intel.com Ruiyu Ni ruiyu...@intel.com Shifei Lu shifeix.a...@intel.com Star Zeng star.z...@intel.com Yao, Jiewen jiewen@intel.com Yingke Liu yingke.d@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-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail 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 Not pushing. (No revision log; it would be 882 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 05/10] xsm: add XEN_DOMCTL_soft_reset support
On 05/27/2015 11:25 AM, Vitaly Kuznetsov wrote:
Dummy policy just checks that the current domain is privileged. In the FLASK
policy two new vectors are added to the DOMAIN2 class: soft_reset and
reset_transfer. First one is being used to check that the domain making the
hypercall is allowed to do it, the second is being used that is's possible
two typos in the commit message
to trasfer memory from source domain to destination domain. The default policy
requires their contexts to match.
Signed-off-by: Vitaly Kuznetsov vkuzn...@redhat.com
Acked-by: Daniel De Graaf dgde...@tycho.nsa.gov
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 57335: regressions - trouble: broken/fail/pass
flight 57335 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/57335/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl 3 host-install(3) broken REGR. vs. 56375 test-armhf-armhf-xl-credit2 9 debian-installfail REGR. vs. 56375 test-armhf-armhf-xl-multivcpu 17 leak-check/check fail REGR. vs. 56375 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-sedf 3 host-install(3) broken REGR. vs. 56375 test-amd64-amd64-libvirt 11 guest-start fail REGR. vs. 56375 test-amd64-i386-libvirt-xsm 11 guest-start fail like 56375 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 56375 test-amd64-i386-libvirt 11 guest-start fail like 56375 test-armhf-armhf-libvirt 11 guest-start fail like 56375 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 56375 test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail like 56948-bisect Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-xsm 14 guest-localmigrate fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-i386-xl-xsm 14 guest-localmigrate fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 12 guest-localmigrate fail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: xen 6b05648d12ea2a797d6ef9ebc074ee0c03646bce baseline version: xen e13013dbf1d5997915548a3b5f1c39594d8c1d7b People who touched revisions under test: Andrew Cooper andrew.coop...@citrix.com Charles Arnold carn...@suse.com Chen Baozi baoz...@gmail.com Daniel De Graaf dgde...@tycho.nsa.gov David Vrabel david.vra...@citrix.com George Dunlap george.dun...@eu.citrix.com Huaitong Han huaitong@intel.com Ian Campbell ian.campb...@citrix.com Ian Jackson ian.jack...@eu.citrix.com Jan Beulich jbeul...@suse.com Julien Grall julien.gr...@citrix.com Julien Grall julien.gr...@citrix.com (ARM) Julien Grall julien.gr...@linaro.org Kevin Tian kevin.t...@intel.com Konrad Rzeszutek Wilk konrad.w...@oracle.com Len Brown len.br...@intel.com Olaf Hering o...@aepfle.de Pranavkumar Sawargaonkar pranavku...@linaro.org Roger Pau Monné roger@citrix.com Tiejun Chen tiejun.c...@intel.com Tim Deegan t...@xen.org 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 broken test-amd64-i386-xl
[Xen-devel] [linux-3.18 test] 57345: regressions - trouble: blocked/broken/fail/pass
flight 57345 linux-3.18 real [real] http://logs.test-lab.xenproject.org/osstest/logs/57345/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf 3 host-install(3) broken REGR. vs. 57312 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 57312 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a test-armhf-armhf-xl 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-xl-sedf-pin 1 build-check(1) blocked n/a test-armhf-armhf-xl-sedf 1 build-check(1) blocked n/a test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a build-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-amd64-i386-xl-xsm 11 guest-start fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-libvirt-xsm 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-xsm 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-freebsd10-i386 9 freebsd-install fail never pass test-amd64-i386-freebsd10-amd64 9 freebsd-install fail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl-xsm 6 xen-boot fail never pass version targeted for testing: linux51af817611f2c0987030d024f24fc7ea95dd33e6 baseline version: linuxb2776bf7149bddd1f4161f14f79520f17fc1d71d 900 people touched revisions under test, not listing them all jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf broken build-i386 pass build-amd64-libvirt pass build-armhf-libvirt blocked 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 blocked test-amd64-i386-xl pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-libvirt-xsm fail test-armhf-armhf-libvirt-xsm blocked test-amd64-i386-libvirt-xsm fail test-amd64-amd64-xl-xsm fail test-armhf-armhf-xl-xsm fail test-amd64-i386-xl-xsm fail 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-amd64
[Xen-devel] [rumpuserxen test] 57368: regressions - FAIL
flight 57368 rumpuserxen real [real] http://logs.test-lab.xenproject.org/osstest/logs/57368/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-rumpuserxen 5 rumpuserxen-build fail REGR. vs. 33866 build-i386-rumpuserxen5 rumpuserxen-build fail REGR. vs. 33866 Tests which did not succeed, but are not blocking: test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a version targeted for testing: rumpuserxen 3b91e44996ea6ae1276bce1cc44f38701c53ee6f baseline version: rumpuserxen 30d72f3fc5e35cd53afd82c8179cc0e0b11146ad People who touched revisions under test: Antti Kantee po...@iki.fi Ian Jackson ian.jack...@eu.citrix.com Martin Lucina mar...@lucina.net Wei Liu l...@liuw.name jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-pvopspass build-i386-pvops pass build-amd64-rumpuserxen fail build-i386-rumpuserxen fail test-amd64-amd64-rumpuserxen-amd64 blocked test-amd64-i386-rumpuserxen-i386 blocked 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 Not pushing. (No revision log; it would be 535 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 57340: regressions - FAIL
flight 57340 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/57340/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail REGR. vs. 56492 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail REGR. vs. 56492 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass version targeted for testing: ovmf e6557276f0cf3c114dc881be2478cf724b171e39 baseline version: ovmf f1f0f0deb6e64df6b7c04ead7330afecf5537e46 People who touched revisions under test: Mudusuru, Giri P giri.p.mudus...@intel.com Yao, Jiewen jiewen@intel.com Chao Zhang chao.b.zh...@intel.com Dandan Bi dandan...@intel.com Eric Dong eric.d...@intel.com Feng Tian feng.t...@intel.com Guo Dong guo.d...@intel.com Hao Wu hao.a...@intel.com Jeff Fan jeff@intel.com jiaxinwu jiaxin...@intel.com Liming Gao liming@intel.com Ludovic Rousseau ludovic.rouss...@gmail.com Mudusuru, Giri P giri.p.mudus...@intel.com Ruiyu Ni ruiyu...@intel.com Star Zeng star.z...@intel.com Yao, Jiewen jiewen@intel.com Yingke Liu yingke.d@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-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail 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 Not pushing. (No revision log; it would be 771 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-3.4 test] 57390: regressions - FAIL
flight 57390 linux-3.4 real [real] http://logs.test-lab.xenproject.org/osstest/logs/57390/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl 9 debian-install fail REGR. vs. 52209-bisect test-amd64-amd64-pair 15 debian-install/dst_host fail REGR. vs. 52715-bisect test-amd64-i386-pair15 debian-install/dst_host fail REGR. vs. 56366-bisect Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 9 debian-installfail blocked in 56366-bisect test-amd64-amd64-libvirt 9 debian-installfail blocked in 56366-bisect test-amd64-i386-libvirt 9 debian-installfail blocked in 56366-bisect test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-multivcpu 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-freebsd10-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-libvirt-xsm 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl9 debian-installfail blocked in 56366-bisect test-amd64-i386-rumpuserxen-i386 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-sedf-pin 9 debian-installfail blocked in 56366-bisect test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-rumpuserxen-amd64 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail blocked in 56366-bisect test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail blocked in 56366-bisect test-amd64-i386-freebsd10-i386 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-bootfail blocked in 56366-bisect test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail blocked in 56366-bisect test-amd64-amd64-xl-qemut-winxpsp3 6 xen-bootfail blocked in 56366-bisect test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-bootfail like 53709-bisect Tests which did not succeed, but are not blocking: test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-xsm9 debian-install fail never pass test-amd64-amd64-xl-credit2 9 debian-install fail never pass test-amd64-amd64-xl-pvh-amd 9 debian-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-libvirt-xsm 9 debian-install fail never pass test-amd64-amd64-xl-pvh-intel 9 debian-install fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-xsm 9 debian-install fail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: linux56b48fcda5076d4070ab00df32ff5ff834e0be86 baseline version: linuxbb4a05a0400ed6d2f1e13d1f82f289ff74300a70 370 people touched revisions under test, not listing them all 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 build-amd64-rumpuserxen pass build-i386-rumpuserxen pass test-amd64-amd64-xl fail test-amd64-i386-xl fail test-amd64-amd64-xl-qemut-debianhvm-amd64-xsmfail
[Xen-devel] [PATCH V7] xen/vm_event: Clean up control-register-write vm_events and add XCR0 event
As suggested by Andrew Cooper, this patch attempts to remove
some redundancy and allow for an easier time when adding vm_events
for new control registers in the future, by having a single
VM_EVENT_REASON_WRITE_CTRLREG vm_event type, meant to serve CR0,
CR3, CR4 and (newly introduced) XCR0. The actual control register
will be deduced by the new .index field in vm_event_write_ctrlreg
(renamed from vm_event_mov_to_cr). The patch has also modified
the xen-access.c test - it is now able to log CR3 events.
Signed-off-by: Razvan Cojocaru rcojoc...@bitdefender.com
Acked-by: Jan Beulich jbeul...@suse.com
---
Changes since V6:
- Removed Reviewed-by: Tim Deegan t...@xen.org, as the patch
went beyond cosmetic-only changes.
- Parenthesized hvm_event_cr in event.c, to prevent expansion of
the macro with the same name if event.h gets #included.
- Moved the hvm_event_cr() macro immediately adjacent to the
hvm_event_cr() function declaration.
---
tools/libxc/include/xenctrl.h |9 ++---
tools/libxc/xc_monitor.c| 40 +++---
tools/tests/xen-access/xen-access.c | 30 +++--
xen/arch/x86/hvm/event.c| 54 --
xen/arch/x86/hvm/hvm.c | 11 +++---
xen/arch/x86/hvm/vmx/vmx.c |6 ++--
xen/arch/x86/monitor.c | 63 +--
xen/include/asm-x86/domain.h| 12 ++-
xen/include/asm-x86/hvm/event.h |5 ++-
xen/include/asm-x86/monitor.h |2 ++
xen/include/public/domctl.h | 12 +++
xen/include/public/vm_event.h | 29
12 files changed, 113 insertions(+), 160 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 09a7450..83fd289 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2375,12 +2375,9 @@ int xc_mem_access_disable_emulate(xc_interface *xch,
domid_t domain_id);
void *xc_monitor_enable(xc_interface *xch, domid_t domain_id, uint32_t *port);
int xc_monitor_disable(xc_interface *xch, domid_t domain_id);
int xc_monitor_resume(xc_interface *xch, domid_t domain_id);
-int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly);
-int xc_monitor_mov_to_cr3(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly);
-int xc_monitor_mov_to_cr4(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly);
+int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
+ uint16_t index, bool enable, bool sync,
+ bool onchangeonly);
int xc_monitor_mov_to_msr(xc_interface *xch, domid_t domain_id, bool enable,
bool extended_capture);
int xc_monitor_singlestep(xc_interface *xch, domid_t domain_id, bool enable);
diff --git a/tools/libxc/xc_monitor.c b/tools/libxc/xc_monitor.c
index 87ad968..63013de 100644
--- a/tools/libxc/xc_monitor.c
+++ b/tools/libxc/xc_monitor.c
@@ -45,8 +45,9 @@ int xc_monitor_resume(xc_interface *xch, domid_t domain_id)
NULL);
}
-int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly)
+int xc_monitor_write_ctrlreg(xc_interface *xch, domid_t domain_id,
+ uint16_t index, bool enable, bool sync,
+ bool onchangeonly)
{
DECLARE_DOMCTL;
@@ -54,39 +55,8 @@ int xc_monitor_mov_to_cr0(xc_interface *xch, domid_t
domain_id, bool enable,
domctl.domain = domain_id;
domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
: XEN_DOMCTL_MONITOR_OP_DISABLE;
-domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR0;
-domctl.u.monitor_op.u.mov_to_cr.sync = sync;
-domctl.u.monitor_op.u.mov_to_cr.onchangeonly = onchangeonly;
-
-return do_domctl(xch, domctl);
-}
-
-int xc_monitor_mov_to_cr3(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly)
-{
-DECLARE_DOMCTL;
-
-domctl.cmd = XEN_DOMCTL_monitor_op;
-domctl.domain = domain_id;
-domctl.u.monitor_op.op = enable ? XEN_DOMCTL_MONITOR_OP_ENABLE
-: XEN_DOMCTL_MONITOR_OP_DISABLE;
-domctl.u.monitor_op.event = XEN_DOMCTL_MONITOR_EVENT_MOV_TO_CR3;
-domctl.u.monitor_op.u.mov_to_cr.sync = sync;
-domctl.u.monitor_op.u.mov_to_cr.onchangeonly = onchangeonly;
-
-return do_domctl(xch, domctl);
-}
-
-int xc_monitor_mov_to_cr4(xc_interface *xch, domid_t domain_id, bool enable,
- bool sync, bool onchangeonly)
-{
-DECLARE_DOMCTL;
-
-domctl.cmd = XEN_DOMCTL_monitor_op;
-domctl.domain = domain_id;
-domctl.u.monitor_op.op = enable ?
Re: [Xen-devel] gntdev/gntalloc and fork? - crash in gntdev
On Thu, Apr 30, 2015 at 04:47:44PM +0200, Marek Marczykowski-Górecki wrote: Hi, What is the proper way to handle shared pages (either side - using gntdev or gntalloc) regarding fork and possible exec later? The child process do not need to access those pages in any way, but will map different one(s), using newly opened FD to the gntdev/gntalloc device. Should it unmap them and close FD to the device manually just after the fork? Or the process using gntdev or gntalloc should prevent using fork at all? I'm asking because I get kernel oops[1] in context of such process. This process uses both gntdev and gntalloc. The PID reported there is a child, which maps additional pages (using newly opened FD to /dev/xen/gnt*), but I'm not sure if the crash happens before, after or at this second mapping (actually vchan connection), or maybe even at cleanup of this second mapping. The parent process keeps its mappings for the whole lifetime of its child. I don't have a 100% reliable way to reproduce this problem, but it happens quite often when I run such operations in a loop. Any ideas? The kernel is vanilla 3.19.3, running on Xen 4.4.2. The kernel message: [74376.073464] general protection fault: [#1] SMP [74376.073475] Modules linked in: fuse xt_conntrack ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip6table_filter ip6_tables intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul crc32c_intel pcspkr xen_netfront ghash_clmulni_intel nfsd auth_rpcgss nfs_acl lockd grace xenfs xen_privcmd dummy_hcd udc_core xen_gntdev xen_gntalloc xen_blkback sunrpc u2mfn(O) xen_evtchn xen_blkfront [74376.073522] CPU: 1 PID: 9377 Comm: qrexec-agent Tainted: G O 3.19.3-4.pvops.qubes.x86_64 #1 [74376.073528] task: 880002442e40 ti: 8832c000 task.ti: 8832c000 [74376.073532] RIP: e030:[a00952c5] [a00952c5] unmap_if_in_range+0x15/0xd0 [xen_gntdev] [74376.073543] RSP: e02b:8832fc08 EFLAGS: 00010292 [74376.073546] RAX: RBX: dead00100100 RCX: 7fd8616ea000 [74376.073550] RDX: 7fd8616ea000 RSI: 7fd8616e9000 RDI: dead00100100 [74376.073554] RBP: 8832fc48 R08: R09: [74376.073557] R10: ea21bb00 R11: R12: 7fd8616e9000 [74376.073561] R13: 7fd8616ea000 R14: 880012702e40 R15: 880012702e70 [74376.073569] FS: 7fd8616ca700() GS:880013c8() knlGS: [74376.073574] CS: e033 DS: ES: CR0: 80050033 [74376.073577] CR2: 7fd8616e9458 CR3: e7af5000 CR4: 00042660 [74376.073582] Stack: [74376.073584] 8800188356c0 00d0 8832fc68 c64ef797 [74376.073590] 0220 dead00100100 7fd8616e9000 7fd8616ea000 [74376.073596] 8832fc88 a00953c6 8832fcc8 880012702e70 [74376.073603] Call Trace: [74376.073610] [a00953c6] mn_invl_range_start+0x46/0x90 [xen_gntdev] [74376.073620] [811e88fb] __mmu_notifier_invalidate_range_start+0x5b/0x90 [74376.073627] [811c2a59] do_wp_page+0x769/0x820 [74376.074031] [811c4f5c] handle_mm_fault+0x7fc/0x10c0 [74376.074031] [813864cd] ? radix_tree_lookup+0xd/0x10 [74376.074031] [81061e1c] __do_page_fault+0x1dc/0x5a0 [74376.074031] [817560a6] ? mutex_lock+0x16/0x37 [74376.074031] [a0008928] ? evtchn_ioctl+0x118/0x3c0 [xen_evtchn] [74376.074031] [812209d8] ? do_vfs_ioctl+0x2f8/0x4f0 [74376.074031] [811cafdf] ? do_munmap+0x29f/0x3b0 [74376.074031] [81062211] do_page_fault+0x31/0x70 [74376.074031] [81759e28] page_fault+0x28/0x30 [74376.074031] Code: e9 dd fd ff ff 31 c9 31 db e9 20 fe ff ff 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 e5 41 55 41 54 53 48 89 fb 48 83 ec 28 48 8b 47 10 48 85 c0 74 4e 4c 8b 00 49 39 d0 73 46 4c 8b 48 08 [74376.074031] RIP [a00952c5] unmap_if_in_range+0x15/0xd0 [xen_gntdev] [74376.074031] RSP 8832fc08 [74376.091682] ---[ end trace 2b21c5b714eb1071 ]--- [74404.069009] NMI watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [qrexec-agent:9379] [74404.069009] Modules linked in: fuse xt_conntrack ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack ip6table_filter ip6_tables intel_rapl iosf_mbi x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul crc32c_intel pcspkr xen_netfront ghash_clmulni_intel nfsd auth_rpcgss nfs_acl lockd grace xenfs xen_privcmd dummy_hcd udc_core xen_gntdev xen_gntalloc xen_blkback sunrpc u2mfn(O) xen_evtchn xen_blkfront [74404.069009] CPU: 2 PID: 9379 Comm: qrexec-agent Tainted: G DO 3.19.3-4.pvops.qubes.x86_64 #1 [74404.069009] task:
Re: [Xen-devel] [RFC][v2][PATCH 00/14] Fix RMRR
On 2015/5/22 17:46, Jan Beulich wrote:
On 22.05.15 at 11:35, tiejun.c...@intel.com wrote:
As you know all devices are owned by Dom0 firstly before we create any
DomU, right? Do we allow Dom0 still own a group device while assign another
device in the same group?
Clearly not, or - just like anything else putting the security of a system
at risk - only at explicit host admin request.
You're right.
After we discussed internally, we're intending to cover this simply
since the case of shared RMRR is a rare case according to our previous
experiences. Furthermore, Xen doesn't have a good existing API to
directly assign this sort of group devices and even Xen doesn't identify
these devices, so currently we always assign devices one by one, right?
This means we have to put more efforts to concern a good implementation
to address something like, identification, atomic, hotplug and so on.
Obviously, this would involve hypervisor and tools at the same time so
this has a little bit of difficulty to work along with 4.6.
So could we do this separately?
#1. Phase 1 to 4.6
#1.1. Do a simple implementation
We just prevent from that device assignment if we're assigning this sort
of group devices like this,
@@ -2291,6 +2291,16 @@ static int intel_iommu_assign_device(
PCI_BUS(bdf) == bus
PCI_DEVFN2(bdf) == devfn )
{
+if ( rmrr-scope.devices_cnt 1 )
+{
+reassign_device_ownership(d, hardware_domain, devfn, pdev);
+printk(XENLOG_G_ERR VTDPREFIX
+cannot assign any device with RMRR for Dom%d
(%d)\n,
+ rmrr-base_address, rmrr-end_address,
+ d-domain_id, ret);
+ret = -EPERM;
+break;
+}
ret = rmrr_identity_mapping(d, 1, rmrr, flag);
if ( ret )
{
Note this is just one draft code to show our idea. And I'm also
concerning if we need to introduce a flag to bypass this to make sure we
still have a approach to our original behavior.
#1.2. Post a design
We'd like to post a preliminary design to Xen community to get a better
solution.
#2. Phase 2 after 4.6
Once the design is clear we will start writing patches to address this
completely.
So any idea?
Thanks
Tiejun
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 57404: regressions - FAIL
flight 57404 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/57404/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-freebsd10-amd64 16 guest-localmigrate/x10 fail in 57362 REGR. vs. 56831 Tests which are failing intermittently (not blocking): test-armhf-armhf-xl-cubietruck 3 host-install(3) broken in 57362 pass in 57404 test-armhf-armhf-xl-sedf-pin 3 host-install(3) broken in 57362 pass in 57404 test-amd64-i386-freebsd10-i386 6 xen-boot fail in 57362 pass in 57404 test-amd64-i386-freebsd10-amd64 12 guest-saverestorefail pass in 57362 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt 11 guest-start fail like 56784 test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-installfail like 56784 test-amd64-i386-libvirt 11 guest-start fail like 56831 test-amd64-amd64-libvirt 11 guest-start fail like 56831 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-libvirt-xsm 11 guest-start fail never pass test-amd64-amd64-xl-xsm 11 guest-start fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-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-xl-xsm 11 guest-start fail never pass test-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-xsm 11 guest-start fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-sedf-pin 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail never pass version targeted for testing: qemuu0915aed5842bd4dbe396b92d4f3b846ae29ad663 baseline version: qemuueba05e922e8e7f307bc5d4104a78797e55124e97 People who touched revisions under test: Alberto Garcia be...@igalia.com Bastian Koppelmann kbast...@mail.uni-paderborn.de Christoph Hellwig h...@lst.de Cole Robinson crobi...@redhat.com Daniel P. Berrange berra...@redhat.com Denis V. Lunev d...@openvz.org Eric Blake ebl...@redhat.com Fam Zheng f...@redhat.com Gerd Hoffmann kra...@redhat.com John Snow js...@redhat.com Ján Tomko jto...@redhat.com Keith Busch keith.bu...@intel.com Kevin Wolf kw...@redhat.com Mark Cave-Ayland mark.cave-ayl...@ailande.co.uk Mark Cave-Ayland mark.cave-ayl...@ilande.co.uk Markus Armbruster arm...@redhat.com Paolo Bonzini pbonz...@redhat.com Peter Maydell peter.mayd...@linaro.org Richard Henderson r...@twiddle.net Richard W.M. Jones rjo...@redhat.com Roman Kagan rka...@parallels.com Stefan Hajnoczi stefa...@redhat.com jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl pass test-armhf-armhf-xl pass test-amd64-i386-xl pass test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm fail test-amd64-amd64-libvirt-xsm fail test-armhf-armhf-libvirt-xsm fail
Re: [Xen-devel] [PATCH Part2 v11 1/2] xen/PCI: Don't use deprecated function pci_scan_bus_parented()
On Tue, Apr 28, 2015 at 05:32:33PM +0800, Yijing Wang wrote:
From: Arnd Bergmann a...@arndb.de
Use pci_scan_root_bus() instead of deprecated function
pci_scan_bus_parented().
Signed-off-by: Arnd Bergmann a...@arndb.de
Signed-off-by: Yijing Wang wangyij...@huawei.com
CC: Konrad Rzeszutek Wilk konrad.w...@oracle.com
CC: xen-de...@lists.xenproject.org
Applied both to pci/enumeration for v4.2, thanks!
---
drivers/pci/xen-pcifront.c | 16 +---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/xen-pcifront.c b/drivers/pci/xen-pcifront.c
index 7cfd2db..240f388 100644
--- a/drivers/pci/xen-pcifront.c
+++ b/drivers/pci/xen-pcifront.c
@@ -446,9 +446,15 @@ static int pcifront_scan_root(struct pcifront_device
*pdev,
unsigned int domain, unsigned int bus)
{
struct pci_bus *b;
+ LIST_HEAD(resources);
struct pcifront_sd *sd = NULL;
struct pci_bus_entry *bus_entry = NULL;
int err = 0;
+ static struct resource busn_res = {
+ .start = 0,
+ .end = 255,
+ .flags = IORESOURCE_BUS,
+ };
#ifndef CONFIG_PCI_DOMAINS
if (domain != 0) {
@@ -470,17 +476,21 @@ static int pcifront_scan_root(struct pcifront_device
*pdev,
err = -ENOMEM;
goto err_out;
}
+ pci_add_resource(resources, ioport_resource);
+ pci_add_resource(resources, iomem_resource);
+ pci_add_resource(resources, busn_res);
pcifront_init_sd(sd, domain, bus, pdev);
pci_lock_rescan_remove();
- b = pci_scan_bus_parented(pdev-xdev-dev, bus,
- pcifront_bus_ops, sd);
+ b = pci_scan_root_bus(pdev-xdev-dev, bus,
+ pcifront_bus_ops, sd, resources);
if (!b) {
dev_err(pdev-xdev-dev,
Error creating PCI Frontend Bus!\n);
err = -ENOMEM;
pci_unlock_rescan_remove();
+ pci_free_resource_list(resources);
goto err_out;
}
@@ -488,7 +498,7 @@ static int pcifront_scan_root(struct pcifront_device
*pdev,
list_add(bus_entry-list, pdev-root_buses);
- /* pci_scan_bus_parented skips devices which do not have a have
+ /* pci_scan_root_bus skips devices which do not have a
* devfn==0. The pcifront_scan_bus enumerates all devfn. */
err = pcifront_scan_bus(pdev, domain, bus, b);
--
1.7.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 for Xen 4.6 1/4] xen: enabling XL to set per-VCPU parameters of a domain for RTDS scheduler
On Wed, May 27, 2015 at 5:02 AM, Chao Peng chao.p.p...@linux.intel.com wrote:
On Mon, May 25, 2015 at 07:05:52PM -0500, Chong Li wrote:
I didn't see any fields you need to copy back here ('vcpus' were copied back
in rt_vcpu_cntl() already).
+{
+struct rt_private *prv = rt_priv(ops);
+struct rt_dom * const sdom = rt_dom(d);
+struct rt_vcpu *svc;
+struct list_head *iter;
+unsigned long flags;
+int rc = 0;
+xen_domctl_sched_rtds_params_t local_sched;
+unsigned int vcpuid;
+unsigned int i;
'vcpuid' is only used in 'get' path once while 'i' is used in 'set' path
only, perhaps merge the two variables?
Yes, we can use vcpuid in both cases.
+}
+spin_unlock_irqrestore(prv-lock, flags);
+break;
'nr_vcpus' is not actually used untile now but in xc side you do pass
that in.
Right. nr_vcpus is just useful when it is 'set' case. I'll remove this
from the 'get' case.
Regards
Chao
Thanks,
Chong
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-next test] 57389: regressions - trouble: broken/fail/pass
flight 57389 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/57389/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-win7-amd64 9 windows-install fail REGR. vs. 57367 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-xl-sedf-pin 3 host-install(3) broken REGR. vs. 57289 test-armhf-armhf-xl-sedf 3 host-install(3) broken REGR. vs. 57289 test-armhf-armhf-libvirt 3 host-install(3) broken REGR. vs. 57289 test-amd64-amd64-libvirt 11 guest-start fail like 57367 test-amd64-i386-freebsd10-amd64 9 freebsd-install fail like 57367 test-amd64-i386-freebsd10-i386 9 freebsd-install fail like 57367 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail like 57367 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 57367 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-xsm 11 guest-start fail never pass test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail never pass test-amd64-i386-libvirt-xsm 11 guest-start 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-amd64-amd64-libvirt-xsm 11 guest-start fail never pass test-amd64-amd64-xl-xsm 11 guest-start fail never pass test-armhf-armhf-libvirt-xsm 11 guest-start fail never pass test-armhf-armhf-xl-xsm 11 guest-start fail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass version targeted for testing: linux8a383d3e66a1b84703bd63cf52577c09f702e64a baseline version: linuxa8b253b9f253c05e5e10b829b8d1fb24556f4b56 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 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-xsmfail test-amd64-i386-xl-qemut-debianhvm-amd64-xsm fail test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmfail test-amd64-i386-xl-qemuu-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 fail test-armhf-armhf-xl-xsm fail test-amd64-i386-xl-xsm fail 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
