flight 132469 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132469/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-checkfail like 132453
test-armhf-armhf-libvirt-raw 13
flight 132465 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132465/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 12
guest-start/debianhvm.repeat fail
On Fri, Jan 25, 2019 at 6:10 PM Chris Patterson wrote:
>
> > -static int domain_has_perm(struct domain *dom1, struct domain *dom2,
> > +static int domain_has_perm(const struct domain *dom1,
> > + const struct domain *dom2,
> > u16 class, u32
On Fri, Jan 25, 2019 at 5:34 PM Chris Patterson wrote:
>
> On Wed, Jan 23, 2019 at 9:07 PM Christopher Clark
> wrote:
> >
> > XSM controls for argo ring registration with two distinct cases
> > ---
> > diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
> > index 3b192b5..e32a645 100644
On Fri, Jan 25, 2019 at 5:32 PM Chris Patterson wrote:
>
> On Wed, Jan 23, 2019 at 9:07 PM Christopher Clark
> wrote:
> >
> > Will inhibit initialization of the domain's argo data structure to
> > prevent receiving any messages or notifications and access to any of
> > the argo hypercall
Add libxc wrapper for PHYSDEVOP_msi_msix_set_enable introduced in
previous commit.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- new patch
---
tools/libxc/include/xenctrl.h | 7 +++
tools/libxc/xc_physdev.c | 21 +
2 files changed, 28
When qemu is running in stubdomain, handling "pci-ins" command will fail
if pcifront is not initialized already. Fix this by sending such command
only after confirming that pciback/front is running.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v2:
- Fixed code style since previous
Stubdomain do not have it's own config file - its configuration is
derived from target domains. Do not try to manipulate it when attaching
PCI device.
This bug prevented starting HVM with stubdomain and PCI passthrough
device attached.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in
In this version, I add PHYSDEVOP_msi_msix_set_enable to allow stubdomain
enabling MSI after mapping it. This patch is rather RFC and probably will
need adjustments (see comments after commit message there), if physdevop will
be the way to go.
Related article:
From: Simon Gaiser
Stubdomains need to be given sufficient privilege over the guest which it
provides emulation for in order for PCI passthrough to work correctly.
When a HVM domain try to enable MSI, QEMU in stubdomain calls
PHYSDEVOP_map_pirq, but later it needs to call XEN_DOMCTL_bind_pt_irq
Allow device model running in stubdomain to enable/disable MSI(-X),
bypassing pciback. While pciback is still used to access config space
from within stubdomain, it refuse to write to
PCI_MSI_FLAGS_ENABLE/PCI_MSIX_FLAGS_ENABLE in non-permissive mode. Which
is the right thing to do for PV domain
HVM domains use IOMMU and device model assistance for communicating with
PCI devices, xen-pcifront/pciback isn't directly needed by HVM domain.
But pciback serve also second function - it reset the device when it is
deassigned from the guest and for this reason pciback needs to be used
with HVM
On Thu, Jan 17, 2019 at 11:29:59AM +0100, Roger Pau Monné wrote:
> On Tue, Jan 15, 2019 at 04:36:29PM +0100, Marek Marczykowski-Górecki wrote:
> > When qemu is running in stubdomain, handling "pci-ins" command will fail
> > if pcifront is not initialized already. Fix this by sending such command
>
> -static int domain_has_perm(struct domain *dom1, struct domain *dom2,
> +static int domain_has_perm(const struct domain *dom1,
> + const struct domain *dom2,
> u16 class, u32 perms)
> {
This const conversion triggers compilation errors:
On Wed, Jan 23, 2019 at 9:07 PM Christopher Clark
wrote:
>
> XSM controls for argo ring registration with two distinct cases, where
> the ring being registered is:
>
> 1) Single source: registering a ring for communication to receive messages
>from a specified single other
On Wed, Jan 23, 2019 at 9:07 PM Christopher Clark
wrote:
>
> Will inhibit initialization of the domain's argo data structure to
> prevent receiving any messages or notifications and access to any of
> the argo hypercall operations.
>
> Signed-off-by: Christopher Clark
> Acked-by: Daniel De Graaf
On Mon, 21 Jan 2019, Julien Grall wrote:
> Hi,
>
> Ping?
>
> Cheers,
>
> On 30/11/2018 17:25, Julien Grall wrote:
> > Hi,
> >
> > Below a list of backport candidate for Arm.
> >
> >
> > For Xen 4.10+ to handle correctly SMC call parameters and result
> >
> > 35fc608612 xen/arm:
On Thu, 24 Jan 2019, Julien Grall wrote:
> (+ James)
>
> Hi Stefano,
>
> @James, please correct me if I am wrong below :).
>
> On 24/01/2019 00:52, Stefano Stabellini wrote:
> > On Wed, 28 Nov 2018, Julien Grall wrote:
> > > void p2m_restore_state(struct vcpu *n)
> > > @@ -111,10 +130,17 @@
flight 132457 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132457/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 132422
flight 132477 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132477/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
On Fri, Jan 25, 2019 at 08:43:59PM +0100, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 16, 2019 at 11:52:21AM +0100, Marek Marczykowski-Górecki wrote:
> > On Wed, Jan 16, 2019 at 10:21:29AM +0100, Roger Pau Monné wrote:
> > > On Tue, Jan 15, 2019 at 04:36:31PM +0100, Marek Marczykowski-Górecki
On Wed, Jan 16, 2019 at 11:52:21AM +0100, Marek Marczykowski-Górecki wrote:
> On Wed, Jan 16, 2019 at 10:21:29AM +0100, Roger Pau Monné wrote:
> > On Tue, Jan 15, 2019 at 04:36:31PM +0100, Marek Marczykowski-Górecki wrote:
> > > From: Simon Gaiser
> > >
> > > Stubdomains need to be given
On Fri, Jan 25, 2019 at 05:45:02PM +, Catalin Marinas wrote:
> On Mon, Jan 21, 2019 at 10:03:53AM +0200, Mike Rapoport wrote:
> > diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> > index ae34e3a..2c61ea4 100644
> > --- a/arch/arm64/mm/numa.c
> > +++ b/arch/arm64/mm/numa.c
> > @@
On Fri, 25 Jan 2019, Peng Fan wrote:
> > On Wed, Jan 23, 2019 at 01:04:33PM -0800, Stefano Stabellini wrote:
> > > If vring_use_dma_api is actually supposed to return true when
> > > dma_dev->dma_mem is set, then both Peng's patch and the patch I wrote
> > > are not fixing the real issue here.
> >
On Thu, Jan 24, 2019 at 2:08 AM Julien Grall wrote:
>
> Hi,
>
> On 24/01/2019 02:04, Christopher Clark wrote:
> > Presence is gated upon CONFIG_ARGO.
> >
> > Registers the hypercall previously reserved for this.
> > Takes 5 arguments, does nothing and returns -ENOSYS.
> >
> > Will be avoiding a
On 25/01/2019 15:38, Roger Pau Monné wrote:
> On Thu, Jan 24, 2019 at 01:04:31PM +0100, Roger Pau Monné wrote:
>> On Thu, Jan 24, 2019 at 12:55:06PM +0100, Sander Eikelenboom wrote:
>>> On 24/01/2019 11:11, Roger Pau Monné wrote:
On Thu, Jan 24, 2019 at 10:25:33AM +0100, Sander Eikelenboom
On Tue, Jan 22, 2019 at 03:53:46PM +, Paul Durrant wrote:
> There is a flaw in the xen-bus state model. To allow a frontend to re-
> connect the backend state of an online XenDevice is transitioned from
> Closed to InitWait, but this is currently done unilaterally which is
> incorrect. The
On Mon, Jan 21, 2019 at 10:03:53AM +0200, Mike Rapoport wrote:
> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
> index ae34e3a..2c61ea4 100644
> --- a/arch/arm64/mm/numa.c
> +++ b/arch/arm64/mm/numa.c
> @@ -237,6 +237,10 @@ static void __init setup_node_data(int nid, u64
> start_pfn,
Roger Pau Monne writes ("Re: [OSSTEST PATCH 5/5] power: ssh: Wait for the
target to appear to go down"):
> On Fri, Jan 25, 2019 at 02:50:46PM +, Ian Jackson wrote:
> > On some systems (notably, FreeBSD) the kernel does not simply reboot
> > immediately even with the runes we provide here, ie
On Fri, Jan 25, 2019 at 02:50:46PM +, Ian Jackson wrote:
> When we `power on' with the ssh method, we actually run ssh reboot.
>
> On some systems (notably, FreeBSD) the kernel does not simply reboot
> immediately even with the runes we provide here, ie for FreeBSD
> reboot -nq
> Eg, I have
On Fri, Jan 25, 2019 at 02:50:45PM +, Ian Jackson wrote:
> We look at the installer environment uptime, to
> | check that this is the installer environment
> as requested by the comment
> | in particular $await must only succeed if the host really did
> | reboot into the boot environment
From: Andrii Anisov
Currently, that assert condition does not correspond to a comment above
and makes assertion failed on HW IRQ disconnection.
Fix the condition so it corresponds to the comment and allows IRQ
disconnection on debug builds.
Fixes: ec2a2f1 ("ARM: VGIC: factor out
>>> On 20.12.18 at 14:14, wrote:
> The Hygon Dhyana CPU supports lots of MSRs(such as perf event select and
> counter MSRs, hardware configuration MSR, MMIO configuration base address
> MSR, MPERF/APERF MSRs) as AMD CPU does, so add Hygon Dhyana support to the
> PV emulation infrastructure by
On Fri, Jan 25, 2019 at 04:39:35PM +, Anthony PERARD wrote:
> On Fri, Jan 25, 2019 at 04:10:55PM +, Wei Liu wrote:
> > On Fri, Jan 25, 2019 at 02:47:20PM +, George Dunlap wrote:
> > > On 1/25/19 11:33 AM, Wei Liu wrote:
> > > > On Thu, Jan 24, 2019 at 05:48:27PM +, George Dunlap
>>> On 23.01.19 at 12:57, wrote:
> When interacting with hpet, read and write operations can be executed
> during instruction emulation, where the guest controls the data that
> is used. As it is hard to predict the number of instructions that are
> executed speculatively, we prevent out-of-bound
On Fri, Jan 25, 2019 at 04:10:55PM +, Wei Liu wrote:
> On Fri, Jan 25, 2019 at 02:47:20PM +, George Dunlap wrote:
> > On 1/25/19 11:33 AM, Wei Liu wrote:
> > > On Thu, Jan 24, 2019 at 05:48:27PM +, George Dunlap wrote:
> > >> Remove "chatty" and redundant information from the xl man
>>> On 23.01.19 at 12:57, wrote:
> @@ -66,6 +67,9 @@ static struct hvm_vioapic *gsi_vioapic(const struct domain
> *d,
> {
> unsigned int i;
>
> +/* Make sure the compiler does not optimize the initialization */
> +OPTIMIZER_HIDE_VAR(pin);
Since there's no initialization here, I
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 25 January 2019 14:23
> To: Paul Durrant
> Cc: Andrew Cooper ; xen-
> de...@lists.xenproject.org; Wei Liu ; Jan Beulich
> ; Roger Pau Monne
> Subject: Re: [Xen-devel] [PATCH 1/8] viridian: add init hooks
>
> On
>>> On 25.01.19 at 09:26, wrote:
> --- a/xen/arch/x86/domctl.c
> +++ b/xen/arch/x86/domctl.c
> @@ -732,7 +732,11 @@ long arch_do_domctl(
> break;
>
> ret = -EPERM;
> -if ( irq <= 0 || !irq_access_permitted(currd, irq) )
> +/*
> + * irq < 0 denotes
On Fri, Jan 25, 2019 at 02:47:20PM +, George Dunlap wrote:
> On 1/25/19 11:33 AM, Wei Liu wrote:
> > On Thu, Jan 24, 2019 at 05:48:27PM +, George Dunlap wrote:
> >> Remove "chatty" and redundant information from the xl man page;
> >> restrict it to functional descriptions only, and point
>>> On 25.01.19 at 12:10, wrote:
> On Tue, Jan 22, 2019 at 09:28:16AM -0700, Jan Beulich wrote:
> On 22.01.19 at 17:08, wrote:
>>> On Tue, Jan 22, 2019 at 01:24:48AM -0700, Jan Beulich wrote:
>>> On 22.01.19 at 06:50, wrote:
> On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau
>>> On 25.01.19 at 15:15, wrote:
> On 25/01/2019 13:25, Jan Beulich wrote:
> On 25.01.19 at 12:10, wrote:
>>> On 25/01/2019 10:25, Jan Beulich wrote:
>>> On 24.01.19 at 19:28, wrote:
> Code clearing the "Suppress VE" bit in an EPT entry isn't nececsserily
> running
> in current
When we `power on' with the ssh method, we actually run ssh reboot.
On some systems (notably, FreeBSD) the kernel does not simply reboot
immediately even with the runes we provide here, ie for FreeBSD
reboot -nq
Eg, I have seen reboots with several messages like this:
Jan 25 14:17:59.100044
When this error trips it is usually because the call site looked up an
unset runvar and it can be hard to tell what that runvar was.
If we use confess we will at least find out the calling line number...
Signed-off-by: Ian Jackson
---
Osstest.pm | 4 +++-
1 file changed, 3 insertions(+), 1
The script fragment contains a reference to $delay which is a perl
variable, not a variable in the script fragment. We therefore need to
not ''-quote the script.
Without this, the ssh method will often fail spuriously: the exiting
parent (which will signal success back to the osstest controller)
This replaces the `DO NOT APPLY' patch 26/26 from the part 1 series.
It also contains some other fixes/improvements.
Ian Jackson (5):
flight_otherjob: Use confess rather than die
power: ssh: Fix handling of $delay
power: ssh: Reduce timeout for script fragment
power:
We look at the installer environment uptime, to
| check that this is the installer environment
as requested by the comment
| in particular $await must only succeed if the host really did
| reboot into the boot environment that $await expects.
near the top of power_reboot_attempts
CC: Roger Pau
This is really not going to take a minute. Probably, much less.
Waiting less long will save time when we fall back.
Signed-off-by: Ian Jackson
---
Osstest/PDU/ssh.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Osstest/PDU/ssh.pm b/Osstest/PDU/ssh.pm
index
On 1/25/19 11:33 AM, Wei Liu wrote:
> On Thu, Jan 24, 2019 at 05:48:27PM +, George Dunlap wrote:
>> Remove "chatty" and redundant information from the xl man page;
>> restrict it to functional descriptions only, and point instead to
>> qemu-depriv.pandoc and SUPPORT.md as locations for
On Thu, Jan 24, 2019 at 01:04:31PM +0100, Roger Pau Monné wrote:
> On Thu, Jan 24, 2019 at 12:55:06PM +0100, Sander Eikelenboom wrote:
> > On 24/01/2019 11:11, Roger Pau Monné wrote:
> > > On Thu, Jan 24, 2019 at 10:25:33AM +0100, Sander Eikelenboom wrote:
> > >> On 24/01/2019 08:50, Roger Pau
On Thu, Jan 03, 2019 at 02:18:18PM +, Paul Durrant wrote:
> > -Original Message-
[...]
> >
> > Looking at this a little more... Viridian is an x86 specific thing, so an
> > extra flag in xen_arch_domainconfig would seem most appropriate. This
> > would then need to wired into the
On Tue, Jan 08, 2019 at 03:01:34PM +, Petre Ovidiu PIRCALABU wrote:
> On Wed, 2019-01-02 at 11:11 +, Wei Liu wrote:
> > On Wed, Dec 19, 2018 at 08:52:05PM +0200, Petre Pircalabu wrote:
> > > Define the type for each of the supported vm_event rings (paging,
> > > monitor and sharing) and
On 25/01/2019 13:25, Jan Beulich wrote:
On 25.01.19 at 12:10, wrote:
>> On 25/01/2019 10:25, Jan Beulich wrote:
>> On 24.01.19 at 19:28, wrote:
Code clearing the "Suppress VE" bit in an EPT entry isn't nececsserily
running
in current context. In ALTP2M_external mode, it
On Fri, Jan 25, 2019 at 07:36:36PM +0800, Chao Gao wrote:
> On Fri, Jan 25, 2019 at 10:36:13AM +0100, Roger Pau Monné wrote:
> >Thanks for the patch!
> >
> >On Fri, Jan 25, 2019 at 04:26:59PM +0800, Chao Gao wrote:
> >> I find some pass-thru devices don't work any more across guest
> >> reboot.
>>> On 25.01.19 at 12:10, wrote:
> On 25/01/2019 10:25, Jan Beulich wrote:
> On 24.01.19 at 19:28, wrote:
>>> Code clearing the "Suppress VE" bit in an EPT entry isn't nececsserily
>>> running
>>> in current context. In ALTP2M_external mode, it definitely is not, and in
>>> PV
>>>
>>> On 25.01.19 at 11:50, wrote:
> On 1/25/19 11:14, Jan Beulich wrote:
> On 24.01.19 at 22:29, wrote:
>>> Worse is the "evaluate condition, stash result, fence, use variable"
>>> option, which is almost completely useless. If you work out the
>>> resulting instruction stream, you'll have a
flight 132471 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132471/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
Stefan,
I hope you would not mind if I put your Suggested-by for v2?
On 25.01.19 08:55, Andrii Anisov wrote:
You are absolutely correct.
--
Sincerely,
Andrii Anisov.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
On Thu, Jan 24, 2019 at 05:48:27PM +, George Dunlap wrote:
> Remove "chatty" and redundant information from the xl man page;
> restrict it to functional descriptions only, and point instead to
> qemu-depriv.pandoc and SUPPORT.md as locations for "canonical"
> information.
>
> Add a man page
On Fri, Jan 25, 2019 at 10:36:13AM +0100, Roger Pau Monné wrote:
>Thanks for the patch!
>
>On Fri, Jan 25, 2019 at 04:26:59PM +0800, Chao Gao wrote:
>> I find some pass-thru devices don't work any more across guest
>> reboot. Assigning it to another domain also meets the same issue. And
>> the
Hi,
On 23/01/2019 14:59, Andrew Cooper wrote:
+/*
+ * For each allocated vcpu, d->vcpu[X]->vcpu_id == X
+ *
+ * During construction, all vcpus in d->vcpu[] are allocated sequentially, and
+ * in ascending order. Therefore, if d->vcpu[N] exists (e.g. derived from
+ * current), all vcpus with an
On 25/01/2019 10:25, Jan Beulich wrote:
On 24.01.19 at 19:28, wrote:
>> Code clearing the "Suppress VE" bit in an EPT entry isn't nececsserily
>> running
>> in current context. In ALTP2M_external mode, it definitely is not, and in PV
>> context, vcpu_altp2m(current) acts upon the HVM
On Tue, Jan 22, 2019 at 09:28:16AM -0700, Jan Beulich wrote:
On 22.01.19 at 17:08, wrote:
>> On Tue, Jan 22, 2019 at 01:24:48AM -0700, Jan Beulich wrote:
>> On 22.01.19 at 06:50, wrote:
On Wed, Jan 16, 2019 at 11:38:23AM +0100, Roger Pau Monné wrote:
>On Wed, Jan 16, 2019 at
On 1/25/19 11:14, Jan Beulich wrote:
On 24.01.19 at 22:29, wrote:
>> Worse is the "evaluate condition, stash result, fence, use variable"
>> option, which is almost completely useless. If you work out the
>> resulting instruction stream, you'll have a conditional expression
>> calculated
flight 132455 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132455/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail never pass
test-amd64-i386-xl-pvshim12
>>> On 24.01.19 at 19:28, wrote:
> Code clearing the "Suppress VE" bit in an EPT entry isn't nececsserily running
> in current context. In ALTP2M_external mode, it definitely is not, and in PV
> context, vcpu_altp2m(current) acts upon the HVM union.
>
> Even if we could sensibly resolve the
>>> On 24.01.19 at 22:29, wrote:
> Worse is the "evaluate condition, stash result, fence, use variable"
> option, which is almost completely useless. If you work out the
> resulting instruction stream, you'll have a conditional expression
> calculated down into a register, then a fence, then a
Hi,
> -Original Message-
> From: h...@infradead.org [mailto:h...@infradead.org]
> Sent: 2019年1月24日 5:14
> To: Stefano Stabellini
> Cc: h...@infradead.org; Peng Fan ; m...@redhat.com;
> jasow...@redhat.com; xen-devel@lists.xenproject.org;
> linux-remotep...@vger.kernel.org;
Thanks for the patch!
On Fri, Jan 25, 2019 at 04:26:59PM +0800, Chao Gao wrote:
> I find some pass-thru devices don't work any more across guest
> reboot. Assigning it to another domain also meets the same issue. And
> the only way to make it work again is un-binding and binding it to
> pciback.
>>> On 24.01.19 at 20:50, wrote:
> On 1/24/19 17:56, Jan Beulich wrote:
> On 23.01.19 at 12:57, wrote:
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -368,8 +368,14 @@ int evtchn_bind_virq(evtchn_bind_virq_t *bind,
>>> evtchn_port_t port)
>>> if (
>>> On 24.01.19 at 21:33, wrote:
> On 24/01/2019 12:07, Norbert Manthey wrote:
>> On 1/23/19 14:20, Jan Beulich wrote:
>> On 23.01.19 at 12:51, wrote:
--- a/xen/include/xen/nospec.h
+++ b/xen/include/xen/nospec.h
@@ -58,6 +58,21 @@ static inline unsigned long
>
Also clean up current code by moving initialization of arch specific
fields out of common code.
Signed-off-by: Chao Gao
Reviewed-by: Jan Beulich
Reviewed-by: Roger Pau Monné
---
Changes in v5:
- rename init_arch_msix to arch_init_msix
- place arch_init_msix right after the definition of
I find some pass-thru devices don't work any more across guest
reboot. Assigning it to another domain also meets the same issue. And
the only way to make it work again is un-binding and binding it to
pciback. Someone reported this issue one year ago [1].
If the device's driver doesn't disable
When I destroyed a guest with 'xl destroy', I found the warning
in msi_set_mask_bit() in Xen was triggered. After adding "WARN_ON(1)"
to that place, I got the call trace below:
(XEN) Xen call trace:
(XEN)[] msi.c#msi_set_mask_bit+0x1da/0x29b
(XEN)[] guest_mask_msi_irq+0x1c/0x1e
(XEN)
74 matches
Mail list logo
