Re: [Xen-devel] [PATCH v2 1/1] xen-netback: process malformed sk_buff correctly to avoid BUG_ON()

Hi Eric, On 03/29/2018 12:03 PM, Eric Dumazet wrote: > > > On 03/28/2018 08:51 PM, Dongli Zhang wrote: >> 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 &&

[Xen-devel] [ovmf test] 121323: regressions - FAIL

flight 121323 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/121323/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs. 121309 version targeted for

Re: [Xen-devel] [PATCH v2 1/1] xen-netback: process malformed sk_buff correctly to avoid BUG_ON()

On 03/28/2018 08:51 PM, Dongli Zhang wrote: > 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: > >... > > The

[Xen-devel] [PATCH v2 1/1] xen-netback: process malformed sk_buff correctly to avoid BUG_ON()

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]

[Xen-devel] [linux-3.18 test] 121320: tolerable FAIL - PUSHED

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

[Xen-devel] [xen-4.8-testing test] 121318: tolerable FAIL - PUSHED

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

[Xen-devel] [rumprun test] 121324: regressions - FAIL

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

Re: [Xen-devel] [PATCH v3 06/39] ARM: evtchn: Handle level triggered IRQs correctly

(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

Re: [Xen-devel] Make coverity results public

(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

[Xen-devel] [linux-linus test] 121315: regressions - FAIL

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

[Xen-devel] [xen-unstable-smoke test] 121334: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH] xl/libxl: add pvcalls support

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

Re: [Xen-devel] [PATCH v3 32/39] ARM: new VGIC: Implement arch_move_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

Re: [Xen-devel] [PATCH v3 06/39] ARM: evtchn: Handle level triggered IRQs correctly

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

Re: [Xen-devel] Make coverity results public

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, >

Re: [Xen-devel] Make coverity results public

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é

Re: [Xen-devel] [PATCH v3 18/39] ARM: new VGIC: Add CTLR, TYPER and IIDR handlers

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, > >>

Re: [Xen-devel] [PATCH v3 26/39] ARM: new VGIC: Add SGIPENDR register handlers

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 =

Re: [Xen-devel] [PATCH v3 19/39] ARM: new VGIC: Add ENABLE registers handlers

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 > >>

Re: [Xen-devel] Make coverity results public

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

Re: [Xen-devel] [PATCH] xen/acpi: off by one in read_acpi_id()

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,

Re: [Xen-devel] Make coverity results public

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

Re: [Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

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

Re: [Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

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

Re: [Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

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

Re: [Xen-devel] possible I/O emulation state machine issue

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:

Re: [Xen-devel] [PATCH v5] new config option vtsc_tolerance_khz to avoid TSC emulation

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

Re: [Xen-devel] [PATCH for-4.11] tools: set DEBUG_DIR from configure

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: >

Re: [Xen-devel] Dropping rumpkernel tests from osstest

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

Re: [Xen-devel] [PATCH v2 for-4.11] tools: set DEBUG_DIR from configure

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

Re: [Xen-devel] [PATCH v2 for-4.11] tools: set DEBUG_DIR from configure

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.

Re: [Xen-devel] possible I/O emulation state machine issue

>>> 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 >

[Xen-devel] Dropping rumpkernel tests from osstest

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

Re: [Xen-devel] [PATCH v3 06/39] ARM: evtchn: Handle level triggered IRQs correctly

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

[Xen-devel] [xen-unstable-smoke test] 121329: tolerable all pass - PUSHED

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

Re: [Xen-devel] [PATCH v18 01/11] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

> -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:

Re: [Xen-devel] [PATCH v18 01/11] x86/hvm/ioreq: maintain an array of ioreq servers rather than a list

> -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

Re: [Xen-devel] X86 Community Call - Wed Apr 11, 14:00 - 15:00 UTC - Call for Agenda Items

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

[Xen-devel] preparations for 4.10.1

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

Re: [Xen-devel] possible I/O emulation state machine issue

> -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 >

[Xen-devel] [linux-4.1 test] 121314: regressions - FAIL

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

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

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

Re: [Xen-devel] [PATCH v3 20/39] ARM: new VGIC: Add PENDING registers handlers

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

Re: [Xen-devel] possible I/O emulation state machine issue

>>> 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(),

Re: [Xen-devel] Make coverity results public

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

Re: [Xen-devel] [PATCH v4 4/7] xen/x86: use invpcid for flushing the TLB

>>> 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

Re: [Xen-devel] possible I/O emulation state machine issue

> -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 >

Re: [Xen-devel] [PATCH v4 2/7] x86/xpti: don't flush TLB twice when switching to 64-bit pv context

>>> 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

Re: [Xen-devel] Make coverity results public

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

Re: [Xen-devel] [PATCH v4 1/7] x86/xpti: avoid copying L4 page table contents when possible

>>> 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

Re: [Xen-devel] [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans

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

[Xen-devel] Make coverity results public

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

Re: [Xen-devel] [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans

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

Re: [Xen-devel] [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans

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

Re: [Xen-devel] [PATCH] xen/acpi: off by one in read_acpi_id()

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

Re: [Xen-devel] [PATCH] docs/qemu-deprivilege: Revise and update with status and future plans

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

[Xen-devel] [xen-4.6-testing test] 121311: regressions - FAIL

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

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

> -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. > >

Re: [Xen-devel] [PATCH] xen/acpi: off by one in read_acpi_id()

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

Re: [Xen-devel] [PATCH v2 for-4.11 1/2] libxc/x86: fix mapping of the start_info area

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

[Xen-devel] [PATCH v2 for-4.11 2/2] libxc/x86: do not unconditionally set the module cmdline address

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é

[Xen-devel] [PATCH v2 for-4.11 1/2] libxc/x86: fix mapping of the start_info area

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

Re: [Xen-devel] Sunseting mercurial

>>> 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

[Xen-devel] [PATCH] xen/acpi: off by one in read_acpi_id()

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

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

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:

Re: [Xen-devel] [PATCH for-4.11 1/2] libxc/x86: fix mapping of the start_info area

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

Re: [Xen-devel] [PATCH resend 02/13] acpi: arm: query estimated size of hardware domain's IORT.

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

Re: [Xen-devel] Sunseting mercurial

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

Re: [Xen-devel] [PATCH v2] libxl: allow libxl_domain_suspend to simply suspend a domain, without saving it

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

Re: [Xen-devel] [PATCH 1/3] ci: add Dockerfile for CentOS 6

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 >

Re: [Xen-devel] [PATCH for-4.11 1/2] libxc/x86: fix mapping of the start_info area

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 > > >

Re: [Xen-devel] [PATCH v4 4/4] libxc: Pass e820 map to HVM/PVH guests via hvm_start_info

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.

[Xen-devel] [xen-unstable-coverity test] 121326: all pass - PUSHED

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

Re: [Xen-devel] [PATCH v3 18/39] ARM: new VGIC: Add CTLR, TYPER and IIDR handlers

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

Re: [Xen-devel] [PATCH v3 26/39] ARM: new VGIC: Add SGIPENDR register handlers

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,

Re: [Xen-devel] [PATCH v4 2/2] drm/xen-front: Add support for Xen PV display frontend

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-devel] [libvirt test] 121310: tolerable all pass - PUSHED

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

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

> -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.

Re: [Xen-devel] [PATCH] correct maintainers file

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

[Xen-devel] [PATCH] correct maintainers file

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:

Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocate MMCONFIG area in the MMIO hole + minor code refactoring

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:

Re: [Xen-devel] [PATCH 1/1] xen-netback: process malformed sk_buff correctly to avoid BUG_ON()

> -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

Re: [Xen-devel] [PATCH v3 29/39] ARM: new VGIC: Handle virtual IRQ allocation/reservation

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

Re: [Xen-devel] [PATCH v3 19/39] ARM: new VGIC: Add ENABLE registers handlers

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

[Xen-devel] [qemu-mainline test] 121308: regressions - trouble: broken/fail/pass

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

Re: [Xen-devel] [PATCH] Config.mk: remove CONFIG_TESTS

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

Re: [Xen-devel] [PATCH] x86/alt: Fix wrong usage of as_max in OLDINSTR_2

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

Re: [Xen-devel] [PATCH v2 2/6] x86: fix OLDINSTR_2()

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

Re: [Xen-devel] [PATCH] x86/alt: Fix wrong usage of as_max in OLDINSTR_2

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

[Xen-devel] [rumprun test] 121313: regressions - FAIL

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

Re: [Xen-devel] [PATCH v4 2/2] drm/xen-front: Add support for Xen PV display frontend

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

Re: [Xen-devel] [PATCH for-4.11 1/2] libxc/x86: fix mapping of the start_info area

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 > > >

Re: [Xen-devel] [PATCH v4 2/2] drm/xen-front: Add support for Xen PV display frontend

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

[Xen-devel] [PATCH v2 for-4.11] tools: set DEBUG_DIR from configure

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

Re: [Xen-devel] [PATCH for-4.11] tools: set DEBUG_DIR from configure

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: > >>> >

Re: [Xen-devel] [Intel-gfx] [PATCH v4 1/2] drm: Use srcu to protect drm_device.unplugged

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

[Xen-devel] [ovmf test] 121309: all pass - PUSHED

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

[Xen-devel] [PATCH v4 0/2] drm/xen-front: Add support for Xen PV display frontend

From: Oleksandr Andrushchenko Hello! Notes. 1. Boris, I put your R-b tag as I almost didn't change Xen part of the driver (see below). Please let me know if this is not acceptable, so I remove the tag. 2. With this patch series I am also adding a patch from

[Xen-devel] [PATCH v4 1/2] drm: Use srcu to protect drm_device.unplugged

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 available after the device is gone. Suggested-by: Daniel Vetter

[Xen-devel] [PATCH v4 2/2] drm/xen-front: Add support for Xen PV display frontend

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 Weston client or DRM master. Configuration of both

  1   2   >