flight 137354 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137354/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xen-freebsd 7 xen-build-freebsdfail REGR. vs. 136901
version targeted
flight 137314 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137314/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail REGR.
flight 137391 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137391/
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 Thu, 6 Jun 2019, Julien Grall wrote:
> On 06/06/2019 09:42, Jan Beulich wrote:
> > > > > On 05.06.19 at 23:38, wrote:
> > > On 6/5/19 9:29 PM, Stefano Stabellini wrote:
> > > > My vote is to backport to both. Jan/others please express your opinion.
> > >
> > > To follow the vote convention:
>
flight 137387 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137387/
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 137286 qemu-upstream-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137286/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64 broken in 134504
build-arm64-xsm
flight 137283 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137283/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine11 examine-serial/bootloader fail REGR. vs. 133580
test-amd64-i386-qem
Hi Stefano,
On 05/06/2019 00:12, Stefano Stabellini wrote:
On Tue, 4 Jun 2019, Julien Grall wrote:
On 6/4/19 6:59 PM, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
At the moment, set_fixmap may replace a valid entry without following
the break-before-make sequence. This m
Hi Stefano,
On 05/06/2019 00:12, Stefano Stabellini wrote:
On Tue, 14 May 2019, Julien Grall wrote:
Since commit f60658c6ae "xen/arm: Stop relocating Xen", the function
setup_page_tables() does not require any information from the FDT.
So the initialization of the page-tables can be done much
flight 137386 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137386/
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
Hi Stefano,
Gentle ping, you have acked the other patches but not this patch. I can't merge
them without this one.
Cheers,
On 21/05/2019 11:01, Andrii Anisov wrote:
On 14.05.19 15:24, Julien Grall wrote:
The parameter cpuid is not used by start_xen. So remove it.
Signed-off-by: Julien Gr
Currently, the structure vcpu_guest_core_regs is part of the public API.
This implies that any change in the structure should be backward
compatible.
However, the structure is only needed by the tools and Xen. It is also
not expected to be ever used outside of that context. So we could save us
som
On 04/04/2019 14:44, Pu Wen wrote:
> This patch series have been applied and tested successfully on Hygon
> Dhyana processor, also been tested on AMD EPYC (family 17h) processor.
> It works fine and makes no harm to the existing code.
Hello,
Sorry for the delay.
I've rebased the patches over my
> -Original Message-
> From: Roger Pau Monne
> Sent: 06 June 2019 17:28
> To: Paul Durrant
> Cc: xen-devel@lists.xenproject.org; Kevin Tian ;
> Stefano Stabellini
> ; Wei Liu ; Konrad Rzeszutek Wilk
> ; George
> Dunlap ; Andrew Cooper ;
> Ian Jackson
> ; Tim (Xen.org) ; Julien Grall
>
On Thu, Jun 06, 2019 at 01:22:30PM +0200, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > Of Roger Pau Monne
> > Sent: 06 June 2019 10:02
> > To: xen-devel@lists.xenproject.org
> > Cc: Kevin Tian ; Stefano Stabell
Hi Volodymyr,
On 5/21/19 10:25 PM, Volodymyr Babchuk wrote:
+static inline bool tee_handle_call(struct cpu_user_regs *regs)
+{
+return false;
+}
+
+static inline int tee_domain_init(struct domain *d, uint16_t tee_type)
+{
+return -ENODEV;
+}
I had a report that Xen fails to boot with t
On 6/3/19 8:13 AM, Vishnu Pajjuri OS wrote:
Hi Julien Grall,
Hi,
Sorry for the late reply.
It is a pleasure for your review on Xen patch.
And Thanks for your commit suggestion and we completely agree with your
commit suggestion.
Thank you for the confirmation, I have now merged the
Hi Volodymyr,
On 6/4/19 2:31 PM, Volodymyr Babchuk wrote:
Hello Julien,
Julien Grall writes:
On 6/1/19 5:07 PM, Volodymyr Babchuk wrote:
Hi Julien,
Hi Volodymyr,
Julien Grall writes:
Hi Volodymyr,
I tried to apply the patches to staging but fail because the patches
contains =20. Do
Hi,
On 6/3/19 11:01 PM, Stefano Stabellini wrote:
This series is a small collection of PDX fixes. They are technically
independent but discovered together trying to understand the memory
waste caused by the frametable allocation on Xilinx ZynqMP.
Cheers,
Stefano
The following changes since c
On 6/5/19 10:24 AM, Julien Grall wrote:
I will commit it later on with another bunch of patches.
Pushed now.
Thank you,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-de
Hi Jan,
On 6/4/19 7:56 AM, Jan Beulich wrote:
On 04.06.19 at 00:02, wrote:
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -482,7 +482,14 @@ static void __init init_pdx(void)
{
paddr_t bank_start, bank_size, bank_end;
-u64 mask = pdx_init_mask(bootinfo.mem.bank[0].start
>>> On 06.06.19 at 16:54, wrote:
> On Thu, Jun 06, 2019 at 06:37:04AM -0600, Jan Beulich wrote:
>> >>> On 06.06.19 at 11:01, wrote:
>> > --- a/xen/include/xen/pci.h
>> > +++ b/xen/include/xen/pci.h
>> > @@ -83,9 +83,15 @@ struct pci_dev {
>> > struct arch_msix *msix;
>> >
>> > struct
>>> On 06.06.19 at 16:31, wrote:
> On Thu, Jun 06, 2019 at 03:26:29PM +0100, Andrew Cooper wrote:
>> UBSAN reports:
>>
>> (XEN)
> =
> ===
>> (XEN) UBSAN: Undefined behaviour in irq.c:682:22
>> (XEN) left shift of 1
>>> On 06.06.19 at 16:52, wrote:
> UBSAN reports:
>
> (XEN)
> =
> ===
> (XEN) UBSAN: Undefined behaviour in x86_64/mm.c:1108:31
> (XEN) left shift of 255 by 24 places cannot be represented in type 'int'
> (XEN) -
On Thu, Jun 06, 2019 at 06:37:04AM -0600, Jan Beulich wrote:
> >>> On 06.06.19 at 11:01, wrote:
> > And use an union with the current seg, bus and devfn fields to make
> > fields point to the same underlying data.
> >
> > No functional change.
> >
> > Suggested-by: Jan Beulich
> > Signed-off-by
UBSAN reports:
(XEN)
(XEN) UBSAN: Undefined behaviour in x86_64/mm.c:1108:31
(XEN) left shift of 255 by 24 places cannot be represented in type 'int'
(XEN) [ Xen-4.13-unstable x86_64 debug=y Tainted:
On Thu, Jun 06, 2019 at 03:26:29PM +0100, Andrew Cooper wrote:
> UBSAN reports:
>
> (XEN)
>
> (XEN) UBSAN: Undefined behaviour in irq.c:682:22
> (XEN) left shift of 1 by 31 places cannot be represented in type
UBSAN reports:
(XEN)
(XEN) UBSAN: Undefined behaviour in irq.c:682:22
(XEN) left shift of 1 by 31 places cannot be represented in type 'int'
(XEN) [ Xen-4.13-unstable x86_64 debug=y Not tainted ]
>>> On 06.06.19 at 15:48, wrote:
> On Thu, 2019-06-06 at 02:37 -0600, Jan Beulich wrote:
>> In which case maybe use vmalloc() and then assign_pages()?
>> Jan
> Unfortunately I wasn't able to make it work:
> I replaced the buffer allocation with this code:
>
> impl->slots = vzalloc(impl->n
On Thu, 2019-06-06 at 02:37 -0600, Jan Beulich wrote:
> > > > On 05.06.19 at 19:01, wrote:
> >
> > On Tue, 2019-06-04 at 15:43 +0100, Andrew Cooper wrote:
> > > On 30/05/2019 15:18, Petre Pircalabu wrote:
> > > > +static int vm_event_channels_alloc_buffer(struct
> > > > vm_event_channels_domain *
osstest service owner writes ("[xen-unstable test] 137274: regressions - FAIL"):
> flight 137274 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/137274/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> t
On Wed, Jun 5, 2019 at 3:30 PM Jan Beulich wrote:
>
> guest_handle_subrange_okay() takes inclusive first and last parameters,
> i.e. checks that [first, last] is valid. Many callers, however, actually
> need to see whether [first, limit) is valid (i.e., limit is non-
> inclusive), and to do this t
On 06.06.2019 15:25, Jan Beulich wrote:
On 06.06.19 at 14:16, wrote:
>> @@ -4735,6 +4736,29 @@ static int do_altp2m_op(
>> _gfn(a.u.change_gfn.old_gfn),
>> _gfn(a.u.change_gfn.new_gfn));
>> break;
>> +
>> +case HVMOP_altp2m_get_p2m_i
>>> On 06.06.19 at 11:01, wrote:
> And use an union with the current seg, bus and devfn fields to make
> fields point to the same underlying data.
>
> No functional change.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
with one question:
> --- a/xen/in
>>> On 06.06.19 at 11:01, wrote:
> --- a/xen/include/xen/pci.h
> +++ b/xen/include/xen/pci.h
> @@ -49,7 +49,10 @@ typedef union {
> uint8_t func : 3,
> dev : 5;
> };
> -uint8_t extfunc;
> +
flight 137380 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137380/
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 06.06.19 at 14:16, wrote:
> @@ -4735,6 +4736,29 @@ static int do_altp2m_op(
> _gfn(a.u.change_gfn.old_gfn),
> _gfn(a.u.change_gfn.new_gfn));
> break;
> +
> +case HVMOP_altp2m_get_p2m_idx:
> +{
> +struct vcpu *v;
> +
> +
flight 137278 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137278/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-ws16-amd64 7 xen-boot fail REGR. vs. 136728
test-amd64-amd
Hi all,
a quick reminder that the call will be today
Regards
Lars
On 30/05/2019, 18:35, "Lars Kurth" wrote:
Hi all,
Please propose topics by either editing the running agenda document at
https://cryptpad.fr/pad/#/2/pad/edit/WZr2VTdfmaPdvIxjXp+cgSF- or by replying to
the mail.
This new function returns the active altp2m index form a given vcp.
Signed-off-by: Alexandru Isaila
---
tools/libxc/include/xenctrl.h | 2 ++
tools/libxc/xc_altp2m.c | 25 +
xen/arch/x86/hvm/hvm.c | 24
xen/include/public/hvm/h
On 06/06/2019 12:43, Jan Beulich wrote:
On 06.06.19 at 13:34, wrote:
>> On 06/06/2019 09:17, Jan Beulich wrote:
>> On 05.06.19 at 19:15, wrote:
On 08/05/2019 13:46, Jan Beulich wrote:
> @@ -1130,8 +1130,10 @@ static void irq_guest_eoi_timer_fn(void
> }
> }
>>> On 06.06.19 at 13:34, wrote:
> On 06/06/2019 09:17, Jan Beulich wrote:
> On 05.06.19 at 19:15, wrote:
>>> On 08/05/2019 13:46, Jan Beulich wrote:
@@ -1130,8 +1130,10 @@ static void irq_guest_eoi_timer_fn(void
}
}
-if ( action->in_flight != 0 )
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 06 June 2019 12:31
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Roger Pau
> Monne
> ; Kevin Tian ; Stefano Stabellini
> ; xen-devel ; Konrad
> Rzeszutek Wilk
> ; Tim
On 06/06/2019 09:17, Jan Beulich wrote:
On 05.06.19 at 19:15, wrote:
>> On 08/05/2019 13:46, Jan Beulich wrote:
>>> @@ -1130,8 +1130,10 @@ static void irq_guest_eoi_timer_fn(void
>>> }
>>> }
>>>
>>> -if ( action->in_flight != 0 )
>>> -goto out;
>>> +if ( action
>>> On 06.06.19 at 13:19, wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
>> Paul Durrant
>> Sent: 06 June 2019 12:11
>>
>> > -Original Message-
>> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On B
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Roger Pau Monne
> Sent: 06 June 2019 10:02
> To: xen-devel@lists.xenproject.org
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu
> ; Konrad Rzeszutek Wilk ; George Dunlap
> ; Andrew Coop
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Paul Durrant
> Sent: 06 June 2019 12:11
> To: Roger Pau Monne ; xen-devel@lists.xenproject.org
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu
> ; Konrad Rzeszutek Wilk ; Andrew Cooper
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Roger Pau Monne
> Sent: 06 June 2019 10:02
> To: xen-devel@lists.xenproject.org
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu
> ; Konrad Rzeszutek Wilk ; George Dunlap
> ; Andrew Coop
On Thu, Jun 06, 2019 at 04:22:54AM -0600, Jan Beulich wrote:
> >>> On 06.06.19 at 12:13, wrote:
> > On Thu, Jun 06, 2019 at 04:09:31AM -0600, Jan Beulich wrote:
> >> >>> On 06.06.19 at 11:50, wrote:
> >> >> -Original Message-
> >> >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenpro
>>> On 06.06.19 at 12:13, wrote:
> On Thu, Jun 06, 2019 at 04:09:31AM -0600, Jan Beulich wrote:
>> >>> On 06.06.19 at 11:50, wrote:
>> >> -Original Message-
>> >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> >> Of
>> > Roger Pau Monne
>> >> Sent: 06 June
On Thu, Jun 06, 2019 at 04:09:31AM -0600, Jan Beulich wrote:
> >>> On 06.06.19 at 11:50, wrote:
> >> -Original Message-
> >> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> >> Of
> > Roger Pau Monne
> >> Sent: 06 June 2019 10:02
> >> To: xen-devel@lists.xenpr
On Thu, Jun 06, 2019 at 11:50:06AM +0200, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > Of Roger Pau Monne
> > Sent: 06 June 2019 10:02
> > To: xen-devel@lists.xenproject.org
> > Cc: Stefano Stabellini ; Wei Liu
>>> On 06.06.19 at 11:50, wrote:
>> -Original Message-
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Roger Pau Monne
>> Sent: 06 June 2019 10:02
>> To: xen-devel@lists.xenproject.org
>> Cc: Stefano Stabellini ; Wei Liu ;
>> Konrad
> Rzeszutek Wilk
>
flight 137277 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/137277/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-saverestore.2
fail REGR. vs. 1
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Roger Pau Monne
> Sent: 06 June 2019 10:02
> To: xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu ;
> Konrad Rzeszutek Wilk
> ; George Dunlap ; Andrew
> Cooper
> ; Ian J
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf Of
> Roger Pau Monne
> Sent: 06 June 2019 10:02
> To: xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu ;
> Konrad Rzeszutek Wilk
> ; George Dunlap ; Andrew
> Cooper
> ; Ian J
On 06/06/2019 09:08, Jan Beulich wrote:
On 05.06.19 at 19:04, wrote:
>> On 08/05/2019 13:46, Jan Beulich wrote:
>>> The timer needs to remain active only until all pending IRQ instances
>>> have seen EOIs from their respective domains. Stop it when the in-flight
>>> count has reached zero in
This reduces the number of parameters of the function to two, and
simplifies some of the calling sites.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc:
And fix it's only caller.
Signed-off-by: Roger Pau Monné
---
Cc: Kevin Tian
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
xen/drivers/passthrough/vtd/dmar.c | 2 +-
xe
And fix it's callers.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
xen/common/compat/memory.c| 4 ++--
xen/common/memory.c
The new format specifier is '%pp', and prints a pci_sbdf_t using the
seg:bus:dev.func format. Replace all SBDFs printed using
'%04x:%02x:%02x.%u' to use the new format specifier.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jacks
This reduces the number of parameters of the function to two, and
simplifies some of the calling sites.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: "Roger Pau Monné"
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: S
This reduces the number of parameters of the function to two, and
simplifies some of the calling sites.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc:
This reduces the number of parameters of the function to two, and
simplifies some of the calling sites.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc:
And fix it's only caller.
Signed-off-by: Roger Pau Monné
---
Cc: Kevin Tian
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc: Tim Deegan
Cc: Wei Liu
---
Changes since v1:
- New in this version.
---
This reduces the number of parameters of the function to two, and
simplifies some of the calling sites.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc:
IMO pci_sbdf_t it's nicer to use than passing around a sbdf in multiple
fields. However it's hard to expand the usage of pci_sbdf_t in the code
base without changing some of the core pci functions and the pci_dev
struct fields, hence this patch set.
Note there's still more low hanging fruit that c
And use an union with the current seg, bus and devfn fields to make
fields point to the same underlying data.
No functional change.
Suggested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Grall
Cc: Konrad R
This reduces the number of parameters of the function to two, and
simplifies some of the calling sites.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: George Dunlap
Cc: Ian Jackson
Cc: Julien Grall
Cc: Konrad Rzeszutek Wilk
Cc: Stefano Stabellini
Cc:
This is equivalent to the current extfunc field in term of contents.
Switch the two current users of extfunc to use devfn instead for
correctness.
No functional change.
Requested-by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan B
>>> On 06.06.19 at 10:26, wrote:
> On Tue, Jun 04, 2019 at 08:39:15AM -0600, Jan Beulich wrote:
> On 27.05.19 at 10:31, wrote:
>>> --- a/xen/arch/x86/microcode_intel.c
>>> +++ b/xen/arch/x86/microcode_intel.c
>>> @@ -134,14 +134,28 @@ static int collect_cpu_info(unsigned int cpu_num,
> struc
On 06/06/2019 09:42, Jan Beulich wrote:
On 05.06.19 at 23:38, wrote:
On 6/5/19 9:29 PM, Stefano Stabellini wrote:
My vote is to backport to both. Jan/others please express your opinion.
To follow the vote convention:
4.11: -1
Hmm, I'm surprised by this. Didn't I see you mention to Ian (
>>> On 05.06.19 at 23:38, wrote:
> On 6/5/19 9:29 PM, Stefano Stabellini wrote:
>> My vote is to backport to both. Jan/others please express your opinion.
>
> To follow the vote convention:
>
> 4.11: -1
Hmm, I'm surprised by this. Didn't I see you mention to Ian (on irc)
you'd prefer backportin
Hi Jan,
On 04/06/2019 13:44, Jan Beulich wrote:
A couple of adjustments are needed to code checking for dom_cow, but
since there are pretty few it is probably better to adjust those than
to set up and keep around a never used domain.
Signed-off-by: Jan Beulich
Acked-by: Julien Grall
Cheers
Hi Jan,
On 04/06/2019 13:43, Jan Beulich wrote:
Split out this mostly arch-independent code into a common-code helper
function. (This does away with Arm's arch_init_memory() altogether.)
On x86 this needs to happen before acpi_boot_init(): Commit 9fa94e1058
("x86/ACPI: also parse AMD IOMMU tabl
>>> On 05.06.19 at 19:01, wrote:
> On Tue, 2019-06-04 at 15:43 +0100, Andrew Cooper wrote:
>> On 30/05/2019 15:18, Petre Pircalabu wrote:
>> > +static int vm_event_channels_alloc_buffer(struct
>> > vm_event_channels_domain *impl)
>> > +{
>> > +int i, rc = -ENOMEM;
>> > +
>> > +for ( i = 0;
On Tue, Jun 04, 2019 at 08:39:15AM -0600, Jan Beulich wrote:
On 27.05.19 at 10:31, wrote:
>> --- a/xen/arch/x86/microcode_intel.c
>> +++ b/xen/arch/x86/microcode_intel.c
>> @@ -134,14 +134,28 @@ static int collect_cpu_info(unsigned int cpu_num,
>> struct cpu_signature *csig)
>> return 0
>>> On 05.06.19 at 19:15, wrote:
> On 08/05/2019 13:46, Jan Beulich wrote:
>> @@ -1130,8 +1130,10 @@ static void irq_guest_eoi_timer_fn(void
>> }
>> }
>>
>> -if ( action->in_flight != 0 )
>> -goto out;
>> +if ( action->in_flight )
>> +printk(XENLOG_G_WARNING
>>> On 05.06.19 at 19:04, wrote:
> On 08/05/2019 13:46, Jan Beulich wrote:
>> The timer needs to remain active only until all pending IRQ instances
>> have seen EOIs from their respective domains. Stop it when the in-flight
>> count has reached zero in desc_guest_eoi(). Note that this is race free
>>> On 05.06.19 at 20:02, wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-4.7-testing test] 137065:
> regressions -
> FAIL"):
>> The one you've picked looks to be a "fail never pass" one, so is perhaps
>> not ideal. I've looked at a couple other ones, and in particular when the
>> guests are
80 matches
Mail list logo
