flight 78509 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78509/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail REGR. vs.
78421
Regressions whic
>>> On 19.01.16 at 20:24, wrote:
> On 1/19/16 2:48 AM, Jan Beulich wrote:
> On 18.01.16 at 18:21, wrote:
>>> On 1/18/16 11:03 AM, Jan Beulich wrote:
>>> On 18.01.16 at 17:53, wrote:
> To help people avoid having to figure out what versions of make and
> binutils need to be suppor
>>> On 20.01.16 at 08:49, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, January 18, 2016 11:14 PM
>> >>> On 03.12.15 at 09:35, wrote:
>> > --- a/xen/arch/x86/hvm/vmx/vmx.c
>> > +++ b/xen/arch/x86/hvm/vmx/vmx.c
>> > @@ -83,7 +83,131 @@ static int vmx_msr_write_intercept(u
On 20/01/2016 06:33, Shannon Zhao wrote:
>
> On 2016/1/18 20:52, Andrew Cooper wrote:
>> On 18/01/16 12:46, Stefano Stabellini wrote:
On Mon, 18 Jan 2016, Andrew Cooper wrote:
>> On 18/01/16 12:38, Stefano Stabellini wrote:
On Fri, 15 Jan 2016, Shannon Zhao wrote:
>> From:
>>> On 20.01.16 at 06:31, wrote:
> The primary reason of current solution is to reuse existing NVDIMM
> driver in Linux kernel.
Re-using code in the Dom0 kernel has benefits and drawbacks, and
in any event needs to depend on proper layering to remain in place.
A benefit is less code duplication b
On 2016/1/20 16:39, Andrew Cooper wrote:
> On 20/01/2016 06:33, Shannon Zhao wrote:
>> >
>> > On 2016/1/18 20:52, Andrew Cooper wrote:
>>> >> On 18/01/16 12:46, Stefano Stabellini wrote:
> On Mon, 18 Jan 2016, Andrew Cooper wrote:
>>> >> On 18/01/16 12:38, Stefano Stabellini wrot
Introduce pvclk interface which is useful when doing device passthrough
on ARM platform.
To ARM platform, saying embedded SoCs, clock management hardware IP
is controlled by Dom0, DomU does not have clocksource. So we need a
paravirtualized clock source to let DomU can handle device that are
passe
On 20/01/2016 08:46, Jan Beulich wrote:
On 20.01.16 at 06:31, wrote:
>> The primary reason of current solution is to reuse existing NVDIMM
>> driver in Linux kernel.
> Re-using code in the Dom0 kernel has benefits and drawbacks, and
> in any event needs to depend on proper layering to remain
On 20/01/16 09:31, Peng Fan wrote:
> Introduce pvclk interface which is useful when doing device passthrough
> on ARM platform.
...
> +/*
> + * Frontend request
> + *
> + * cmd: command for operation on clk, should be XEN_CLK_[xx],
> + * excluding XEN_CLK_END. id is the
> + * id: clk id
> + * r
Hi!
Can anybody tell me please where I have to post bugs like this to
find the right contact person who is qualified to fix or even to discuss it?
Is xen-devel@lists.xen.org the right list for this?
Thanks in advance,
Michael
Gesendet: Freitag, 15. Januar 2016 um 10:17 Uhr
Von
Hi,
> > > > +i440fx_realize = k->realize;
> > > > k->realize = igd_pt_i440fx_realize;
> >
> > ... because we are overriding it right here.
>
> Many device classes have a parent_realize field so they can keep
> a pointer to the original realize function. It's better than a
> static var
> Cc: wei.l...@citrix.com; ian.campb...@citrix.com;
> stefano.stabell...@eu.citrix.com; ian.jack...@eu.citrix.com; xen-
> de...@lists.xen.org; jbeul...@suse.com
> Subject: Re: [Xen-devel] [PATCH] libxc: Expose the MPX cpuid flag to guest
>
> On Mon, Jan 11, 2016 at 04:52:10PM +0800, Liang Li wrote
Hi Juergen,
On Wed, Jan 20, 2016 at 10:05:15AM +0100, Juergen Gross wrote:
>On 20/01/16 09:31, Peng Fan wrote:
>> Introduce pvclk interface which is useful when doing device passthrough
>> on ARM platform.
>
>...
>
>> +/*
>> + * Frontend request
>> + *
>> + * cmd: command for operation on clk, sho
>>> On 19.01.16 at 20:55, wrote:
> I tried booting staging branch but results were identical. Following
> line repeats endlessly.
> (XEN) traps.c:3290: GPF (): 82d0801c1cce -> 82d080252e5c
>
> $ 'addr2line -e xen-syms 82d0801c1cce' returns
> 'xen/xen/arch/x86/xstate.c:387' which a
>>> On 20.01.16 at 09:31, wrote:
> +/*
> + * Backend response
> + *
> + * cmd: command for operation on clk, same with the cmd in request.
> + * id: clk id, same with the id in request.
> + * success: indicate failure or success for the cmd.
> + * rate: clock rate. Used for get rate.
> + *
> + * c
On 01/20/16 08:58, Andrew Cooper wrote:
> On 20/01/2016 08:46, Jan Beulich wrote:
> On 20.01.16 at 06:31, wrote:
> >> The primary reason of current solution is to reuse existing NVDIMM
> >> driver in Linux kernel.
> > Re-using code in the Dom0 kernel has benefits and drawbacks, and
> > in any
>>> On 20.01.16 at 10:25, wrote:
> On Wed, Jan 20, 2016 at 10:05:15AM +0100, Juergen Gross wrote:
>>On 20/01/16 09:31, Peng Fan wrote:
>>> + */
>>> +struct xen_clkif_request {
>>> + uint32_t cmd;
>>> + uint32_t id;
>>> + uint64_t rate;
>>> +};
>>> +typedef struct xen_clkif_request xen_clkif_
On Wed, 2016-01-20 at 03:58 +, Tian, Kevin wrote:
> > From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> > Sent: Wednesday, January 20, 2016 11:33 AM
> > > As a feature this write-protection has nothing to be GPU
> > > virtualization specific.
> > > In the future the same mediated pass-throu
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 20 January 2016 10:16
> To: Kevin Tian; Yu, Zhang; Wei Liu; Paul Durrant
> Cc: Keir (Xen.org); jbeul...@suse.com; Andrew Cooper; xen-
> de...@lists.xen.org; Lv, Zhiyuan; Stefano Stabellini
> Subject: Re: [Xen
On Wed, Jan 20, 2016 at 01:02:39PM +0800, Yu, Zhang wrote:
>
>
> On 1/20/2016 11:58 AM, Tian, Kevin wrote:
> >>From: Yu, Zhang [mailto:yu.c.zh...@linux.intel.com]
> >>Sent: Wednesday, January 20, 2016 11:33 AM
> >>>As a feature this write-protection has nothing to be GPU virtualization
> >>>spec
On Tue, Jan 19, 2016 at 9:38 AM, Ian Campbell wrote:
> On Tue, 2016-01-19 at 01:43 -0700, Jan Beulich wrote:
>> > > > On 18.01.16 at 19:19, wrote:
>> > On 18/01/16 16:57, Jan Beulich wrote:
>> > > > > > On 18.01.16 at 17:45, wrote:
>> > > > On 18/01/16 16:41, Jan Beulich wrote:
>> > > > > > > >
Jan, thanks for your comments.
> On January 15, 2016 at 9:10, wrote:
> >>> On 23.12.15 at 09:25, wrote:
> > --- a/xen/drivers/passthrough/vtd/qinval.c
> > +++ b/xen/drivers/passthrough/vtd/qinval.c
> > @@ -190,9 +190,19 @@ static int queue_invalidate_wait(struct iommu
> > *iommu, static int inv
On Wed, 2016-01-20 at 09:56 +0100,
> Hi!
>
> Can anybody tell me please where I have to post bugs like this to
> find the right contact person who is qualified to fix or even to discuss
> it?
>
> Is xen-devel@lists.xen.org the right list for this?
For XenServer related bugs:
If you are a Cit
struct gntdev_copy_batch is arguably too large to fit on the kernel stack,
and we get a warning about the stack usage in gntdev_ioctl_grant_copy:
drivers/xen/gntdev.c:949:1: error: the frame size of 1240 bytes is larger than
1024 bytes
This changes the code to us a dynamic allocation instead.
S
On 20/01/16 10:25, Peng Fan wrote:
> Hi Juergen,
>
> On Wed, Jan 20, 2016 at 10:05:15AM +0100, Juergen Gross wrote:
>> On 20/01/16 09:31, Peng Fan wrote:
>>> Introduce pvclk interface which is useful when doing device passthrough
>>> on ARM platform.
>>
>> ...
>>
>>> +/*
>>> + * Frontend request
>
Hi,
On 01/20/2016 06:15 PM, Haozhong Zhang wrote:
CCing QEMU vNVDIMM maintainer: Xiao Guangrong
Conceptually, an NVDIMM is just like a fast SSD which is linearly mapped
into memory. I am still on the dom0 side of this fence.
The real question is whether it is possible to take an NVDIMM, sp
On Tue, 2016-01-19 at 21:46 -0700, Jim Fehlig wrote:
> On 01/19/2016 05:03 AM, Ian Campbell wrote:
> > I went to ping this but noticed that I had sent it to "jimfehlig" (i.e.
> > no
> > domain), so no wonder there was no reply!
> >
> > To: line fixed here, let me know if you would prefer a resend.
flight 78525 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78525/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 9 windows-installfail REGR. vs. 77892
test-amd64-i386-xl-q
I've been running a couple of adhoc production tests per day on these since
before Xmas and they haven't lost sight of their disks again.
TLDR; I think we should throw them back in the pool.
With the recent timeout fixes they are working as well as the production
cubietruck-braque.
There are two
flight 78581 linux-mingo-tip-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78581/
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. 60684
Regression
On 01/20/16 01:46, Jan Beulich wrote:
> >>> On 20.01.16 at 06:31, wrote:
> > The primary reason of current solution is to reuse existing NVDIMM
> > driver in Linux kernel.
>
CC'ing QEMU vNVDIMM maintainer: Xiao Guangrong
> Re-using code in the Dom0 kernel has benefits and drawbacks, and
> in any
On Wed, 2016-01-20 at 01:35 -0700, Jan Beulich wrote:
> > > > On 20.01.16 at 08:49, wrote:
> > >
> > We need to call arch_vcpu_block() before
> > local_events_need_delivery(),
> > since VT-d hardware can issue notification event when we are in
> > arch_vcpu_block(), it that happens, 'ON' bit is s
On 1/20/2016 6:18 PM, Paul Durrant wrote:
-Original Message-
From: Ian Campbell [mailto:ian.campb...@citrix.com]
Sent: 20 January 2016 10:16
To: Kevin Tian; Yu, Zhang; Wei Liu; Paul Durrant
Cc: Keir (Xen.org); jbeul...@suse.com; Andrew Cooper; xen-
de...@lists.xen.org; Lv, Zhiyuan; Stef
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Wednesday, January 20, 2016 7:13 PM
> To: Jan Beulich ; Wu, Feng
> Cc: Andrew Cooper ; George Dunlap
> ; Tian, Kevin ; xen-
> de...@lists.xen.org; Keir Fraser
> Subject: Re: [PATCH v10 6/7] vmx: VT-d
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 20, 2016 4:35 PM
> To: Wu, Feng
> Cc: Andrew Cooper ; Dario Faggioli
> ; George Dunlap ;
> Tian, Kevin ; xen-devel@lists.xen.org; Keir Fraser
>
> Subject: RE: [PATCH v10 6/7] vmx: VT-d posted-
Hi Jan,
On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrote:
On 20.01.16 at 09:31, wrote:
>> +/*
>> + * Backend response
>> + *
>> + * cmd: command for operation on clk, same with the cmd in request.
>> + * id: clk id, same with the id in request.
>> + * success: indicate failure or
Hi Juergen,
On Wed, Jan 20, 2016 at 11:40:55AM +0100, Juergen Gross wrote:
>On 20/01/16 10:25, Peng Fan wrote:
>> Hi Juergen,
>>
>> On Wed, Jan 20, 2016 at 10:05:15AM +0100, Juergen Gross wrote:
>>> On 20/01/16 09:31, Peng Fan wrote:
Introduce pvclk interface which is useful when doing devic
Ian Campbell writes ("OSSTEST: Re-blessing
cubietruck-{picasso,gleizes,metzinger} for production use"):
> I've been running a couple of adhoc production tests per day on these since
> before Xmas and they haven't lost sight of their disks again.
>
> TLDR; I think we should throw them back in the
On Mon, 2016-01-18 at 18:58 +0100, Roger Pau Monné wrote:
> You certainly are more familiar with the migration code than me, but
> wouldn't it be enough to add a new field to libxl_domain_build_info
> (uint32_t emulation_flags), and teach
> libxl_domain_build_info_gen_json/libxl__domain_build_info_
Current implementation of elf_load_bsdsyms is broken when loading inside of
a HVM guest, because it assumes elf_memcpy_safe is able to write into guest
memory space, which it is not.
Take the oportunity to do some cleanup and properly document how
elf_{parse/load}_bsdsyms works. The new implementa
And use it as the default value for the VGA kind. This allows libxl to set
it to the default value later on when the domain type is known. For HVM
guests the default value is LIBXL_VGA_INTERFACE_TYPE_CIRRUS while for
HVMlite the default value is LIBXL_VGA_INTERFACE_TYPE_NONE.
Signed-off-by: Roger
libxl__arch_domain_prepare_config has access to the libxl_domain_build_info
struct, so make sure it's properly initialised.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Ian Campbell
Cc: Wei Liu
---
NB: libxl__arch_domain_prepare_config is called from libxl__domain_make.
---
tools/li
Allow enabling or disabling emulated devices from the libxl domain
configuration file. For HVM guests with a device model all the emulated
devices are enabled. For HVM guests without a device model no devices are
enabled by default, although they can be enabled using the options provided.
The arbit
Hello,
The series is sorted in the following way:
- Patch 1/5 is a preparatory patch for Dom0 HVMlite support.
- Patch 4/5 is a fix from a fallout introduced by the HVMlite series, which
inadvertently disabled the emulated PIT that was added to PV(H) guests.
- Patches 2, 3 and 5 expand the
This fixes the fallout from the HVMlite series, that removed the emulated
PIT from PV(H) guests. Also, this patch forces the hardware domain to
always have an emulated PIT, regardless of whether the toolstack specified
one or not.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Coo
On Wed, 2016-01-20 at 11:52 +, Ian Jackson wrote:
> Ian Campbell writes ("OSSTEST: Re-blessing cubietruck-
> {picasso,gleizes,metzinger} for production use"):
> > I've been running a couple of adhoc production tests per day on these
> > since
> > before Xmas and they haven't lost sight of their
flight 78583 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78583/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR.
vs. 65543
test-amd64-amd64-
... and consolidate the cmdline/extra/root parsing to facilitate doing
so.
The logic is the same as xl's parse_cmdline from the current xen.git master
branch (e6f0e099d2c17de47fd86e817b1998db903cab61).
In order to introduce a use of VIR_WARN for logging I had to add
virerror.h and VIR_LOG_INIT.
On Wed, 20 Jan 2016, Peng Fan wrote:
> To my use case, Dom0 and DomU both use device tree, I need to build
> the mapping table between id and name, since I use name to lookup
> the clk in backend, like this:
> "clk = __clk_loopkup(clkname); clk_prepare_enable(clk)". Maybe ACPI
> is another differen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-1570 / XSA-167
version 4
PV superpage functionality missing sanity checks
UPDATES IN VERSION 4
Public release.
ISSUE DESCRIPTION
=
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Xen Security Advisory CVE-2016-1571 / XSA-168
version 3
VMX: intercept issue with INVLPG on non-canonical address
UPDATES IN VERSION 3
Public release.
ISSUE DESCRIPTION
=
On 20/01/16 12:48, Peng Fan wrote:
> Hi Juergen,
>
> On Wed, Jan 20, 2016 at 11:40:55AM +0100, Juergen Gross wrote:
>> On 20/01/16 10:25, Peng Fan wrote:
>>> Hi Juergen,
>>>
>>> On Wed, Jan 20, 2016 at 10:05:15AM +0100, Juergen Gross wrote:
On 20/01/16 09:31, Peng Fan wrote:
> Introduce p
There have been a few reports recently[0] which relate to a failure of
netfront to allocate sufficient grant refs for all the queues:
[0.533589] xen_netfront: can't alloc rx grant refs
[0.533612] net eth0: only created 31 queues
Which can be worked around by increasing the number of grant
On Wed, 2016-01-20 at 12:06 +, Stefano Stabellini wrote:
> On Wed, 20 Jan 2016, Peng Fan wrote:
> > To my use case, Dom0 and DomU both use device tree, I need to build
> > the mapping table between id and name, since I use name to lookup
> > the clk in backend, like this:
> > "clk = __clk_loopk
On Wed, 2016-01-20 at 11:58 +, Ian Campbell wrote:
> On Wed, 2016-01-20 at 11:52 +, Ian Jackson wrote:
> > Ian Campbell writes ("OSSTEST: Re-blessing cubietruck-
> > {picasso,gleizes,metzinger} for production use"):
> > > I've been running a couple of adhoc production tests per day on these
On Wed, 2016-01-20 at 12:57 +0100, Roger Pau Monne wrote:
> And use it as the default value for the VGA kind. This allows libxl to
> set
> it to the default value later on when the domain type is known. For HVM
> guests the default value is LIBXL_VGA_INTERFACE_TYPE_CIRRUS while for
> HVMlite the de
On Wed, 20 Jan 2016, Tian, Kevin wrote:
> > From: Zhang, Haozhong
> > Sent: Tuesday, December 29, 2015 7:32 PM
> >
> > This patch series is the Xen part patch to provide virtual NVDIMM to
> > guest. The corresponding QEMU patch series is sent separately with the
> > title "[PATCH 0/2] add vNVDIMM
On Wed, 2016-01-20 at 12:57 +0100, Roger Pau Monne wrote:
> libxl__arch_domain_prepare_config has access to the
> libxl_domain_build_info
> struct, so make sure it's properly initialised.
>
> Signed-off-by: Roger Pau Monné
> ---
> Cc: Ian Jackson
> Cc: Ian Campbell
> Cc: Wei Liu
> ---
> NB: li
>>> On 20.01.16 at 12:04, wrote:
> On 01/20/16 01:46, Jan Beulich wrote:
>> >>> On 20.01.16 at 06:31, wrote:
>> > Secondly, the driver implements a convenient block device interface to
>> > let software access areas where NVDIMM devices are mapped. The
>> > existing vNVDIMM implementation in QEMU
My patch b2700877 "move and amend multicast control documentation"
clarified use of the multicast control protocol between frontend and
backend. However, it transpires that the restrictions that documentation
placed on the "request-multicast-control" flag make it hard for a
frontend to enable 'all
>>> On 20.01.16 at 11:26, wrote:
>> On January 15, 2016 at 9:10, wrote:
>> >>> On 23.12.15 at 09:25, wrote:
>> > @@ -229,6 +239,63 @@ int qinval_device_iotlb(struct iommu *iommu,
>> > return 0;
>> > }
>> >
>> > +static void dev_invalidate_iotlb_timeout(struct iommu *iommu, u16 did,
>> > +
>>> On 20.01.16 at 12:20, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, January 20, 2016 4:35 PM
>> >>> On 20.01.16 at 08:49, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Monday, January 18, 2016 11:14 PM
>> >> >>> On 03.12.15 at 09:35, wrote
On Wed, 2016-01-20 at 12:57 +0100, Roger Pau Monne wrote:
> Allow enabling or disabling emulated devices from the libxl domain
> configuration file. For HVM guests with a device model all the emulated
> devices are enabled. For HVM guests without a device model no devices are
> enabled by default,
>>> On 20.01.16 at 12:40, wrote:
> Hi Jan,
>
> On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrote:
> On 20.01.16 at 09:31, wrote:
>>> +/*
>>> + * Backend response
>>> + *
>>> + * cmd: command for operation on clk, same with the cmd in request.
>>> + * id: clk id, same with the id in
>>> On 18.01.16 at 16:53, wrote:
> Possibly also:
> 42940c046902 "x86/shadow: Fix missing newline in dprintk()"
The affected statement compiles to nothing in a release build, which
can be taken as an argument both ways. I lean towards not putting
it in.
> 6851e979874e "VT-d: use proper error cod
>>> On 20.01.16 at 12:57, wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -542,8 +542,11 @@ int arch_domain_create(struct domain *d, unsigned int
> domcr_flags,
> d->domain_id, config->emulation_flags);
> return -EINVAL;
> }
> -
flight 78528 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78528/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds 11 guest-start fail blocked in 77441
test-amd64-amd64-xl-qemut-
On Wed, 2016-01-20 at 12:50 +, Paul Durrant wrote:
> My patch b2700877 "move and amend multicast control documentation"
> clarified use of the multicast control protocol between frontend and
> backend. However, it transpires that the restrictions that documentation
> placed on the "request-mult
> -Original Message-
> From: Ian Campbell [mailto:ian.campb...@citrix.com]
> Sent: 20 January 2016 13:06
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Ian Jackson; Jan Beulich; Keir (Xen.org); Tim (Xen.org)
> Subject: Re: [PATCH] public/io/netif.h: change semantics of "request-
>
On 20/01/16 12:29, Jan Beulich wrote:
On 18.01.16 at 16:53, wrote:
>> Possibly also:
>> 42940c046902 "x86/shadow: Fix missing newline in dprintk()"
> The affected statement compiles to nothing in a release build, which
> can be taken as an argument both ways. I lean towards not putting
> it i
On 20/01/16 10:36, Xiao Guangrong wrote:
>
> Hi,
>
> On 01/20/2016 06:15 PM, Haozhong Zhang wrote:
>
>> CCing QEMU vNVDIMM maintainer: Xiao Guangrong
>>
>>> Conceptually, an NVDIMM is just like a fast SSD which is linearly
>>> mapped
>>> into memory. I am still on the dom0 side of this fence.
>>>
On Wed, 2016-01-20 at 04:35 -0700, Jan Beulich wrote:
> > > > On 20.01.16 at 12:20, wrote:
> > >
> > > Then you didn't understand: The question isn't this path, but the
> > > path where the hook gets called if non-NULL (and hence the
> > > possibility to avoid such needless calls).
> >
> > I und
All,
with this first point release due in about two weeks, please indicate
backports you find missing from its staging tree but necessary in the
release.
Thanks, Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
> -Original Message-
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com]
> Sent: Wednesday, January 20, 2016 9:31 PM
> To: Jan Beulich ; Wu, Feng
> Cc: Andrew Cooper ; George Dunlap
> ; Tian, Kevin ; xen-
> de...@lists.xen.org; Keir Fraser
> Subject: Re: [PATCH v10 6/7] vmx: VT-d
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, January 20, 2016 7:36 PM
> To: Wu, Feng
> Cc: Andrew Cooper ; Dario Faggioli
> ; George Dunlap ;
> Tian, Kevin ; xen-devel@lists.xen.org; Keir Fraser
>
> Subject: RE: [PATCH v10 6/7] vmx: VT-d posted-
Hi Ian, Stefano
On Wed, Jan 20, 2016 at 12:27:07PM +, Ian Campbell wrote:
>On Wed, 2016-01-20 at 12:06 +, Stefano Stabellini wrote:
>> On Wed, 20 Jan 2016, Peng Fan wrote:
>> > To my use case, Dom0 and DomU both use device tree, I need to build
>> > the mapping table between id and name, s
1: mmuext: tighten TLB flush address checks
2: PV: relax LDT address check
3: paging: invlpg() hook returns boolean
Signed-off-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 20.01.16 at 14:48, wrote:
>
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, January 20, 2016 7:36 PM
>> To: Wu, Feng
>> Cc: Andrew Cooper ; Dario Faggioli
>> ; George Dunlap ;
>> Tian, Kevin ; xen-devel@lists.xen.org; Keir Fraser
>>
>> S
Addresses passed by PV guests should be subjected to __addr_ok(),
avoiding undue TLB flushes; .
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3268,8 +3268,9 @@ long do_mmuext_op(
case MMUEXT_INVLPG_LOCAL:
if ( unlikely(d != pg_owner) )
There's no point placing restrictions on its address when the LDT size
is zero.
Also convert a local variable to a slightly more efficient type.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -3348,8 +3348,8 @@ long do_mmuext_op(
case MMUEXT_SET_LDT:
Hi Jan,
On Wed, Jan 20, 2016 at 05:01:40AM -0700, Jan Beulich wrote:
On 20.01.16 at 12:40, wrote:
>> Hi Jan,
>>
>> On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrote:
>> On 20.01.16 at 09:31, wrote:
+/*
+ * Backend response
+ *
+ * cmd: command for operation
... so make its return type reflect this.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/mm/hap/hap.c
+++ b/xen/arch/x86/mm/hap/hap.c
@@ -680,7 +680,7 @@ static int hap_page_fault(struct vcpu *v
* HAP guests can handle invlpg without needing any action from Xen, so
* should not be interceptin
Hi Juergen,
On Wed, Jan 20, 2016 at 01:11:39PM +0100, Juergen Gross wrote:
>On 20/01/16 12:48, Peng Fan wrote:
>> Hi Juergen,
>>
>> On Wed, Jan 20, 2016 at 11:40:55AM +0100, Juergen Gross wrote:
>>> On 20/01/16 10:25, Peng Fan wrote:
Hi Juergen,
On Wed, Jan 20, 2016 at 10:05:15AM +
>>> On 20.01.16 at 15:05, wrote:
> Hi Jan,
> On Wed, Jan 20, 2016 at 05:01:40AM -0700, Jan Beulich wrote:
> On 20.01.16 at 12:40, wrote:
>>> Hi Jan,
>>>
>>> On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrote:
>>> On 20.01.16 at 09:31, wrote:
> +/*
> + * Backend response
On 20/01/16 14:05, Jan Beulich wrote:
> Addresses passed by PV guests should be subjected to __addr_ok(),
> avoiding undue TLB flushes; .
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -3268,8 +3268,9 @@ long do_mmuext_op(
> case MMUEXT_INVLPG_LO
This run is configured for baseline tests only.
flight 38665 qemu-mainline real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38665/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pv
flight 78617 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/78617/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 5 xen-build fail REGR. vs. 78553
Tests which di
On 01/20/16 12:43, Stefano Stabellini wrote:
> On Wed, 20 Jan 2016, Tian, Kevin wrote:
> > > From: Zhang, Haozhong
> > > Sent: Tuesday, December 29, 2015 7:32 PM
> > >
> > > This patch series is the Xen part patch to provide virtual NVDIMM to
> > > guest. The corresponding QEMU patch series is sen
On 20/01/16 14:06, Jan Beulich wrote:
> There's no point placing restrictions on its address when the LDT size
> is zero.
>
> Also convert a local variable to a slightly more efficient type.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
__
On 20/01/16 14:07, Jan Beulich wrote:
> ... so make its return type reflect this.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper , although this
needs MM and shadow acks as well (CC'd).
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http
On Wed, 20 Jan 2016, Andrew Cooper wrote:
> On 20/01/16 10:36, Xiao Guangrong wrote:
> >
> > Hi,
> >
> > On 01/20/2016 06:15 PM, Haozhong Zhang wrote:
> >
> >> CCing QEMU vNVDIMM maintainer: Xiao Guangrong
> >>
> >>> Conceptually, an NVDIMM is just like a fast SSD which is linearly
> >>> mapped
> >
> On Jan 15, 2016, at 11:01 AM, Jonathan Creekmore
> wrote:
>
> Creates a section to contain scheduler entry pointers that are gathered
> together into an array. This will allow, in a follow-on patch, scheduler
> entries to be automatically gathered together into the array for
> automatic parsi
On Wed, 20 Jan 2016, Zhang, Haozhong wrote:
> On 01/20/16 12:43, Stefano Stabellini wrote:
> > On Wed, 20 Jan 2016, Tian, Kevin wrote:
> > > > From: Zhang, Haozhong
> > > > Sent: Tuesday, December 29, 2015 7:32 PM
> > > >
> > > > This patch series is the Xen part patch to provide virtual NVDIMM to
flight 38672 distros-debian-squeeze real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/38672/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 3 host-install(3) broken RE
Hi Jan,
On Wed, Jan 20, 2016 at 07:16:36AM -0700, Jan Beulich wrote:
On 20.01.16 at 15:05, wrote:
>> Hi Jan,
>> On Wed, Jan 20, 2016 at 05:01:40AM -0700, Jan Beulich wrote:
>> On 20.01.16 at 12:40, wrote:
Hi Jan,
On Wed, Jan 20, 2016 at 03:14:20AM -0700, Jan Beulich wrot
At 07:07 -0700 on 20 Jan (1453273623), Jan Beulich wrote:
> ... so make its return type reflect this.
>
> Signed-off-by: Jan Beulich
Acked-by: Tim Deegan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
>>> On 20.01.16 at 15:23, wrote:
> On 20/01/16 14:05, Jan Beulich wrote:
>> Addresses passed by PV guests should be subjected to __addr_ok(),
>> avoiding undue TLB flushes; .
>>
>> Signed-off-by: Jan Beulich
>>
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -3268,8 +3268,9 @@ long do
On 01/20/16 14:29, Stefano Stabellini wrote:
> On Wed, 20 Jan 2016, Andrew Cooper wrote:
> > On 20/01/16 10:36, Xiao Guangrong wrote:
> > >
> > > Hi,
> > >
> > > On 01/20/2016 06:15 PM, Haozhong Zhang wrote:
> > >
> > >> CCing QEMU vNVDIMM maintainer: Xiao Guangrong
> > >>
> > >>> Conceptually, an
>>> On 20.01.16 at 15:30, wrote:
> On 20/01/16 14:07, Jan Beulich wrote:
>> ... so make its return type reflect this.
>>
>> Signed-off-by: Jan Beulich
>
> Reviewed-by: Andrew Cooper , although this
> needs MM and shadow acks as well (CC'd).
Oh, sure - I meant to but then forgot; thanks for noti
On 20/01/16 14:29, Stefano Stabellini wrote:
> On Wed, 20 Jan 2016, Andrew Cooper wrote:
>> On 20/01/16 10:36, Xiao Guangrong wrote:
>>> Hi,
>>>
>>> On 01/20/2016 06:15 PM, Haozhong Zhang wrote:
>>>
CCing QEMU vNVDIMM maintainer: Xiao Guangrong
> Conceptually, an NVDIMM is just like a
1 - 100 of 206 matches
Mail list logo
