Hi all,
The cut-off date for Xen 4.11 is March 30th, 2018. If you want your
features to be included for the release, please make sure they are
committed by March 30th, 2018.
Juergen Gross
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https:
>>> On 28.03.18 at 18:35, wrote:
> On 28/03/18 17:22, Paul Durrant wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: 28 March 2018 16:59
>>>
>>> I thought we cache the translation result, thus avoiding the need
>>> for a translation during the retry cycle, so either I'm misremember
>>> On 28.03.18 at 18:22, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 28 March 2018 16:59
>>
>> Simply timing, perhaps. In any event, newest logs suggest we have
>> an issue with Windows paging out the page the data for the
>> REP OUTSW is coming from while the port I/O part o
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 && !skb_shinfo(skb)-
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 te
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
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
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
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 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
(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
(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
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
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
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
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
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 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, 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 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, 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:
> 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
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, 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
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 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 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 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: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 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 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 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
> -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
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
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
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 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
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
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
>>> 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
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
> -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
> -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.
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
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
> -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
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
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
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 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
>>
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 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 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
> -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 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
>>> 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 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
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: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
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 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 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
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
> -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
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
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
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é
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
>>> 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
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 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
>> >
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
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 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
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 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
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 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
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
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 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, 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
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
> -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
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
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 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
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
>>
> -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 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
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
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
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
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 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
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 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
1 - 100 of 106 matches
Mail list logo
