flight 120763 linux-4.1 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120763/
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 16.03.18 at 16:38, wrote:
> On Fri, Mar 16, 2018 at 09:05:44AM -0600, Jan Beulich wrote:
>> >>> On 16.03.18 at 15:34, wrote:
>> > vpci_remove_device is never called from the user-space test harness,
>> > so it just needs to build, but not necessarily be correct in that
>> > context.
>> >
>>> On 16.03.18 at 16:42, wrote:
> On 16/03/18 15:04, Jan Beulich wrote:
> On 16.03.18 at 15:29, wrote:
>>> Somewhat independently of this patch, I think we should assert that
>>> flags are in the expected state in the return-to-guest path, so we
>>> notice accidental breakage like this more
On Fri, 16 Mar 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 15/03/18 23:52, Stefano Stabellini wrote:
> > On Wed, 14 Mar 2018, Stefano Stabellini wrote:
> > > After looking at the test results, which are good for arm, and
> > > considering that master hasn't passed yet after 2 more days, I agree
Hi Stefano,
On 16/03/2018 16:33, Stefano Stabellini wrote:
On Fri, 16 Mar 2018, Julien Grall wrote:
Hi Stefano,
On 15/03/18 23:52, Stefano Stabellini wrote:
On Wed, 14 Mar 2018, Stefano Stabellini wrote:
After looking at the test results, which are good for arm, and
considering that master h
This series tightens up permissions checking on ioreq server control plane
operations.
Paul Durrant (4):
x86/hvm: stop passing explicit domid to hvm_create_ioreq_server()
x86/hvm: take a reference on ioreq server emulating domain
x86/hvm: re-structure some of the ioreq server look-up loops
This patch is a cosmetic re-structuring of some of the loops with look up
an ioreq server based on target domain and server id.
The restructuring is done separately here to ease review of a subsquent
patch.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm
Only in the legacy 'default server' case do we pass anything other than
current->domain->domain_id, and in that case we pass the value of
HVM_PARAM_DM_DOMAIN.
The only known user of HVM_PARAM_DM_DOMAIN is qemu-trad, which always sets
it to DOMID_SELF (ignoring the return value of xc_set_hvm_param)
When an ioreq server is created the code currently stores the id
of the emulating domain, but does not take a reference on that domain.
This patch modifies the code to hold a reference for the lifetime of the
ioreq server.
Signed-off-by: Paul Durrant
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
On 3/16/2018 4:11 AM, Roger Pau Monné wrote:
On Thu, Mar 15, 2018 at 02:33:09PM -0700, Maran Wilson wrote:
The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information ab
There has always been an intention in the ioreq server API that only the
domain that creates an ioreq server should be able to manipulate it.
However, so far, nothing has enforced this. This means that two domains
with DM_PRIV over a target domain can currently manipulate each others
ioreq servers.
On 16/03/2018 16:56, Julien Grall wrote:
Hi Stefano,
On 16/03/2018 16:33, Stefano Stabellini wrote:
On Fri, 16 Mar 2018, Julien Grall wrote:
Hi Stefano,
On 15/03/18 23:52, Stefano Stabellini wrote:
On Wed, 14 Mar 2018, Stefano Stabellini wrote:
After looking at the test results, which are
A gentle RFC-ping.
Any thoughts on this? Regarding the feature as a whole. So far there
were responses mostly targeting individual patches, while I'd like to
hear about chosen approaches in general, whether the overall direction
is correct (or not), etc. It's just RFC after all, not v11. :)
I can
This patch adds driver for UART controller found on Armada 3700 SoC.
There is no reference manuals available for 3700 SoC in public and this
driver is derived by looking at Linux driver.
https://github.com/torvalds/linux/blob/master/drivers/tty/serial/mvebu-uart.c
It allows XEN to boot on ESPRESS
On Fri, Mar 16, 2018 at 10:24:04AM -0600, Jan Beulich wrote:
> >>> On 16.03.18 at 16:38, wrote:
> > On Fri, Mar 16, 2018 at 09:05:44AM -0600, Jan Beulich wrote:
> >> >>> On 16.03.18 at 15:34, wrote:
> >> > vpci_remove_device is never called from the user-space test harness,
> >> > so it just need
On Fri, Mar 16, 2018 at 10:00:54AM -0700, Maran Wilson wrote:
> On 3/16/2018 4:11 AM, Roger Pau Monné wrote:
> > On Thu, Mar 15, 2018 at 02:33:09PM -0700, Maran Wilson wrote:
> > >* 8 ++
> > >*| flags | SIF_xxx flags.
> > >* 12 ++
> > > @@ -
On Thu, Mar 15, 2018 at 02:35:16PM -0700, Maran Wilson wrote:
> From: Boris Ostrovsky
>
> Since hvm_start_info has now been expanded to include PVH guest's
> memory map (i.e. e820) we need to know size of this map by the time we
> create dom->start_info_seg in alloc_magic_pages_hvm().
>
> To do
On Thu, Mar 15, 2018 at 02:35:17PM -0700, Maran Wilson wrote:
> From: Boris Ostrovsky
>
> We will later copy it to hvm_start_info.
>
> (Also remove stale comment claming that xc_dom_image.start_info_seg is
> only used for HVMlite guests)
>
> Signed-off-by: Boris Ostrovsky
> ---
> tools/libxc/
Hi Alexey, thanks for the ping. I think this is a good feature to have
and I would like to check it in when it is ready. I spoke with Anthony
and agreed that he will be reviewing it. Please be patient but we'll get
there :-)
On Sat, 17 Mar 2018, Alexey G wrote:
> A gentle RFC-ping.
>
> Any though
On Thu, Mar 15, 2018 at 02:35:18PM -0700, Maran Wilson wrote:
> From: Boris Ostrovsky
>
> Signed-off-by: Boris Ostrovsky
> Signed-off-by: Maran Wilson
> ---
> tools/libxc/xc_dom_x86.c | 30 +-
> 1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/tools
On 03/16/2018 02:12 PM, Roger Pau Monné wrote:
> On Thu, Mar 15, 2018 at 02:35:16PM -0700, Maran Wilson wrote:
>> From: Boris Ostrovsky
>>
>> Since hvm_start_info has now been expanded to include PVH guest's
>> memory map (i.e. e820) we need to know size of this map by the time we
>> create dom->s
flight 120844 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120844/
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 Sat, Mar 17, 2018 at 03:34:58AM +1000, Alexey G wrote:
> A gentle RFC-ping.
>
> Any thoughts on this? Regarding the feature as a whole. So far there
> were responses mostly targeting individual patches, while I'd like to
> hear about chosen approaches in general, whether the overall direction
>
On 03/16/2018 02:20 PM, Roger Pau Monné wrote:
> On Thu, Mar 15, 2018 at 02:35:17PM -0700, Maran Wilson wrote:
>> From: Boris Ostrovsky
>>
>> We will later copy it to hvm_start_info.
>>
>> (Also remove stale comment claming that xc_dom_image.start_info_seg is
>> only used for HVMlite guests)
>>
>>
Commit ec05090403ef4d760fbe701e31afd0f0edc414d5 ("x86/entry: Erase guest
GPR state on entry to Xen") zero-ed %rbp, compat arg 6, but it is not
restored before passing to hypercalls. We need to pass the saved compat
arg 6 to the hypercall in r9, the 6th function argument.
Signed-off-by: Jason Andr
On 16/03/18 19:55, Jason Andryuk wrote:
> Commit ec05090403ef4d760fbe701e31afd0f0edc414d5 ("x86/entry: Erase guest
> GPR state on entry to Xen") zero-ed %rbp, compat arg 6, but it is not
> restored before passing to hypercalls. We need to pass the saved compat
> arg 6 to the hypercall in r9, the 6
On Thu, 8 Mar 2018, julien.gr...@arm.com wrote:
> From: Julien Grall
>
> Xen is currently allowing to route/remove an interrupt from/to the
> domain while it is running.
>
> However, we never sync the virtual interrupt state to the physical
> interrupt. This could lead to undesirable effect on t
On Mon, 12 Mar 2018, julien.gr...@arm.com wrote:
> From: Julien Grall
>
> A recent update to the ARM SMCCC_ARCH_WORKAROUND_1 specification (see [1])
> allows firmware to return a non zero, positive value, to describe that
> although the mitigation is implemented at the higher exception level,
> t
On Mon, 12 Mar 2018, julien.gr...@arm.com wrote:
> From: Julien Grall
>
> Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt"
> assumed the read-write lock can be taken recursively. However, this
> assumption is wrong and will lead to deadlock when the lock is
> contended.
>
> The
On Thu, 15 Mar 2018, Andre Przywara wrote:
> gic_event_needs_delivery() is not named very intuitively, especially
> the gic_ prefix is somewhat misleading.
> Rename it to vgic_vcpu_pending_irq(), which makes it clear that this
> relates to the virtual GIC and is about interrupts.
> Also add a VCPU
On Thu, 15 Mar 2018, Andre Przywara wrote:
> If we change something in a vCPU that affects its runnability or
> otherwise needs the vCPU's attention, we might need to tell the scheduler
> about it.
> We are using this in one place (vIRQ injection) at the moment, but will
> need this at more places
On Thu, 15 Mar 2018, Andre Przywara wrote:
> From: Julien Grall
>
> At the moment, write_lr is assuming the caller will set correctly the
> group. However the group should always be 0 when the guest is using
> vGICv2 and 1 for vGICv3. As the caller should not care about the group,
> override it d
On Thu, 15 Mar 2018, Andre Przywara wrote:
> From: Julien Grall
>
> hw_status can only be 1 or 0. So convert to a bool.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Andre Przywara
> Signed-off-by: Andre Przywara
Acked-by: Stefano Stabellini
> ---
> Changes:
> - Remove == *LR_HW as it is
On Thu, 15 Mar 2018, Andre Przywara wrote:
> From: Julien Grall
>
> Mostly making the code nicer to read.
>
> Signed-off-by: Julien Grall
> Reviewed-by: Andre Przywara
> Signed-off-by: Andre Przywara
> ---
> Changes:
> - Use 1ULL
> - Remove pointless == *_STATE_*
>
> xen/arch/arm/gic-v2.c
On Thu, 15 Mar 2018, Andre Przywara wrote:
> From: Julien Grall
>
> The field pirq should only be valid when the virtual interrupt
> is associated to a physical interrupt.
>
> This change will help to extend gic_lr for supporting specific virtual
> interrupt field (e.g eoi, source) that clashes
flight 120851 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120851/
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, 15 Mar 2018, Andre Przywara wrote:
> From: Julien Grall
>
> So far our LR read/write functions do not handle the EOI bit and the
> source CPUID bits in an LR, because the current VGIC implementation does
> not use them.
> Extend the gic_lr data structure to hold these bits of information
On 16/03/2018 21:34, Stefano Stabellini wrote:
On Thu, 15 Mar 2018, Andre Przywara wrote:
From: Julien Grall
diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
index daec51499c..c32861d4fa 100644
--- a/xen/include/asm-arm/gic.h
+++ b/xen/include/asm-arm/gic.h
@@ -209,7 +209,8
On Fri, 16 Mar 2018, Julien Grall wrote:
> On 16/03/2018 21:34, Stefano Stabellini wrote:
> > On Thu, 15 Mar 2018, Andre Przywara wrote:
> > > From: Julien Grall
> > > diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h
> > > index daec51499c..c32861d4fa 100644
> > > --- a/xen/inclu
flight 120854 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120854/
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 120767 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120767/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-livepatch 7 xen-boot fail REGR. vs. 120037
test-amd64-i386-xl
101 - 141 of 141 matches
Mail list logo
