On May 04, 2016 9:49 PM, George Dunlap wrote:
> On Fri, Apr 29, 2016 at 10:25 AM, Quan Xu wrote:
> > When IOMMU mapping is failed, we issue a best effort rollback,
> > stopping IOMMU mapping, unmapping the previous IOMMU maps and
> then
> > reporting the error up to the call trees. When rollback
flight 93512 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93512/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-amd64-xl-qemuu-ov
The pvusb request structure contains the transfer_flags member which
is missing definitions of it's semantics.
Add the definition of the USBIF_SHORT_NOT_OK flag.
Signed-off-by: Juergen Gross
---
Please consider taking this patch for 4.7 release. I believe this is the
last bit missing for support
On 2016-05-05 12:32, Steven Haigh wrote:
Overview
If you're using iSCSI, you can mount a target by multiple Dom0
machines on the same target. For non-cluster aware filesystems, this
can lead to disk corruption and general bad times by all. The iSCSI
protocol allows the use of persistent reservat
flight 93503 linux-3.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93503/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-amd64-rumpuserxen 6 xen-buildfail like 92198
build-i386-rumpuserxen6
flight 93496 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93496/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
build-i386-rumpuserxen6 xen-buildfail like 93408
build-amd64-rumpuserxen
Hi,
I'm going to create a domU for XEN on ARM64. I'm following [1] to cross
compile the xen tools and [2] to create domU. One thing different is
that I'm using Build_AEMv8A-AEMv8A fastmodel.
After executing "/etc/init.d/xencommons start", xl list shows:
Name ID Mem VCPUs State Tim
Overview
If you're using iSCSI, you can mount a target by multiple Dom0 machines
on the same target. For non-cluster aware filesystems, this can lead to
disk corruption and general bad times by all. The iSCSI protocol allows
the use of persistent reservations as per the SCSI disk spec. Low lev
flight 93497 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93497/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-amd64-xl-qemuu-ov
On May 04, 2016 9:44 PM, Jan Beulich wrote:
> >>> On 04.05.16 at 13:49, wrote:
> > On May 04, 2016 9:29 AM, Tian, Kevin wrote:
> >> > From: Quan Xu
> >> > Sent: Friday, April 29, 2016 5:25 PM
> >> >
> >> > Treat IOMMU mapping and unmapping failures as a fatal to the domain
> >> > (with the excep
On Fri, Apr 29, 2016 at 10:13:42AM +0100, Wei Liu wrote:
> On Fri, Apr 29, 2016 at 09:21:39AM +0800, Shuai Ruan wrote:
> > On Mon, Apr 25, 2016 at 01:07:54AM -0600, Jan Beulich wrote:
> > > Commit 4d27280572 ("x86/xsaves: fix overwriting between non-lazy/lazy
> > > xsaves") switched to always savin
On 2016-05-04 20:50, Roger Pau Monné wrote:
On Wed, May 04, 2016 at 08:18:18PM +1000, Steven Haigh wrote:
On 4/05/2016 7:37 PM, Roger Pau Monné wrote:
> On Wed, May 04, 2016 at 06:41:26PM +1000, Steven Haigh wrote:
>> On 4/05/2016 5:34 PM, Roger Pau Monné wrote:
>>> On Wed, May 04, 2016 at 03:06
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Wednesday, May 04, 2016 5:29 PM
>
> >>> On 04.05.16 at 11:13, wrote:
> > On May 04, 2016 4:41 PM, Jan Beulich wrote:
> >> >>> On 04.05.16 at 03:45, wrote:
> >> >> From: Xu, Quan
> >> >> Sent: Friday, April 29, 2016 5:25 PM
> >> >> --- a/xe
Sector-based blk_aio_readv() and blk_aio_writev() should die; switch
to byte-based blk_aio_preadv() and blk_aio_pwritev() instead.
Signed-off-by: Eric Blake
---
hw/block/xen_disk.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/hw/block/xen_disk.c b/hw/block/xen_d
On Wed, May 4, 2016 at 2:08 PM, Konrad Rzeszutek Wilk
wrote:
>> +/*
>> ++ * Local variables:
>> ++ * mode: C
>> ++ * c-file-style: "BSD"
>> ++ * c-basic-offset: 4
>> ++ * tab-width: 4
>> ++ * indent-tabs-mode: nil
>> ++ * End:
>> ++ */
>
> ++ ?
>
> Why the extra + ?
Will fix.
Thanks,
Tamas
On 05/04/2016 08:41 AM, osstest service owner wrote:
> flight 93436 libvirt real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/93436/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-libvirt-qemuu-deb
flight 93480 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93480/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-amd64-xl-qemuu-ov
flight 93458 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93458/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 3 host-install(3) broken REGR. vs. 93408
test-armhf-armhf-xl-
> +/*
> ++ * Local variables:
> ++ * mode: C
> ++ * c-file-style: "BSD"
> ++ * c-basic-offset: 4
> ++ * tab-width: 4
> ++ * indent-tabs-mode: nil
> ++ * End:
> ++ */
++ ?
Why the extra + ?
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists
On Thu, Apr 28, 2016 at 06:02:54PM +0100, Ian Jackson wrote:
> Wei Liu writes ("Re: [Xen-devel] [PATCH] Fix cpumap setting before passing to
> XEN"):
> > So what is the conclusion of this discussion so far? I admit I'm a bit
> > lost here.
>
> Undoubtedly:
>
> * That "xm ..." generates the repor
On Wed, May 04, 2016 at 02:44:56PM -0500, Doug Goldstein wrote:
> On 5/4/16 12:20 PM, Daniel De Graaf wrote:
> > Reported-by: Doug Goldstein
> > Signed-off-by: Daniel De Graaf
> > ---
> > tools/flask/policy/policy/modules/xen/xen.te | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> >
On 5/4/16 12:20 PM, Daniel De Graaf wrote:
> Reported-by: Doug Goldstein
> Signed-off-by: Daniel De Graaf
> ---
> tools/flask/policy/policy/modules/xen/xen.te | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/tools/flask/policy/policy/modules/xen/xen.te
> b/tools/flask/polic
On 5/4/16 2:39 PM, Konrad Rzeszutek Wilk wrote:
>>
>> Well it turns out yes I was using a bad policy. I grabbed the policy
>> updates from master and not from 4.7.0-rc1 when I merged them with my
>> policy. So yes the above are incorrect and noise on my part. master
>> wasn't (and still isn't) at t
>
> Well it turns out yes I was using a bad policy. I grabbed the policy
> updates from master and not from 4.7.0-rc1 when I merged them with my
> policy. So yes the above are incorrect and noise on my part. master
> wasn't (and still isn't) at the same point that 4.7.0-rc1 was at.
>
> >
> >> (X
On 5/4/16 12:20 PM, Daniel De Graaf wrote:
> On 05/04/2016 09:52 AM, Doug Goldstein wrote:
>> Hi all,
>>
>> Sometime after d4cd5a205973171475b8c63bc250c2803e0f51fa, I get the
>> following denials for any domU that attempts to run "xl". In my
>> situation my domU needs to run "xl devd" because its a
On Wed, May 04, 2016 at 01:20:46PM -0400, Daniel De Graaf wrote:
> Reported-by: Doug Goldstein
> Signed-off-by: Daniel De Graaf
Wait, why don't we give Doug a chance to respond about the
policy he is using. I am really not sure how we would deny
permission to these using the default policy.
Dou
flight 93482 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93482/
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
On May 4, 2016 11:34, "Wei Liu" wrote:
>
> On Wed, May 04, 2016 at 11:16:24AM -0600, Tamas K Lengyel wrote:
> > On May 4, 2016 09:35, "Jan Beulich" wrote:
> > >
> > > >>> On 04.05.16 at 16:51, wrote:
> > > > --- a/tools/tests/xen-access/xen-access.c
> > > > +++ b/tools/tests/xen-access/xen-acces
>
>> --- a/xen/include/asm-x86/domain.h
>> +++ b/xen/include/asm-x86/domain.h
>> @@ -401,12 +401,12 @@ struct arch_domain
>> unsigned int write_ctrlreg_enabled : 4;
>> unsigned int write_ctrlreg_sync : 4;
>> unsigned int write_ctrlreg_onchangeonly : 4;
>>
flight 93471 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93471/
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
On 04/05/16 18:21, Dario Faggioli wrote:
> On Wed, 2016-05-04 at 18:05 +0100, George Dunlap wrote:
>> On 04/05/16 16:58, Dario Faggioli wrote:
>>> On Wed, 2016-05-04 at 16:11 +0100, George Dunlap wrote:
>>> There are quite a few other similar cases all around scheduling
>>> code.
>>> Some of them h
On Wed, May 04, 2016 at 11:16:24AM -0600, Tamas K Lengyel wrote:
> On May 4, 2016 09:35, "Jan Beulich" wrote:
> >
> > >>> On 04.05.16 at 16:51, wrote:
> > > --- a/tools/tests/xen-access/xen-access.c
> > > +++ b/tools/tests/xen-access/xen-access.c
> > > @@ -1,4 +1,3 @@
> > > -/*
This line -- you
Just re-submitted via `git send-email` ... hopefully the formatting is to your
liking. Please let me know otherwise.
-Paul
-Original Message-
From: Wei Liu [mailto:wei.l...@citrix.com]
Sent: Wednesday, May 4, 2016 9:18 AM
To: Lai, Paul C
Cc: Wei Liu ; xen-de...@lists.xenproject.org
Su
During the make world, git mini-os.git didn't honor the 'configure
--enable-githttp' option. The 'enable-githttp' was only honored in
the tools subdirectory.
Signed-off-by: Paul Lai
---
config/Toplevel.mk.in | 1 +
configure | 27 +++
configure.ac |
On Wed, 2016-05-04 at 18:05 +0100, George Dunlap wrote:
> On 04/05/16 16:58, Dario Faggioli wrote:
> > On Wed, 2016-05-04 at 16:11 +0100, George Dunlap wrote:
> > There are quite a few other similar cases all around scheduling
> > code.
> > Some of them have comments, none has ASSERT()-s, and I thi
Reported-by: Doug Goldstein
Signed-off-by: Daniel De Graaf
---
tools/flask/policy/policy/modules/xen/xen.te | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te
b/tools/flask/policy/policy/modules/xen/xen.te
index bef33b0..fed09a9 100644
-
On 05/04/2016 09:52 AM, Doug Goldstein wrote:
Hi all,
Sometime after d4cd5a205973171475b8c63bc250c2803e0f51fa, I get the
following denials for any domU that attempts to run "xl". In my
situation my domU needs to run "xl devd" because its a driver domain.
(XEN) avc: denied { xen_extraversion }
On May 4, 2016 09:35, "Jan Beulich" wrote:
>
> >>> On 04.05.16 at 16:51, wrote:
> > --- a/tools/tests/xen-access/xen-access.c
> > +++ b/tools/tests/xen-access/xen-access.c
> > @@ -1,4 +1,3 @@
> > -/*
> > * xen-access.c
> > *
> > * Exercises the basic per-page access mechanisms
>
> Are you s
flight 93462 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93462/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 65543
test-amd64-amd64-xl-qemuu-ov
On 04/05/16 16:58, Dario Faggioli wrote:
> On Wed, 2016-05-04 at 16:11 +0100, George Dunlap wrote:
>> On 03/05/16 22:46, Dario Faggioli wrote:
>>>
>>> In fact, interrupts are already disabled when calling
>>> the hook from schedule_cpu_switch(), and hence using
>>> anything different than just spin
On Wed, May 04, 2016 at 04:05:21PM +, Lai, Paul C wrote:
> Wei:
> I'm not sure what "refreshing this patch" this patch means.
>
That means to add your SoB (and go through other stuff mentioned in our
contribution guideline wiki page) and resend it to xen-devel.
> I just 'git pull origin mast
Wei:
I'm not sure what "refreshing this patch" this patch means.
I just 'git pull origin master' from origin (
http://xenbits.xen.org/git-http/xen.git ) and rebased my work branch with this
patch on it cleanly. No conflicts to resolve.
Looking to help out,
-Paul
-Original Message-
Fr
>>> On 06.04.16 at 01:38, wrote:
> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
> with vga="qxl", Xorg will segfault instantly if tried started. Multiple
> Linux distros have been tested and Xorg segfaults in all.
So I've been wanting to make an attempt to repro this, bu
On 04/05/16 17:02, Jan Beulich wrote:
On 06.04.16 at 01:38, wrote:
>> I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
>> with vga="qxl", Xorg will segfault instantly if tried started. Multiple
>> Linux distros have been tested and Xorg segfaults in all.
> So I've been w
On Wed, May 04, 2016 at 10:02:07AM -0600, Jan Beulich wrote:
> >>> On 06.04.16 at 01:38, wrote:
> > I'm running Xen 4.6.1 with Alpine Linux 3.3.3 in dom0. In a HVM domU
> > with vga="qxl", Xorg will segfault instantly if tried started. Multiple
> > Linux distros have been tested and Xorg segfaul
On Tue, May 03, 2016 at 11:46:27PM +0200, Dario Faggioli wrote:
> Hi,
>
> This small series contains some bugfixes for various schedulers. They're all
> bugfixes, so I think all should be considered for 4.7. Here's some more
> detailed analysis.
>
> Patch 1 and 3 are for Credit2. Patch 1 is a lot
On Wed, 2016-05-04 at 16:11 +0100, George Dunlap wrote:
> On 03/05/16 22:46, Dario Faggioli wrote:
> >
> > In fact, interrupts are already disabled when calling
> > the hook from schedule_cpu_switch(), and hence using
> > anything different than just spin_lock() is wrong (and
> > ASSERT()-s in deb
On Wed, May 04, 2016 at 04:26:31PM +0100, Wei Liu wrote:
> On Tue, May 03, 2016 at 09:37:01AM -0400, Konrad Rzeszutek Wilk wrote:
> > On Tue, May 03, 2016 at 02:29:20PM +0100, Wei Liu wrote:
> > > On Tue, May 03, 2016 at 09:27:23AM -0400, Konrad Rzeszutek Wilk wrote:
> > > > On Tue, May 03, 2016 at
On Wed, May 4, 2016 at 11:51 AM, George Dunlap wrote:
> On 03/05/16 22:46, Dario Faggioli wrote:
>> The scheduling hooks API is now used properly, and no
>> initialization or de-initialization happen in
>> alloc/free_pdata any longer.
>>
>> In fact, just like it is for Credit2, there is no real
>>
On 03/05/16 22:46, Dario Faggioli wrote:
> Hi,
>
> This small series contains some bugfixes for various schedulers. They're all
> bugfixes, so I think all should be considered for 4.7. Here's some more
> detailed analysis.
>
> Patch 1 and 3 are for Credit2. Patch 1 is a lot more important, as we
For the record this is caused by a bug in Linux kernel, not a bug in
Xen.
Jan wrote a patch for it:
[PATCH] xen: fix ring resize of /dev/evtchn
And David has submitted a pull request for Linux 4.6-rc6 which includes
that patch.
Thanks everyone.
Wei.
___
On 03/05/16 22:46, Dario Faggioli wrote:
> The scheduling hooks API is now used properly, and no
> initialization or de-initialization happen in
> alloc/free_pdata any longer.
>
> In fact, just like it is for Credit2, there is no real
> need for implementing alloc_pdata and free_pdata.
>
> This a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.6-rc6-tag
xen: regression fixes for 4.6-rc6
- - Fix two regressions causing crashes in 32-bit PV guests.
- - Fix a regression in the
>>> On 04.05.16 at 17:34, wrote:
> On 04/05/16 14:30, David Vrabel wrote:
>> On 04/05/16 14:02, Jan Beulich wrote:
>>> The copying of ring data was wrong for two cases: For a full ring
>>> nothing got copied at all (as in that case the canonicalized producer
>>> and consumer indexes are identical)
On 03/05/16 22:46, Dario Faggioli wrote:
> All calculations that involve load_last_update uses quantities
> shifted by LOADAVG_GRANULARITY_SHIFT, so make sure that this
> is true even when the field is assigned a value for the first
> time, during vcpu allocation.
>
> Also, during migration, while
On 04/05/16 14:30, David Vrabel wrote:
> On 04/05/16 14:02, Jan Beulich wrote:
>> The copying of ring data was wrong for two cases: For a full ring
>> nothing got copied at all (as in that case the canonicalized producer
>> and consumer indexes are identical). And in case one or both of the
>> cano
>>> On 04.05.16 at 16:51, wrote:
> --- a/tools/tests/xen-access/xen-access.c
> +++ b/tools/tests/xen-access/xen-access.c
> @@ -1,4 +1,3 @@
> -/*
> * xen-access.c
> *
> * Exercises the basic per-page access mechanisms
Are you saying this still builds with such a change?
Jan
__
On Wed, May 04, 2016 at 03:05:38PM +0100, Wei Liu wrote:
> CC Konrad and Ross
>
> On Wed, May 04, 2016 at 08:52:24AM -0500, Doug Goldstein wrote:
> > Hi all,
> >
> > Sometime after d4cd5a205973171475b8c63bc250c2803e0f51fa, I get the
> > following denials for any domU that attempts to run "xl". In
On Wed, May 04, 2016 at 12:25:52PM +0100, Wei Liu wrote:
> On Tue, May 03, 2016 at 04:59:49PM +0100, Anthony PERARD wrote:
> > From systemd change log, since version 209, libsystemd.so contain
> > everything, including libsystemd-daemon.so. Distro may, or may not provide
> > the compatibility libra
On Tue, May 03, 2016 at 09:37:01AM -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, May 03, 2016 at 02:29:20PM +0100, Wei Liu wrote:
> > On Tue, May 03, 2016 at 09:27:23AM -0400, Konrad Rzeszutek Wilk wrote:
> > > On Tue, May 03, 2016 at 12:55:07PM +0200, Roger Pau Monne wrote:
> > > > Avoid using sys
On 03/05/16 22:46, Dario Faggioli wrote:
> commit 64269d9365 "sched: implement .init_pdata in Credit,
> Credit2 and RTDS" helped fixing Credit2 runqueues, and
> the races we had in switching scheduler for pCPUs, but
> introduced another issue. In fact, if CPU bringup fails
> during __cpu_up() (and,
On 03/05/16 22:46, Dario Faggioli wrote:
> In fact, interrupts are already disabled when calling
> the hook from schedule_cpu_switch(), and hence using
> anything different than just spin_lock() is wrong (and
> ASSERT()-s in debug builds) or unnecessary.
>
> Signed-off-by: Dario Faggioli
Good ca
On May 04, 2016 9:52 PM, Jan Beulich wrote:
> >>> On 04.05.16 at 14:09, wrote:
> > On May 04, 2016 9:26 AM, Tian, Kevin wrote:
> >> > From: Xu, Quan
> >> > Sent: Friday, April 29, 2016 5:25 PM static void
> >> > intel_iommu_iotlb_flush(struct domain *d, unsigned long gfn,
> >> > unsigned int
>
Add support for monitoring ARM SMC events. This patch only adds the required
bits to enable/disable monitoring and forwarding the event through vm_event.
Signed-off-by: Tamas K Lengyel
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Razvan Cojocaru
v3: Split parts off as separate patches
Add support for getting/setting registers through vm_event on ARM.
Signed-off-by: Tamas K Lengyel
---
Cc: Stefano Stabellini
Cc: Julien Grall
Cc: Razvan Cojocaru
---
xen/arch/arm/Makefile | 1 +
xen/arch/arm/vm_event.c| 141 +
xen/inc
The prototype of vm_event_fill_regs will differ on x86 and ARM so in this patch
we move components from common to arch-specific that use this function. As
part of this patch we rename and relocate vm_event_monitor_guest_request as
monitor_guest_request from vm_event to monitor.
Signed-off-by: Tama
Since in-guest debug exceptions are now unconditionally trapped to Xen, adding
a hook for vm_event subscribers to tap into this new always-on guest event. We
rename along the way hvm_event_breakpoint_type to hvm_event_type to better
match the various events that can be passed with it. We also intro
These are the user-space components for the new ARM SMC events.
Signed-off-by: Tamas K Lengyel
Acked-by: Wei Liu
---
Cc: Ian Jackson
---
tools/libxc/include/xenctrl.h | 2 ++
tools/libxc/xc_monitor.c | 24
2 files changed, 26 insertions(+)
diff --git a/tools/lib
Add headers to the covered list.
Signed-off-by: Tamas K Lengyel
Acked-by: Jan Beulich
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
MAINTAINERS | 12 ++--
1 file changed, 6 insertions(+), 6
Mechanical renaming to better describe that the code in hvm/event is part of
the monitor subsystem.
Signed-off-by: Tamas K Lengyel
Acked-by: Kevin Tian
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Razvan Cojocaru
Cc: Jun Nakajima
---
xen/arch/x86/hvm/Makefile | 2 +-
xen/
Signed-off-by: Tamas K Lengyel
---
Cc: Razvan Cojocaru
Cc: Ian Jackson
Cc: Wei Liu
---
tools/tests/xen-access/xen-access.c | 32 ++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/tools/tests/xen-access/xen-access.c
b/tools/tests/xen-access/xen-acc
The monitor_get_capabilities check actually belongs to the monitor subsystem so
relocating and renaming it to sanitize the code's name and location. Mechanical
patch, no code changes introduced.
Signed-off-by: Tamas K Lengyel
Acked-by: Andrew Cooper
Acked-by: Razvan Cojocaru
---
Jan Beulich
St
>>> On 29.04.16 at 08:03, wrote:
> --- a/xen/arch/x86/monitor.c
> +++ b/xen/arch/x86/monitor.c
> @@ -22,6 +22,104 @@
> #include
> #include
>
> +int arch_monitor_init_domain(struct domain *d)
> +{
> +if ( !d->arch.monitor_msr_bitmap )
> +d->arch.monitor_msr_bitmap = xzalloc(struct
On Wed, May 04, 2016 at 04:13:48PM +0200, Olaf Hering wrote:
> On Wed, May 04, Wei Liu wrote:
>
> > Are these gnutls.git commits?
>
> Its from qemu.git, after all its a bug in qemu.
>
Oh, right. That makes sense!
In that case I can just use those commits. This is very useful
information. Thank
On Wed, May 04, Wei Liu wrote:
> Are these gnutls.git commits?
Its from qemu.git, after all its a bug in qemu.
Olaf
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Wed, May 04, 2016 at 04:03:57PM +0200, Olaf Hering wrote:
> On Wed, May 04, Wei Liu wrote:
>
> > I will go check the gnutls repo and update this patch accordingly. In
> > the meantime I will wait for comment on the priority list. If you know
> > any documents please let me know.
>
> I cant hel
On Wed, May 4, 2016 at 8:03 AM, Julien Grall wrote:
>
>
> On 04/05/2016 14:30, Razvan Cojocaru wrote:
>>
>> On 05/04/2016 04:26 PM, Julien Grall wrote:
>>>
>>> I may misunderstand some parts of the vm event subsystem. To get/set the
>>> full set of registers, the user will have to use the
>>> DOMC
CC Konrad and Ross
On Wed, May 04, 2016 at 08:52:24AM -0500, Doug Goldstein wrote:
> Hi all,
>
> Sometime after d4cd5a205973171475b8c63bc250c2803e0f51fa, I get the
> following denials for any domU that attempts to run "xl". In my
> situation my domU needs to run "xl devd" because its a driver dom
On Wed, May 04, Wei Liu wrote:
> I will go check the gnutls repo and update this patch accordingly. In
> the meantime I will wait for comment on the priority list. If you know
> any documents please let me know.
I cant help with that.
My xen.rpm carries upstream commits
f40d55081667a716312b9a8b6
On 04/05/2016 14:30, Razvan Cojocaru wrote:
On 05/04/2016 04:26 PM, Julien Grall wrote:
I may misunderstand some parts of the vm event subsystem. To get/set the
full set of registers, the user will have to use the
DOMCTL_{set,get}vcpucontext, correct? So why does Xen expose a part of
the vCPU
On 5/4/16 8:58 AM, Jan Beulich wrote:
On 04.05.16 at 15:52, wrote:
>> Hi all,
>>
>> Sometime after d4cd5a205973171475b8c63bc250c2803e0f51fa, I get the
>> following denials for any domU that attempts to run "xl". In my
>> situation my domU needs to run "xl devd" because its a driver domain.
>>
>>> On 04.05.16 at 15:52, wrote:
> Hi all,
>
> Sometime after d4cd5a205973171475b8c63bc250c2803e0f51fa, I get the
> following denials for any domU that attempts to run "xl". In my
> situation my domU needs to run "xl devd" because its a driver domain.
>
> (XEN) avc: denied { xen_extraversion }
On Wed, May 04, 2016 at 03:38:01PM +0200, Olaf Hering wrote:
> On Wed, May 04, Wei Liu wrote:
>
> > Do you have a link to the NEWS file so that I can read and put it into
> > the commit message? https://www.gnutls.org/news.html doesn't seem to
> > cover release that old.
>
> I cloned their git t
Hi all,
Sometime after d4cd5a205973171475b8c63bc250c2803e0f51fa, I get the
following denials for any domU that attempts to run "xl". In my
situation my domU needs to run "xl devd" because its a driver domain.
(XEN) avc: denied { xen_extraversion } for domid=1
scontext=system_u:system_r:domU_t t
flight 93460 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/93460/
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
>>> On 04.05.16 at 14:09, wrote:
> On May 04, 2016 9:26 AM, Tian, Kevin wrote:
>> > From: Xu, Quan
>> > Sent: Friday, April 29, 2016 5:25 PM
>> > static void intel_iommu_iotlb_flush(struct domain *d, unsigned long
>> > gfn, unsigned int
>> > page_count)
>>
>> could we remove "Intel_" prefix com
On Fri, Apr 29, 2016 at 10:25 AM, Quan Xu wrote:
> When IOMMU mapping is failed, we issue a best effort rollback, stopping
> IOMMU mapping, unmapping the previous IOMMU maps and then reporting the
> error up to the call trees. When rollback is not feasible (in early
> initialization phase or trade
>>> On 04.05.16 at 13:49, wrote:
> On May 04, 2016 9:29 AM, Tian, Kevin wrote:
>> > From: Quan Xu
>> > Sent: Friday, April 29, 2016 5:25 PM
>> >
>> > Treat IOMMU mapping and unmapping failures as a fatal to the domain
>> > (with the exception of the hardware domain).
>> >
>> > If IOMMU mapping an
On 04/05/16 14:38, Jan Beulich wrote:
On 04.05.16 at 15:14, wrote:
>> On 04/05/16 14:08, Jan Beulich wrote:
>>> David,
>>>
>>> in the course of putting together the fix just sent I got puzzled by the
>>> apparent raciness of the initial part of evtchn_resize_ring(). Is it
>>> intentional that
>>> On 04.05.16 at 13:32, wrote:
> But while implementing a stub that falls back to the actual LOCK CMPXCHG
> and replacing hvm_copy_to_guest_virt() with it would indeed be an
> improvement (with the added advantage of being able to treat
> non-emulated LOCK CMPXCHG cases), I don't understand how
On Wed, May 04, Wei Liu wrote:
> Do you have a link to the NEWS file so that I can read and put it into
> the commit message? https://www.gnutls.org/news.html doesn't seem to
> cover release that old.
I cloned their git tree.
git clone https://gitlab.com/gnutls/gnutls.git
Thanks anyway for mak
>>> On 04.05.16 at 15:14, wrote:
> On 04/05/16 14:08, Jan Beulich wrote:
>> David,
>>
>> in the course of putting together the fix just sent I got puzzled by the
>> apparent raciness of the initial part of evtchn_resize_ring(). Is it
>> intentional that the function relies on being implicitly ser
>>> On 04.05.16 at 12:03, wrote:
> v3 has logic intended to omit cr4 changes while in the content of 32bit
> PV guest userspace. This in turn was intended to increase performance
> by reducing the quantity of TLB flushes.
>
> Even if hardware has logic to speed up CR4 writes when following reads
On 04/05/16 14:02, Jan Beulich wrote:
> The copying of ring data was wrong for two cases: For a full ring
> nothing got copied at all (as in that case the canonicalized producer
> and consumer indexes are identical). And in case one or both of the
> canonicalized (after the resize) indexes would po
On Wed, May 04, 2016 at 03:06:04PM +0200, Olaf Hering wrote:
> On Wed, May 04, Wei Liu wrote:
>
> > gnutls_kx_set_priority, gnutls_certificate_type_set_priority and
> > gnutls_protocol_set_priority are removed in 3.4. Application should use
> > gnutls_priority_set_direct instead.
>
> > +#if defin
On 05/04/2016 04:26 PM, Julien Grall wrote:
> I may misunderstand some parts of the vm event subsystem. To get/set the
> full set of registers, the user will have to use the
> DOMCTL_{set,get}vcpucontext, correct? So why does Xen expose a part of
> the vCPU context through the vm_event?
Because DO
Hi Tamas,
I have just noticed that you use an old email address for Stefano.
Please check MAINTAINERS file for any update on email address, new
maintainers.
On 04/05/2016 13:42, Tamas K Lengyel wrote:
> On 03/05/2016 19:48, Tamas K Lengyel wrote:
>>
>>
>>
>> On Tue, May 3, 2016 at 5:31
On May 04, 2016 9:29 AM, Tian, Kevin wrote:
> > From: Quan Xu
> > Sent: Friday, April 29, 2016 5:25 PM
> >
> > Treat IOMMU mapping and unmapping failures as a fatal to the domain
> > (with the exception of the hardware domain).
> >
> > If IOMMU mapping and unmapping failed, crash the domain (with
On May 04, 2016 9:26 AM, Tian, Kevin wrote:
> > From: Xu, Quan
> > Sent: Friday, April 29, 2016 5:25 PM
> >
> > The propagation value from IOMMU flush interfaces may be positive,
> > which indicates callers need to flush cache, not one of faliures.
> >
> > when the propagation value is positive, t
On 04/05/16 14:08, Jan Beulich wrote:
> David,
>
> in the course of putting together the fix just sent I got puzzled by the
> apparent raciness of the initial part of evtchn_resize_ring(). Is it
> intentional that the function relies on being implicitly serialized via the
> bind mutex?
Yes.
Alth
1 - 100 of 161 matches
Mail list logo
