flight 121309 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121309/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf b24e99f7c4270e7c5e2df511a41ff70e46138612
baseline version:
ovmf dd190645eb43424706eb1
On Wed, Mar 28, 2018 at 09:47:40AM +0300, Oleksandr Andrushchenko wrote:
> From: Noralf Trønnes
>
> Use srcu to protect drm_device.unplugged in a race free manner.
> Drivers can use drm_dev_enter()/drm_dev_exit() to protect and mark
> sections preventing access to device resources that are not av
On Tue, Mar 27, 2018 at 11:55:37AM -0500, Doug Goldstein wrote:
> On 3/27/18 11:28 AM, Roger Pau Monné wrote:
> > On Tue, Mar 27, 2018 at 05:20:57PM +0100, Roger Pau Monné wrote:
> >> On Tue, Mar 27, 2018 at 06:18:08PM +0200, Olaf Hering wrote:
> >>> On Tue, Mar 27, Roger Pau Monne wrote:
> >>>
> >
Allow the path to be set from a configure command line option.
Signed-off-by: Roger Pau Monné
---
Cc: Ian Jackson
Cc: Wei Liu
Cc: Olaf Hering
Cc: Jan Beulich
---
Changes since v1:
- Fix the path so it's PREFRIX/lib/... instead of PREFIX/usr/lib/...
---
config/Paths.mk.in | 1 +
m4/paths.m4
On Wed, Mar 28, 2018 at 09:47:41AM +0300, Oleksandr Andrushchenko wrote:
> From: Oleksandr Andrushchenko
>
> Add support for Xen para-virtualized frontend display driver.
> Accompanying backend [1] is implemented as a user-space application
> and its helper library [2], capable of running as a We
Ping?
On Thu, Mar 22, 2018 at 09:10:03AM +, Roger Pau Monné wrote:
> On Wed, Mar 21, 2018 at 06:09:57PM +, Wei Liu wrote:
> > On Wed, Mar 21, 2018 at 02:42:10PM +, Roger Pau Monne wrote:
> > > The start_info size calculated in bootlate_hvm is wrong. It should use
> > > HVMLOADER_MODULE
On 03/28/2018 10:42 AM, Daniel Vetter wrote:
kms side looks good now too.
Reviewed-by: Daniel Vetter
Thank you
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
flight 121313 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121313/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumprun 6 rumprun-buildfail REGR. vs. 106754
build-i386-rumprun
On Tue, Mar 27, 2018 at 07:03:36PM -0700, Zhenzhong Duan wrote:
> When ALTERNATIVE_2 is used, we see below error during build.
> "error: macro "as_max" requires 2 arguments, but only 1 given"
>
> Signed-off-by: Zhenzhong Duan
Reviewed-by: Wei Liu
___
On Tue, Mar 13, 2018 at 08:14:51AM -0600, Jan Beulich wrote:
> Its as_max() invocation was wrongly parenthesized.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.o
On Tue, Mar 27, 2018 at 11:52:56PM -0600, Jan Beulich wrote:
> >>> Zhenzhong Duan 03/28/18 4:03 AM >>>
> >When ALTERNATIVE_2 is used, we see below error during build.
> >"error: macro "as_max" requires 2 arguments, but only 1 given"
> >
> >Signed-off-by: Zhenzhong Duan
>
> See "[PATCH v2 2/6] x8
On Wed, Mar 28, 2018 at 12:02:11AM -0600, Jan Beulich wrote:
> >>> Wei Liu 03/27/18 8:52 PM >>>
> >--- a/Config.mk
> >+++ b/Config.mk
> >@@ -301,8 +301,3 @@ QEMU_TRADITIONAL_LOC ?= $(call or,$(wildcard
> >$(QEMU_TRADITIONAL_INTREE)),\
> >
> >QEMU_UPSTREAM_LOC ?= $(call or,$(wildcard $(QEMU_UPSTR
flight 121308 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121308/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-pvshimbroken
test-amd64-amd64-qemuu-nested-intel 14 x
Hi,
On 27/03/18 22:06, Stefano Stabellini wrote:
> On Wed, 21 Mar 2018, Andre Przywara wrote:
>> As the enable register handlers are shared between the v2 and v3
>> emulation, their implementation goes into vgic-mmio.c, to be easily
>> referenced from the v3 emulation as well later.
>> This introd
Hi,
On 27/03/18 23:38, Stefano Stabellini wrote:
> On Wed, 21 Mar 2018, Andre Przywara wrote:
>> To find an unused virtual IRQ number Xen uses a scheme to track used
>> virtual IRQs.
>> Implement this interface in the new VGIC to make the Xen core/arch code
>> happy.
>> This is actually somewhat V
> -Original Message-
> From: Dongli Zhang [mailto:dongli.zh...@oracle.com]
> Sent: 28 March 2018 00:42
> To: xen-devel@lists.xenproject.org; linux-ker...@vger.kernel.org
> Cc: net...@vger.kernel.org; Wei Liu ; Paul Durrant
>
> Subject: [PATCH 1/1] xen-netback: process malformed sk_buff cor
Hi,
On 27/03/18 21:07, Stefano Stabellini wrote:
> On Wed, 21 Mar 2018, Andre Przywara wrote:
>> Add an MMIO handling framework to the VGIC emulation:
>> Each register is described by its offset, size (or number of bits per
>> IRQ, if applicable) and the read/write handler functions. We provide
>>
On Wed, Mar 28, 2018 at 01:37:29AM +1000, Alexey G wrote:
> On Tue, 27 Mar 2018 09:45:30 +0100
> Roger Pau Monné wrote:
>
> >On Tue, Mar 27, 2018 at 05:42:11AM +1000, Alexey G wrote:
> >> On Mon, 26 Mar 2018 10:24:38 +0100
> >> Roger Pau Monné wrote:
> >>
> >> >On Sat, Mar 24, 2018 at 08:32:4
Correct wrong entry in MAINTAINERS file.
Signed-off-by: Juergen Gross
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index eace09ed22..bb049c8664 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -416,7 +416,7 @@ F: xen/arch/*/vm_event.
On 03/28/2018 12:51 PM, Juergen Gross wrote:
> Correct wrong entry in MAINTAINERS file.
>
> Signed-off-by: Juergen Gross
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index eace09ed22..bb049c8664 100644
> --- a/MAINTAINE
> -Original Message-
> >IMO a single entity should be in control of the memory layout, and
> >that's the toolstack.
> >
> >Ideally we should not allow the firmware to change the layout at all.
>
> This approach is terribly wrong, I don't know why opinions like this
> so common at Citrix. T
flight 121310 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121310/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 121283
test-armhf-armhf-libvirt-xsm 14 saveresto
Hi, Daniel!
I just noticed I have missed one change in the patch:
the below must be static.
On 03/28/2018 10:42 AM, Daniel Vetter wrote:
+enum drm_mode_status display_mode_valid(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode)
+{
+ struct xen_drm_front_drm_pipel
Hi,
On 27/03/18 23:27, Stefano Stabellini wrote:
> On Wed, 21 Mar 2018, Andre Przywara wrote:
>> As this register is v2 specific, its implementation lives entirely
>> in vgic-mmio-v2.c.
>> This register allows setting the source mask of an IPI.
>>
>> This is based on Linux commit ed40213ef9b0, wri
Hi,
On 27/03/18 21:38, Stefano Stabellini wrote:
> On Wed, 21 Mar 2018, Andre Przywara wrote:
>> Those three registers are v2 emulation specific, so their implementation
>> lives entirely in vgic-mmio-v2.c. Also they are handled in one function,
>> as their implementation is pretty simple.
>> We c
Hi,
On 28/03/18 00:16, Stefano Stabellini wrote:
> On Wed, 21 Mar 2018, Andre Przywara wrote:
>> This patch allocates and initializes the data structures used to model
>> the vgic distributor and virtual cpu interfaces. At that stage the
>> number of IRQs and number of virtual CPUs is frozen.
>> I
On Wed, Mar 21, 2018 at 01:53:37PM -0400, Boris Ostrovsky wrote:
> (As a side note, dom->num_modules is meaningless for HVM guests here ---
> we only add one module, the FW blob.)
>
FWIW It will soon be relevant as we split ipxe from rombios.
Wei.
___
flight 121326 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121326/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 73a10cb91a4e5c6f7049a78a12dcdea3460f0bd1
baseline version:
xen eabb
On Thu, Mar 22, 2018 at 09:10:03AM +, Roger Pau Monné wrote:
> On Wed, Mar 21, 2018 at 06:09:57PM +, Wei Liu wrote:
> > On Wed, Mar 21, 2018 at 02:42:10PM +, Roger Pau Monne wrote:
> > > The start_info size calculated in bootlate_hvm is wrong. It should use
> > > HVMLOADER_MODULE_MAX_CO
On Sun, Mar 25, 2018 at 3:21 PM, Doug Goldstein wrote:
> Added a Dockerfile which captures all the necessary dependencies to
> build Xen on a CentOS 6 system.
>
> Signed-off-by: Doug Goldstein
> ---
> automation/build/centos/6.dockerfile | 40
>
> 1 file cha
Wei Liu writes ("Re: [PATCH v2] libxl: allow libxl_domain_suspend to simply
suspend a domain, without saving it"):
> On Wed, Mar 14, 2018 at 03:36:08PM +0100, Marek Marczykowski-Górecki wrote:
> > When LIBXL_SUSPEND_NO_SAVE flag is set, no savefile will be written, but
> > the domain will still be
On Mon, Mar 26, 2018 at 2:56 PM, Doug Goldstein wrote:
> On 3/26/18 5:35 AM, Jan Beulich wrote:
> On 25.03.18 at 04:46, wrote:
>>> Its been officially 5+ years since Xen has moved to git so I propose we
>>> start thinking about when to retire the mercurial mirrors. At this point
>>> the last
Hi Julien,
On 03/21/2018 03:42 PM, Julien Grall wrote:
Title: Please drop the full stop.
On 03/13/2018 03:20 PM, mja...@caviumnetworks.com wrote:
...
+ struct rid_devid_map *rmap;
I am sorry but I still don't see any comment about my comment on the
previous version. For reminder:
"A
On Wed, Mar 28, 2018 at 12:08:07PM +0100, Wei Liu wrote:
> On Thu, Mar 22, 2018 at 09:10:03AM +, Roger Pau Monné wrote:
> > On Wed, Mar 21, 2018 at 06:09:57PM +, Wei Liu wrote:
> > > On Wed, Mar 21, 2018 at 02:42:10PM +, Roger Pau Monne wrote:
> > > > The start_info size calculated in b
On Wed, 28 Mar 2018 10:30:32 +0100
Roger Pau Monné wrote:
>On Wed, Mar 28, 2018 at 01:37:29AM +1000, Alexey G wrote:
>> On Tue, 27 Mar 2018 09:45:30 +0100
>> Roger Pau Monné wrote:
>>
>> >On Tue, Mar 27, 2018 at 05:42:11AM +1000, Alexey G wrote:
>> >> On Mon, 26 Mar 2018 10:24:38 +0100
>> >
If acpi_id is == nr_acpi_bits, then we access one element beyond the end
of the acpi_psd[] array or we set one bit beyond the end of the bit map
when we do __set_bit(acpi_id, acpi_id_cst_present);
Fixes: 59a568029181 ("xen/acpi-processor: C and P-state driver that uploads
said data to hypervisor.
>>> On 28.03.18 at 13:25, wrote:
> On Mon, Mar 26, 2018 at 2:56 PM, Doug Goldstein wrote:
>> On 3/26/18 5:35 AM, Jan Beulich wrote:
>> On 25.03.18 at 04:46, wrote:
Its been officially 5+ years since Xen has moved to git so I propose we
start thinking about when to retire the mercur
The start_info size calculated in bootlate_hvm is wrong. It should use
HVMLOADER_MODULE_MAX_COUNT instead of dom->num_modules and it doesn't
take into account the size of the modules command line.
This is not a problem so far because the actually used amount of
memory doesn't cross a page boundary
This will lead to writing a wrong module command line physical memory
address if no command line is actually provided.
This hasn't caused problems so far because hvmloader is the only
consumer of the modules command line, and it's unconditionally set
in that case.
Signed-off-by: Roger Pau Monné
On Wed, Mar 28, 2018 at 12:55:15PM +0100, Roger Pau Monne wrote:
> The start_info size calculated in bootlate_hvm is wrong. It should use
> HVMLOADER_MODULE_MAX_COUNT instead of dom->num_modules and it doesn't
> take into account the size of the modules command line.
>
> This is not a problem so f
On 28/03/18 13:47, Dan Carpenter wrote:
> If acpi_id is == nr_acpi_bits, then we access one element beyond the end
> of the acpi_psd[] array or we set one bit beyond the end of the bit map
> when we do __set_bit(acpi_id, acpi_id_cst_present);
>
> Fixes: 59a568029181 ("xen/acpi-processor: C and P-s
> -Original Message-
>
> I think we must all agree which approach to implement next. Basically,
> whether we need to completely discard the option #1 for this series and
> move on with #2. That lengthy requirements/risks email was an attempt to
> provide some ground for comparison.
>
> Le
flight 121311 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121311/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs.
119227
Tests w
On 03/27/2018 11:21 AM, George Dunlap wrote:
On 03/26/2018 05:43 PM, Ian Jackson wrote:
+### Network
+If QEMU runs in its own network namespace, it can't open the tap
+device itself because the interface won't be visible outside of its
+own namespace. So instead, have the toolstack open the
On 03/28/2018 12:47 PM, Dan Carpenter wrote:
> If acpi_id is == nr_acpi_bits, then we access one element beyond the end
> of the acpi_psd[] array or we set one bit beyond the end of the bit map
> when we do __set_bit(acpi_id, acpi_id_cst_present);
>
... or even acpi_id_present (which comes right a
On 03/27/2018 02:33 PM, Ian Jackson wrote:
George Dunlap writes ("Re: [PATCH] docs/qemu-deprivilege: Revise and update with
status and future plans"):
Actually I think most of the user-facing stuff already in xl.cfg is
inappropriate for that man page. It might make sense to have a separate
man
On 03/28/2018 01:28 PM, Ross Lagerwall wrote:
> On 03/27/2018 11:21 AM, George Dunlap wrote:
>> On 03/26/2018 05:43 PM, Ian Jackson wrote:
+### Network
+If QEMU runs in its own network namespace, it can't open the tap
+device itself because the interface won't be visible outside of
Hello,
According to the contribution guidelines document [0] the coverity
database of issues is private, which makes it hard for new people to
see issues. IMO it makes no sense to keep the result private anymore:
- They have been audited for plenty of time by different people
that currently h
On 03/28/2018 01:47 PM, Ross Lagerwall wrote:
> On 03/27/2018 02:33 PM, Ian Jackson wrote:
>> George Dunlap writes ("Re: [PATCH] docs/qemu-deprivilege: Revise and
>> update with status and future plans"):
>>> Actually I think most of the user-facing stuff already in xl.cfg is
>>> inappropriate for
>>> On 27.03.18 at 11:06, wrote:
> For mitigation of Meltdown the current L4 page table is copied to the
> cpu local root page table each time a 64 bit pv guest is entered.
>
> Copying can be avoided in cases where the guest L4 page table hasn't
> been modified while running the hypervisor, e.g.
On 03/28/2018 02:33 PM, Roger Pau Monné wrote:
> Hello,
>
> According to the contribution guidelines document [0] the coverity
> database of issues is private, which makes it hard for new people to
> see issues. IMO it makes no sense to keep the result private anymore:
>
> - They have been audit
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 March 2018 09:43
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org>
> Subject: Re: possible I/O emulation state machine issue
>
> >>> On 23.03.18 at 14:41, wrote:
> > So somehow it
>>> On 27.03.18 at 11:06, wrote:
> When switching to a 64-bit pv context the TLB is flushed twice today:
> the first time when switching to the new address space in
> write_ptbase(), the second time when switching to guest mode in
> restore_to_guest.
>
> Avoid the first TLB flush in that case.
T
On Wed, Mar 28, 2018 at 02:33:37PM +0100, Roger Pau Monné wrote:
> Hello,
>
> According to the contribution guidelines document [0] the coverity
> database of issues is private, which makes it hard for new people to
> see issues. IMO it makes no sense to keep the result private anymore:
>
> - Th
>>> On 27.03.18 at 11:07, wrote:
> If possible use the INVPCID instruction for flushing the TLB instead of
> toggling cr4.pge for that purpose.
>
> While at it remove the dependency on cr4.pge being required for mtrr
> loading, as this will be required later anyway.
>
> Add a command line option
On 03/28/2018 02:49 PM, Wei Liu wrote:
> On Wed, Mar 28, 2018 at 02:33:37PM +0100, Roger Pau Monné wrote:
>> Hello,
>>
>> According to the contribution guidelines document [0] the coverity
>> database of issues is private, which makes it hard for new people to
>> see issues. IMO it makes no sense t
>>> On 28.03.18 at 15:48, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 26 March 2018 09:43
>>
>> After having added I/O emulation state checks at the beginning of
>> vmx_vmexit_handler() as well as very early and very late in
>> vmx_vmenter_helper(), it was the one early in
>>
Hi,
On 27/03/18 22:14, Stefano Stabellini wrote:
> On Wed, 21 Mar 2018, Andre Przywara wrote:
>> The pending register handlers are shared between the v2 and v3
>> emulation, so their implementation goes into vgic-mmio.c, to be easily
>> referenced from the v3 emulation as well later.
>> For level
On Wed, 28 Mar 2018 10:03:29 +
Paul Durrant wrote:
>> >IMO a single entity should be in control of the memory layout, and
>> >that's the toolstack.
>> >
>> >Ideally we should not allow the firmware to change the layout at
>> >all.
>>
>> This approach is terribly wrong, I don't know why opin
flight 121314 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121314/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 118294
build-i386-pvops
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 March 2018 15:08
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org>
> Subject: RE: possible I/O emulation state machine issue
>
> >>> On 28.03.18 at 15:48, wrote:
> >> From: Jan Be
All,
this first stable release for our newest major version should go out
some time around mid of April. Please point out backport candidates
you find missing from its staging branch, but which you consider
relevant.
Jan
___
Xen-devel mailing list
Xen
On 03/22/2018 10:22 AM, Lars Kurth wrote:
> Hi all,
>
> please find attached
> a) Meeting details (just a link with timezones) – the meeting invite will
> follow when we have an agenda
>Bridge details – will be sent with the meeting invite
>I am thinking of using GotoMeeting, but want to
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 26 March 2018 12:22
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [PATCH v18 01/11] x86/hvm/ioreq: maintain an array of ioreq
> servers rather than a list
>
> >>> On 22.
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 28 March 2018 15:44
> To: 'Jan Beulich'
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v18 01/11] x86/hvm/ioreq: maintain an
flight 121329 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121329/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
>>> On 28.03.18 at 16:20, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 28 March 2018 15:08
>> To: Paul Durrant
>> Cc: Andrew Cooper ; xen-devel > de...@lists.xenproject.org>
>> Subject: RE: possible I/O emulation state machine issue
>>
>> >>> On
Hi,
On 28/03/18 01:01, Stefano Stabellini wrote:
> On Wed, 21 Mar 2018, Andre Przywara wrote:
>> The event channel IRQ has level triggered semantics, however the current
>> VGIC treats everything as edge triggered.
>> To correctly process those IRQs, we have to lower the (virtual) IRQ line
>> at s
Hi all
Rumpkernel upstream has seen few activity during the past two years.
Its toolchain has been rotting and doesn't build on stretch. Despite my
(and some other person's) attempt to fix various issues in the toolchain
and netbsd in the past 10 months, it is still not usable at this point.
I th
>>> On 28.03.18 at 15:48, wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 26 March 2018 09:43
>> To: Paul Durrant
>> Cc: Andrew Cooper ; xen-devel > de...@lists.xenproject.org>
>> Subject: Re: possible I/O emulation state machine issue
>>
>> >>> On
On Wed, Mar 28, 2018 at 08:34:14AM +0100, Roger Pau Monne wrote:
> Allow the path to be set from a configure command line option.
>
> Signed-off-by: Roger Pau Monné
I think the DEBUG_DIR?= lines in StdGNU.mk and SunOS.mk can be removed
now.
Wei.
___
On Wed, Mar 28, 2018 at 05:07:33PM +0100, Wei Liu wrote:
> On Wed, Mar 28, 2018 at 08:34:14AM +0100, Roger Pau Monne wrote:
> > Allow the path to be set from a configure command line option.
> >
> > Signed-off-by: Roger Pau Monné
>
> I think the DEBUG_DIR?= lines in StdGNU.mk and SunOS.mk can be
Wei Liu writes ("Dropping rumpkernel tests from osstest"):
> Rumpkernel upstream has seen few activity during the past two years.
> Its toolchain has been rotting and doesn't build on stretch. Despite my
> (and some other person's) attempt to fix various issues in the toolchain
> and netbsd in the
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 28 March 2018 16:59
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-devel de...@lists.xenproject.org>
> Subject: RE: possible I/O emulation state machine issue
>
> >>> On 28.03.18 at 15:48, wrote:
> >> -Origin
On 3/28/18 2:26 AM, Roger Pau Monné wrote:
> On Tue, Mar 27, 2018 at 11:55:37AM -0500, Doug Goldstein wrote:
>> On 3/27/18 11:28 AM, Roger Pau Monné wrote:
>>> On Tue, Mar 27, 2018 at 05:20:57PM +0100, Roger Pau Monné wrote:
On Tue, Mar 27, 2018 at 06:18:08PM +0200, Olaf Hering wrote:
> On
On Tue, Mar 27, 2018 at 11:26:55AM +0200, Olaf Hering wrote:
> Add an option to control when vTSC emulation will be activated for a
> domU with tsc_mode=default. Without such option each TSC access from
> domU will be emulated, which causes a significant perfomance drop for
> workloads that make us
On 28/03/18 17:22, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 28 March 2018 16:59
>> To: Paul Durrant
>> Cc: Andrew Cooper ; xen-devel > de...@lists.xenproject.org>
>> Subject: RE: possible I/O emulation state machine issue
>>
> O
On 03/28/2018 05:27 PM, Wei Liu wrote:
> On Tue, Mar 27, 2018 at 11:26:55AM +0200, Olaf Hering wrote:
>> Add an option to control when vTSC emulation will be activated for a
>> domU with tsc_mode=default. Without such option each TSC access from
>> domU will be emulated, which causes a significant
On Wed, Mar 28, 2018 at 05:49:28PM +0100, George Dunlap wrote:
> On 03/28/2018 05:27 PM, Wei Liu wrote:
> > On Tue, Mar 27, 2018 at 11:26:55AM +0200, Olaf Hering wrote:
> >> Add an option to control when vTSC emulation will be activated for a
> >> domU with tsc_mode=default. Without such option eac
On 03/28/2018 05:52 PM, Wei Liu wrote:
> On Wed, Mar 28, 2018 at 05:49:28PM +0100, George Dunlap wrote:
>> On 03/28/2018 05:27 PM, Wei Liu wrote:
>>> On Tue, Mar 27, 2018 at 11:26:55AM +0200, Olaf Hering wrote:
Add an option to control when vTSC emulation will be activated for a
domU with
On Wed, Mar 28, 2018 at 06:07:53PM +0100, George Dunlap wrote:
> On 03/28/2018 05:52 PM, Wei Liu wrote:
> > On Wed, Mar 28, 2018 at 05:49:28PM +0100, George Dunlap wrote:
> >> On 03/28/2018 05:27 PM, Wei Liu wrote:
> >>> On Tue, Mar 27, 2018 at 11:26:55AM +0200, Olaf Hering wrote:
> Add an opt
On Wed, 28 Mar 2018, George Dunlap wrote:
> On 03/28/2018 02:49 PM, Wei Liu wrote:
> > On Wed, Mar 28, 2018 at 02:33:37PM +0100, Roger Pau Monné wrote:
> >> Hello,
> >>
> >> According to the contribution guidelines document [0] the coverity
> >> database of issues is private, which makes it hard fo
On Wed, Mar 28, 2018 at 01:57:20PM +0200, Juergen Gross wrote:
> On 28/03/18 13:47, Dan Carpenter wrote:
> > If acpi_id is == nr_acpi_bits, then we access one element beyond the end
> > of the acpi_psd[] array or we set one bit beyond the end of the bit map
> > when we do __set_bit(acpi_id, acpi_id
Cc Lars
On Wed, Mar 28, 2018 at 10:15:36AM -0700, Stefano Stabellini wrote:
> On Wed, 28 Mar 2018, George Dunlap wrote:
> > On 03/28/2018 02:49 PM, Wei Liu wrote:
> > > On Wed, Mar 28, 2018 at 02:33:37PM +0100, Roger Pau Monné wrote:
> > >> Hello,
> > >>
> > >> According to the contribution guidel
On Wed, 28 Mar 2018, Andre Przywara wrote:
> Hi,
>
> On 27/03/18 22:06, Stefano Stabellini wrote:
> > On Wed, 21 Mar 2018, Andre Przywara wrote:
> >> As the enable register handlers are shared between the v2 and v3
> >> emulation, their implementation goes into vgic-mmio.c, to be easily
> >> refer
On Wed, 28 Mar 2018, Andre Przywara wrote:
> >> +static void vgic_mmio_write_sgipends(struct vcpu *vcpu,
> >> + paddr_t addr, unsigned int len,
> >> + unsigned long val)
> >> +{
> >> +uint32_t intid = VGIC_ADDR_TO_INTID(add
On Wed, 28 Mar 2018, Andre Przywara wrote:
> On 27/03/18 21:38, Stefano Stabellini wrote:
> > On Wed, 21 Mar 2018, Andre Przywara wrote:
> >> Those three registers are v2 emulation specific, so their implementation
> >> lives entirely in vgic-mmio-v2.c. Also they are handled in one function,
> >> a
On Wed, Mar 28, 2018 at 06:18:40PM +0100, Wei Liu wrote:
> Cc Lars
>
> On Wed, Mar 28, 2018 at 10:15:36AM -0700, Stefano Stabellini wrote:
> > On Wed, 28 Mar 2018, George Dunlap wrote:
> > > On 03/28/2018 02:49 PM, Wei Liu wrote:
> > > > On Wed, Mar 28, 2018 at 02:33:37PM +0100, Roger Pau Monné wr
On 03/28/2018 06:18 PM, Wei Liu wrote:
> Cc Lars
>
> On Wed, Mar 28, 2018 at 10:15:36AM -0700, Stefano Stabellini wrote:
>> On Wed, 28 Mar 2018, George Dunlap wrote:
>>> On 03/28/2018 02:49 PM, Wei Liu wrote:
On Wed, Mar 28, 2018 at 02:33:37PM +0100, Roger Pau Monné wrote:
> Hello,
>
On Wed, 28 Mar 2018, Andre Przywara wrote:
> On 28/03/18 01:01, Stefano Stabellini wrote:
> > On Wed, 21 Mar 2018, Andre Przywara wrote:
> >> The event channel IRQ has level triggered semantics, however the current
> >> VGIC treats everything as edge triggered.
> >> To correctly process those IRQs,
On Wed, 21 Mar 2018, Andre Przywara wrote:
> When a VCPU moves to another CPU, we need to adjust the target affinity
> of any hardware mapped vIRQs, to observe our "physical-follows-virtual"
> policy.
> Implement arch_move_irqs() to adjust the physical affinity of all hardware
> mapped vIRQs target
It would be nice to get it in before the code freeze
On Tue, 27 Feb 2018, Stefano Stabellini wrote:
> Add pvcalls support to libxl and xl. Create the appropriate pvcalls
> entries in xenstore.
>
> Signed-off-by: Stefano Stabellini
>
> diff --git a/docs/misc/xenstore-paths.markdown
> b/docs/mis
flight 121334 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121334/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
flight 121315 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121315/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-xsm7 xen-boot fail REGR. vs. 118324
test-amd64-i386-lib
(sorry for the formatting)
On Wed, 28 Mar 2018, 21:48 George Dunlap, wrote:
> On 03/28/2018 02:33 PM, Roger Pau Monné wrote:
> > Hello,
> >
> > According to the contribution guidelines document [0] the coverity
> > database of issues is private, which makes it hard for new people to
> > see issu
(sorry for the formatting)
On Thu, 29 Mar 2018, 01:48 Stefano Stabellini,
wrote:
> On Wed, 28 Mar 2018, Andre Przywara wrote:
> > On 28/03/18 01:01, Stefano Stabellini wrote:
> > > On Wed, 21 Mar 2018, Andre Przywara wrote:
> > >> The event channel IRQ has level triggered semantics, however the
flight 121324 rumprun real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121324/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-rumprun 6 rumprun-buildfail REGR. vs. 106754
build-i386-rumprun
flight 121318 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121318/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail in 121291 pass
in 121318
test-xtf-amd64-amd64
flight 121320 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121320/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-arm64-arm64-xl-xsm 1 build-check
The "BUG_ON(!frag_iter)" in function xenvif_rx_next_chunk() is triggered if
the received sk_buff is malformed, that is, when the sk_buff has pattern
(skb->data_len && !skb_shinfo(skb)->nr_frags). Below is a sample call
stack:
[ 438.652658] [ cut here ]
[ 438.652660] kerne
1 - 100 of 106 matches
Mail list logo
