This run is configured for baseline tests only.
flight 38308 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38308/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 386cdfbecbbacb600ffc8e2ffa8c7af1b3855a61
baseline version:
ovm
Cosmetics: most of the variables used in vif-bridge are already quoted.
Add quoting also to the remaining shell variables.
Signed-off-by: Olaf Hering
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/hotplug/Linux/vif-bridge | 6 +++---
1 file changed, 3 insertion
This run is configured for baseline tests only.
flight 38307 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38307/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl 21 guest-start/debian.repea
Hi,
> > Another area of extension is how to expose a framebuffer to QEMU for
> > seamless integration into a SPICE/VNC channel. For this I believe we
> > could use a new region, much like we've done to expose VGA access
> > through a vfio device file descriptor. An area within this new
> > fra
>>> On 19.11.15 at 08:44, wrote:
>
>> -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: Wednesday, November 18, 2015 6:11 PM
>> To: Wu, Feng ; Jan Beulich
>> Cc: Tian, Kevin ; wei.l...@citrix.com;
>> ian.campb...@citrix.com; stefano.stabell...@eu.citr
From: Joe Perches
Perl 5.22 emits a deprecated message when "\C" is used in a regex. Perl
5.24 will disallow it altogether.
Fix it by using [A-Z] instead of \C.
[ Upstream commit ce8155f7a3d59ce868ea16d8891edda4d865e873 ]
Signed-off-by: Olaf Hering
Cc: Ian Campbell
Cc: Ian Jackson
Cc: Jan
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Thursday, November 19, 2015 4:44 PM
> To: Wu, Feng
> Cc: Andrew Cooper ; ian.campb...@citrix.com;
> wei.l...@citrix.com; george.dun...@eu.citrix.com;
> ian.jack...@eu.citrix.com; stefano.stabell...@eu.citrix.com;
On 18/11/15 20:02, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 17, 2015 at 05:30:59PM +, Andrew Cooper wrote:
>> On 17/11/15 17:04, Jan Beulich wrote:
>> On 03.11.15 at 18:58, wrote:
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -178,6 +178,10 @@ struct act
On 18/11/15 19:14, Boris Ostrovsky wrote:
> After commit 8c058b0b9c34 ("x86/irq: Probe for PIC presence before
> allocating descs for legacy IRQs") early_irq_init() will no longer
> preallocate descriptors for legacy interrupts if PIC does not
> exist, which is the case for Xen PV guests.
>
> Ther
On Wed, 2015-11-18 at 18:32 +, Martin Osterloh wrote:
> I wanted to inquire about the current state of LibXL and in particular
> if there are any issues with using it in long-running processes.
It is currently being used by libvirtd which I think has shaken out most of
the issues with that e
flight 64723 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64723/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-multivcpu 6 xen-boot fail REGR. vs. 64320
test-amd64-amd64-xl-pv
The Microsoft Hypervisor Top Level Functional Spec. (section 3.4) defines
two bits in CPUID leaf 0x4004:EAX for the hypervisor to recommend
whether or not to issue a hypercall for local or remote TLB flush.
Whilst it's doubtful whether using a hypercall for local TLB flush would
be any more ef
In commit a85da715cf ("x86/IO-APIC: adjust setting of destinations") I
made a pretty blatant mistake: get_apic_id() can be used there only
when running APICs in physical mode. For both flat and clustered modes
the change was wrong, causing different kinds of boot problems on
affected systems. Don't
Hi,
Thanks Tianyang for the report and for the patch, and Meng for helping
getting the patch itself on the list and to me, and for commenting.
On Wed, 2015-11-18 at 22:38 -0500, Meng Xu wrote:
> [cc. Dario...]
>
> 2015-11-18 22:24 GMT-05:00 Tianyang Chen :
> > In nested virtualization, choosing
On 18/11/15 20:02, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 17, 2015 at 05:30:59PM +, Andrew Cooper wrote:
>> On 17/11/15 17:04, Jan Beulich wrote:
>> On 03.11.15 at 18:58, wrote:
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -178,6 +178,10 @@ struct act
Commit-ID: 581b7f158fe0383b492acd1ce3fb4e99d4e57808
Gitweb: http://git.kernel.org/tip/581b7f158fe0383b492acd1ce3fb4e99d4e57808
Author: Andrew Cooper
AuthorDate: Wed, 3 Jun 2015 10:31:14 +0100
Committer: Thomas Gleixner
CommitDate: Thu, 19 Nov 2015 11:07:49 +0100
x86/cpu: Fix SMAP check
>>> On 19.11.15 at 10:43, wrote:
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -2452,6 +2452,13 @@ int hvm_vcpu_initialise(struct vcpu *v)
> if ( rc != 0 )
> goto fail6;
>
> +if ( is_viridian_domain(d) )
> +{
> +rc = viridian_init(v);
I think t
On Thu, Nov 19, 2015 at 9:20 AM, Ian Campbell wrote:
> On Wed, 2015-11-18 at 18:32 +, Martin Osterloh wrote:
>
>> I wanted to inquire about the current state of LibXL and in particular
>> if there are any issues with using it in long-running processes.
>
> It is currently being used by libvirt
On 18/11/15 15:49, Wei Liu wrote:
> Hi Juergen
>
> Looks like there is something we missed after all.
>
> On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote:
>> flight 64494 xen-unstable real [real]
>> http://logs.test-lab.xenproject.org/osstest/logs/64494/
>>
>> Regressions :-
>>> On 19.11.15 at 00:17, wrote:
> The disassembly of do_IRQ now looks like a plausible function, but the
> consistently faulting address has no plausible way of generating a
> double fault. I suspect therefore that something has caused memory
> corruption in Xen .text section.
Dump of assembler
On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote:
> On 18/11/15 15:49, Wei Liu wrote:
> > Hi Juergen
> >
> > Looks like there is something we missed after all.
> >
> > On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote:
> > > flight 64494 xen-unstable real [real]
> > > ht
On 19/11/15 10:24, Jan Beulich wrote:
On 19.11.15 at 00:17, wrote:
>> The disassembly of do_IRQ now looks like a plausible function, but the
>> consistently faulting address has no plausible way of generating a
>> double fault. I suspect therefore that something has caused memory
>> corrupti
On Thu, Nov 19, 2015 at 10:30:30AM +, Ian Campbell wrote:
> On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote:
> > On 18/11/15 15:49, Wei Liu wrote:
> > > Hi Juergen
> > >
> > > Looks like there is something we missed after all.
> > >
> > > On Wed, Nov 18, 2015 at 02:31:57PM +, osste
On 19/11/15 09:20, Ian Campbell wrote:
> On Wed, 2015-11-18 at 18:32 +, Martin Osterloh wrote:
>
>> I wanted to inquire about the current state of LibXL and in particular
>> if there are any issues with using it in long-running processes.
> It is currently being used by libvirtd which I think
On Thu, 2015-11-19 at 10:50 +, Wei Liu wrote:
> On Thu, Nov 19, 2015 at 10:30:30AM +, Ian Campbell wrote:
> > On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote:
> > > On 18/11/15 15:49, Wei Liu wrote:
> > > > Hi Juergen
> > > >
> > > > Looks like there is something we missed after all
On Thu, Nov 19, 2015 at 10:55:13AM +, Ian Campbell wrote:
> On Thu, 2015-11-19 at 10:50 +, Wei Liu wrote:
> > On Thu, Nov 19, 2015 at 10:30:30AM +, Ian Campbell wrote:
> > > On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote:
> > > > On 18/11/15 15:49, Wei Liu wrote:
> > > > > Hi Ju
flight 38310 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38310/
Perfect :-)
All tests in this flight passed
baseline version:
flight 38270
jobs:
build-amd64 pass
build-armhf
On 19/11/15 11:30, Ian Campbell wrote:
> On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote:
>> On 18/11/15 15:49, Wei Liu wrote:
>>> Hi Juergen
>>>
>>> Looks like there is something we missed after all.
>>>
>>> On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote:
flight
On 19/11/2015 09:40, Gerd Hoffmann wrote:
>> > But this code should be
>> > minor to be maintained in libvirt.
> As far I know libvirt only needs to discover those devices. If they
> look like sr/iov devices in sysfs this might work without any changes to
> libvirt.
I don't think they will look
create !
title it libxl exit() on ENOMEM incompatible with gc'd languages
thanks
On Thu, 2015-11-19 at 10:55 +, Andrew Cooper wrote:
> On 19/11/15 09:20, Ian Campbell wrote:
> > On Wed, 2015-11-18 at 18:32 +, Martin Osterloh wrote:
> >
> > > I wanted to inquire about the current state of
Processing commands for x...@bugs.xenproject.org:
> create !
Created new bug #51 rooted at `<1447932195.5647.46.ca...@citrix.com>'
Title: `Re: [Xen-devel] Current LibXL Status'
> title it libxl exit() on ENOMEM incompatible with gc'd languages
Set title for #51 to `libxl exit() on ENOMEM incompati
> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Olaf Hering
> Sent: 18 November 2015 09:45
> To: George Dunlap
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] missing block script support for qemu in libxl
>
> O
On 19/11/15 11:23, Ian Campbell wrote:
> create !
> title it libxl exit() on ENOMEM incompatible with gc'd languages
> thanks
Can this be extended to "should not use exit() in general" ?
andrewcoop@andrewcoop:/local/xen.git/xen$ git grep exit\( --
:/tools/libxl/libxl*
../tools/libxl/libxl.c:1707:
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 November 2015 10:18
> To: Paul Durrant
> Cc: Andrew Cooper; Ian Campbell; Wei Liu; Ian Jackson; Stefano Stabellini;
> xen-de...@lists.xenproject.org; Keir (Xen.org)
> Subject: Re: [PATCH v1] x86/hvm/viridian: flu
On 19/11/15 11:30, Ian Campbell wrote:
> On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote:
>> On 18/11/15 15:49, Wei Liu wrote:
>>> Hi Juergen
>>>
>>> Looks like there is something we missed after all.
>>>
>>> On Wed, Nov 18, 2015 at 02:31:57PM +, osstest service owner wrote:
flight
On Thu, 2015-11-19 at 11:33 +, Andrew Cooper wrote:
>
> The majority of those are cases are not appropriate uses of exit().
> AFAIIR, the *only* valid use of exit() in a library is to clean up in a
> child process from a library-initiated fork().
... or (in this case) in the libxl-save-helpe
On Thu, 2015-11-19 at 11:48 +, Ian Campbell wrote:
> On Thu, 2015-11-19 at 11:33 +, Andrew Cooper wrote:
> >
> > The majority of those are cases are not appropriate uses of exit().
> > AFAIIR, the *only* valid use of exit() in a library is to clean up in a
> > child process from a librar
On Wed, Nov 18, 2015 at 12:21:56PM -0800, Andy Lutomirski wrote:
> Could we make this a little less subtle:
>
> ALTERNATIVE "testl %eax, %eax; lz .Lsyscall_32_done", "jmp
> .Lsyscasll_32_done", X86_FEATURE_XENPV
>
> Borislav, what do you think?
I don't mind either.
I would've said your version
On Wed, Nov 18, 2015 at 03:06:16PM -0500, Boris Ostrovsky wrote:
> The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike
> the
> earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit
> (and sysret32 in compat mode) pv ops, as suggested by Andy. (I ende
On Thu, Nov 19, 2015 at 12:47:41PM +0100, Juergen Gross wrote:
> On 19/11/15 11:30, Ian Campbell wrote:
> > On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote:
> >> On 18/11/15 15:49, Wei Liu wrote:
> >>> Hi Juergen
> >>>
> >>> Looks like there is something we missed after all.
> >>>
> >>> On W
On Thu, 2015-11-19 at 11:55 +, Ian Campbell wrote:
> On Thu, 2015-11-19 at 11:48 +, Ian Campbell wrote:
> > On Thu, 2015-11-19 at 11:33 +, Andrew Cooper wrote:
> > >
> > > The majority of those are cases are not appropriate uses of exit().
> > > AFAIIR, the *only* valid use of exit()
On 19/11/15 13:19, Wei Liu wrote:
> On Thu, Nov 19, 2015 at 12:47:41PM +0100, Juergen Gross wrote:
>> On 19/11/15 11:30, Ian Campbell wrote:
>>> On Thu, 2015-11-19 at 11:24 +0100, Juergen Gross wrote:
On 18/11/15 15:49, Wei Liu wrote:
> Hi Juergen
>
> Looks like there is something
The Microsoft Hypervisor Top Level Functional Spec. (section 3.4) defines
two bits in CPUID leaf 0x4004:EAX for the hypervisor to recommend
whether or not to issue a hypercall for local or remote TLB flush.
Whilst it's doubtful whether using a hypercall for local TLB flush would
be any more ef
On Thu, Nov 19, 2015 at 01:29:01PM +0100, Juergen Gross wrote:
[...]
> > To be precise, the problem is in mini-os, which is used by rump kernel
> > as well. :-(
> >
> >> pvgrub is making assumptions about the page table allocation scheme
> >> of the toolset starting pvgrub. It is calculating the f
libxl__exec() doesn't ever return. Inform the compiler of this, and
remove all dead code.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Ian Campbell
CC: Ian Jackson
CC: Wei Liu
---
tools/libxl/libxl.c| 1 -
tools/libxl/libxl_aoutils.c| 2 --
tools/libxl/libxl_bo
This is a follow of commit 90f2e2a307fc6a6258c39cc87b3b2bf9441c0fa7 "use
masking operation instead of test_bit for MCSF bits" where the ARM
changes were missing.
Signed-off-by: Julien Grall
---
xen/arch/arm/domain.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch
>>> On 19.11.15 at 13:33, wrote:
> +case HvFlushVirtualAddressSpace:
> +case HvFlushVirtualAddressList:
> +{
> +cpumask_var_t pcpu_mask;
cpumask_t * (or else ... [skip next comment]
> +struct vcpu *v;
> +
> +struct {
Stray blank line.
> +uint64_t
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 19 November 2015 12:55
> To: Paul Durrant
> Cc: Andrew Cooper; Ian Campbell; Wei Liu; Ian Jackson; Stefano Stabellini;
> xen-de...@lists.xenproject.org; Keir (Xen.org)
> Subject: Re: [PATCH v2] x86/hvm/viridian: flu
flight 64729 linux-3.16 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64729/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-intel 12 guest-start/redhat.repeat fail REGR.
vs. 63429
test-amd64-i3
The Microsoft Hypervisor Top Level Functional Spec. (section 3.4) defines
two bits in CPUID leaf 0x4004:EAX for the hypervisor to recommend
whether or not to issue a hypercall for local or remote TLB flush.
Whilst it's doubtful whether using a hypercall for local TLB flush would
be any more ef
On 11/19/2015 01:09 AM, Juergen Gross wrote:
On 18/11/15 17:21, Boris Ostrovsky wrote:
On 11/18/2015 11:16 AM, Wei Liu wrote:
On Wed, Nov 18, 2015 at 11:11:16AM -0500, Boris Ostrovsky wrote:
On 11/12/2015 08:43 AM, Juergen Gross wrote:
In order to prepare a p2m list outside of the initial ker
On 11/18/2015 07:01 PM, Jim Fehlig wrote:
> On 11/13/2015 06:14 AM, Joao Martins wrote:
>> Introduce initial support for domainBlockStats API call that
>> allow us to query block device statistics. openstack nova
>> uses this API call to query block statistics, alongside
>> virDomainMemoryStats a
On 11/18/2015 10:03 PM, Jim Fehlig wrote:
> On 11/13/2015 06:14 AM, Joao Martins wrote:
>> Introduce support for connectGetAllDomainStats call that
>> allow us to _all_ domain(s) statistics including network, block,
>
> allows us to get
>
>> cpus and memory. Changes are rather mechanical and mo
On 11/19/2015 04:46 AM, Jan Beulich wrote:
In commit a85da715cf ("x86/IO-APIC: adjust setting of destinations") I
made a pretty blatant mistake: get_apic_id() can be used there only
when running APICs in physical mode. For both flat and clustered modes
the change was wrong, causing different kind
On 19/11/15 09:46, Jan Beulich wrote:
> In commit a85da715cf ("x86/IO-APIC: adjust setting of destinations") I
> made a pretty blatant mistake: get_apic_id() can be used there only
> when running APICs in physical mode. For both flat and clustered modes
> the change was wrong, causing different kin
> -Original Message-
> From: xen-devel-boun...@lists.xen.org [mailto:xen-devel-
> boun...@lists.xen.org] On Behalf Of Andrew Cooper
> Sent: Monday, November 16, 2015 8:01 PM
> To: Han, Huaitong ; jbeul...@suse.com; Nakajima,
> Jun ; Dong, Eddie ; Tian,
> Kevin ; george.dun...@eu.citrix.co
c/s abdf3c5b "libxc: create p2m list outside of kernel mapping if supported"
introduces a use which Coverity objects to; an int used to mask a uint64_t.
The result needs to be signed to allow ~XC_DOM_PAGE_SIZE() to function
correctly, and long long to function properly in 32bit builds.
Signed-off
Following on from IRC conversation regarding an issue similar to [0] (which
was reported by someone else).
I've implemented the missing hypercall support in valgrind, see attached
which applies to SVN r15732. This is migrating cleanly (i.e. no
"README_MISSING_SYSCALL_OR_IOCTL" spew) for me with th
Is there any documentation about planned interfaces and API contracts for
people building around the virtio/9pfs layers? For example, while this is
still getting debugged/checked in, in order to build DomU support for these
devices, the expected API contracts/interfaces would need to be known.
On
Hi Dario,
2015-11-19 4:51 GMT-05:00 Dario Faggioli :
> Hi,
>
> Thanks Tianyang for the report and for the patch, and Meng for helping
> getting the patch itself on the list and to me, and for commenting.
>
> On Wed, 2015-11-18 at 22:38 -0500, Meng Xu wrote:
>> [cc. Dario...]
>>
>> 2015-11-18 22:24
On Thu, Nov 19, 2015 at 09:55:00AM -0500, Neil Sikka wrote:
> Is there any documentation about planned interfaces and API contracts for
> people building around the virtio/9pfs layers? For example, while this is
I assume that you're interested in getting 9pfs to work but don't care
much about how
On Mon, Nov 16, 2015 at 08:02:35PM -0700, Linda wrote:
> Hi Wei,
>
> On 11/16/2015 10:35 AM, Wei Liu wrote:
> >On Mon, Nov 16, 2015 at 10:22:41AM -0700, Linda wrote:
> ...
> >>
> >>The bug is a timing issue: During virtio's probe step, on the front end, it
> >>initialized the mount path. Since a
On Thu, 19 Nov 2015, Jike Song wrote:
> Hi Alex, thanks for the discussion.
>
> In addition to Kevin's replies, I have a high-level question: can VFIO
> be used by QEMU for both KVM and Xen?
No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
is owned by Xen.
_
On Thu, Nov 19, 2015 at 11:23 AM, Ian Campbell wrote:
> create !
> title it libxl exit() on ENOMEM incompatible with gc'd languages
> thanks
Actually, can I suggest that someone send a new thread with an
appropriate title, so that people who aren't directly following the
thread know what kinds of
>>> On 19.11.15 at 14:19, wrote:
> The Microsoft Hypervisor Top Level Functional Spec. (section 3.4) defines
> two bits in CPUID leaf 0x4004:EAX for the hypervisor to recommend
> whether or not to issue a hypercall for local or remote TLB flush.
>
> Whilst it's doubtful whether using a hyperc
George,
could I please get an ack or otherwise on
http://lists.xenproject.org/archives/html/xen-devel/2015-11/msg00764.html
http://lists.xenproject.org/archives/html/xen-devel/2015-11/msg00765.html
? While the latter has been reviewed by Andrew, it would feel wrong
to commit it without your ack, e
On 19/11/2015 16:32, Stefano Stabellini wrote:
> > In addition to Kevin's replies, I have a high-level question: can VFIO
> > be used by QEMU for both KVM and Xen?
>
> No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
> is owned by Xen.
I don't think QEMU command line compa
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> On Thu, 19 Nov 2015, Jike Song wrote:
> > Hi Alex, thanks for the discussion.
> >
> > In addition to Kevin's replies, I have a high-level question: can VFIO
> > be used by QEMU for both KVM and Xen?
>
> No. VFIO cannot be used with Xe
Today mini-os is making assumptions how the page tables it is started
with are being allocated. Especially it is using the number of page
table frames to calculate which is the first unmapped pfn.
Instead of relying on page table number assumptions just look into the
page tables to find the first
On 19/11/15 13:19, Paul Durrant wrote:
> @@ -561,10 +584,81 @@ int viridian_hypercall(struct cpu_user_regs *regs)
> switch ( input.call_code )
> {
> case HvNotifyLongSpinWait:
> +/*
> + * See Microsoft Hypervisor Top Level Spec. section 18.5.1.
> + */
>
Commit 81a76e4b12961a9f54f5021809074196dfe6dbba ("libxc: rework of
domain builder's page table handler") dropped a special case for pvh
resulting in page tables being mapped read-only. This led to a panic
of the domain in early boot.
Correct this error.
Signed-off-by: Juergen Gross
---
tools/li
On Thu, 19 Nov 2015, Paolo Bonzini wrote:
> On 19/11/2015 16:32, Stefano Stabellini wrote:
> > > In addition to Kevin's replies, I have a high-level question: can VFIO
> > > be used by QEMU for both KVM and Xen?
> >
> > No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
> > is
On Wed, 21 Oct 2015, Ian Campbell wrote:
> (Trimming CCs a bit)
>
> On Wed, 2015-10-21 at 16:22 +0100, Ian Campbell wrote:
> >
> [...]
> > Still to come would be libraries for specific out of tree purposes
> > (device model, kexec), which would be adding new library at the same
> > level as libxc
Hi Wei,
On 11/19/2015 8:03 AM, Wei Liu wrote:
On Thu, Nov 19, 2015 at 09:55:00AM -0500, Neil Sikka wrote:
Is there any documentation about planned interfaces and API contracts for
people building around the virtio/9pfs layers? For example, while this is
I assume that you're interested in getti
On Thu, Nov 19, 2015 at 05:11:08PM +0100, Juergen Gross wrote:
> Commit 81a76e4b12961a9f54f5021809074196dfe6dbba ("libxc: rework of
> domain builder's page table handler") dropped a special case for pvh
> resulting in page tables being mapped read-only. This led to a panic
> of the domain in early
On Thu, Nov 19, 2015 at 02:45:41PM +, Andrew Cooper wrote:
> c/s abdf3c5b "libxc: create p2m list outside of kernel mapping if supported"
> introduces a use which Coverity objects to; an int used to mask a uint64_t.
>
> The result needs to be signed to allow ~XC_DOM_PAGE_SIZE() to function
$
> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 19 November 2015 16:07
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Ian Jackson; Stefano Stabellini; Ian Campbell; Wei Liu; Keir (Xen.org);
> Jan
> Beulich
> Subject: Re: [PATCH v3] x86/hvm/vi
On 19/11/15 16:50, Wei Liu wrote:
> On Thu, Nov 19, 2015 at 02:45:41PM +, Andrew Cooper wrote:
>> c/s abdf3c5b "libxc: create p2m list outside of kernel mapping if supported"
>> introduces a use which Coverity objects to; an int used to mask a uint64_t.
>>
>> The result needs to be signed to al
On Thu, 2015-11-19 at 16:20 +, Stefano Stabellini wrote:
I'll just answer this bit, since it ties into your other answers, I think.
> Does the Xen<->libxc interface need to be stable for libxendevicemodel
> to have a stable ABI?
We could:
1) support multiple versions of Xen in a single libr
The Microsoft Hypervisor Top Level Functional Spec. (section 3.4) defines
two bits in CPUID leaf 0x4004:EAX for the hypervisor to recommend
whether or not to issue a hypercall for local or remote TLB flush.
Whilst it's doubtful whether using a hypercall for local TLB flush would
be any more ef
On 19/11/15 16:57, Paul Durrant wrote:
>> -Original Message-
>> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
>> Sent: 19 November 2015 16:07
>> To: Paul Durrant; xen-de...@lists.xenproject.org
>> Cc: Ian Jackson; Stefano Stabellini; Ian Campbell; Wei Liu; Keir (Xen.org);
>> Jan
>
On 09/11/15 14:48, Jan Beulich wrote:
> Since calling the function isn't cheap, try to avoid the call when we
> know up front it won't help; see the code comment for details on those
> conditions.
>
> Signed-off-by: Jan Beulich
Reviewed-by: George Dunlap
Sorry for the delay.
___
On 09/11/15 14:52, Jan Beulich wrote:
> As noted regarding the mixture of checks in p2m_pt_set_entry(),
> introduce an new P2M type group allowing to be used everywhere we
> just care about accepting operations with either a valid MFN or a type
> permitting to be used without (valid) MFN.
>
> Note
A sample Gentoo compliation of Xen contains
lea-0x1058(%rsp),%rsp
orq$0x0,(%rsp)
lea0x1020(%rsp),%rsp
Whatever the reason for silly code like this, it fools the current stack
overflow detection logic in the #DF handler (which triggers reliably on the
'orq' instruction).
U
On 19/11/15 17:34, Andrew Cooper wrote:
> A sample Gentoo compliation of Xen contains
>
> lea-0x1058(%rsp),%rsp
> orq$0x0,(%rsp)
> lea0x1020(%rsp),%rsp
>
> Whatever the reason for silly code like this, it fools the current stack
> overflow detection logic in the #DF handler
On 11/19/2015 11:45 AM, Wei Liu wrote:
On Thu, Nov 19, 2015 at 05:11:08PM +0100, Juergen Gross wrote:
Commit 81a76e4b12961a9f54f5021809074196dfe6dbba ("libxc: rework of
domain builder's page table handler") dropped a special case for pvh
resulting in page tables being mapped read-only. This led
flight 64733 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64733/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3) broken REGR. vs. 59254
build-amd64-rumpuserx
flight 64861 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64861/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass
test-armhf-armhf-xl 12
Am 19.11.15 um 11:38 schrieb Andrew Cooper:
On 19/11/15 10:24, Jan Beulich wrote:
On 19.11.15 at 00:17, wrote:
The disassembly of do_IRQ now looks like a plausible function, but the
consistently faulting address has no plausible way of generating a
double fault. I suspect therefore that somet
Am 19.11.15 um 02:06 schrieb Andrew Cooper:
Thanks! That is what I was looking for.
Sadly, it is less useful than I was hoping. The guest is not appearing
to do anything interesting which causes the bad state; it is almost a
full second between the previous action of note, and the crash.
Can y
Hi Kevin,
On Thu, 2015-11-19 at 04:06 +, Tian, Kevin wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Thursday, November 19, 2015 2:12 AM
> >
> > [cc +qemu-devel, +paolo, +gerd]
> >
> > On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
> > > Hi all,
> > >
> >
branch xen-unstable
xenbranch xen-unstable
job test-amd64-amd64-xl-pvh-amd
testid xen-boot
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike the
earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit
(and sysret32 in compat mode) pv ops, as suggested by Andy.
As result of this patch irq_enable_sysexit and usergs_sysret32 pv ops are not
us
As result of commit "x86/xen: Avoid fast syscall path for Xen PV guests"
usergs_sysret32 pv op is not called by Xen PV guests anymore and
since they were the only ones who used it we can safely remove it.
Signed-off-by: Boris Ostrovsky
---
arch/x86/entry/entry_64_compat.S | 10 ++
a
After 32-bit syscall rewrite, and specifically after commit 5f310f739b4c
("x86/entry/32: Re-implement SYSENTER using the new C path"), the stack
frame that is passed to xen_sysexit is no longer a "standard" one (i.e.
it's not pt_regs).
Since we end up calling xen_iret from xen_sysexit we don't nee
As result of commit "x86/xen: Avoid fast syscall path for Xen PV guests"
irq_enable_sysexit pv op is not called by Xen PV guests anymore and since
they were the only ones who used it we can safely remove it.
Signed-off-by: Boris Ostrovsky
---
arch/x86/entry/entry_32.S | 8 ++--
On Thu, Nov 19, 2015 at 1:55 PM, Boris Ostrovsky
wrote:
> The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike
> the
> earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit
> (and sysret32 in compat mode) pv ops, as suggested by Andy.
>
> As result o
flight 64750 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/64750/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 64035
test-amd64-amd64-i38
On Thu, Nov 19, 2015 at 04:55:44PM -0500, Boris Ostrovsky wrote:
> The first patch fixes Xen PV regression introduced by 32-bit rewrite. Unlike
> the
> earlier version it uses ALTERNATIVE instruction and avoids using xen_sysexit
> (and sysret32 in compat mode) pv ops, as suggested by Andy.
>
> As
On Fri, Oct 9, 2015 at 12:34 AM, Jan Beulich wrote:
On 08.10.15 at 21:36, wrote:
>> Signed-off-by: Mark Pryor
>
> Without any description I cannot see what is being fixed here, or why
> there are _different_ comment changes on the inclusion of the same
> comment. Since I assume that whateve
1 - 100 of 125 matches
Mail list logo
