flight 106554 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106554/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 3 host-install(3) broken REGR. vs. 105963
test-amd64-i386-xl-qemuu-o
On 03/09/2017 08:18 AM, Reshetova, Elena wrote:
>> On Mon, Mar 06, 2017 at 04:21:09PM +0200, Elena Reshetova wrote:
>>> refcount_t type and corresponding API should be
>>> used instead of atomic_t when the variable is used as
>>> a reference counter. This allows to avoid accidental
>>> refcounter o
On Wed, 2017-03-08 at 17:46 +, Ross Lagerwall wrote:
> Remove the unused x86 implementation.
>
> Signed-off-by: Ross Lagerwall
>
FWIW,
Reviewed-by: Dario Faggioli
Regards,
Dario
--
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D,
On Wed, 2017-03-08 at 17:46 +, Ross Lagerwall wrote:
> When using LivePatch, use of __LINE__ can generate spurious changes
> in
> functions due to embedded line numbers. For release builds with
> LivePatch enabled, remove the use of these line numbers in
> domain_crash*() and print the current
> On 03/09/2017 08:18 AM, Reshetova, Elena wrote:
> >> On Mon, Mar 06, 2017 at 04:21:09PM +0200, Elena Reshetova wrote:
> >>> refcount_t type and corresponding API should be
> >>> used instead of atomic_t when the variable is used as
> >>> a reference counter. This allows to avoid accidental
> >>>
On 03/09/2017 10:26 AM, Reshetova, Elena wrote:
>
>> On 03/09/2017 08:18 AM, Reshetova, Elena wrote:
On Mon, Mar 06, 2017 at 04:21:09PM +0200, Elena Reshetova wrote:
> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a refer
For the default EPT view we have xc_set_mem_access_multi(), which
is able to set an array of pages to an array of access rights with
a single hypercall. However, this functionality was lacking for the
altp2m subsystem, which could only set page restrictions for one
page at a time. This patch addres
Signed-off-by: Dario Faggioli
---
Cc: George Dunlap
---
xen/common/sched_credit2.c |2 --
1 file changed, 2 deletions(-)
diff --git a/xen/common/sched_credit2.c b/xen/common/sched_credit2.c
index af457c1..bb1c657 100644
--- a/xen/common/sched_credit2.c
+++ b/xen/common/sched_credit2.c
@@ -2
>>> On 09.03.17 at 10:54, wrote:
> --- a/xen/common/sched_credit2.c
> +++ b/xen/common/sched_credit2.c
> @@ -2437,8 +2437,6 @@ csched2_runtime(const struct scheduler *ops, int cpu,
> return time;
> }
>
> -void __dump_execstate(void *unused);
All fine, except the function wasn't static (or
>>> On 08.03.17 at 19:30, wrote:
> On Wed, Mar 8, 2017 at 2:01 AM, Razvan Cojocaru
> wrote:
>> For the default EPT view we have xc_set_mem_access_multi(), which
>> is able to set an array of pages to an array of access rights with
>> a single hypercall. However, this functionality was lacking for
On 03/09/2017 12:16 PM, Jan Beulich wrote:
On 08.03.17 at 19:30, wrote:
>> On Wed, Mar 8, 2017 at 2:01 AM, Razvan Cojocaru
>> wrote:
>>> For the default EPT view we have xc_set_mem_access_multi(), which
>>> is able to set an array of pages to an array of access rights with
>>> a single hyper
The way these extension spaces get handled we so far always end up
going through the generic SrcMem operand fetch path for unused table
entries. Suppress actual memory accesses happening by forcing op_bytes
to zero in those cases.
Signed-off-by: Jan Beulich
---
RFC: There are still some gaps left
Their 64-bit register constraints prevented this so far.
Signed-off-by: Jan Beulich
--- a/include/arch/x86/lib.h
+++ b/include/arch/x86/lib.h
@@ -398,18 +398,18 @@ static inline unsigned int str(void)
static inline uint64_t xgetbv(uint32_t index)
{
-uint32_t feat_lo;
-uint64_t feat_h
>>> On 09.03.17 at 11:19, wrote:
> So should I revert to a V3 that's basically V1 then? I've been
> trigger-happy and submitted V2 roughly an hour ago based on Tamas'
> suggestion.
Well, I'd suggest waiting for further opinions. Others may agree with
Tamas, or may have a 3rd opinion.
Jan
_
>>> On 08.03.17 at 18:46, wrote:
> Remove the unused x86 implementation.
Unused or not - what's wrong with it? (I can guess it from the
context of the series, but the justification should be put here.)
After all it's there for debugging purposes, so if it's unused it
also can't cause any issues f
>>> On 08.03.17 at 18:46, wrote:
> Sorry for the long delay since the first version of this series
> (previously called "Make building xSplice patches easier"). Here is a
> set of changes that remove the use of __LINE__ when building with NDEBUG
> and LivePatch enabled. Tested to boot on x86. C
On Thu, 2017-03-09 at 03:09 -0700, Jan Beulich wrote:
> > > > On 09.03.17 at 10:54, wrote:
> >
> > --- a/xen/common/sched_credit2.c
> > +++ b/xen/common/sched_credit2.c
> > @@ -2437,8 +2437,6 @@ csched2_runtime(const struct scheduler *ops,
> > int cpu,
> > return time;
> > }
> >
> > -void
>>> On 08.03.17 at 18:46, wrote:
When seeing the title I wondered by I didn't get Cc-ed. Perhaps the
prefix would better have been VT-d: ?
> --- a/xen/drivers/passthrough/vtd/dmar.h
> +++ b/xen/drivers/passthrough/vtd/dmar.h
> @@ -108,6 +108,19 @@ struct acpi_atsr_unit
> *acpi_find_matched_atsr
flight 106562 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106562/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-libvirt 13 saverestore-support-checkfail like 106543
test-armhf-armhf-libvirt-xsm 13
>>> On 08.03.17 at 18:46, wrote:
> @@ -791,9 +807,7 @@ do{ asm volatile (
> \
> [stub] "rm" (stub.func) ); \
> if ( unlikely(~res_.raw) ) \
> {
>>> On 09.03.17 at 11:36, wrote:
> On Thu, 2017-03-09 at 03:09 -0700, Jan Beulich wrote:
>> > > > On 09.03.17 at 10:54, wrote:
>> >
>> > --- a/xen/common/sched_credit2.c
>> > +++ b/xen/common/sched_credit2.c
>> > @@ -2437,8 +2437,6 @@ csched2_runtime(const struct scheduler *ops,
>> > int cpu,
>>
On 09/03/17 10:22, Jan Beulich wrote:
> Their 64-bit register constraints prevented this so far.
>
> Signed-off-by: Jan Beulich
Ah - I already noticed and fixed this in
http://xenbits.xen.org/gitweb/?p=xtf.git;a=commitdiff;h=07f29b74020fa3b3f4fc2209e620e71a838062b4
In fact, the patch is identica
On Thu, Mar 09, 2017 at 11:59:51AM +0900, Roger Pau Monné wrote:
> On Wed, Mar 08, 2017 at 02:12:09PM -0500, Konrad Rzeszutek Wilk wrote:
> > On Wed, Mar 08, 2017 at 07:06:23PM +, Julien Grall wrote:
> > > Hi,
> > >
> > > On 02/02/17 23:06, Stefano Stabellini wrote:
> > > > On Thu, 2 Feb 2017,
flight 106559 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106559/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stopfail like 106544
test-amd64-i386-xl-qemuu-w
On 09/03/17 10:20, Jan Beulich wrote:
> The way these extension spaces get handled we so far always end up
> going through the generic SrcMem operand fetch path for unused table
> entries. Suppress actual memory accesses happening by forcing op_bytes
> to zero in those cases.
>
> Signed-off-by: Jan
flight 68647 distros-debian-wheezy real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68647/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
build-arm64 2 hosts-allocate broken never pass
build-arm64-pvops
On Tue 07-03-17 13:40:04, Igor Mammedov wrote:
> On Mon, 6 Mar 2017 15:54:17 +0100
> Michal Hocko wrote:
>
> > On Fri 03-03-17 18:34:22, Igor Mammedov wrote:
[...]
> > > in current mainline kernel it triggers following code path:
> > >
> > > online_pages()
> > > ...
> > >if (online_typ
Hi Konrad,
On 09/03/17 11:17, Konrad Rzeszutek Wilk wrote:
On Thu, Mar 09, 2017 at 11:59:51AM +0900, Roger Pau Monné wrote:
On Wed, Mar 08, 2017 at 02:12:09PM -0500, Konrad Rzeszutek Wilk wrote:
On Wed, Mar 08, 2017 at 07:06:23PM +, Julien Grall wrote:
Hi,
On 02/02/17 23:06, Stefano Stab
This run is configured for baseline tests only.
flight 68646 xen-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68646/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i3864 host-build-p
>>> On 15.02.17 at 09:49, wrote:
> @@ -397,6 +408,25 @@ static int l3_cat_compare_val(const uint64_t val[],
> return 0;
> }
>
> +static bool l3_cat_fits_cos_max(const uint64_t val[],
> +const struct feat_node *feat,
> +unsigne
flight 106561 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106561/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR.
vs. 106534
test-amd
>>> On 15.02.17 at 09:49, wrote:
> --- a/xen/arch/x86/psr.c
> +++ b/xen/arch/x86/psr.c
> @@ -97,6 +97,7 @@ struct psr_cat_hw_info {
> struct feat_hw_info {
> union {
> struct psr_cat_hw_info l3_cat_info;
> +struct psr_cat_hw_info l3_cdp_info;
Two union members of the same t
>>> On 15.02.17 at 09:49, wrote:
> @@ -684,6 +686,53 @@ struct feat_ops l3_cdp_ops = {
> .write_msr = l3_cdp_write_msr,
> };
>
> +/* L2 CAT callback functions implementation. */
> +static void l2_cat_init_feature(struct cpuid_leaf regs,
const struct cpuid_leaf * (and of course I should ha
Hi,
Yesterday I decided to upgrade my Xen version from 4.6.0 to 4.8.0. I
compiled it from source and at the same time I compiled the latest Linux
kernel (4.10.1).
When rebooting I decided to try if dom0 PVH would work (with previous Xen
version it just caused kernel panic). Seemed to boot fine un
>>> On 15.02.17 at 09:49, wrote:
> +static bool l2_cat_get_feat_info(const struct feat_node *feat,
> + uint32_t data[], uint32_t array_len)
> +{
> +if ( !data || 2 > array_len )
> +return false;
> +
> +data[CBM_LEN] = feat->info.l2_cat_info.cbm_len;
When doing the recent stable release branches, I tripped over some
deficiencies in these checklists. And, now that they are in git, we
can much more safely throw away a lot of ancient stuff.
Please shout if you have any objections. I hope to push this today.
Ian.
__
Remove:
- Head comment saying not to edit here. This came from the
now-no-longer-master xenbits copy which I have deleted.
- Many old (commented-out) instruction related to hg
- Many old (commented-out) instruction related to pre-unified
qemu trees.
- Many old (commented-out) instruc
This is almost all just motion. There is one new paragraph in
branching-checklist.txt:
+ Update both new branches according to release-checklist.txt section re
+ README etc.
Signed-off-by: Ian Jackson
---
misc/branching-checklist.txt | 97
misc/rele
On Tue, Mar 07, 2017 at 12:39:04AM +0100, Daniel Kiper wrote:
> On Wed, Feb 22, 2017 at 09:04:17AM -0800, Doug Goldstein wrote:
>
> [...]
>
> > I'm currently at ELC and then on vacation so I don't have access to any
> > of the machines currently myself. However the machine I most use to test
> > is
4.2 is well out of support and we will never need to make a release of
it again. Delete all the stuff for making combined tarballs "by hand".
Signed-off-by: Ian Jackson
---
misc/release-checklist.txt | 34 --
1 file changed, 34 deletions(-)
diff --git a/misc/rel
Signed-off-by: Ian Jackson
---
misc/branching-checklist.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/misc/branching-checklist.txt b/misc/branching-checklist.txt
index c905383..8899432 100644
--- a/misc/branching-checklist.txt
+++ b/misc/branching-checklist.txt
@@ -54,6 +54,12 @@
On 03/08/2017 06:58 PM, Stefano Stabellini wrote:
> Introduce the Xen 9pfs transport driver: add struct xenbus_driver to
> register as a xenbus driver and add struct p9_trans_module to register
> as v9fs driver.
>
> All functions are empty stubs for now.
>
> Signed-off-by: Stefano Stabellini
> CC:
> +
> +static int xen_9pfs_front_alloc_dataring(struct xenbus_device *dev,
> + struct xen_9pfs_dataring *ring)
> +{
> + int i;
> + int ret = -ENOMEM;
> +
> + init_waitqueue_head(&ring->wq);
> + spin_lock_init(&ring->lock);
> + INIT_WORK(&ring->work, p9_xen_response)
On 09/03/17 15:24, Daniel Kiper wrote:
> On Tue, Mar 07, 2017 at 12:39:04AM +0100, Daniel Kiper wrote:
>> On Wed, Feb 22, 2017 at 09:04:17AM -0800, Doug Goldstein wrote:
>>
>> [...]
>>
>>> I'm currently at ELC and then on vacation so I don't have access to any
>>> of the machines currently myself.
>>> On 09.03.17 at 16:24, wrote:
> Though it looks that I found a bug in Xen IOMMU code. If I run Xen from master
> in QEMU then QEMU complains and crashes:
>
> qemu-system-x86_64: /srv/dev/qemu/qemu_20170308/hw/i386/intel_iommu.c:1786:
> vtd_mem_write: Assertion `size == 4' failed.
> Aborte
On 03/08/2017 06:58 PM, Stefano Stabellini wrote:
> Implement struct p9_trans_module create and close functions by looking
> at the available Xen 9pfs frontend-backend connections. We don't expect
> many frontend-backend connections, thus walking a list is OK.
>
> Send requests to the backend by co
>>> On 09.03.17 at 16:19, wrote:
> @@ -232,14 +202,10 @@ GZIP=-9v tar zcf
> /volatile/iwj/website-thing/xen.org/oss-xen/release/$v/xen-$v.t
> #rsync -a --delete xen-$v build/
> cd xen-$v
> export http_proxy=http://localhost:3128/
> -
>>> On 09.03.17 at 16:19, wrote:
> --- /dev/null
> +++ b/misc/branching-checklist.txt
> @@ -0,0 +1,97 @@
> +v=4.1
> +ov=4.0
> +
> +##* tag branchpoint
> +##hg tag $v.0-branched
> +##hg sign -k 'Xen tree' 4.1.0-branched
Does this Mercurial stuff need keeping?
> +* make branch in q
>>> On 09.03.17 at 16:19, wrote:
> When doing the recent stable release branches, I tripped over some
> deficiencies in these checklists. And, now that they are in git, we
> can much more safely throw away a lot of ancient stuff.
>
> Please shout if you have any objections. I hope to push this
Jan Beulich writes ("Re: [PATCH 2/4] misc/release-checklist: Remove pre-4.3
tarball target instructions"):
> On 09.03.17 at 16:19, wrote:
> > @@ -232,14 +202,10 @@ GZIP=-9v tar zcf
> > /volatile/iwj/website-thing/xen.org/oss-xen/release/$v/xen-$v.t
> > -(make -j4 KERNELS='' && ec
Jan Beulich writes ("Re: [PATCH 3/4] misc/release-checklist: Split out
branching-checklist.txt"):
> On 09.03.17 at 16:19, wrote:
> > +##* tag branchpoint
> > +##hg tag $v.0-branched
> > +##hg sign -k 'Xen tree' 4.1.0-branched
>
> Does this Mercurial stuff need keeping?
No. But,
>>> On 09.03.17 at 16:53, wrote:
> Jan Beulich writes ("Re: [PATCH 2/4] misc/release-checklist: Remove pre-4.3
> tarball target instructions"):
>> On 09.03.17 at 16:19, wrote:
>> > @@ -232,14 +202,10 @@ GZIP=-9v tar zcf
>> > /volatile/iwj/website-thing/xen.org/oss-xen/release/$v/xen-$v.t
>> > -
On 03/08/2017 06:58 PM, Stefano Stabellini wrote:
> Upon receiving a notification from the backend, schedule the
> p9_xen_response work_struct. p9_xen_response checks if any responses are
> available, if so, it reads them one by one, calling p9_client_cb to send
> them up to the 9p layer (p9_client
Hi,
I've sent my last couple of days on trying to make raisin tests run on
different distributions. Tried Ubuntu 16.04, Ubuntu 14.04, CentOS 7 and
CentOS 6.8 so far. The tests fail because of different reasons on these
distributions:
1. bussybox-pv passes on Ubuntu 14.04 and 16.04, it fails
>>> On 09.03.17 at 10:38, wrote:
> @@ -4535,6 +4536,30 @@ static int do_altp2m_op(
> a.u.set_mem_access.view);
> break;
>
> +case HVMOP_altp2m_set_mem_access_multi:
> +if ( a.u.set_mem_access_multi.pad ||
> + a.u.set_mem_acces
Hi all,
that is now live at https://xenproject.org/governance.html and committed (with
manually beautified html to make tables look good) at
http://xenbits.xen.org/gitweb/?p=people/larsk/governance.git;a=summary
At some point probably a blog post is in order, but am too busy right now
Regards
On 03/09/2017 06:56 PM, Jan Beulich wrote:
On 09.03.17 at 10:38, wrote:
>> @@ -4535,6 +4536,30 @@ static int do_altp2m_op(
>> a.u.set_mem_access.view);
>> break;
>>
>> +case HVMOP_altp2m_set_mem_access_multi:
>> +if ( a.u.set_mem_acc
On Thu, Mar 9, 2017 at 9:56 AM, Jan Beulich wrote:
On 09.03.17 at 10:38, wrote:
>> @@ -4535,6 +4536,30 @@ static int do_altp2m_op(
>> a.u.set_mem_access.view);
>> break;
>>
>> +case HVMOP_altp2m_set_mem_access_multi:
>> +if ( a.u.set_
flight 106563 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106563/
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
test-amd64-amd64-xl
On Mon, 6 Mar 2017 18:12:48 -0800
Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini
> CC: anthony.per...@citrix.com
> CC: jgr...@suse.com
> CC: Aneesh Kumar K.V
> CC: Greg Kurz
> ---
> hw/9pfs/Makefile.objs| 1 +
> hw/xen/xen_backend.c | 1 +
> include/hw/xen/xen_
On Mon, 6 Mar 2017 18:12:43 -0800
Stefano Stabellini wrote:
> Introduce the Xen 9pfs backend: add struct XenDevOps to register as a
> Xen backend and add struct V9fsTransport to register as v9fs transport.
>
> All functions are empty stubs for now.
>
> Signed-off-by: Stefano Stabellini
> CC:
flight 106564 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106564/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 105963
test-amd64-i386-xl-qemuu-
Saving/restoring the physmap to/from xenstore was introduced to
QEMU majorly in order to cover up the VRAM region restore issue.
The sequence of restore operations implies that we should know
the effective guest VRAM address *before* we have the VRAM region
restored (which happens later). Unfortuna
flight 106569 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106569/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
Create a basic Makefile to build and install libxenlight Golang
bindings. Also add a stub package which only opens libxl context.
Include a global xenlight.Ctx variable which can be used as the
default context by the entire program if desired.
For now, return simple errors. Proper error handling
Add calls for the following host-related functionality:
- libxl_domain_info
- libxl_domain_unpause
Include Golang version for the libxl_domain_info as
DomainInfo.
Signed-off-by: George Dunlap
Signed-off-by: Ronald Rojas
---
Changes since last version
- Formating fixes
- used defer for libxl_d
Create tests for the following functions:
- GetVersionInfo
- GetPhysinfo
- GetDominfo
- GetMaxCpus
- GetOnlineCpus
- GetMaxNodes
- GetFreeMemory
Signed-off-by: Ronald Rojas
Signed-off-by: George Dunlap
---
changes since last version
- created CFLAGS and LDLIBS variables to build test C
files w
Create error type Errorxl for throwing proper xenlight
errors.
Update Ctx functions to throw Errorxl errors.
Signed-off-by: Ronald Rojas
---
CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
tools/golang/xenlight/xenlight.go
Implement Bitmap type, along with helper functions.
The Bitmap type is implemented interllay in a way which makes it
easy to copy into and out of the C libxl_bitmap type.
Signed-off-by: George Dunlap
Signed-off-by: Ronald Rojas
---
CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC:
Include some useful "Utility" functions:
- CpupoolFindByName
- CpupoolMakeFree
Still need to implement the following functions:
- libxl_cpupool_rename
- libxl_cpupool_cpuadd_node
- libxl_cpupool_cpuremove_node
- libxl_cpupool_movedomain
Signed-off-by: George Dunlap
Signed-off-by: Ronald Rojas
-
Include both constants and a Stringification for libxl_scheduler.
Signed-off-by: George Dunlap
Signed-off-by: Ronald Rojas
---
CC: xen-devel@lists.xen.org
CC: george.dun...@citrix.com
CC: ian.jack...@eu.citrix.com
CC: wei.l...@citrix.com
---
---
tools/golang/xenlight/xenlight.go | 62 +
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Subject: [Qemu-devel] [PATCH] xen: don't save/restore the physmap on VM
save/restore
Message-id: 1489084689-19008-1-git-send-email-igor.druzhi...@citrix.com
=== TEST SCRIPT BEGIN ===
#!
Hi,
This series failed automatic build test. Please find the testing commands and
their output below. If you have docker installed, you can probably reproduce it
locally.
Type: series
Subject: [Qemu-devel] [PATCH] xen: don't save/restore the physmap on VM
save/restore
Message-id: 1489084689-1900
In some cases during XenBus disconnect event handling and subsequent
queue resource release there may be some TX handlers active on
other processors. Use RCU in order to synchronize with them.
Signed-off-by: Igor Druzhinin
---
v3:
* Fix unintended semantic change in xenvif_get_ethtool_stats
* D
On 3/7/17 9:44 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 07, 2017 at 12:39:04AM +0100, Daniel Kiper wrote:
>> On Wed, Feb 22, 2017 at 09:04:17AM -0800, Doug Goldstein wrote:
>>
>> [...]
>>
>>> I'm currently at ELC and then on vacation so I don't have access to any
>>> of the machines currently
> -Original Message-
> From: Igor Druzhinin [mailto:igor.druzhi...@citrix.com]
> Sent: 09 March 2017 19:42
> To: net...@vger.kernel.org; xen-de...@lists.xenproject.org
> Cc: Paul Durrant ; jgr...@suse.com; Wei Liu
> ; Igor Druzhinin
> Subject: [PATCH net v3] xen-netback: fix race condition
flight 106573 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106573/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 1 build-check(1) blocked n/a
build-arm64 5 xen
On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier wrote:
> Each processor holds a GDT in its per-cpu structure. The sgdt
> instruction gives the base address of the current GDT. This address can
> be used to bypass KASLR memory randomization. With another bug, an
> attacker could target other per-cpu
On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier wrote:
> This patch makes the GDT remapped pages read-only to prevent corruption.
> This change is done only on 64-bit.
>
> The native_load_tr_desc function was adapted to correctly handle a
> read-only GDT. The LTR instruction always writes to the GD
On 09/03/2017 21:32, Andy Lutomirski wrote:
> On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier wrote:
>
>> --- a/arch/x86/xen/enlighten.c
>> +++ b/arch/x86/xen/enlighten.c
>> @@ -710,7 +710,7 @@ static void load_TLS_descriptor(struct thread_struct *t,
>>
>> *shadow = t->tls_array[i];
>>
>> -
On Thu, Mar 9, 2017 at 1:43 PM, Andrew Cooper wrote:
> On 09/03/2017 21:32, Andy Lutomirski wrote:
>> On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier wrote:
>>
>>> --- a/arch/x86/xen/enlighten.c
>>> +++ b/arch/x86/xen/enlighten.c
>>> @@ -710,7 +710,7 @@ static void load_TLS_descriptor(struct threa
On Thu, Mar 9, 2017 at 1:46 PM, Andy Lutomirski wrote:
> On Thu, Mar 9, 2017 at 1:43 PM, Andrew Cooper
> wrote:
>> On 09/03/2017 21:32, Andy Lutomirski wrote:
>>> On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier wrote:
>>>
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
>>
On 03/09/2017 04:54 PM, Thomas Garnier wrote:
> On Thu, Mar 9, 2017 at 1:46 PM, Andy Lutomirski wrote:
>> On Thu, Mar 9, 2017 at 1:43 PM, Andrew Cooper
>> wrote:
>>> On 09/03/2017 21:32, Andy Lutomirski wrote:
On Mon, Mar 6, 2017 at 2:03 PM, Thomas Garnier wrote:
> --- a/arch/x86/
>> I don't have any experience with Xen so it would be great if virtme can test
>> it.
>
> I am pretty sure I tested this series at some point but I'll test it again.
>
Fails 32-bit build:
/home/build/linux-boris/arch/x86/kvm/vmx.c: In function ‘segment_base’:
/home/build/linux-boris/arch/x86
> > All worked fine.
>
>
>
> >
> > konrad-Super-Server login: [ 188.181526] reboot: Restarting system
> > (XEN) Hardware Dom0 shutdown: rebooting machine
> > (XEN) APIC error on CPU0: 40(00)
> >
> > ... reboot.
>
> So as I've mentioned you have to run 'xl info' and look at nr_cpus to
> see t
On Thu, Mar 9, 2017 at 2:13 PM, Boris Ostrovsky
wrote:
>
>>> I don't have any experience with Xen so it would be great if virtme can
>>> test it.
>>
>> I am pretty sure I tested this series at some point but I'll test it again.
>>
>
>
> Fails 32-bit build:
>
>
> /home/build/linux-boris/arch/x86/k
flight 106565 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106565/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm5 xen-buildfail REGR. vs. 106534
build-amd64-oldker
On 03/09/2017 05:31 PM, Thomas Garnier wrote:
> On Thu, Mar 9, 2017 at 2:13 PM, Boris Ostrovsky
> wrote:
I don't have any experience with Xen so it would be great if virtme can
test it.
>>> I am pretty sure I tested this series at some point but I'll test it again.
>>>
>>
>> Fails 32-bi
Hi Igor,
[auto build test WARNING on net/master]
url:
https://github.com/0day-ci/linux/commits/Igor-Druzhinin/xen-netback-fix-race-condition-on-XenBus-disconnect/20170310-055447
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_END
On 10/03/17 02:13, Valtteri Kiviniemi wrote:
> Hi,
>
> Yesterday I decided to upgrade my Xen version from 4.6.0 to 4.8.0. I
> compiled it from source and at the same time I compiled the latest Linux
> kernel (4.10.1).
>
> When rebooting I decided to try if dom0 PVH would work (with previous
> Xen
On 10/03/2017 00:09, Steven Haigh wrote:
> On 10/03/17 02:13, Valtteri Kiviniemi wrote:
>> Hi,
>>
>> Yesterday I decided to upgrade my Xen version from 4.6.0 to 4.8.0. I
>> compiled it from source and at the same time I compiled the latest Linux
>> kernel (4.10.1).
>>
>> When rebooting I decided to
On Thu, Mar 09, 2017 at 01:26:45PM +, Julien Grall wrote:
> Hi Konrad,
>
> On 09/03/17 11:17, Konrad Rzeszutek Wilk wrote:
> > On Thu, Mar 09, 2017 at 11:59:51AM +0900, Roger Pau Monné wrote:
> > > On Wed, Mar 08, 2017 at 02:12:09PM -0500, Konrad Rzeszutek Wilk wrote:
> > > > On Wed, Mar 08, 2
On 03/09/2017 07:19 PM, Andrew Cooper wrote:
On 10/03/2017 00:09, Steven Haigh wrote:
On 10/03/17 02:13, Valtteri Kiviniemi wrote:
Hi,
Yesterday I decided to upgrade my Xen version from 4.6.0 to 4.8.0. I
compiled it from source and at the same time I compiled the latest Linux
kernel (4.10.1)
On 17-03-08 07:56:54, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49, wrote:
[...]
> > -static int psr_cpu_prepare(unsigned int cpu)
> > +static void cpu_init_work(void)
> > +{
> > +struct psr_socket_info *info;
> > +unsigned int socket;
> > +unsigned int cpu = smp_processor_id();
> >
On 17-03-08 08:15:33, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49, wrote:
> > --- a/xen/arch/x86/psr.c
> > +++ b/xen/arch/x86/psr.c
> > @@ -84,6 +84,7 @@ enum psr_feat_type {
> > PSR_SOCKET_L3_CAT = 0,
> > PSR_SOCKET_L3_CDP,
> > PSR_SOCKET_L2_CAT,
> > +PSR_SOCKET_UNKNOWN = 0xF
On 17-03-08 08:35:53, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49, wrote:
> > @@ -260,9 +263,22 @@ static bool l3_cat_get_feat_info(const struct
> > feat_node *feat,
> > return true;
> > }
> >
> > +static bool l3_cat_get_val(const struct feat_node *feat, unsigned int cos,
> > +
On 17-03-08 09:07:10, Jan Beulich wrote:
> >>> On 15.02.17 at 09:49, wrote:
> > As set value flow is the most complicated one in psr, it will be
> > divided to some patches to make things clearer. This patch
> > implements the set value framework to show a whole picture firstly.
> >
> > It also c
The layout of the structures make them already aligned, there's no need for the
packed attributes.
Signed-off-by: Roger Pau Monné
---
Cc: Tim Deegan
Cc: Ian Jackson
Cc: Wei Liu
---
tools/debugger/kdd/kdd.h | 44 +---
1 file changed, 21 insertions(+), 23
On Thu, Mar 09, 2017 at 05:13:38PM +0200, Valtteri Kiviniemi wrote:
> Hi,
>
> Yesterday I decided to upgrade my Xen version from 4.6.0 to 4.8.0. I
> compiled it from source and at the same time I compiled the latest Linux
> kernel (4.10.1).
>
> When rebooting I decided to try if dom0 PVH would wo
flight 106570 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/106570/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvops 3 host-install(3) broken in 106563 REGR. vs. 59254
test-amd64-amd64-xl
1 - 100 of 115 matches
Mail list logo
