On 10 February 2015 at 15:26, Ian Campbell wrote:
> On Tue, 2015-02-10 at 07:00 +, Stefano Stabellini wrote:
>> On Fri, 30 Jan 2015, Ard Biesheuvel wrote:
>> > This patch registers hvc0 as the preferred console if no console
>> > has been specified explicitly on the kernel command line.
>> >
>
Hi Stefano,
On 10/02/2015 15:00, Stefano Stabellini wrote:
On Fri, 30 Jan 2015, Ard Biesheuvel wrote:
This patch registers hvc0 as the preferred console if no console
has been specified explicitly on the kernel command line.
The purpose is to allow platform agnostic kernels and boot images
(su
On Tue, 2015-02-10 at 07:00 +, Stefano Stabellini wrote:
> On Fri, 30 Jan 2015, Ard Biesheuvel wrote:
> > This patch registers hvc0 as the preferred console if no console
> > has been specified explicitly on the kernel command line.
> >
> > The purpose is to allow platform agnostic kernels and
flight 34341 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34341/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-libvirt 9 guest-start fail like 34137
test-amd64-i386-pair1
On Fri, 30 Jan 2015, Ard Biesheuvel wrote:
> This patch registers hvc0 as the preferred console if no console
> has been specified explicitly on the kernel command line.
>
> The purpose is to allow platform agnostic kernels and boot images
> (such as distro installers) to boot in a Xen/ARM domU wi
Hi Ian,
On 10/02/2015 12:45, Ian Campbell wrote:
Previously 32-bit userspace on 32-bit kernel and 64-bit userspace on 64-bit
kernel could access these registers irrespective of whether the kernel had
configured them to be allowed to. To fix this:
- Userspace access to CNTP_CTL_EL0 and CNTP_TV
On 01/19/2015 09:28 AM, Chunyan Liu wrote:
Add pvusb commands.
To attach a usb device to guest through pvusb, one could follow
following example:
#xl usb-ctrl-attach test_vm version=1 num_ports=8
#xl usb-list test_vm
will show the usb controllers and port usage under the domain.
#xl u
On Tue, 2015-02-10 at 13:44 +0800, Julien Grall wrote:
> > /* The cond for this instruction works out as the top 4 bits. */
> > -cond = ( it >> 4 );
> > +cond = ( it >> 4 );
>
> I haven't spot it in the previous review. This seems to be only a coding
> change. Could you
Hi Ian,
On 10/02/2015 12:45, Ian Campbell wrote:
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
---
xen/arch/arm/traps.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c5f65db..be65862 100644
--- a/xen/
CP14 dbg and general CP register access are both handled with
unconditional injection of #undef from their respective handlers, so
allow these even from 32-bit userspace on a 64-bit kernel.
SMC32 and HVC32 should only come from a guest in AArch32 mode and
SMC64 and HVC64 should only come from a gu
p15,0,c9,c13,1 is PMXEVTYPER not PMXEVCNTR.
p15,0,c9,c13,2 is PMXEVCNTR not PMXEVCNR.
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
---
xen/arch/arm/traps.c |2 +-
xen/include/asm-arm/cpregs.h |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/ar
Accesses to these from 32-bit userspace would cause a hypervisor exception
(host crash) when running a 64-bit kernel, which is worked around by the fix to
XSA-102. On 32-bit kernels they would be implemented as RAZ/WI which is
incorrect but harmless.
Update as follows:
- DBGDSCRINT should be R/O.
Previously userspace access to PM* would have been incorrectly (but benignly)
implemented as RAZ/WI when running on a 32-bit kernel and would cause a
hypervisor exception (host crash) when running a 64-bit kernel (this was
already solved via the fix to XSA-102).
CLIDR, CCSIDR, DCCISW, ACTLR, PMINT
Previously 32-bit userspace on 32-bit kernel and 64-bit userspace on 64-bit
kernel could access these registers irrespective of whether the kernel had
configured them to be allowed to. To fix this:
- Userspace access to CNTP_CTL_EL0 and CNTP_TVAL_EL0 should be gated on
CNTKCTL_EL1.EL0PTEN.
-
Signed-off-by: Ian Campbell
Reviewed-by: Julien Grall
---
xen/arch/arm/traps.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index c5f65db..be65862 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1487,7
This embodies the logic on arm64 that userspace can be either 32-bit
or 64-bit. It will be used in other places shortly.
Note that the logic differs slightly because the original (in
inject_abt64_exception) knew that the kernel was 64-bit and could
therefore assume that any 32-bit mode was userspa
Previously we implemented all registers as RAZ/WI even if they
shouldn't be accessible to userspace.
Accesses to the *_EL1 registers from EL0 are trapped to EL1 by the
hardware, so add a BUG_ON. Likewise accesses from 32-bit EL1 cannot
happen.
PMUSERENR_EL0 and MDCCSR_EL0 are R/O to EL0.
Other P
This removes the unconditional #undef injected in response to such traps which
was added by the fixes to CVE-2014-5147 / XSA-102 in c0020e099702 "xen: arm:
Handle traps from 32-bit userspace on 64-bit kernel as undef", we now handle
such traps correctly.
Signed-off-by: Ian Campbell
---
xen/arch/
On 02/09/2015 08:52 PM, Luis R. Rodriguez wrote:
On Mon, Feb 09, 2015 at 07:17:23AM +0100, Juergen Gross wrote:
On 02/07/2015 12:44 AM, Luis R. Rodriguez wrote:
After some feedback for the first draft I'd suggest the following:
Option Selects Depends
--
XSA-102/CVE-2014-5147[0] concerned a crash when trapping from 32-bit
userspace in a 64-bit guest. Part of that security patch was c0020e09970
"xen: arm: Handle traps from 32-bit userspace on 64-bit kernel as undef
fix" which turned the exploitable crash into a #undef to the guest (so
as to kill the
Hi Lars,
I would like to take up "Enabling the 9P File System transport as a
paravirt device" in GSOC 2015.
http://wiki.xenproject.org/wiki/GSoC_2015#Enabling_the_9P_File_System_transport_as_a_paravirt_device
I was unable to find a mentor for this project in the last OPW cycle
due to unavailib
On 10/02/2015 11:40, Ian Campbell wrote:
On Wed, 2014-09-10 at 10:48 +0100, Ian Campbell wrote:
On Tue, 2014-09-09 at 16:45 -0700, Julien Grall wrote:
Hi Ian,
On 09/09/14 09:23, Ian Campbell wrote:
Accesses to these from 32-bit userspace would cause a hypervisor exception
(host crash) when
The main comment I will make on this patch is to rename "redistributor
interface" into "redistributor region".
The Device Tree binding actually defines the entry as 'GIC Redistributor
region' or 'GIC Redistributors':
http://lxr.free-electrons.com/diff/Documentation/devicetree/bindings/arm/gic-v3.t
Hi Ard,
I did an implementation of BaseSynchronizationLib for ARM(32) a couple years
ago. I am not sure why I have never pushed this patch upstream.
Anyway, feel free to use it and push it upstream after reviewing it and adding
support for AArch64.
Contributed-under: TianoCore Contribution A
On Wed, 2014-09-10 at 10:48 +0100, Ian Campbell wrote:
> On Tue, 2014-09-09 at 16:45 -0700, Julien Grall wrote:
> > Hi Ian,
> >
> > On 09/09/14 09:23, Ian Campbell wrote:
> > > Accesses to these from 32-bit userspace would cause a hypervisor exception
> > > (host crash) when running a 64-bit kerne
Ian Campbell wrote:
> Jim,
>
> Thought you might like to know that we are now testing actually starting
> a guest with libvirt in osstest and this is the first pass.
>
Nice! I'll keep an eye out for any regressions.
> Currently we don't test migration (which is why that appears to have
> fail
Stefano,
do you have any comments on the viability of the general approach here
before I go off and start addressing the review comments?
Cheers,
Ian.
On Mon, 2015-01-26 at 15:55 +, Ian Campbell wrote:
> ... instead of artificially masking the timer interrupt in the timer
> state and relying
On 10/02/2015 09:36, Julien Grall wrote:
Hi Stefano,
On 06/02/2015 22:06, Stefano Stabellini wrote:
On Fri, 30 Jan 2015, Julien Grall wrote:
When SMMU doesn't support coherent table walk, Xen may need to clean
updated PT (see commit 4c5f4cb "xen/arm: p2m: Clean cache PT when the
IOMMU doesn'
Hi Stefano,
On 06/02/2015 22:06, Stefano Stabellini wrote:
On Fri, 30 Jan 2015, Julien Grall wrote:
When SMMU doesn't support coherent table walk, Xen may need to clean
updated PT (see commit 4c5f4cb "xen/arm: p2m: Clean cache PT when the
IOMMU doesn't support coherent walk").
If one SMMU of t
On 09/02/2015 20:02, Oleksandr Tyshchenko wrote:
On Mon, Feb 9, 2015 at 10:31 AM, Julien Grall wrote:
On 07/02/2015 01:15, Oleksandr Tyshchenko wrote:
Hi Julien
Hi Oleksandr,
On Thu, Feb 5, 2015 at 6:36 PM, Oleksandr Tyshchenko
The next problem is ballooning. When the guest balloon out
Hi,
While testing commit 2563bca1, I found that libxl_get_free_memory returns 0
until there is more free memory than required for freemem-slack. This means
that during the domain creation process, freed memory is first set aside for
freemem-slack, then marked as truly free for consumption.
On
Dear Wilk:
> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Monday, February 9, 2015 11:36 PM
> To: Wang, Xiaoming
> Cc: r...@linux-mips.org; boris.ostrov...@oracle.com;
> david.vra...@citrix.com; linux-m...@linux-mips.org; linux-
> ker...@vger.ker
On Mon, Feb 9, 2015 at 4:02 AM, Peter Zijlstra wrote:
> On Mon, Feb 09, 2015 at 03:04:22PM +0530, Raghavendra K T wrote:
>> So we have 3 choices,
>> 1. xadd
>> 2. continue with current approach.
>> 3. a read before unlock and also after that.
>
> For the truly paranoid we have probe_kernel_address
On Mon, 2015-02-09 at 18:07 +, Ian Jackson wrote:
> Add a column
Did you mean row? (looks to be in the HTML, as opposed to the email)
> listing the host(s) used. We first find the relevant set
> of host runvars (with a SELECT DISTINCT) and then look up each var for
> each actual flight.
>
On 02/09/2015 01:53 PM, Tamas K Lengyel wrote:
The XSM label vm_event_op has been used to control the three memops
controlling mem_access, mem_paging and mem_sharing. While these systems
rely on vm_event, these are not vm_event operations themselves. Thus,
in this patch we introduce three separat
On 02/09/2015 01:53 PM, Tamas K Lengyel wrote:
In this patch we mechanically rename mem_event to vm_event. This patch
introduces no logic changes to the code. Using the name vm_event better
describes the intended use of this subsystem, which is not limited to memory
events. It can be used for off
On 02/09/2015 01:53 PM, Tamas K Lengyel wrote:
In preparation for allowing for introspecting ARM and PV domains the old
control interface via the hvm_op hypercall is retired. A new control mechanism
is introduced via the domctl hypercall: monitor_op.
This patch aims to establish a base API on wh
On 02/09/2015 01:53 PM, Tamas K Lengyel wrote:
The vm_event subsystem has been artifically tied to the presence of mem_access.
While mem_access does depend on vm_event, vm_event is an entirely independent
subsystem that can be used for arbitrary function-offloading to helper apps in
domains. This
Various pieces of code test whether node value is NUMA_NO_NODE even
though pxm_to_node() may return (int)-1 for an invalid node.
Make pxm_to_node() and setup_node() return u8 and have them return
NUMA_NO_NODE when necessary.
Adjust code that tests for (node == -1).
Signed-off-by: Boris Ostrovsky
If ACPI provides PXM data for IO devices then dom0 will pass it to
hypervisor during PHYSDEVOP_pci_device_add call. This information,
however, is currently ignored.
We will store this information (in the form of nodeID) in pci_dev
structure so that we can provide it, for example, to the toolstack
Currently both of these sysctls make a copy to userspace for each index of
various query arrays. We should try to copy whole arrays instead.
This requires some changes in sysctl's public data structure, thus bump
interface version.
Report topology for all present (not just online) cpus.
Rename x
Signed-off-by: Boris Ostrovsky
---
tools/libxc/include/xenctrl.h |4 +-
tools/libxc/xc_misc.c | 23 +++-
tools/libxl/libxl.c | 32 +--
tools/misc/xenpm.c| 51 -
tools/python
Changes in v3:
* Added patch #1 to more consistently define nodes as a u8 and properly
use NUMA_NO_NODE.
* Make changes to xen_sysctl_numainfo, similar to those made to
xen_sysctl_topologyinfo. (Q: I kept both sets of changes in the same
patch #3 to avoid bumping interface version twice. Perh
Signed-off-by: Boris Ostrovsky
---
tools/libxc/include/xenctrl.h |4 ++-
tools/libxc/xc_misc.c | 29 --
tools/libxl/libxl.c | 36 -
tools/python/xen/lowlevel/xc/xc.c | 39 +++---
.. and use this new interface to display it along with CPU topology
and NUMA information when 'xl info -n' command is issued
The output will look like
...
cpu_topology :
cpu:coresocket node
0: 000
...
device topology:
device node
Signed-off-by: Boris Ostrovsky
---
xen/common/sysctl.c | 73 +++
xen/include/public/sysctl.h | 29 +
2 files changed, 102 insertions(+), 0 deletions(-)
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 30c5806..ea6557
On Mon, Feb 09, 2015 at 07:17:23AM +0100, Juergen Gross wrote:
> On 02/07/2015 12:44 AM, Luis R. Rodriguez wrote:
>> After some feedback for the first draft I'd suggest the following:
>>
>> Option Selects Depends
>> --
In this patch we mechanically rename mem_event to vm_event. This patch
introduces no logic changes to the code. Using the name vm_event better
describes the intended use of this subsystem, which is not limited to memory
events. It can be used for off-loading the decision making logic into helper
ap
The XSM label vm_event_op has been used to control the three memops
controlling mem_access, mem_paging and mem_sharing. While these systems
rely on vm_event, these are not vm_event operations themselves. Thus,
in this patch we introduce three separate labels for each of these memops.
Signed-off-by
Thus far mem_access and mem_sharing memops had been able to signal
to Xen to start pulling responses off the corresponding rings. In this patch
we retire these memops and add them to the option to the vm_event_op domctl.
The vm_event_op domctl suboptions are the same for each ring thus we
consolid
In preparation for allowing for introspecting ARM and PV domains the old
control interface via the hvm_op hypercall is retired. A new control mechanism
is introduced via the domctl hypercall: monitor_op.
This patch aims to establish a base API on which future applications can build
on.
Suggested-
The vm_event subsystem has been artifically tied to the presence of mem_access.
While mem_access does depend on vm_event, vm_event is an entirely independent
subsystem that can be used for arbitrary function-offloading to helper apps in
domains. This patch removes the dependency that mem_access nee
This patch series aims to clean up the mem_event subsystem within Xen. The
original use-case for this system was to allow external helper applications
running in privileged domains to control various memory operations performed
by Xen. Amongs these were paging, sharing and access control. The subsy
The memop handler function for paging/sharing responsible for calling XSM
doesn't really have anything to do with vm_event, thus in this patch we
relocate it into mem_paging_memop and mem_sharing_memop. This has already
been the approach in mem_access_memop, so in this patch we just make it
consist
The spin-lock implementation in the xen-access test program is implemented
in a fashion that is actually incomplete. The x86 assembly that guarantees that
the lock is held by only one thread lacks the "lock;" instruction.
However, the spin-lock is not actually necessary in xen-access as it is not
The only use-case of the mem_event_op structure had been in mem_paging,
thus renaming the structure mem_paging_op and relocating its associated
functions clarifies its actual usage.
Signed-off-by: Tamas K Lengyel
Acked-by: Tim Deegan
Acked-by: Ian Campbell
---
v4: Style fixes
v3: Style fixes
--
To avoid growing hvm.c these functions can be stored separately. Minor style
changes are applied to the logic in the file.
Signed-off-by: Tamas K Lengyel
Acked-by: Kevin Tian
---
v4: Style fixes
v3: Style fixes and removing unused fields from msr events.
---
xen/arch/x86/hvm/Makefile |
The flag is only used for debugging purposes, thus it should be only checked
for in debug builds of Xen.
Signed-off-by: Tamas K Lengyel
---
xen/arch/x86/mm/mem_sharing.c | 2 ++
xen/arch/x86/mm/p2m.c | 2 ++
xen/common/mem_access.c | 2 ++
3 files changed, 6 insertions(+)
diff --g
The name of one of the mem_event rings still implies it is used only
for memory accesses, which is no longer the case. It is also used to
deliver various HVM events, thus the name "monitor" is more appropriate
in this setting.
The mem_event subop definitions are also shortened to be more meaningfu
From: Razvan Cojocaru
The public mem_event structures used to communicate with helper applications via
shared rings have been used in different settings. However, the variable names
within this structure have not reflected this fact, resulting in the reuse of
variables to mean different things un
The current sanity check when enabling mem_event is only applicable
to mem_access.
Signed-off-by: Tamas K Lengyel
---
xen/common/mem_event.c | 4
xen/include/asm-x86/p2m.h | 8 +---
xen/include/public/domctl.h | 1 -
3 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/
>>> --- a/xen/include/public/hvm/params.h
>>> +++ b/xen/include/public/hvm/params.h
>>> @@ -162,21 +162,6 @@
>>> */
>>> #define HVM_PARAM_ACPI_IOPORTS_LOCATION 19
>>>
>>> -/* Enable blocking memory events, async or sync (pause vcpu until response)
>>> - * onchangeonly indicates messages only on
Ian Campbell writes ("Re: [OSSTEST PATCH 05/10] sg-run-job: testid generation:
Move spawn-step-begin"):
> TBH any Ack I gave here (and to the following TCL patches) would be
> pretty cursory. I agree with what you seem to be trying to do even if
> I'm not really in a position to confirm it's what
Ian Campbell writes ("Re: [OSSTEST PATCH 04/10] tcl/osstestlib.tcl: Provide
lshift"):
> On Fri, 2015-02-06 at 19:17 +, Ian Jackson wrote:
> > +proc lshift {listvar} {
> > +upvar 1 $listvar list
> > +set head [lindex $list 0]
> > +set list [lrange $list 1 end]
>
> You calculate but
Ian Campbell writes ("Re: [OSSTEST PATCH 01/10] TestSupport: Provide
target_editfile_cancel"):
> On Fri, 2015-02-06 at 19:17 +, Ian Jackson wrote:
> > This allows a caller of target_editfile to cancel the edit from within
> > their supplied code block.
> >
> > Signed-off-by: Ian Jackson
>
>
Add a column listing the host(s) used. We first find the relevant set
of host runvars (with a SELECT DISTINCT) and then look up each var for
each actual flight.
We do the pattern-matching on runvar names in perl to avoid giving the
postgresql optimiser a chance to turn this query into a full tabl
We are going to want to reuse this, so separate out the computation of
$cond and @params.
Signed-off-by: Ian Jackson
---
sg-report-job-history | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/sg-report-job-history b/sg-report-job-history
index ee021b6..479e34
Hi all,
On Fri, Jan 30, 2015 at 06:54:04PM +0100, Daniel Kiper wrote:
> Hi,
>
> I am sending, long awaited, first version of multiboot2 protocol
> support for legacy BIOS and EFI platforms.
>
> The final goal is xen.efi binary file which could be loaded by EFI
> loader, multiboot (v1) protocol (on
Hi all,
On Fri, Jan 30, 2015 at 06:59:23PM +0100, Daniel Kiper wrote:
> Hi,
>
> This patch series enable EFI boot services usage
> in loaded images by multiboot2 protocol.
Guys, do you have any comments on this patch series?
Should I fix something? Could you apply them to GRUB2 tree?
Daniel
PS
Wei Liu writes ("Re: [PATCH 4/4] libxl: More probably detect reentry of
destroyed ctx"):
> On Mon, Feb 09, 2015 at 03:51:12PM +, Ian Jackson wrote:
> > In libxl_ctx_free:
> >
> > 1. Move the GC_INIT earlier, so that we can:
>
> Acked-by: Wei Liu
Thanks.
> > +assert(!ctx->osevent_in_ho
On Mon, Feb 09, 2015 at 02:13:30AM +, Wang, Xiaoming wrote:
> Dear Wilk:
>
> > -Original Message-
> > From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> > Sent: Saturday, February 7, 2015 2:12 AM
> > To: Wang, Xiaoming
> > Cc: r...@linux-mips.org; boris.ostrov...@oracle.com;
Monday, February 9, 2015, 5:36:28 PM, you wrote:
On 09.02.15 at 16:18, wrote:
>> On 09/02/15 15:03, Sander Eikelenboom wrote:
>>> Hi Jan / David / Konrad,
>>>
>>> I was just testing a 3.19 kernel on my intel machine and again
>>> ran into the sporadically appearing "irq nobody cared" on th
Ccing Davidlohr, (sorry that I got confused with similar address in cc
list).
On 02/09/2015 08:44 PM, Oleg Nesterov wrote:
On 02/09, Raghavendra K T wrote:
+static inline void __ticket_check_and_clear_slowpath(arch_spinlock_t *lock)
+{
+ arch_spinlock_t old, new;
+ __ticket_t diff;
>>> On 09.02.15 at 16:18, wrote:
> On 09/02/15 15:03, Sander Eikelenboom wrote:
>> Hi Jan / David / Konrad,
>>
>> I was just testing a 3.19 kernel on my intel machine and again
>> ran into the sporadically appearing "irq nobody cared" on the dom0 kernel.
>> This occurs now for quite some kernel v
On Mon, Feb 09, 2015 at 03:51:12PM +, Ian Jackson wrote:
> In libxl_ctx_free:
>
> 1. Move the GC_INIT earlier, so that we can:
>
> 2. Take the lock around most of the work. This is technically
>unnecessary since calling any other libxl entrypoint on a ctx being
>passed to libxl_ctx_f
On Mon, Feb 09, 2015 at 03:51:10PM +, Ian Jackson wrote:
> Break out the test in libxl__ao_complete_check_progress_reports, into
> ao_work_outstanding, which reports false if either (i) the ao is still
> ongoing or (ii) there is a progress report (perhaps on a different
> thread's callback queu
Anthony PERARD wrote:
> On Mon, Feb 02, 2015 at 05:00:34PM -0700, Jim Fehlig wrote:
>
>> This small series fixes some assertions we occasionally see in the
>> libxl driver when running libvirt-TCK. The assertions were due to
>> races between destroying per-domain libxl_ctx and receiving fd and
On Mon, Feb 09, 2015 at 03:51:11PM +, Ian Jackson wrote:
> libxl__ao_inprogress needs to check (like
> libxl__ao_complete_check_progress_reports) that there are no
> oustanding progress callbacks.
>
> Otherwise it might happen that we would destroy the ao while another
> thread has an outstand
On Mon, Feb 09, 2015 at 03:51:09PM +, Ian Jackson wrote:
> Check that the ao is still live when we are about to running some of
> its callbacks.
>
> This reveals an existing bug in libxl which is exercised by libvirt,
> converting
>libvirtd: libxl_event.c:1792: libxl__ao_complete_check_pro
flight 34346 rumpuserxen real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34346/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-rumpuserxen6 xen-build fail REGR. vs. 33866
build-amd64-rumpuserx
libxl__ao_inprogress needs to check (like
libxl__ao_complete_check_progress_reports) that there are no
oustanding progress callbacks.
Otherwise it might happen that we would destroy the ao while another
thread has an outstanding callback its egc report queue. The other
thread would then, in its e
Break out the test in libxl__ao_complete_check_progress_reports, into
ao_work_outstanding, which reports false if either (i) the ao is still
ongoing or (ii) there is a progress report (perhaps on a different
thread's callback queue) which has yet to be reported to the
application.
No functional ch
Check that the ao is still live when we are about to running some of
its callbacks.
This reveals an existing bug in libxl which is exercised by libvirt,
converting
libvirtd: libxl_event.c:1792: libxl__ao_complete_check_progress_reports:
Assertion `ao->in_initiator' failed.
into
libvirtd: li
In libxl_ctx_free:
1. Move the GC_INIT earlier, so that we can:
2. Take the lock around most of the work. This is technically
unnecessary since calling any other libxl entrypoint on a ctx being
passed to libxl_ctx_free risks undefined behaviour. But, taking
the lock allows us to much m
Hi Stefano,
On 06/02/2015 21:20, Stefano Stabellini wrote:
On Fri, 30 Jan 2015, Julien Grall wrote:
-static int force_stage;
-module_param_named(force_stage, force_stage, int, S_IRUGO | S_IWUSR);
-MODULE_PARM_DESC(force_stage,
- "Force SMMU mappings to be installed at a particular stage o
Monday, February 9, 2015, 4:18:15 PM, you wrote:
> On 09/02/15 15:03, Sander Eikelenboom wrote:
>> Hi Jan / David / Konrad,
>>
>> I was just testing a 3.19 kernel on my intel machine and again
>> ran into the sporadically appearing "irq nobody cared" on the dom0 kernel.
>> This occurs now for qu
On 09/02/15 15:03, Sander Eikelenboom wrote:
> Hi Jan / David / Konrad,
>
> I was just testing a 3.19 kernel on my intel machine and again
> ran into the sporadically appearing "irq nobody cared" on the dom0 kernel.
> This occurs now for quite some kernel versions (running xen-unstable now,
> but
On 02/09, Raghavendra K T wrote:
>
> +static inline void __ticket_check_and_clear_slowpath(arch_spinlock_t *lock)
> +{
> + arch_spinlock_t old, new;
> + __ticket_t diff;
> +
> + old.tickets = READ_ONCE(lock->tickets);
> + diff = (old.tickets.tail & ~TICKET_SLOWPATH_FLAG) - old.ticke
flight 34319 qemu-upstream-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/34319/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-freebsd10-i386 11 guest-localmigrate fail REGR. vs. 33488
test-amd64
at are now xen-4.5).
[ 1905.880200] irq 18: nobody cared (try booting with the "irqpoll" option)
[ 1905.914838] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
3.19.0-creanuc-20150209-doflr+ #1
[ 1905.935473] Hardware name: /D53427RKE, BIOS
RKPPT10H.86A.0017.2013.0425.1251 04/2
Hi Ian,
On 09/02/2015 21:08, Ian Campbell wrote:
On Mon, 2015-02-09 at 19:16 +0800, Julien Grall wrote:
The last problem but not the least is, depending on which backend you
are running in the 1:1 domain (such blkback), grant won't be mapped 1:1
to the guest, so you will have to use swiotlb in
On Mon, Feb 09, 2015 at 01:23:26PM +, Wei Liu wrote:
> Er... The title should be
>
> "libxl, xl: don't init/dispose when not unnecessary"
> --
Grrr... What was I thinking. The initial title was correct.
Sorry for the noise and spam.
__
On Mon, Feb 9, 2015 at 4:11 AM, Ian Campbell wrote:
> On Tue, 2015-02-03 at 23:06 -0500, Eric Shelton wrote:
>> This enum gives the ability to select between a MiniOS-based QEMU
>> traditional stub domain and a Linux-based QEMU upstream stub domain. To
>> use the Linux-based stubdomain, the follo
On 09/02/15 13:26, Jan Beulich wrote:
On 09.02.15 at 14:13, wrote:
>> On 09/02/15 12:56, Jan Beulich wrote:
>>> So wouldn't it be possible to get rid of nmi_crash() and have
>>> nmi() call *nmi_handler instead of don_nmi (and nmi_handler
>>> would really just become an alias of exception_tabl
On Fri, 2015-02-06 at 19:17 +, Ian Jackson wrote:
> Add a new step which uses repeat-ts to run
> ts-rumpuserxen-demo-xenstorels many times.
>
> We have to run ts-guest-destroy-hard first each time, to destroy the
> guest which might exist at each previous step. To help with ad-hoc
> debugging
On Fri, 2015-02-06 at 19:17 +, Ian Jackson wrote:
> If the guest config is already set up to preserve, cancel the edit.
> We are going to repeat this test, and this avoids creating many
> identical copies of the same file in the log output.
>
> Signed-off-by: Ian Jackson
Acked-by: Ian Campbe
On Mon, Feb 9, 2015 at 7:08 AM, Anthony PERARD
wrote:
> On Mon, Feb 09, 2015 at 09:07:13AM +, Ian Campbell wrote:
>> On Fri, 2015-02-06 at 17:23 +, Stefano Stabellini wrote:
>> > >
>> > > One of the main issues outstanding from when Anthony originally posted
>> > > his patches is how we wa
On Fri, 2015-02-06 at 19:17 +, Ian Jackson wrote:
> Run spawn-step-begin until after the loop over $args, and after the
> computation of the basic deftestid.
>
> No functional change: nothing in that loop looks at stepno.
>
> Signed-off-by: Ian Jackson
TBH any Ack I gave here (and to the fo
On Fri, 2015-02-06 at 19:17 +, Ian Jackson wrote:
> No callers yet.
>
> Signed-off-by: Ian Jackson
> ---
> tcl/osstestlib.tcl |7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/tcl/osstestlib.tcl b/tcl/osstestlib.tcl
> index 1531c87..a0413c4 100644
> --- a/tcl/osstestlib.tcl
On 02/09/2015 02:33 PM, Stefan Bader wrote:
On 09.02.2015 14:07, Stefan Bader wrote:
On 05.02.2015 20:36, Konrad Rzeszutek Wilk wrote:
On Thu, Feb 05, 2015 at 03:33:02PM +0100, Stefan Bader wrote:
While experimenting/testing various kernel versions I discovered that trying to
boot a Haswell ba
1 - 100 of 164 matches
Mail list logo
