Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL

[Jan Beulich]

>>> On 04.02.19 at 20:08,  wrote:
> On Mon, 4 Feb 2019, Jan Beulich wrote:
>> And btw - I can't judge on b. anyway, as I still don't know what
>> exactly MISRA compliance is to mean, with the rules to adhere to
>> suitably justified.
> 
> I can't pretend to know exactly what MISRAC compliance means for this
> specific issue, but we do have the recommended way forward by the
> compliance experts, which also matches the rough understanding of most
> of the engineers involved in this discussion. Picking the option
> suggested by the MISRAC people, could be a decent way to settle this
> debate?

It could be, if their reasoning was acceptable, which to me in particular
means (a) backed by references to the C spec and (b) not resorting to
use compiler bugs as an excuse for (pseudo) rules. But I'm afraid by
saying this I'm not really opening up any new avenues...

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v7 09/15] argo: implement the sendv op; evtchn: expose send_guest_global_virq

[Jan Beulich]

>>> On 05.02.19 at 01:52,  wrote:
> To make Argo's current Experimental status clearer, with the ABI stability
> status that accords, I propose the following addition to SUPPORT.md:
> 
> Within section: ## Virtual Hardware, Hypervisor
> 
> ### Argo: Inter-domain message delivery by hypercall.
> 
> Status: Experimental

Ah yes. It's odd enough that no-one so far has noticed the need
for an addition there. I think we're still on the path of learning that
feature additions need new entries there.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12 2/8] amd/ntp: remove assert that prevents creating 2M MMIO entries

[Jan Beulich]

>>> On 04.02.19 at 18:18,  wrote:
> On Mon, Feb 04, 2019 at 09:56:22AM -0700, Jan Beulich wrote:
>> >>> On 30.01.19 at 11:36,  wrote:
>> > The assert was originally added to make sure that higher order
>> > regions (> PAGE_ORDER_4K) could not be used to bypass the
>> > mmio_ro_ranges check performed by p2m_type_to_flags.
>> > 
>> > This however is already checked in set_mmio_p2m_entry, which makes
>> > sure that higher order mappings don't overlap with mmio_ro_ranges,
>> > thus allowing the creation of high order MMIO mappings safely.
>> 
>> Well, the assertions were added to make sure no other code
>> path appears that violates this requirement. Arguably e.g.
>> set_identity_p2m_entry() could gain an order parameter and
>> then try to establish larger p2m_mmio_direct entries.
>> 
>> Don't get me wrong, I don't object to the removal of the
>> assertions, but the description makes it sound as if they were
>> entirely redundant. Even better would be though if they
>> could be extended to keep triggering in "bad" cases.
> 
> I could add something like:
> 
> ASSERT(!rangeset_overlaps_range(mmio_ro_ranges, mfn_x(mfn),
> mfn_x(mfn) + PFN_DOWN(MB(2;
> 
> I think this should be safe and would trigger in case of misuse.

Looks okay, if slightly extended (or made conditional) to exclude
the addition of MB(2) to MFN_INVALID to wrap and potentially
hit a r/o range in the low 1Mb.

>> > --- a/xen/arch/x86/mm/p2m-pt.c
>> > +++ b/xen/arch/x86/mm/p2m-pt.c
>> > @@ -668,7 +668,6 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, 
>> > mfn_t mfn,
>> >  }
>> >  
>> >  ASSERT(p2m_flags_to_type(flags) != p2m_ioreq_server);
>> > -ASSERT(!mfn_valid(mfn) || p2mt != p2m_mmio_direct);
>> >  l2e_content = mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt)
>> >  ? p2m_l2e_from_pfn(mfn_x(mfn),
>> > p2m_type_to_flags(p2m, p2mt, mfn, 1))
>> 
>> There's a similar check in the 1G mapping logic several lines up. Why
>> does that not also need removing?
> 
> So far mmio_order doesn't allow creation of 1G entries for mmio
> regions, that's why I haven't removed that assert. I can however
> replace it with the assert suggested above properly adjusted for 1G
> pages.

Yes, this or explicitly say in the description why you leave alone the
other one.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12 1/8] dom0/pvh: align allocation and mapping order to start address

[Jan Beulich]

>>> On 04.02.19 at 18:11,  wrote:
> On Mon, Feb 04, 2019 at 09:41:34AM -0700, Jan Beulich wrote:
>> >>> On 30.01.19 at 11:36,  wrote:
>> > Due to the recent changes in the iommu mapping logic, the start
>> > addresses provided need to be aligned to the order intended to be
>> > mapped.
>> 
>> Irrespective of your reply to Wei's similar request (where you've
>> provided links to mails showing crashes) I'd like you to explain
>> this better. This is in particular because I don't really see what
>> "recent changes in the iommu mapping logic" you talk about.
> 
> Commit 725bf00a87f ("iommu / p2m: add a page_order parameter to
> iommu_map/unmap_page()...") added the following two asserts to
> iommu_map:
> 
> ASSERT(IS_ALIGNED(dfn_x(dfn), (1ul << page_order)));
> ASSERT(IS_ALIGNED(mfn_x(mfn), (1ul << page_order)));
> 
> Previously iommu_map would add unaligned entries without complaining,
> but now in debug builds the assert will trigger.

Right, but the assertions were added to ensure expected behavior,
not to change anything. It was a bug to call the functions without
suitably aligned frame numbers.

> Maybe adding a 'Fixes' tag would help identifying what this commit is
> trying to address?

Yes, but as per above it wouldn't be the commit adding the assertions
that the one here fixes (and hence I think the wording of the commit
message ought to change as well).

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL

[Juergen Gross]

On 04/02/2019 20:08, Stefano Stabellini wrote:
> On Mon, 4 Feb 2019, Jan Beulich wrote:
> On 01.02.19 at 19:52,  wrote:
>>
>> I'm not going to reply in detail to all of what you wrote about fanatics,
>> but I would like to say that I think compiler people less of that than
>> you appear to imply, at least the ones I know. In particular, they can
>> be convinced of there being bugs by pointing out what aspect of the
>> standard their implementation violates. (Of course there are also
>> going to be areas where interpretations of the standard vary too
>> much to come to an agreement.)
>>
>>> Improvements this series seeks to make, as I understand it, include
>>> (in order of urgency):
>>>
>>> 1. Fixing one concrete instance of "UB hazard"
>>
>> Right, and we want to work around compiler bugs here.
>>
>>> 2. Minimize risk of further "UB hazard" in this bit of functionality
>>> 3. Retain the effort Stefano has put in identifying all the places
>>> where such UB hazards need to be addressed.
>>> 4. Move towards MISRA-C compliance.
>>>
>>> As far as I can tell, primary objections you've leveled at the options
>>> which try to address 2-4 are:
>>>
>>> a. "UB hazard" still not zero
>>> b. MISRA compliancy no 100%
>>> c. Ugly
>>> d. Inefficient
>>>
>>> (Obviously some proposals have had more technical discussion.)
>>>
>>> Anything I missed?
>>
>> I don't think so, especially since various aspects can fall under "ugly"
>> and/or "inefficient". What I'm not sure I see is what you mean to
>> express with all you wrote in terms of finding a way out of the
>> current situation (besides requesting a vote): Improving on a. and
>> b. is not a good excuse to extend c., at least not unequivocally.
>> Whether d. actually matters is a separate aspect, partly because it
>> may mean different things (it could e.g. be taken as another
>> wording for a. and b.).
> 
> I would be OK with a vote (or Juergen making a decision for us), but
> this issue is not so fundamentally critical that I want to move forward
> with it at the cost of making one or more maintainers unhappy. Ideally,
> I would like to find an option that is acceptable for everybody.
> Unfortunately, it doesn't look like it's possible.

I can make a decision whether the series is fine for 4.12, but for being
ready to be committed I can only have an opinion or make a suggestion.

In my opinion we should try to move forward. Fighting opinions of
compiler developers won't help as George pointed out in a slightly
sarcastic way. ;-)

While a completely future proof solution would be nice I don't think
this is achievable now. And we should be aware that a solution being
better than what we have today should be preferred over a perfect
solution which doesn't work due to compiler issues.

>> And btw - I can't judge on b. anyway, as I still don't know what
>> exactly MISRA compliance is to mean, with the rules to adhere to
>> suitably justified.
> 
> I can't pretend to know exactly what MISRAC compliance means for this
> specific issue, but we do have the recommended way forward by the
> compliance experts, which also matches the rough understanding of most
> of the engineers involved in this discussion. Picking the option
> suggested by the MISRAC people, could be a decent way to settle this
> debate?

This would be my suggestion, too.


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12 v2] arm: gic-v3: deactivate SGI/PPI during initialization

[Peng Fan]

> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: 2019年2月3日 0:04
> To: Peng Fan ; sstabell...@kernel.org; jgr...@suse.com
> Cc: xen-devel@lists.xenproject.org
> Subject: Re: [PATCH for-4.12 v2] arm: gic-v3: deactivate SGI/PPI during
> initialization
> 
> 
> 
> On 2/2/19 12:54 PM, Peng Fan wrote:
> > Hi Julien
> 
> Hi Peng,
> 
> >> -Original Message-
> >> From: Julien Grall [mailto:julien.gr...@arm.com]
> >> Sent: 2019年2月1日 18:41
> >> To: Peng Fan ; sstabell...@kernel.org;
> >> jgr...@suse.com
> >> Cc: xen-devel@lists.xenproject.org
> >> Subject: Re: [PATCH for-4.12 v2] arm: gic-v3: deactivate SGI/PPI
> >> during initialization
> >>
> >> Hi,
> >>
> >> We spoke about SPIs in the previous version. Why aren't they
> >> de-activated here?
> >
> > According to GIC-V3 " 8.9.5 GICD_ICACTIVER, Interrupt Clear-Active
> Registers, n = 0 - 31"
> > "
> > Some or all RW fields of this register have defined reset values.
> > When this register has an architecturally-defined reset value, this field
> resets to 0.
> > "
> 
> I can't find this wording in the last spec (IHI0069E). Can you please give the
> version of the specific version of the spec when quoting it?

The spec I use is IHI0069D_gic_architecture_specification. Will add the version 
in
future patches when needed.

> 
> >
> > So I think we no need to deactivated, because it has reset values 0
> 
> The specification is about the reset value from the hardware, it does not tell
> you how the firmware (or the previous kernel when using kexec) is going to
> leave the interrupts. For instance, as I pointed out in a different thread, 
> Xen
> may reboot with SPIs activated. This can happen if you receive the
> reboot/power off request while handling an SPI.

Thanks, just sent out v3 including the deactivation of SPI.

> 
> >
> >>
> >> On 1/30/19 2:00 PM, Peng Fan wrote:
> >>> On i.MX8, we implemented partition reboot which means Cortex-A
> >>> reboot will not impact M4 cores and System control Unit core.
> >>> However GICv3 is not reset because we also need to support A72
> >>> Cluster reboot without affecting A53 Cluster.
> >>>
> >>> The gic-v3 controller is configured with EOImode to 1, so during xen
> >>> reboot, there is a function call "smp_call_function(halt_this_cpu, NULL,
> 0);"
> >>> , but halt_this_cpu never return, that means other CPUs have no
> >>> chance to deactivate the SGI interrupt, because the deactivate_irq
> >>> operation is at the end of do_sgi. During the next boot of Xen, CPU0
> >>> will issue GIC_SGI_CALL_FUNCTION to other CPUs. As the Active state
> >>> for SGI is left untouched during the reboot, the
> >>> GIC_SGI_CALL_FUNCTION will still be active on the non-boot CPUs.
> >>> This means the interrupt cannot be triggered again until it get
> deactivated.
> >>>
> >>> And according to IHI0069D_gic_architecture_specification, chapter
> >>> "8.11.3 GICR_ICACTIVER0, Interrupt Clear-Active Register 0", the RW
> >>> field of GICR_ICACTIVER0 resets to a value that is architecturally
> >> UNKNOWN.
> >>>
> >>> So set a fixed value during gic-v3 initialization to make sure
> >>> interrupts are in deactivated state.
> >>
> >> It is a bit unclear what you mean by "fixed value" here. The only
> >> thing you do is clearing active state. So a better wording is "So
> >> make sure all interrupts are deactivated at during initialization by 
> >> clearing
> the state".
> >>
> >> How about SPIs?
> >
> > Replied above. I could add the following to the patch if you think it
> > needed, I am not sure whether it is valid that SPI is in active state when 
> > Xen
> booting.
> 
> See above, I think this is valid and can happen today.
> 
> >
> > diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index
> > 1c1d2604f3..5b9c5559a7 100644
> > --- a/xen/arch/arm/gic-v3.c
> > +++ b/xen/arch/arm/gic-v3.c
> > @@ -622,9 +622,12 @@ static void __init gicv3_dist_init(void)
> >   writel_relaxed(priority, GICD + GICD_IPRIORITYR + (i / 4) * 4);
> >   }
> >
> > -/* Disable all global interrupts */
> > +/* Disable/deactivate all global interrupts */
> >   for ( i = NR_GIC_LOCAL_IRQS; i < nr_lines; i += 32 )
> > +{
> >   writel_relaxed(0x, GICD + GICD_ICENABLER + (i / 32)
> > * 4);
> > +writel_relaxed(0x, GICD + GICD_ICACTIVER + (i / 32) * 4);
> > +}
> >
> >   /*
> >* Configure SPIs as non-secure Group-1. This will only matter
> 
> This chunk looks good. I will also write a patch for GICv2 doing the same.

Thanks,
Peng.

> 
> Cheers,
> 
> --
> Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH v3 for-4.12] arm: gic-v3: deactivate interrupts during initialization

[Peng Fan]

On i.MX8, we implemented partition reboot which means Cortex-A reboot
will not impact M4 cores and System control Unit core. However GICv3
is not reset because we also need to support A72 Cluster reboot without
affecting A53 Cluster.

The gic-v3 controller is configured with EOImode to 1, so during xen
reboot, there is a function call "smp_call_function(halt_this_cpu, NULL, 0);"
, but halt_this_cpu never return, that means other CPUs have no chance to
deactivate the SGI interrupt, because the deactivate_irq operation is at
the end of do_sgi. During the next boot of Xen, CPU0 will issue
GIC_SGI_CALL_FUNCTION to other CPUs. As the Active state for SGI is left
untouched during the reboot, the GIC_SGI_CALL_FUNCTION will still be active
on the non-boot CPUs. This means the interrupt cannot be triggered again
until it get deactivated.

And according to IHI0069D_gic_architecture_specification, chapter
"8.11.3 GICR_ICACTIVER0, Interrupt Clear-Active Register 0", the RW
field of GICR_ICACTIVER0 resets to a value that is architecturally UNKNOWN.
So make sure all interrupts are deactivated at during initialization by
clearing the state.

Signed-off-by: Peng Fan 
---

V3:
  SGI/PPI->interrupts.
  refine commit log.
  Deactivate SPI
V2:
  refine commit log
  deactivate SGI/PPI.
  No need for SPI, because Some or all RW fields of this GICD_ICACTIVER
  have defined reset values

 xen/arch/arm/gic-v3.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
index c9200d24e1..0f6cbf6224 100644
--- a/xen/arch/arm/gic-v3.c
+++ b/xen/arch/arm/gic-v3.c
@@ -626,9 +626,12 @@ static void __init gicv3_dist_init(void)
 writel_relaxed(priority, GICD + GICD_IPRIORITYR + (i / 4) * 4);
 }
 
-/* Disable all global interrupts */
+/* Disable/deactivate all global interrupts */
 for ( i = NR_GIC_LOCAL_IRQS; i < nr_lines; i += 32 )
+{
 writel_relaxed(0x, GICD + GICD_ICENABLER + (i / 32) * 4);
+writel_relaxed(0x, GICD + GICD_ICACTIVER + (i / 32) * 4);
+}
 
 /*
  * Configure SPIs as non-secure Group-1. This will only matter
@@ -834,6 +837,11 @@ static int gicv3_cpu_init(void)
 writel_relaxed(priority,
 GICD_RDIST_SGI_BASE + GICR_IPRIORITYR0 + (i / 4) * 4);
 
+/*
+ * The activate state is unknown at boot, so make sure all
+ * SGIs and PPIs are de-activated.
+ */
+writel_relaxed(0x, GICD_RDIST_SGI_BASE + GICR_ICACTIVER0);
 /*
  * Disable all PPI interrupts, ensure all SGI interrupts are
  * enabled.
-- 
2.14.1


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12] xen/arm: irq: End cleanly spurious interrupt

[Juergen Gross]

On 05/02/2019 01:54, Stefano Stabellini wrote:
> On Mon, 28 Jan 2019, Julien Grall wrote:
>> no_irq_type handlers are used when an IRQ does not have action attached.
>> This is useful to detect misconfiguration between the interrupt
>> controller and the software.
>>
>> Currently, all the handlers will do nothing on spurious interrupt. This
>> means if such interrupt is received, the priority of the interrupt will
>> not be dropped and the processor will lose the ability to receive any
>> interrupt lower or equal to the priority.
>>
>> Spurious interrupt can happen while releasing interrupt assigned to
>> guest (happen during domain destruction). The interaction is roughly
>>
>> CPU0CPU1
>> release_guest_irq(A)
>> spin_lock(>lock)
>> gic_remove_irq_from_guest
>> receive IRQ A
>> spin_lock(>lock)
>> desc->handler->shutdown()
>>   set_bit(IRQ_DISABLED)
>> desc->handler = _irq_type
>> spin_unlock(>lock)
>> desc->handler->end();
>> spin_unlock(>lock)
>>
>> Because the no_irq_type.end callback is implemented as a NOP, CPU1 will
>> not drop the priority of the interrupt. So the CPU will not be able to
>> receive any interrupt route to any guest afterwards.
>>
>> The problem can be prevented by dropping the priority and deactivating
>> the interrupt via gic_hw_ops->gic_host_irq->end().
>>
>> Note that, for now, interrupt used by Xen are safe because it is not
>> using no_irq_type on release.
>>
>> Signed-off-by: Julien Grall 
> 
> Reviewed-by: Stefano Stabellini 
> 
> Hi Juergen,
> 
> Can I have your relese ack on this fix?

Release-acked-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.10-testing test] 132815: regressions - FAIL

[osstest service owner]

flight 132815 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132815/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   6 xen-buildfail REGR. vs. 132630
 build-i386-xsm6 xen-buildfail REGR. vs. 132630
 build-amd64-xsm   6 xen-buildfail REGR. vs. 132630
 build-i3866 xen-buildfail REGR. vs. 132630

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-credit2  16 guest-start/debian.repeat  fail pass in 132762

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-xl   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-amd64-i386-livepatch 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-pvhv2-amd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 1 build-check(1) blocked 
n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-xtf-amd64-amd64-21 build-check(1)   blocked  n/a
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-pvhv2-intel  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemuu-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-livepatch1 build-check(1)   blocked  n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 

[Xen-devel] [xen-4.9-testing bisection] complete build-i386-xsm

[osstest service owner]

branch xen-4.9-testing
xenbranch xen-4.9-testing
job build-i386-xsm
testid xen-build

Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  678920e58463a27c0878b3d070e18811a294cce8
  Bug not present: 3a3f48a59e4269c6111e2c30f31a49d76322bf65
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/132917/


  commit 678920e58463a27c0878b3d070e18811a294cce8
  Author: Jan Beulich 
  Date:   Fri Feb 1 12:05:11 2019 +0100
  
  x86emul: fix 3-operand IMUL
  
  While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
  as its title says, it broke the 3-operand form by uniformly using AL/AX/
  EAX/RAX as second source operand. Fix this and add tests covering both
  cases.
  
  Reported-by: Andrei Lutas 
  Signed-off-by: Jan Beulich 
  Tested-by: Razvan Cojocaru 
  Reviewed-by: Andrew Cooper 
  master commit: 19232b378fab04997c0612e5c19e82c29b59d99e
  master date: 2018-12-18 14:27:09 +0100


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.9-testing/build-i386-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.9-testing/build-i386-xsm.xen-build 
--summary-out=tmp/132917.bisection-summary --basis-template=130954 
--blessings=real,real-bisect xen-4.9-testing build-i386-xsm xen-build
Searching for failure / basis pass:
 132783 fail [host=rimava1] / 132582 [host=albana1] 132484 ok.
Failure / basis pass flights: 132783 / 132484
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
04f7fbcc8fcab7f3a59e33798b74582b55dd735a
Basis pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
19fc44f4a180158f27788e60f6da78ea29f68a33
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#aad23066e4b27296d219b9123393fbe2a5a885bb-aad23066e4b27296d219b9123393fbe2a5a885bb
 
git://xenbits.xen.org/xen.git#19fc44f4a180158f27788e60f6da78ea29f68a33-04f7fbcc8fcab7f3a59e33798b74582b55dd735a
Loaded 1001 nodes in revision graph
Searching for test results:
 132484 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
19fc44f4a180158f27788e60f6da78ea29f68a33
 132582 [host=albana1]
 132747 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
04f7fbcc8fcab7f3a59e33798b74582b55dd735a
 132879 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
19fc44f4a180158f27788e60f6da78ea29f68a33
 132881 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
04f7fbcc8fcab7f3a59e33798b74582b55dd735a
 132883 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
78b2732ec5ce883f7061fa2b766b359bb08bba19
 132886 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
 132783 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
04f7fbcc8fcab7f3a59e33798b74582b55dd735a
 132907 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
3a3f48a59e4269c6111e2c30f31a49d76322bf65
 132888 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
4f9a486899b643a3143a77a032f6c2069cb1e40a
 132892 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
3a3f48a59e4269c6111e2c30f31a49d76322bf65
 132917 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
 132895 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
 132902 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
3a3f48a59e4269c6111e2c30f31a49d76322bf65
 132905 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
Searching for interesting versions
 Result found: flight 132484 (pass), for basis pass
 Result found: flight 132747 (fail), for basis failure
 Repro found: flight 132879 (pass), for basis pass
 Repro found: flight 132881 (fail), 

[Xen-devel] [linux-3.18 test] 132798: regressions - FAIL

[osstest service owner]

flight 132798 linux-3.18 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132798/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 128858
 test-amd64-i386-libvirt-xsm   7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-multivcpu  7 xen-bootfail REGR. vs. 128858
 test-amd64-amd64-libvirt  7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-qemuu-debianhvm-amd64  7 xen-bootfail REGR. vs. 128858
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR. 
vs. 128858
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. 
vs. 128858
 test-amd64-i386-pair 10 xen-boot/src_hostfail REGR. vs. 128858
 test-amd64-i386-pair 11 xen-boot/dst_hostfail REGR. vs. 128858
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow 7 xen-boot fail REGR. vs. 
128858
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-credit2   7 xen-boot fail REGR. vs. 128858
 test-amd64-i386-freebsd10-amd64  7 xen-boot  fail REGR. vs. 128858
 test-amd64-amd64-xl   7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-pvshim7 xen-boot fail REGR. vs. 128858
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 128858
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 128858
 test-amd64-i386-xl-qemuu-ovmf-amd64  7 xen-boot  fail REGR. vs. 128858
 test-amd64-amd64-libvirt-pair 10 xen-boot/src_host   fail REGR. vs. 128858
 test-amd64-amd64-libvirt-pair 11 xen-boot/dst_host   fail REGR. vs. 128858
 test-amd64-amd64-qemuu-nested-intel  7 xen-boot  fail REGR. vs. 128858
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-xl-qemuu-ovmf-amd64  7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-rumprun-amd64  7 xen-boot   fail REGR. vs. 128858
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 128858
 test-amd64-amd64-xl-xsm   7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-libvirt-xsm  7 xen-boot fail REGR. vs. 128858
 test-amd64-amd64-pair10 xen-boot/src_hostfail REGR. vs. 128858
 test-amd64-amd64-pair11 xen-boot/dst_hostfail REGR. vs. 128858

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-libvirt 16 guest-start/debian.repeat fail in 132579 pass in 
132798
 test-amd64-i386-libvirt-pair 10 xen-boot/src_host  fail pass in 132579
 test-amd64-i386-libvirt-pair 11 xen-boot/dst_host  fail pass in 132579
 test-armhf-armhf-libvirt-raw 11 guest-startfail pass in 132652

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-rtds  7 xen-boot fail REGR. vs. 128858

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit1   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail in 132579 like 
128858
 test-armhf-armhf-xl-arndale 13 migrate-support-check fail in 132579 never pass
 test-armhf-armhf-xl-arndale 14 saverestore-support-check fail in 132579 never 
pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-check fail in 132579 never pass
 test-armhf-armhf-xl-vhd 12 migrate-support-check fail in 132579 never pass
 test-armhf-armhf-xl-vhd 13 saverestore-support-check fail in 132579 never pass
 test-amd64-amd64-examine  4 memdisk-try-append  fail in 132652 like 128807
 test-armhf-armhf-xl-arndale   7 xen-boot fail  like 128841
 test-armhf-armhf-xl-vhd  10 debian-di-installfail  like 128841
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 128858
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 128858
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128858
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 128858
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 128858
 build-arm64-pvops 6 kernel-build 

[Xen-devel] [xen-4.10-testing bisection] complete build-amd64-xsm

[osstest service owner]

branch xen-4.10-testing
xenbranch xen-4.10-testing
job build-amd64-xsm
testid xen-build

Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  500ceac0a2df2c80c77d3b60ad284dc46f4a364b
  Bug not present: 5f428061a5b2dd980b3047c197b5ff9d9757e010
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/132914/


  commit 500ceac0a2df2c80c77d3b60ad284dc46f4a364b
  Author: Jan Beulich 
  Date:   Fri Feb 1 11:46:37 2019 +0100
  
  x86emul: fix 3-operand IMUL
  
  While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
  as its title says, it broke the 3-operand form by uniformly using AL/AX/
  EAX/RAX as second source operand. Fix this and add tests covering both
  cases.
  
  Reported-by: Andrei Lutas 
  Signed-off-by: Jan Beulich 
  Tested-by: Razvan Cojocaru 
  Reviewed-by: Andrew Cooper 
  master commit: 19232b378fab04997c0612e5c19e82c29b59d99e
  master date: 2018-12-18 14:27:09 +0100


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.10-testing/build-amd64-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.10-testing/build-amd64-xsm.xen-build
 --summary-out=tmp/132914.bisection-summary --basis-template=132630 
--blessings=real,real-bisect xen-4.10-testing build-amd64-xsm xen-build
Searching for failure / basis pass:
 132762 fail [host=godello0] / 132630 [host=albana0] 132577 [host=baroque0] 
132485 [host=elbling1] 131257 [host=godello1] 131223 [host=godello1] 131191 
[host=baroque1] 131151 [host=godello1] 131108 ok.
Failure / basis pass flights: 132762 / 131108
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
0695e67102de6b737baf1b88e2cdfccbb2cb56fa
Basis pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
b6e203bc80e9d3e1dc7eb579d9665a77700d78cc
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://xenbits.xen.org/qemu-xen.git#6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2-6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2
 
git://xenbits.xen.org/xen.git#b6e203bc80e9d3e1dc7eb579d9665a77700d78cc-0695e67102de6b737baf1b88e2cdfccbb2cb56fa
Loaded 1001 nodes in revision graph
Searching for test results:
 130820 [host=huxelrebe1]
 130854 [host=rimava1]
 130893 [host=albana0]
 131108 pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
b6e203bc80e9d3e1dc7eb579d9665a77700d78cc
 131061 [host=albana0]
 131151 [host=godello1]
 131191 [host=baroque1]
 131223 [host=godello1]
 131257 [host=godello1]
 132485 [host=elbling1]
 132577 [host=baroque0]
 132630 [host=albana0]
 132700 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
d5513db9c32c21905c0a73778a53fa1a27f3321e
 132762 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
0695e67102de6b737baf1b88e2cdfccbb2cb56fa
 132891 pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
b6e203bc80e9d3e1dc7eb579d9665a77700d78cc
 132896 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
0695e67102de6b737baf1b88e2cdfccbb2cb56fa
 132897 pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
223fe484090915139799ed0258764c3149864cbf
 132898 pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
5f428061a5b2dd980b3047c197b5ff9d9757e010
 132900 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
8774be8a40ef82116948e9f1955c86e3e2d3bdba
 132901 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
500ceac0a2df2c80c77d3b60ad284dc46f4a364b
 132904 pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
5f428061a5b2dd980b3047c197b5ff9d9757e010
 132906 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
500ceac0a2df2c80c77d3b60ad284dc46f4a364b
 132912 pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
5f428061a5b2dd980b3047c197b5ff9d9757e010
 132914 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 

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

[osstest service owner]

flight 132804 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132804/

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. 132599
 test-amd64-amd64-xl-qemuu-ws16-amd64 15 guest-saverestore.2 fail REGR. vs. 
132599

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 132599

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-credit2   7 xen-bootfail baseline untested
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail like 
132561
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 132599
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail like 132599
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 132599
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 132599
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 132599
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 132599
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stopfail like 132599
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 linux8834f5600cf3c8db365e18a3d5cac2c2780c81e5
baseline version:
 linux4aa9fc2a435abe95a1e8d7f8c7b3d6356514b37a

Last test of basis   132599  2019-01-30 01:09:59 Z6 days
Failing since132669  2019-01-31 12:06:18 Z4 days3 attempts
Testing same since   132804  2019-02-04 02:24:30 Z1 days1 attempts

Re: [Xen-devel] [PATCH v7 10/15] argo: implement the notify op

[Christopher Clark]

On Mon, Feb 4, 2019 at 7:12 AM Jan Beulich  wrote:
>
> >>> On 31.01.19 at 05:28,  wrote:
> > @@ -1802,6 +2157,21 @@ do_argo_op(unsigned int cmd, 
> > XEN_GUEST_HANDLE_PARAM(void) arg1,
> >  break;
> >  }
> >
> > +case XEN_ARGO_OP_notify:
> > +{
> > +XEN_GUEST_HANDLE_PARAM(xen_argo_ring_data_t) ring_data_hnd =
> > +   guest_handle_cast(arg1, xen_argo_ring_data_t);
> > +
> > +if ( unlikely((!guest_handle_is_null(arg2)) || arg3 || arg4) )
> > +{
> > +rc = -EINVAL;
> > +break;
> > +}
> > +
> > +rc = notify(currd, ring_data_hnd);
> > +break;
> > +}
> > +
> >  default:
> >  rc = -EOPNOTSUPP;
> >  break;
> > @@ -1912,6 +2282,21 @@ compat_argo_op(unsigned int cmd, 
> > XEN_GUEST_HANDLE_PARAM(void) arg1,
> >  break;
> >  }
> >
> > +case XEN_ARGO_OP_notify:
> > +{
> > +XEN_GUEST_HANDLE_PARAM(xen_argo_ring_data_t) ring_data_hnd =
> > +   guest_handle_cast(arg1, xen_argo_ring_data_t);
> > +
> > +if ( unlikely((!guest_handle_is_null(arg2)) || arg3 || arg4) )
> > +{
> > +rc = -EINVAL;
> > +break;
> > +}
> > +
> > +rc = notify(currd, ring_data_hnd);
> > +break;
> > +}
>
> At the example of this (likely applies to earlier patches as much): Aren't
> you afraid of this recurring duplication? It's quite easy, especially when
> the functions here grow a little further, for someone to forget updating
> one (more likely the compat one obviously). Did you consider forwarding
> all operations not needing translation straight into do_argo_op(), and
> handling only the sendv one here?

Ack, ok.

Christopher

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12] arm/p2m: do not invalidate p2m root if it is shared with IOMMU

[Stefano Stabellini]

On Tue, 29 Jan 2019, Andrii Anisov wrote:
> On 29.01.19 17:17, Julien Grall wrote:
> > No we don't have to.
> I mean, EPAM systems as a XEN based virtualization solution provider have to
> handle that issue.
> 
> > They have been lucky to see this working even on baremetal.
> > Set/Way operations have been dropped from Linux for a long time, so I really
> > can't see why a proprietary driver is still using them.
> I guess there were some performance concerns. And they are really lucky, so
> they did not face related issues on baremetal.
> 
> > I think the policy for Set/Way operations is correct in Xen. This works to
> > avoid breaking basic case but the most complex one are going to break.
> Maybe it worth to get a notification from XEN, i.e. WARN_ONCE, saying that
> Set/Way cache operations are undesirable in VM and will lead to the system
> performance drop, or even instability in case of IOMMU sharing p2m with CPU.
> This might save days of debugging to XEN on ARM users.

A WARN_ONCE would be nice. If you send a patch I would be happy to take
in 4.12 (if the release manager agrees).


> > You solution is only delaying the real fix
> I would not say it is delaying the fix, but allows us to have a functional
> system until we get that fix.
> 
> > (i.e removing Set/Way operation from the software). So here the best
> > solution is to go to the vendor and ask them to fix their software.
> Actually escalation the issue to the vendor is one of our next steps here.

You really want to fix this in the Linux driver if you can, because
you'll get better performance and a more stable system. In the short
term, I would suggest you keep the work-around in your private tree.
However, do let us know how the escalation with the vendor proceeds and
if you have any troubles with it. Julien and I would be happy to provide
help in terms of information and docs on the reasons why this should be
fixed in the driver. Julien might even be able to help further via his
employer.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12] gic-vgic: fix assert condition

[Stefano Stabellini]

Hi Andrii,

Please send an update soon as I would like to get it in 4.12.


Juergen,

I would like to have your release ack on this.


On Fri, 25 Jan 2019, Andrii Anisov wrote:
> 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
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12] xen/arm: irq: End cleanly spurious interrupt

[Stefano Stabellini]

On Mon, 28 Jan 2019, Julien Grall wrote:
> no_irq_type handlers are used when an IRQ does not have action attached.
> This is useful to detect misconfiguration between the interrupt
> controller and the software.
> 
> Currently, all the handlers will do nothing on spurious interrupt. This
> means if such interrupt is received, the priority of the interrupt will
> not be dropped and the processor will lose the ability to receive any
> interrupt lower or equal to the priority.
> 
> Spurious interrupt can happen while releasing interrupt assigned to
> guest (happen during domain destruction). The interaction is roughly
> 
> CPU0CPU1
> release_guest_irq(A)
> spin_lock(>lock)
> gic_remove_irq_from_guest
> receive IRQ A
> spin_lock(>lock)
> desc->handler->shutdown()
>   set_bit(IRQ_DISABLED)
> desc->handler = _irq_type
> spin_unlock(>lock)
> desc->handler->end();
> spin_unlock(>lock)
> 
> Because the no_irq_type.end callback is implemented as a NOP, CPU1 will
> not drop the priority of the interrupt. So the CPU will not be able to
> receive any interrupt route to any guest afterwards.
> 
> The problem can be prevented by dropping the priority and deactivating
> the interrupt via gic_hw_ops->gic_host_irq->end().
> 
> Note that, for now, interrupt used by Xen are safe because it is not
> using no_irq_type on release.
> 
> Signed-off-by: Julien Grall 

Reviewed-by: Stefano Stabellini 

Hi Juergen,

Can I have your relese ack on this fix?

Cheers,

Stefano


> ---
>  xen/arch/arm/irq.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/arm/irq.c b/xen/arch/arm/irq.c
> index 4a02cc1eba..c51cf333ce 100644
> --- a/xen/arch/arm/irq.c
> +++ b/xen/arch/arm/irq.c
> @@ -44,7 +44,14 @@ static void ack_none(struct irq_desc *irq)
>  printk("unexpected IRQ trap at irq %02x\n", irq->irq);
>  }
>  
> -static void end_none(struct irq_desc *irq) { }
> +static void end_none(struct irq_desc *irq)
> +{
> +/*
> + * Still allow a CPU to end an interrupt if we receive a spurious
> + * interrupt. This will prevent the CPU to lose interrupt forever.
> + */
> +gic_hw_ops->gic_host_irq_type->end(irq);
> +}
>  
>  hw_irq_controller no_irq_type = {
>  .typename = "none",
> -- 
> 2.11.0
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v7 09/15] argo: implement the sendv op; evtchn: expose send_guest_global_virq

[Christopher Clark]

On Mon, Feb 4, 2019 at 6:41 AM Jan Beulich  wrote:
>
> >>> On 31.01.19 at 05:28,  wrote:
> > @@ -1237,6 +1864,54 @@ compat_argo_op(unsigned int cmd, 
> > XEN_GUEST_HANDLE_PARAM(void) arg1,
> >  break;
> >  }
> >
> > +case XEN_ARGO_OP_sendv:
> > +{
> > +xen_argo_send_addr_t send_addr;
> > +xen_argo_iov_t iovs[XEN_ARGO_MAXIOV];
> > +unsigned int i;
> > +unsigned int niov;
> > +
> > +XEN_GUEST_HANDLE_PARAM(xen_argo_send_addr_t) send_addr_hnd =
> > +guest_handle_cast(arg1, xen_argo_send_addr_t);
> > +/* arg2: iovs, arg3: niov, arg4: message_type */
> > +
> > +rc = copy_from_guest(_addr, send_addr_hnd, 1) ? -EFAULT : 0;
> > +if ( rc )
> > +break;
> > +
> > +if ( unlikely(arg3 > XEN_ARGO_MAXIOV) )
> > +{
> > +rc = -EINVAL;
> > +break;
> > +}
> > +niov = array_index_nospec(arg3, XEN_ARGO_MAXIOV + 1);
> > +
> > +/*
> > + * Limited scope for compat_iovs array: enables a single 
> > copy_from_guest
> > + * call and discards the array from the stack before calling sendv.
> > + */
>
> What makes you think the array gets removed from the stack again
> before the call? The typical way of setting up stack frames for a
> function is to allocate the full chunk of space needed at the start
> of the function, and remove it before returning. Without the
> argo_dprintk() after the switch() there would be the potential of
> the sendv() carried out as a tail call, but you can't rely on that.

OK. I've revised the comment.

> With the current XEN_ARGO_MAXIOV value of 8 the overall frame
> size is still tolerable, I would say. But I think you want to add
> BUILD_BUG_ON()s here and in the native handler, such that
> careless bumping of the value won't go unnoticed (but also see
> below).

ack, I've added BUILD_BUG_ON to both.

>
> > --- a/xen/include/public/argo.h
> > +++ b/xen/include/public/argo.h
> > @@ -43,6 +43,28 @@
> >  /* Fixed-width type for "argo port" number. Nothing to do with evtchns. */
> >  typedef uint32_t xen_argo_port_t;
> >
> > +/*
> > + * XEN_ARGO_MAXIOV : maximum number of iovs accepted in a single sendv.
> > + * Caution is required if this value is increased: this determines the 
> > size of
> > + * an array of xen_argo_iov_t structs on the hypervisor stack, so could 
> > cause
> > + * stack overflow if the value is too large.
> > + * The Linux Argo driver never passes more than two iovs.
> > + *
> > + * This value should also not exceed 128 to ensure that the total amount 
> > of data
> > + * posted in a single Argo sendv operation cannot exceed 2^31 bytes, to 
> > reduce
> > + * risk of integer overflow defects:
> > + * Each argo iov can hold ~ 2^24 bytes, so XEN_ARGO_MAXIOV <= 2^(31-24),
> > + * ie. keep XEN_ARGO_MAXIOV <= 128.
> > +*/
> > +#define XEN_ARGO_MAXIOV  8U
>
> How does 2^31 come into play here? uint32_t can hold up to 2^32, and
> you shouldn't be using signed arithmetic anywhere by this time anymore.
> I'm also struggling to see what the "~ 2^24 bytes" refers to - I see nothing
> along these lines added to the public header, and ...
>
> > +typedef struct xen_argo_iov
> > +{
> > +XEN_GUEST_HANDLE(uint8) iov_hnd;
> > +uint32_t iov_len;
>
> ... the field here allows for 2^32-1. Oh, it's XEN_ARGO_MAX_RING_SIZE.
> It would help if the comment cross referenced that name.

I've removed the second paragraph of the comment entirely as it's no longer
accurate or required due to the bounds checking in iov_count.

> Btw., neither of these two maximum values look to be architectural limits,
> so I wonder whether, before declaring the ABI stable, these constants
> shouldn't be purged and replaced by settings the guest is to retrieve via
> hypercall.

That could potentially be useful; though it hasn't been necessary so far.
(fwiw: A determined guest can already retrieve these settings via hypercall.)

To make Argo's current Experimental status clearer, with the ABI stability
status that accords, I propose the following addition to SUPPORT.md:

Within section: ## Virtual Hardware, Hypervisor

### Argo: Inter-domain message delivery by hypercall.

Status: Experimental

Christopher

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v7 02/15] argo: introduce the argo_op hypercall boilerplate

[Stefano Stabellini]

On Wed, 30 Jan 2019, Christopher Clark wrote:
> +#include 
> +#include 
> +
> +long
> +do_argo_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg1,
> +   XEN_GUEST_HANDLE_PARAM(void) arg2, unsigned long arg3,
> +   unsigned long arg4)
> +{
> +return -ENOSYS;
> +}
> +
> +#ifdef CONFIG_COMPAT
> +long
> +compat_argo_op(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg1,
> +   XEN_GUEST_HANDLE_PARAM(void) arg2, unsigned long arg3,
> +   unsigned long arg4)
> +{
> +return -ENOSYS;
> +}
> +#endif

From an ARM perspective, it is not a good idea to use unsigned long as
hypercall parameters because they are going to be of different size on
arm32 and arm64. On ARM, there is no COMPAT code, and we try to keep a
single stable ABI across 32bit and 64bit hypervisors (pointers size
being the only exception and we deal with that using
XEN_GUEST_HANDLE_PARAM).

For this reason, given that we don't need arg3 and arg4 to actually be
64bit, it would be best to use explicitly sized integers instead. I
would use uint32_t or unsigned int for arg3 and arg4. That way, there
are not going to be any ABI compatibility issues between arm32 and arm64
and we could run, and even migrate, 32bit guests to a 64bit hypervisor
without problems.

I know that Andrew expressed concerns about using unsigned int before,
but don't we just need to make sure we are properly ignoring the top
32bit of arg3 and arg4 when the hypervisor is compiled 64bit?

I am really sorry for pointing this out so late in the review cycle, but
I only spotted it now.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [Qemu-devel] [PATCH] configure: Don't add Xen's libs to LDFLAGS

[Eric Blake]

On 1/24/19 12:29 PM, Peter Maydell wrote:
> On Thu, 24 Jan 2019 at 17:40, Eric Blake  wrote:
>>
>> On 1/24/19 2:45 AM, Markus Armbruster wrote:
>>
 Signed-off-by: Michael Tokarev 
 Revieved-by: Michael Tokarev 
>>>
>>> Typo in Reviewed-by.
>>
>> Should we tighten checkpatch.pl to flag suspicious-looking 'xxx-by:'
>> tags, to catch instances of typos?
> 
> Yes, I would vote for having it whitelist the half a dozen
> expected ones and complain about the rest. I think we
> kind of discussed this in the past...

I submitted a patch along those lines:
https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg00910.html

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.10-testing bisection] complete build-i386-xsm

[osstest service owner]

branch xen-4.10-testing
xenbranch xen-4.10-testing
job build-i386-xsm
testid xen-build

Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  500ceac0a2df2c80c77d3b60ad284dc46f4a364b
  Bug not present: 5f428061a5b2dd980b3047c197b5ff9d9757e010
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/132887/


  commit 500ceac0a2df2c80c77d3b60ad284dc46f4a364b
  Author: Jan Beulich 
  Date:   Fri Feb 1 11:46:37 2019 +0100
  
  x86emul: fix 3-operand IMUL
  
  While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
  as its title says, it broke the 3-operand form by uniformly using AL/AX/
  EAX/RAX as second source operand. Fix this and add tests covering both
  cases.
  
  Reported-by: Andrei Lutas 
  Signed-off-by: Jan Beulich 
  Tested-by: Razvan Cojocaru 
  Reviewed-by: Andrew Cooper 
  master commit: 19232b378fab04997c0612e5c19e82c29b59d99e
  master date: 2018-12-18 14:27:09 +0100


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.10-testing/build-i386-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.10-testing/build-i386-xsm.xen-build 
--summary-out=tmp/132887.bisection-summary --basis-template=132630 
--blessings=real,real-bisect xen-4.10-testing build-i386-xsm xen-build
Searching for failure / basis pass:
 132762 fail [host=rimava1] / 132630 ok.
Failure / basis pass flights: 132762 / 132630
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
0695e67102de6b737baf1b88e2cdfccbb2cb56fa
Basis pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
316e4426a185efefa078dd087c89a694b2149be8
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://xenbits.xen.org/qemu-xen.git#6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2-6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2
 
git://xenbits.xen.org/xen.git#316e4426a185efefa078dd087c89a694b2149be8-0695e67102de6b737baf1b88e2cdfccbb2cb56fa
Loaded 1001 nodes in revision graph
Searching for test results:
 132577 [host=albana1]
 132630 pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
316e4426a185efefa078dd087c89a694b2149be8
 132700 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
d5513db9c32c21905c0a73778a53fa1a27f3321e
 132762 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
0695e67102de6b737baf1b88e2cdfccbb2cb56fa
 132885 pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
5f428061a5b2dd980b3047c197b5ff9d9757e010
 132859 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
0695e67102de6b737baf1b88e2cdfccbb2cb56fa
 132868 pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
5f428061a5b2dd980b3047c197b5ff9d9757e010
 132836 pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
316e4426a185efefa078dd087c89a694b2149be8
 132862 pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
d616c1b18d27761f572927bf1f79ba27273afe9a
 132869 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
500ceac0a2df2c80c77d3b60ad284dc46f4a364b
 132864 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
7baf4f08e1eb86e9eea704fcac13ce89e968e16e
 132873 pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
5f428061a5b2dd980b3047c197b5ff9d9757e010
 132882 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
500ceac0a2df2c80c77d3b60ad284dc46f4a364b
 132887 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
500ceac0a2df2c80c77d3b60ad284dc46f4a364b
Searching for interesting versions
 Result found: flight 132630 (pass), for basis pass
 Result found: flight 132762 (fail), for basis failure
 Repro found: flight 132836 (pass), for basis pass
 Repro found: flight 132859 (fail), for basis failure
 0 revisions at c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 

Re: [Xen-devel] [PATCH v7 02/15] argo: introduce the argo_op hypercall boilerplate

[Julien Grall]

Hi Christopher,

On 2/4/19 8:32 PM, Christopher Clark wrote:

On Wed, Jan 30, 2019 at 8:14 PM Christopher Clark
 wrote:


On Fri, Jan 25, 2019 at 10:55 AM Christopher Clark
 wrote:


On Thu, Jan 24, 2019 at 2:08 AM Julien Grall  wrote:

[...]
Sorry for noticing quite late in the process. Don't you need to add the
hypercall in xen/arch/arm/traps.c?


Adding this looked fine, so I've added the ARM hypercall table entry to
this patch.


Julien, do you have any further feedback on the latest version of this patch?


I will not be able to look at the series this week. I defer the Arm part 
to Stefano.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Julien Grall]

Hi Andrii,

On 2/4/19 3:19 PM, Andrii Anisov wrote:



On 04.02.19 13:36, Julien Grall wrote:

That's a good news! Let me try to address your concerns below one by one.

Lets do it:)


And they employ KPTI enabled kernel in the BSP.
KPTI is going to work on Xen. There are no known issue with Linux as 
the virtual address is not going to be re-used for other purpose in 
the virtual address space. The only inconvenience is the message in 
debug build.

Just in case, I am not saying it should not be fixed :).

We have a decision to eliminate it.

That reveals another critical issue for us, in addition to Set/Way issue 


 From the discussion on the another thread and with other people, this 
is not entirely the fault of Xen. This was a misuse of the 
instructions by the driver.


Yep, but it is still on our team to solve.

While you may want to deal with this in your case, I would like to 
avoid promoting bad behavior when using Xen upstream.


Ah, ok. Will say that in different words.



and possible performance drops/irq latency raise due to specter 
mitigation measures.


Can you remind me the cores you are using?


A57+A53.

I see the following in my log:

     (XEN) alternatives: Patching with alt table 002c6608 -> 
002c6c80

     (XEN) CPU0 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
     (XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
     (XEN) CPU3 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
     (XEN) CPU1 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry


Cortex-A53 should not be affected by spectre v2, so I imagine they are 
only for A57?


It is going to be hard to disable the workarounds by default. But we can 
consider to provide host-wide or per-guest option to disable them on 
trusted environment.


Also, when you mean possible, does it mean you haven't looked the 
performance regression?
We have a preliminary results about performance drop with 
xen4.12-unstable comparing to a our system with 4.10.


A lot of patches have not been backported in Xen 4.10 (including 
Spectre/Meltdown) that will definitely fix hole but may have an impact 
on the performance. There were not backported because of performance 
reason but because of the complexity of the port and seemly lack of 
interest.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.9-testing test] 132783: regressions - FAIL

[osstest service owner]

flight 132783 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132783/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-i3866 xen-buildfail REGR. vs. 130954
 build-amd64-xsm   6 xen-buildfail REGR. vs. 130954
 build-amd64   6 xen-buildfail REGR. vs. 130954
 build-i386-xsm6 xen-buildfail REGR. vs. 130954

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 build-i386-rumprun1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-qemuu-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-i386-xl-raw1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-shadow 1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-intel  1 build-check(1) blocked n/a
 test-amd64-i386-rumprun-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-win10-i386  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64  1 build-check(1)blocked n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-livepatch1 build-check(1)   blocked  n/a
 test-amd64-amd64-pygrub   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-livepatch 1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-amd64-amd64-pair 1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm  1 build-check(1)blocked n/a
 test-xtf-amd64-amd64-11 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ws16-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-ws16-amd64  1 build-check(1)  blocked n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1)   blocked  n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1)  blocked n/a
 test-amd64-i386-xl1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-31 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-credit1   1 build-check(1)   blocked  n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-win10-i386  1 build-check(1) blocked n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)   blocked n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-xsm1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  1 build-check(1) blocked n/a
 test-xtf-amd64-amd64-51 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-debianhvm-amd64  1 build-check(1) blocked n/a
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 1 build-check(1) blocked 
n/a
 test-amd64-amd64-xl-qemut-win10-i386  1 build-check(1) blocked n/a
 build-amd64-rumprun   1 build-check(1)   blocked  n/a
 build-i386-libvirt1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumprun-amd64  1 build-check(1)   blocked  n/a
 test-xtf-amd64-amd64-41 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemut-win7-amd64  1 build-check(1) blocked n/a
 test-amd64-i386-freebsd10-i386  1 build-check(1)   blocked  n/a
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64  1 build-check(1)  blocked n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Julien Grall]

Hi,

On 2/4/19 12:53 PM, Roger Pau Monné wrote:

On Fri, Feb 01, 2019 at 05:40:14PM +, Julien Grall wrote:

Hi,

On 01/02/2019 16:53, Roger Pau Monné wrote:

On Thu, Jan 31, 2019 at 11:14:37PM +, Julien Grall wrote:

On 1/31/19 9:56 PM, Stefano Stabellini wrote:

On Thu, 31 Jan 2019, Julien Grall wrote:

On 31/01/2019 12:00, Andrii Anisov wrote:

On 31.01.19 13:37, Julien Grall wrote:

So, I've got a hacky patch to 'fix' this on x86, by taking a reference
to the mfn behind the virtual address provided when setting up the
hypercall and mapping it in Xen.


That was the idea I had in mind :). Hopefully, no guest is modifying the
mapping (i.e the virtual address point to a different physical address)
afterwards.


This however doesn't work on ARM due
to the lack of paging_gva_to_gfn. I guess there's something similar to
translate a guest virtual address into a gfn or a mfn?


get_page_from_gva should to the job for you.

+int map_runstate_area(struct vcpu *v,
+  struct vcpu_register_runstate_memory_area *area)
+{
+unsigned long offset;
+unsigned int i;
+struct domain *d = v->domain;
+size_t size =
+#ifdef CONFIG_COMPAT
+has_32bit_shinfo((v)->domain) ? sizeof(*v->compat_runstate_guest) :
+#endif
+sizeof(*v->runstate_guest);
+
+if ( v->runstate_guest )
+{
+ASSERT_UNREACHABLE();
+return -EBUSY;
+}
+
+offset = area->addr.p & ~PAGE_MASK;
+
+for ( i = 0; i < ARRAY_SIZE(v->runstate_mfn); i++ )
+{
+p2m_type_t t;
+uint32_t pfec = PFEC_page_present;
+gfn_t gfn = _gfn(paging_gva_to_gfn(v, area->addr.p, ));
+struct page_info *pg;
+
+if ( gfn_eq(gfn, INVALID_GFN) )
+return -EFAULT;
+
+v->runstate_mfn[i] = get_gfn(d, gfn_x(gfn), );


get_gfn would need to be implemented on Arm.


+if ( t != p2m_ram_rw || mfn_eq(v->runstate_mfn[i], INVALID_MFN) )
+return -EFAULT;
+
+pg = mfn_to_page(v->runstate_mfn[i]);
+if ( !pg || !get_page_type(pg, PGT_writable_page) )
+{
+put_gfn(d, gfn_x(gfn));
+return -EFAULT;
+}
+
+put_gfn(d, gfn_x(gfn));
+
+if ( PFN_DOWN(gfn_x(gfn) + size) == PFN_DOWN(gfn_x(gfn)) )


This looks wrong, you seem to mix address and frame. I think you might want:

if ( gfn_eq(gfn_add(gfn, PFN_DOWN(size)), gfn) )


Thanks!

Here is an updated version which seems to build on ARM. I don't have
an easy way to test this, could you give it a spin?


Thank you for writing a patch. I am back in France this week for family 
reason and will not have time properly give a spin this week. Stefano, 
Andrii, can you test it?




I don't like adding CONFIG_X86/ARM in common code, so it might be
worth to either try to factor this out into arch specific code, or
even better, provide common functions to translate a guest virtual
address into a gfn, mfn or page.


I would prefer GVA to MFN/page because we already have a fairly 
complicate helper handling all the cases (e.g memaccess, 
break-before-make, ...) for translation and taking a reference on the 
page. Although we could potentially split the function in two if we want 
to cater any other translation.


One comment below.


+#elif defined(CONFIG_ARM)
+pg = get_page_from_gva(v, area->addr.p, GV2M_WRITE);
+if ( !pg || !get_page_type(pg, PGT_writable_page) )


One reference is already taken by get_page_from_gva. So you should not 
need to take another here.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v3 04/15] argo: init, destroy and soft-reset, with enable command line opt

[Christopher Clark]

On Mon, Jan 14, 2019 at 6:47 AM Wei Liu  wrote:
>
> Hi all
>
> The locking scheme seems to be remaining sticking point. The rest are
> mostly cosmetic issues (FAOD, they still need to be addressed).  Frankly
> I don't think there is enough time to address all the technical details,
> but let me sum up each side's position and see if we can reach an
> amicable solution.
>
> From maintainers and reviewers' point of view:
>
> 1. Maintainers / reviewers don't like complexity unless absolutely
>necessary.
> 2. Maintainers / reviewers feel they have a responsibility to understand
>the code and algorithm.
>
> Yet being the gatekeepers doesn't necessarily mean we understand every
> technical details and every usecase. We would like to, but most of the
> time it is unrealistic.
>
> Down to this specific patch series:
>
> Roger thinks the locking scheme is too complex. Christopher argues
> that's necessary for short-live channels to be performant.
>
> Both have their point.
>
> I think having a complex locking scheme is inevitable, just like we did
> for performant grant table several years ago.  Regardless of the timing
> issue we have at hand, asking Christopher to implement a stripped down
> version creates more work for him.
>
> Yet ignoring Roger's concerns is unfair to him as well, since he put in
> so much time and effort to understand the algorithm and provide
> suggestions. It is in fact unreasonable to ask anyone to fully
> understand the locking mechanism and check the implementation is correct
> in a few days (given the series was posted in Dec and there were major
> holidays in between, plus everyone had other commitments).
>
> To unblock this, how about we make Christopher maintainer of Argo? He
> and OpenXT will be on the hook for further improvement. And I believe it
> would be in their best interest to keep Argo bug-free and eventually
> make it become supported.
>
> So:
>
> 1. Make sure Argo is self-contained -- this requires careful review for
>interaction between Argo and other parts of the hypervisor.
> 2. Argo is going to be experimental and off-by-default -- this is the
>default status for new feature anyway.
> 3. Make Christopher maintainer of Argo -- this would be a natural thing
>to do anyway.
>

Wei,

do you have any feedback on the latest argo MAINTAINERS patch?

Christopher

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v7 02/15] argo: introduce the argo_op hypercall boilerplate

[Christopher Clark]

On Wed, Jan 30, 2019 at 8:14 PM Christopher Clark
 wrote:
>
> On Fri, Jan 25, 2019 at 10:55 AM Christopher Clark
>  wrote:
> >
> > On Thu, Jan 24, 2019 at 2:08 AM Julien Grall  wrote:
> > > [...]
> > > Sorry for noticing quite late in the process. Don't you need to add the
> > > hypercall in xen/arch/arm/traps.c?
>
> Adding this looked fine, so I've added the ARM hypercall table entry to
> this patch.

Julien, do you have any further feedback on the latest version of this patch?

Christopher


On Wed, Jan 30, 2019 at 8:28 PM Christopher Clark
 wrote:
>
> Presence is gated upon CONFIG_ARGO.
>
> Registers the hypercall previously reserved for this.
> Takes 5 arguments, does nothing and returns -ENOSYS.
>
> Implementation will provide a compat ABI so COMPAT_CALL is the
> macro used in the hypercall tables.
>
> Signed-off-by: Christopher Clark 
> ---
> v6 dropped Jan Acked-by due to change of implementation and commit msg
> v6 switched to COMPAT_CALL and provides compat_argo_op
> v6 feedback #3 Julien: add argo_op to the ARM hypercall table
> v2 Copyright line: add 2019
> v2 feedback #3 Jan: drop "message" from argo_message_op
> v2 feedback #3 Jan: add Acked-by
> v1 feedback #15 Jan: handle upper-halves of hypercall args
> v1 feedback #15 Jan: use unsigned where negative values impossible
>
>  xen/arch/arm/traps.c|  3 +++
>  xen/arch/x86/guest/hypercall_page.S |  2 +-
>  xen/arch/x86/hvm/hypercall.c|  3 +++
>  xen/arch/x86/hypercall.c|  3 +++
>  xen/arch/x86/pv/hypercall.c |  3 +++
>  xen/common/Makefile |  1 +
>  xen/common/argo.c   | 38 
> +
>  xen/include/public/xen.h|  2 +-
>  xen/include/xen/hypercall.h | 18 ++
>  9 files changed, 71 insertions(+), 2 deletions(-)
>  create mode 100644 xen/common/argo.c
>
> diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
> index 221c762..e1e8ac9 100644
> --- a/xen/arch/arm/traps.c
> +++ b/xen/arch/arm/traps.c
> @@ -1397,6 +1397,9 @@ static arm_hypercall_t arm_hypercall_table[] = {
>  HYPERCALL(platform_op, 1),
>  HYPERCALL_ARM(vcpu_op, 3),
>  HYPERCALL(vm_assist, 2),
> +#ifdef CONFIG_ARGO
> +HYPERCALL(argo_op, 5),
> +#endif
>  };
>
>  #ifndef NDEBUG
> diff --git a/xen/arch/x86/guest/hypercall_page.S 
> b/xen/arch/x86/guest/hypercall_page.S
> index fdd2e72..26afabf 100644
> --- a/xen/arch/x86/guest/hypercall_page.S
> +++ b/xen/arch/x86/guest/hypercall_page.S
> @@ -59,7 +59,7 @@ DECLARE_HYPERCALL(sysctl)
>  DECLARE_HYPERCALL(domctl)
>  DECLARE_HYPERCALL(kexec_op)
>  DECLARE_HYPERCALL(tmem_op)
> -DECLARE_HYPERCALL(xc_reserved_op)
> +DECLARE_HYPERCALL(argo_op)
>  DECLARE_HYPERCALL(xenpmu_op)
>
>  DECLARE_HYPERCALL(arch_0)
> diff --git a/xen/arch/x86/hvm/hypercall.c b/xen/arch/x86/hvm/hypercall.c
> index 19d1263..5bb1750 100644
> --- a/xen/arch/x86/hvm/hypercall.c
> +++ b/xen/arch/x86/hvm/hypercall.c
> @@ -134,6 +134,9 @@ static const hypercall_table_t hvm_hypercall_table[] = {
>  #ifdef CONFIG_TMEM
>  HYPERCALL(tmem_op),
>  #endif
> +#ifdef CONFIG_ARGO
> +COMPAT_CALL(argo_op),
> +#endif
>  COMPAT_CALL(platform_op),
>  #ifdef CONFIG_PV
>  COMPAT_CALL(mmuext_op),
> diff --git a/xen/arch/x86/hypercall.c b/xen/arch/x86/hypercall.c
> index 032de8f..93e7860 100644
> --- a/xen/arch/x86/hypercall.c
> +++ b/xen/arch/x86/hypercall.c
> @@ -64,6 +64,9 @@ const hypercall_args_t hypercall_args_table[NR_hypercalls] =
>  ARGS(domctl, 1),
>  ARGS(kexec_op, 2),
>  ARGS(tmem_op, 1),
> +#ifdef CONFIG_ARGO
> +ARGS(argo_op, 5),
> +#endif
>  ARGS(xenpmu_op, 2),
>  #ifdef CONFIG_HVM
>  ARGS(hvm_op, 2),
> diff --git a/xen/arch/x86/pv/hypercall.c b/xen/arch/x86/pv/hypercall.c
> index 5d11911..f452dd5 100644
> --- a/xen/arch/x86/pv/hypercall.c
> +++ b/xen/arch/x86/pv/hypercall.c
> @@ -77,6 +77,9 @@ const hypercall_table_t pv_hypercall_table[] = {
>  #ifdef CONFIG_TMEM
>  HYPERCALL(tmem_op),
>  #endif
> +#ifdef CONFIG_ARGO
> +COMPAT_CALL(argo_op),
> +#endif
>  HYPERCALL(xenpmu_op),
>  #ifdef CONFIG_HVM
>  HYPERCALL(hvm_op),
> diff --git a/xen/common/Makefile b/xen/common/Makefile
> index 56fc201..59ac7de 100644
> --- a/xen/common/Makefile
> +++ b/xen/common/Makefile
> @@ -1,3 +1,4 @@
> +obj-$(CONFIG_ARGO) += argo.o
>  obj-y += bitmap.o
>  obj-y += bsearch.o
>  obj-$(CONFIG_CORE_PARKING) += core_parking.o
> diff --git a/xen/common/argo.c b/xen/common/argo.c
> new file mode 100644
> index 000..ddc48f1
> --- /dev/null
> +++ b/xen/common/argo.c
> @@ -0,0 +1,38 @@
> +/**
> + * Argo : Hypervisor-Mediated data eXchange
> + *
> + * Derived from v4v, the version 2 of v2v.
> + *
> + * Copyright (c) 2010, Citrix Systems
> + * Copyright (c) 2018-2019 BAE Systems
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * 

Re: [Xen-devel] Organising a workshop to solve safety certification related questions (March 25/26, Cambridge, UK, Citrix)

[Lars Kurth]

Hi all,

from my perspective we have enough momentum to move forward, albeit some 
prospective attendees are still confirming their travel plans. I can 
accommodate a maximum if 15, but possibly, a few more. With this in Mind, 
please start booking flights.

Location:
The Citrix office in Milton, just outside of Cambridge
Citrix Systems:
101 Cambridge Science Park Rd, Milton
Cambridge CB4 0FY
UK

Timing
The event will be held on Monday March 25, and ends on the 26th. I expect days 
to go from 9:00 to 17:00 and some beverages and food will be provided
EPAM will host an evening event on the 25th

Agenda
With regards the agenda, I will work selected community members on it.
The agenda is yours, so please prepare and be specific about the technical, 
community, process and maybe financial problems we have to solve.

Remote Participation
I will still need to test this and provide more feedback

Registration
I will set up an ad-hoc google doc

Getting To Cambridge/Accommodation
London Stansted is the easiest airport to fly to: there is a direct train that 
goes frequently and take 30-40 minutes
You may have to use London Heathrow you come from the US, China or Japan. In 
that case, you can take a fixed rate taxi: see 
http://www.expressairporttransport.co.uk/Taxi-Cambridge-To-Heathrow-Airport 


The key question you will have to decide upon is whether you stay in the town 
centre, which is stunning, but it may take 30 mins to the Citrix office, or 
whether you stay close tp the office. I will provide more info in due time

Regards
Lars 

> On 23 Jan 2019, at 10:16, Lars Kurth  wrote:
> 
> Hi all,
> 
> it looks as if March 25/26 in Frankfurt or Cambridge is the best option. For 
> Matt, this would mean that he can only attend the first day, but I believe 
> this would be OK. Maybe Robin can attend the second day, instead of Matt. 
> Before we finalise the dates, I will need to secure the meeting space. I will 
> be able to do this in the next few days and will send an update as soon as 
> this is done.
> 
> Note that we had a few people on this list which have replied to me 
> privately. Please let me know privately or publicly whether March 25/26 would 
> be suitable for you. We can in parallel work on the agenda.
>  
> Best Regards
> Lars
> 
>> On 16 Jan 2019, at 13:09, Lars Kurth > > wrote:
>> 
>> 
>> 
>>> On 16 Jan 2019, at 12:16, George Dunlap >> > wrote:
>>> 
>>> On 1/8/19 5:59 PM, Lars Kurth wrote:
 What I need is 
 - Raise your hands if you are interested 
 - Let me know of date / location restrictions
 - We could try and so some of this via video conference: would you be able 
 to attend if we did open the meeting up to some remote participation
>>> 
>>> I'm interested.  All the dates mentioned should work for me.
>>> 
>>> -George
>> 
>> Hi all,
>> 
>> to summarise!
>> 
>> We have a good number of people and organisations interested from pretty one 
>> everyone on the list, but it seems the dates won't work for most people. 
>> Location wise: Germany (Frankfurt) and/or UK (Cambridge) work for most, 
>> except for representatives from Dornerworks and Starlab, who would dial in 
>> for some of the meetings 
>> There seems to be a slight bias for Cambridge, as we have most of our 
>> maintainers there. 
>> 
>> Automotive vendors would be happy to align with automotive meetings/events 
>> (even in Japan), but that won't work for the committers as they won't 
>> normally be able to travel. 
>> I also have two organisations which could potentially host in Cambridge and 
>> one in Germany (Frankfurt). But the venue depends partly on the dates. This 
>> tells me, that we should choose either Frankfurt or Cambridge for the event.
>> 
>> In terms of numbers we are roughly looking at 10-12 who could attend 
>> physically, but it could be more
>> 
>> To move forward, I thought I would expend the time horizon a little bit via 
>> the following doodle poll: https://doodle.com/poll/anvfr2hk2t8gy9a8 
>> 
>> Note that you can specify suboptimal dates by clicking twice: also, if you 
>> have any constraints on location, etc. feel free to make use of the 
>> commenting feature.
>> 
>> I will be in the US mid-March and thus excluded these dates. I also excluded 
>> March 28/29: because of Brexit, it is possible that there would be some 
>> travel chaos at least in the UK. 
>> 
>> Regards
>> Lars
>> 
>> 
>> 
> 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.11-testing test] 132779: tolerable FAIL - PUSHED

[osstest service owner]

flight 132779 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132779/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass

version targeted for testing:
 xen  e2e3a1d75798781a8031feec0050e6e1c98187ca
baseline version:
 xen  df1debf494ac38c95abb602b2b3057613de06b47

Last test of basis   132647  2019-01-31 03:32:06 Z4 days
Testing same since   132736  2019-02-02 05:49:09 Z2 days2 attempts


People who touched revisions under test:
  Andrew Cooper 
  Jan Beulich 
  Juergen Gross 
  Julien Grall 
  Kevin Tian 
  Razvan Cojocaru 
  

[Xen-devel] [xen-4.9-testing bisection] complete build-amd64

[osstest service owner]

branch xen-4.9-testing
xenbranch xen-4.9-testing
job build-amd64
testid xen-build

Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  678920e58463a27c0878b3d070e18811a294cce8
  Bug not present: 3a3f48a59e4269c6111e2c30f31a49d76322bf65
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/132877/


  commit 678920e58463a27c0878b3d070e18811a294cce8
  Author: Jan Beulich 
  Date:   Fri Feb 1 12:05:11 2019 +0100
  
  x86emul: fix 3-operand IMUL
  
  While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
  as its title says, it broke the 3-operand form by uniformly using AL/AX/
  EAX/RAX as second source operand. Fix this and add tests covering both
  cases.
  
  Reported-by: Andrei Lutas 
  Signed-off-by: Jan Beulich 
  Tested-by: Razvan Cojocaru 
  Reviewed-by: Andrew Cooper 
  master commit: 19232b378fab04997c0612e5c19e82c29b59d99e
  master date: 2018-12-18 14:27:09 +0100


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.9-testing/build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.9-testing/build-amd64.xen-build 
--summary-out=tmp/132877.bisection-summary --basis-template=130954 
--blessings=real,real-bisect xen-4.9-testing build-amd64 xen-build
Searching for failure / basis pass:
 132747 fail [host=godello0] / 132582 [host=baroque1] 132484 [host=chardonnay0] 
130954 [host=debina1] 130890 ok.
Failure / basis pass flights: 132747 / 130890
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
04f7fbcc8fcab7f3a59e33798b74582b55dd735a
Basis pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
7f01558d9b3fc4011741e9f469c96fd93dd8454e
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#aad23066e4b27296d219b9123393fbe2a5a885bb-aad23066e4b27296d219b9123393fbe2a5a885bb
 
git://xenbits.xen.org/xen.git#7f01558d9b3fc4011741e9f469c96fd93dd8454e-04f7fbcc8fcab7f3a59e33798b74582b55dd735a
Loaded 1001 nodes in revision graph
Searching for test results:
 130890 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
7f01558d9b3fc4011741e9f469c96fd93dd8454e
 130851 [host=godello1]
 130954 [host=debina1]
 130953 [host=debina1]
 131038 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
7f01558d9b3fc4011741e9f469c96fd93dd8454e
 132484 [host=chardonnay0]
 132606 [host=albana1]
 132583 [host=godello1]
 132582 [host=baroque1]
 132684 pass irrelevant
 132688 [host=baroque1]
 132747 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
04f7fbcc8fcab7f3a59e33798b74582b55dd735a
 132860 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
7f01558d9b3fc4011741e9f469c96fd93dd8454e
 132874 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
 132861 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
04f7fbcc8fcab7f3a59e33798b74582b55dd735a
 132865 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
3a3f48a59e4269c6111e2c30f31a49d76322bf65
 132863 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
194142fff394b13ccd6010f3353d340d4e356b78
 132867 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
8b799b1b33a792c896ee2363d7217607051549f4
 132870 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
 132872 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
3a3f48a59e4269c6111e2c30f31a49d76322bf65
 132876 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
3a3f48a59e4269c6111e2c30f31a49d76322bf65
 132877 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
Searching for interesting versions
 Result found: flight 130890 (pass), for basis pass
 Result found: flight 132747 (fail), for basis 

Re: [Xen-devel] [PATCH for-4.12] x86/svm: Fix handling of ICEBP intercepts

[Andrew Cooper]

On 04/02/2019 09:16, Jan Beulich wrote:
 On 01.02.19 at 18:09,  wrote:
>> On 01/02/2019 16:55, Jan Beulich wrote:
>> On 01.02.19 at 17:25,  wrote:
 If it were just getting insn_len incorrectly as 0, then the guest would
 livelock as we wouldn't inject the #DB with trap semantics it requires,
>>> I'm confused again: Why trap semantics? The ICEBP has fault
>>> semantics as you confirmed above.
>> The ICEBP intercept has fault semantics.  An ICEBP instruction executing
>> in the guest has trap semantics.
> Oh, okay - I was mis-remembering this aspect.
>
 but as the #GP is already raised, this will combine to #DF.
>>> How that? #DB is a benign exception, so according to the table on the
>>> #DF page in the SDM, with #GP it shouldn't combine to #DF.
>> #GP is raised first.  It is contributory.
>>
>> A subsequent #DB getting raised causes #GP to turn into #DF.
> That's based on what?

Based on actually trying this error scenario.

(d1) --- Xen Test Framework ---
(d1) Environment: HVM 64bit (Long mode 4 levels)
(d1) Hello World
(XEN) ** Got ICEBP intercept
(d1) **
(d1) PANIC: Unhandled exception at 0046:0008
(d1) Vec 8 #DF[4740]
(d1) **

Clearly something is off-by-one in the eventual stack frame, which
probably means we've got a a bug in svm_inject_event().  I suspect the
escalation to #DF doesn't overwrite the #DB's "no error code"
information, but I've not investigated yet.

> The table on the #DF page clearly says
> otherwise, at least according to my reading.

Hmm - so it does.  Looks like we've got a 3rd bug, in the general
exception combining logic.

> But in the end there shouldn't be any attempt to inject #DB anyway
> when #GP is already pending, irrespective of the fact that this #GP
> is non-architectural.

Correct.  That bug is what this patch is fixing.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL

[Stefano Stabellini]

On Mon, 4 Feb 2019, Jan Beulich wrote:
> >>> On 01.02.19 at 19:52,  wrote:
> 
> I'm not going to reply in detail to all of what you wrote about fanatics,
> but I would like to say that I think compiler people less of that than
> you appear to imply, at least the ones I know. In particular, they can
> be convinced of there being bugs by pointing out what aspect of the
> standard their implementation violates. (Of course there are also
> going to be areas where interpretations of the standard vary too
> much to come to an agreement.)
> 
> > Improvements this series seeks to make, as I understand it, include
> > (in order of urgency):
> > 
> > 1. Fixing one concrete instance of "UB hazard"
> 
> Right, and we want to work around compiler bugs here.
> 
> > 2. Minimize risk of further "UB hazard" in this bit of functionality
> > 3. Retain the effort Stefano has put in identifying all the places
> > where such UB hazards need to be addressed.
> > 4. Move towards MISRA-C compliance.
> > 
> > As far as I can tell, primary objections you've leveled at the options
> > which try to address 2-4 are:
> > 
> > a. "UB hazard" still not zero
> > b. MISRA compliancy no 100%
> > c. Ugly
> > d. Inefficient
> > 
> > (Obviously some proposals have had more technical discussion.)
> > 
> > Anything I missed?
> 
> I don't think so, especially since various aspects can fall under "ugly"
> and/or "inefficient". What I'm not sure I see is what you mean to
> express with all you wrote in terms of finding a way out of the
> current situation (besides requesting a vote): Improving on a. and
> b. is not a good excuse to extend c., at least not unequivocally.
> Whether d. actually matters is a separate aspect, partly because it
> may mean different things (it could e.g. be taken as another
> wording for a. and b.).

I would be OK with a vote (or Juergen making a decision for us), but
this issue is not so fundamentally critical that I want to move forward
with it at the cost of making one or more maintainers unhappy. Ideally,
I would like to find an option that is acceptable for everybody.
Unfortunately, it doesn't look like it's possible.


> And btw - I can't judge on b. anyway, as I still don't know what
> exactly MISRA compliance is to mean, with the rules to adhere to
> suitably justified.

I can't pretend to know exactly what MISRAC compliance means for this
specific issue, but we do have the recommended way forward by the
compliance experts, which also matches the rough understanding of most
of the engineers involved in this discussion. Picking the option
suggested by the MISRAC people, could be a decent way to settle this
debate?

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 00/15] Argo: hypervisor-mediated interdomain communication

[Stefano Stabellini]

On Mon, 4 Feb 2019, Roger Pau Monné wrote:
> > Yes, v7 was sent to address Jan and Julien's review comments in parallel
> > with our ongoing discussion on v5 macros. v7 also provided a checkpoint
> > for Argo testers to maximize test coverage as the series converges into
> > a Xen 4.12 merge candidate for Juergen. It addressed:
> > 
> >  - Jan's v6 review comments
> >  - Julien's v1 review comment
> >  - most of your xen-devel and offline review comments
> 
> I think it will benefit the community to give this review in public,
> so other reviewers know whats going on. IMO getting this private
> review makes it harder for me (as a reviewer) to know the motivation
> of some of the changes between versions, and likely also makes it
> harder for you since you have to keep track of comments from multiple
> sources on different channels.

There is one more reason to require public comments which I have only
learned recently: for safety certifications we need to keep a record of
all review comments and patches that address them for traceability.___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.9-testing bisection] complete build-amd64-xsm

[osstest service owner]

branch xen-4.9-testing
xenbranch xen-4.9-testing
job build-amd64-xsm
testid xen-build

Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  678920e58463a27c0878b3d070e18811a294cce8
  Bug not present: 3a3f48a59e4269c6111e2c30f31a49d76322bf65
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/132858/


  commit 678920e58463a27c0878b3d070e18811a294cce8
  Author: Jan Beulich 
  Date:   Fri Feb 1 12:05:11 2019 +0100
  
  x86emul: fix 3-operand IMUL
  
  While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
  as its title says, it broke the 3-operand form by uniformly using AL/AX/
  EAX/RAX as second source operand. Fix this and add tests covering both
  cases.
  
  Reported-by: Andrei Lutas 
  Signed-off-by: Jan Beulich 
  Tested-by: Razvan Cojocaru 
  Reviewed-by: Andrew Cooper 
  master commit: 19232b378fab04997c0612e5c19e82c29b59d99e
  master date: 2018-12-18 14:27:09 +0100


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.9-testing/build-amd64-xsm.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.9-testing/build-amd64-xsm.xen-build 
--summary-out=tmp/132858.bisection-summary --basis-template=130954 
--blessings=real,real-bisect xen-4.9-testing build-amd64-xsm xen-build
Searching for failure / basis pass:
 132747 fail [host=godello0] / 132582 ok.
Failure / basis pass flights: 132747 / 132582
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
04f7fbcc8fcab7f3a59e33798b74582b55dd735a
Basis pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
0437ba0e578d089eb24fc493575cd0e8f2584ec7
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#aad23066e4b27296d219b9123393fbe2a5a885bb-aad23066e4b27296d219b9123393fbe2a5a885bb
 
git://xenbits.xen.org/xen.git#0437ba0e578d089eb24fc493575cd0e8f2584ec7-04f7fbcc8fcab7f3a59e33798b74582b55dd735a
Loaded 1001 nodes in revision graph
Searching for test results:
 132582 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
0437ba0e578d089eb24fc493575cd0e8f2584ec7
 132747 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
04f7fbcc8fcab7f3a59e33798b74582b55dd735a
 132844 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
 132845 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
4f9a486899b643a3143a77a032f6c2069cb1e40a
 132838 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
0437ba0e578d089eb24fc493575cd0e8f2584ec7
 132849 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
3a3f48a59e4269c6111e2c30f31a49d76322bf65
 132852 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
 132840 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
04f7fbcc8fcab7f3a59e33798b74582b55dd735a
 132842 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
78b2732ec5ce883f7061fa2b766b359bb08bba19
 132850 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
 132856 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
3a3f48a59e4269c6111e2c30f31a49d76322bf65
 132851 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
3a3f48a59e4269c6111e2c30f31a49d76322bf65
 132858 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
Searching for interesting versions
 Result found: flight 132582 (pass), for basis pass
 Result found: flight 132747 (fail), for basis failure
 Repro found: flight 132838 (pass), for basis pass
 Repro found: flight 132840 (fail), for basis failure
 0 revisions at 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
3a3f48a59e4269c6111e2c30f31a49d76322bf65
No revisions left 

Re: [Xen-devel] [PATCH for-4.12 2/8] amd/ntp: remove assert that prevents creating 2M MMIO entries

[Roger Pau Monné]

On Mon, Feb 04, 2019 at 09:56:22AM -0700, Jan Beulich wrote:
> >>> On 30.01.19 at 11:36,  wrote:
> > The assert was originally added to make sure that higher order
> > regions (> PAGE_ORDER_4K) could not be used to bypass the
> > mmio_ro_ranges check performed by p2m_type_to_flags.
> > 
> > This however is already checked in set_mmio_p2m_entry, which makes
> > sure that higher order mappings don't overlap with mmio_ro_ranges,
> > thus allowing the creation of high order MMIO mappings safely.
> 
> Well, the assertions were added to make sure no other code
> path appears that violates this requirement. Arguably e.g.
> set_identity_p2m_entry() could gain an order parameter and
> then try to establish larger p2m_mmio_direct entries.
> 
> Don't get me wrong, I don't object to the removal of the
> assertions, but the description makes it sound as if they were
> entirely redundant. Even better would be though if they
> could be extended to keep triggering in "bad" cases.

I could add something like:

ASSERT(!rangeset_overlaps_range(mmio_ro_ranges, mfn_x(mfn),
mfn_x(mfn) + PFN_DOWN(MB(2;

I think this should be safe and would trigger in case of misuse.

> 
> > Remove the assert to allow 2M entries to be created for MMIO regions
> > that don't overlap with mmio_ro_ranges.
> > 
> > Suggested-by: George Dunlap 
> > Signed-off-by: Roger Pau Monné 
> > ---
> > Cc: George Dunlap 
> > Cc: Jan Beulich 
> > Cc: Andrew Cooper 
> > Cc: Wei Liu 
> > Cc: Juergen Gross 
> > ---
> > Without this patch trying to create a PVH dom0 will trigger an assert
> > on certain hardware depending on the memory map.
> 
> Giving a simple example in the description would be helpful.
> 
> > --- a/xen/arch/x86/mm/p2m-pt.c
> > +++ b/xen/arch/x86/mm/p2m-pt.c
> > @@ -668,7 +668,6 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, 
> > mfn_t mfn,
> >  }
> >  
> >  ASSERT(p2m_flags_to_type(flags) != p2m_ioreq_server);
> > -ASSERT(!mfn_valid(mfn) || p2mt != p2m_mmio_direct);
> >  l2e_content = mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt)
> >  ? p2m_l2e_from_pfn(mfn_x(mfn),
> > p2m_type_to_flags(p2m, p2mt, mfn, 1))
> 
> There's a similar check in the 1G mapping logic several lines up. Why
> does that not also need removing?

So far mmio_order doesn't allow creation of 1G entries for mmio
regions, that's why I haven't removed that assert. I can however
replace it with the assert suggested above properly adjusted for 1G
pages.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12 1/8] dom0/pvh: align allocation and mapping order to start address

[Roger Pau Monné]

On Mon, Feb 04, 2019 at 09:41:34AM -0700, Jan Beulich wrote:
> >>> On 30.01.19 at 11:36,  wrote:
> > Due to the recent changes in the iommu mapping logic, the start
> > addresses provided need to be aligned to the order intended to be
> > mapped.
> 
> Irrespective of your reply to Wei's similar request (where you've
> provided links to mails showing crashes) I'd like you to explain
> this better. This is in particular because I don't really see what
> "recent changes in the iommu mapping logic" you talk about.

Commit 725bf00a87f ("iommu / p2m: add a page_order parameter to
iommu_map/unmap_page()...") added the following two asserts to
iommu_map:

ASSERT(IS_ALIGNED(dfn_x(dfn), (1ul << page_order)));
ASSERT(IS_ALIGNED(mfn_x(mfn), (1ul << page_order)));

Previously iommu_map would add unaligned entries without complaining,
but now in debug builds the assert will trigger.

Maybe adding a 'Fixes' tag would help identifying what this commit is
trying to address?

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12 2/8] amd/ntp: remove assert that prevents creating 2M MMIO entries

[Jan Beulich]

>>> On 30.01.19 at 11:36,  wrote:
> The assert was originally added to make sure that higher order
> regions (> PAGE_ORDER_4K) could not be used to bypass the
> mmio_ro_ranges check performed by p2m_type_to_flags.
> 
> This however is already checked in set_mmio_p2m_entry, which makes
> sure that higher order mappings don't overlap with mmio_ro_ranges,
> thus allowing the creation of high order MMIO mappings safely.

Well, the assertions were added to make sure no other code
path appears that violates this requirement. Arguably e.g.
set_identity_p2m_entry() could gain an order parameter and
then try to establish larger p2m_mmio_direct entries.

Don't get me wrong, I don't object to the removal of the
assertions, but the description makes it sound as if they were
entirely redundant. Even better would be though if they
could be extended to keep triggering in "bad" cases.

> Remove the assert to allow 2M entries to be created for MMIO regions
> that don't overlap with mmio_ro_ranges.
> 
> Suggested-by: George Dunlap 
> Signed-off-by: Roger Pau Monné 
> ---
> Cc: George Dunlap 
> Cc: Jan Beulich 
> Cc: Andrew Cooper 
> Cc: Wei Liu 
> Cc: Juergen Gross 
> ---
> Without this patch trying to create a PVH dom0 will trigger an assert
> on certain hardware depending on the memory map.

Giving a simple example in the description would be helpful.

> --- a/xen/arch/x86/mm/p2m-pt.c
> +++ b/xen/arch/x86/mm/p2m-pt.c
> @@ -668,7 +668,6 @@ p2m_pt_set_entry(struct p2m_domain *p2m, gfn_t gfn_, 
> mfn_t mfn,
>  }
>  
>  ASSERT(p2m_flags_to_type(flags) != p2m_ioreq_server);
> -ASSERT(!mfn_valid(mfn) || p2mt != p2m_mmio_direct);
>  l2e_content = mfn_valid(mfn) || p2m_allows_invalid_mfn(p2mt)
>  ? p2m_l2e_from_pfn(mfn_x(mfn),
> p2m_type_to_flags(p2m, p2mt, mfn, 1))

There's a similar check in the 1G mapping logic several lines up. Why
does that not also need removing?

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12 2/8] amd/ntp: remove assert that prevents creating 2M MMIO entries

[Andrew Cooper]

On 30/01/2019 10:36, Roger Pau Monne wrote:

Subject s/ntp/npt/

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12 1/8] dom0/pvh: align allocation and mapping order to start address

[Jan Beulich]

>>> On 30.01.19 at 11:36,  wrote:
> Due to the recent changes in the iommu mapping logic, the start
> addresses provided need to be aligned to the order intended to be
> mapped.

Irrespective of your reply to Wei's similar request (where you've
provided links to mails showing crashes) I'd like you to explain
this better. This is in particular because I don't really see what
"recent changes in the iommu mapping logic" you talk about. The
code change itself looks okay, despite me not being overly happy
with the use of min() here, which iirc was already commented
about.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12] x86/vpmu: Improve documentation and parsing for vpmu=

[Juergen Gross]

On 04/02/2019 17:06, Jan Beulich wrote:
 On 04.02.19 at 15:58,  wrote:
>> On 04/02/2019 14:44, Jan Beulich wrote:
>> On 04.02.19 at 15:22,  wrote:
 On 04/02/2019 13:53, Jan Beulich wrote:
 On 04.02.19 at 12:41,  wrote:
>> @@ -64,37 +54,37 @@ static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
>>  static int __init parse_vpmu_params(const char *s)
>>  {
>>  const char *ss;
>> +int rc = 0, val;
>> +
>> +do {
>> +ss = strchr(s, ',');
>> +if ( !ss )
>> +ss = strchr(s, '\0');
>> +
>> +if ( (val = parse_bool(s, ss)) >= 0 )
>> +opt_vpmu_enabled = val;
>> +else if ( !cmdline_strcmp(s, "bts") )
>> +vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
>> +else if ( !cmdline_strcmp(s, "ipc") )
>> +vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
>> +else if ( !cmdline_strcmp(s, "arch") )
>> +vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
>> +else
>> +rc = -EINVAL;
>>  
>> -switch ( parse_bool(s, NULL) )
>> -{
>> -case 0:
>> -break;
>> -default:
>> -do {
>> -ss = strchr(s, ',');
>> -if ( !ss )
>> -ss = strchr(s, '\0');
>> -
>> -if ( !cmdline_strcmp(s, "bts") )
>> -vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
>> -else if ( !cmdline_strcmp(s, "ipc") )
>> -vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
>> -else if ( !cmdline_strcmp(s, "arch") )
>> -vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
>> -else
>> -return -EINVAL;
>> +s = ss + 1;
>> +} while ( *ss );
>> +
>> +/* Selecting bts/ipc/arch forces vpmu to enabled. */
>> +if ( vpmu_features )
>> +opt_vpmu_enabled = true;
> If you want to retain original behavior, the condition here would need
> to be "!rc && vpmu_features". It's not clear whether your modification
> in this regard is intentional.
 Oh - that wasn't intentional.

 An alternative, now I think about it, is to just have the =false
 case clear vpmu_features.  This is new behaviour, but it is more
 consistent with how other options work, and it wasn't expressable before.
>>> Generally - yes. But what would e.g. "vpmu=off,ipc" end up doing in
>>> your new model?
>>
>> The use of vpmu_features is somewhat weird.  "bts" acts as an extra
>> feature on top of "generally on", whereas "ipc" and "arch" act as
>> restrictions on top of "generally on".
> 
> Okay let's go that route then.

Release-acked-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12] x86/vpmu: Improve documentation and parsing for vpmu=

[Jan Beulich]

>>> On 04.02.19 at 15:58,  wrote:
> On 04/02/2019 14:44, Jan Beulich wrote:
> On 04.02.19 at 15:22,  wrote:
>>> On 04/02/2019 13:53, Jan Beulich wrote:
>>> On 04.02.19 at 12:41,  wrote:
> @@ -64,37 +54,37 @@ static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
>  static int __init parse_vpmu_params(const char *s)
>  {
>  const char *ss;
> +int rc = 0, val;
> +
> +do {
> +ss = strchr(s, ',');
> +if ( !ss )
> +ss = strchr(s, '\0');
> +
> +if ( (val = parse_bool(s, ss)) >= 0 )
> +opt_vpmu_enabled = val;
> +else if ( !cmdline_strcmp(s, "bts") )
> +vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
> +else if ( !cmdline_strcmp(s, "ipc") )
> +vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
> +else if ( !cmdline_strcmp(s, "arch") )
> +vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
> +else
> +rc = -EINVAL;
>  
> -switch ( parse_bool(s, NULL) )
> -{
> -case 0:
> -break;
> -default:
> -do {
> -ss = strchr(s, ',');
> -if ( !ss )
> -ss = strchr(s, '\0');
> -
> -if ( !cmdline_strcmp(s, "bts") )
> -vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
> -else if ( !cmdline_strcmp(s, "ipc") )
> -vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
> -else if ( !cmdline_strcmp(s, "arch") )
> -vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
> -else
> -return -EINVAL;
> +s = ss + 1;
> +} while ( *ss );
> +
> +/* Selecting bts/ipc/arch forces vpmu to enabled. */
> +if ( vpmu_features )
> +opt_vpmu_enabled = true;
 If you want to retain original behavior, the condition here would need
 to be "!rc && vpmu_features". It's not clear whether your modification
 in this regard is intentional.
>>> Oh - that wasn't intentional.
>>>
>>> An alternative, now I think about it, is to just have the =false
>>> case clear vpmu_features.  This is new behaviour, but it is more
>>> consistent with how other options work, and it wasn't expressable before.
>> Generally - yes. But what would e.g. "vpmu=off,ipc" end up doing in
>> your new model?
> 
> The use of vpmu_features is somewhat weird.  "bts" acts as an extra
> feature on top of "generally on", whereas "ipc" and "arch" act as
> restrictions on top of "generally on".

Okay let's go that route then.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [linux-4.19 test] 132770: regressions - FAIL

[osstest service owner]

flight 132770 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132770/

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 7 xen-boot fail REGR. 
vs. 129313
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313
 test-amd64-amd64-i386-pvgrub  7 xen-boot fail REGR. vs. 129313
 test-amd64-amd64-amd64-pvgrub  7 xen-bootfail REGR. vs. 129313
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-boot fail REGR. 
vs. 129313
 test-amd64-amd64-xl-shadow7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-qemut-rhel6hvm-intel  7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-xl-qemuu-debianhvm-amd64  7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-xl-raw7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm  7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-xl-shadow 7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-libvirt   7 xen-boot fail REGR. vs. 129313
 test-amd64-i386-freebsd10-i386  7 xen-boot   fail REGR. vs. 129313
 test-amd64-i386-examine   8 reboot   fail REGR. vs. 129313
 test-amd64-i386-xl7 xen-boot fail REGR. vs. 129313
 test-amd64-amd64-examine  8 reboot   fail REGR. vs. 129313
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs. 
129313
 test-amd64-amd64-qemuu-nested-intel 17 debian-hvm-install/l1/l2 fail REGR. vs. 
129313

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-rumprun-amd64 17 rumprun-demo-xenstorels/xenstorels.repeat 
fail REGR. vs. 129313

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  7 xen-boot   fail never pass
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 

[Xen-devel] Xen 4.12 RC2

[Juergen Gross]

Hi all,

Xen 4.12 rc2 is tagged. You can check that out from xen.git:

git://xenbits.xen.org/xen.git 4.12-rc2

For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.12-rc2/xen-4.12-rc2.tar.gz

And the signature is at:
https://downloads.xenproject.org/release/xen/4.12-rc2/xen-4.12-rc2.tar.gz.sig

Please send bug reports and test reports to xen-devel@lists.xenproject.org.
When sending bug reports, please CC relevant maintainers and me
(jgr...@suse.com).

There will be a Xen Test Day on Feb 6th.

See instructions on:

https://wiki.xenproject.org/wiki/Xen_4.12_RC_test_instructions
https://wiki.xenproject.org/wiki/Xen_Project_Test_Days


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC v2 1/2] x86/emulate: Move hvmemul_linear_to_phys

[Razvan Cojocaru]

On 2/4/19 5:14 PM, Roger Pau Monné wrote:

On Mon, Feb 04, 2019 at 02:00:40PM +0200, Razvan Cojocaru wrote:

On 2/4/19 1:55 PM, Paul Durrant wrote:

-Original Message-
From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
Sent: 04 February 2019 11:37
To: xen-devel@lists.xenproject.org
Cc: Paul Durrant ; jbeul...@suse.com; Andrew
Cooper ; Wei Liu ; Roger
Pau Monne ; rcojoc...@bitdefender.com;
ta...@tklengyel.com; George Dunlap 
Subject: Re: [PATCH RFC v2 1/2] x86/emulate: Move hvmemul_linear_to_phys

Ping, any thoughts on this are appreciated.

Regards,
Alex

On 11.01.2019 17:37, Alexandru Stefan ISAILA wrote:

This is done so hvmemul_linear_to_phys() can be called from
hvmemul_map_linear_addr()



I have no objection to pure code movement for this purpose. I certainly prefer 
it to forward declaration of statics.

Thanks for the reply!

We're also after thoughts on the whole series (replying to this specific
patch instead of the cover letter was an accident).

We expect the second patch to be more controversial and in some need of
detailed scrutiny.


I've taken a look at patch 2 and provided some review comments, sorry
for the delay. Keep in mind we are in the middle of the release
process and most developers and reviewers are busy trying to fix bugs
or reviewing bugfixes.


Very much appreciated!


Thanks,
Razvan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PULL 0/4] Xen queue 20190204

[Peter Maydell]

On Mon, 4 Feb 2019 at 11:28, Anthony PERARD  wrote:
>
> The following changes since commit b3fc0af1ff5e922d4dd7c875394dbd26dc7313b4:
>
>   Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging 
> (2019-02-01 17:58:27 +)
>
> are available in the Git repository at:
>
>   https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git 
> tags/pull-xen-20190204
>
> for you to fetch changes up to 3149f183d7ca448b1dc30fe3d4acb9e367de01bf:
>
>   xen-block: handle resize callback (2019-02-04 11:04:49 +)
>
> 
> Xen queue
>
> * xen-block, the Xen PV backend, now handles resize.
> * configure cleanup.
> * xen-bus fix.

Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.0
for any user-visible changes.

-- PMM

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Andrii Anisov]

On 04.02.19 13:36, Julien Grall wrote:

That's a good news! Let me try to address your concerns below one by one.

Lets do it:)


And they employ KPTI enabled kernel in the BSP.

KPTI is going to work on Xen. There are no known issue with Linux as the 
virtual address is not going to be re-used for other purpose in the virtual 
address space. The only inconvenience is the message in debug build.
Just in case, I am not saying it should not be fixed :).

We have a decision to eliminate it.

That reveals another critical issue for us, in addition to Set/Way issue 


 From the discussion on the another thread and with other people, this is not 
entirely the fault of Xen. This was a misuse of the instructions by the driver.


Yep, but it is still on our team to solve.


While you may want to deal with this in your case, I would like to avoid 
promoting bad behavior when using Xen upstream.


Ah, ok. Will say that in different words.




and possible performance drops/irq latency raise due to specter mitigation 
measures.


Can you remind me the cores you are using?


A57+A53.

I see the following in my log:

(XEN) alternatives: Patching with alt table 002c6608 -> 
002c6c80
(XEN) CPU0 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) CPU2 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) CPU3 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry
(XEN) CPU1 will call ARM_SMCCC_ARCH_WORKAROUND_1 on exception entry


Also, when you mean possible, does it mean you haven't looked the performance 
regression?

We have a preliminary results about performance drop with xen4.12-unstable 
comparing to a our system with 4.10.
But those results are from Nov IIRC, and we have to recheck. After fixing 
Set/Way misuse in our proprietary driver ;)


I'm not sure if this is sufficient a justification to make it the release 
blocker, but we are up to this stuff.

Which one?


KPTI issue, as you suggested.

--
Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC v2 1/2] x86/emulate: Move hvmemul_linear_to_phys

[Roger Pau Monné]

On Mon, Feb 04, 2019 at 02:00:40PM +0200, Razvan Cojocaru wrote:
> On 2/4/19 1:55 PM, Paul Durrant wrote:
> > > -Original Message-
> > > From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
> > > Sent: 04 February 2019 11:37
> > > To: xen-devel@lists.xenproject.org
> > > Cc: Paul Durrant ; jbeul...@suse.com; Andrew
> > > Cooper ; Wei Liu ; Roger
> > > Pau Monne ; rcojoc...@bitdefender.com;
> > > ta...@tklengyel.com; George Dunlap 
> > > Subject: Re: [PATCH RFC v2 1/2] x86/emulate: Move hvmemul_linear_to_phys
> > > 
> > > Ping, any thoughts on this are appreciated.
> > > 
> > > Regards,
> > > Alex
> > > 
> > > On 11.01.2019 17:37, Alexandru Stefan ISAILA wrote:
> > > > This is done so hvmemul_linear_to_phys() can be called from
> > > > hvmemul_map_linear_addr()
> > > > 
> > 
> > I have no objection to pure code movement for this purpose. I certainly 
> > prefer it to forward declaration of statics.
> Thanks for the reply!
> 
> We're also after thoughts on the whole series (replying to this specific
> patch instead of the cover letter was an accident).
> 
> We expect the second patch to be more controversial and in some need of
> detailed scrutiny.

I've taken a look at patch 2 and provided some review comments, sorry
for the delay. Keep in mind we are in the middle of the release
process and most developers and reviewers are busy trying to fix bugs
or reviewing bugfixes.

Thanks, Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v7 10/15] argo: implement the notify op

[Jan Beulich]

>>> On 31.01.19 at 05:28,  wrote:
> @@ -1802,6 +2157,21 @@ do_argo_op(unsigned int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) arg1,
>  break;
>  }
>  
> +case XEN_ARGO_OP_notify:
> +{
> +XEN_GUEST_HANDLE_PARAM(xen_argo_ring_data_t) ring_data_hnd =
> +   guest_handle_cast(arg1, xen_argo_ring_data_t);
> +
> +if ( unlikely((!guest_handle_is_null(arg2)) || arg3 || arg4) )
> +{
> +rc = -EINVAL;
> +break;
> +}
> +
> +rc = notify(currd, ring_data_hnd);
> +break;
> +}
> +
>  default:
>  rc = -EOPNOTSUPP;
>  break;
> @@ -1912,6 +2282,21 @@ compat_argo_op(unsigned int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) arg1,
>  break;
>  }
>  
> +case XEN_ARGO_OP_notify:
> +{
> +XEN_GUEST_HANDLE_PARAM(xen_argo_ring_data_t) ring_data_hnd =
> +   guest_handle_cast(arg1, xen_argo_ring_data_t);
> +
> +if ( unlikely((!guest_handle_is_null(arg2)) || arg3 || arg4) )
> +{
> +rc = -EINVAL;
> +break;
> +}
> +
> +rc = notify(currd, ring_data_hnd);
> +break;
> +}

At the example of this (likely applies to earlier patches as much): Aren't
you afraid of this recurring duplication? It's quite easy, especially when
the functions here grow a little further, for someone to forget updating
one (more likely the compat one obviously). Did you consider forwarding
all operations not needing translation straight into do_argo_op(), and
handling only the sendv one here?

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC v2 2/2] x86/emulate: Send vm_event from emulate

[Roger Pau Monné]

On Fri, Jan 11, 2019 at 03:37:45PM +, Alexandru Stefan ISAILA wrote:
> This patch aims to have mem access vm events sent from the emulator.
> This is useful in the case of page-walks that have to emulate
> instructions in access denied pages.
> 
> We use hvmemul_map_linear_addr() ro intercept r/w access and
> hvmemul_insn_fetch() to intercept exec access.
> 
> First we try to send a vm event and if the event is sent then emulation
> returns X86EMUL_ACCESS_EXCEPTION. If the event is not sent then the
> emulation goes on as expected.
> 
> Signed-off-by: Alexandru Isaila 
> 
> ---
> Changes since V1:
>   - Add newlines in hvmemul_send_vm_event()
>   - Dropped p2m->get_entry() for p2m_get_mem_access()
>   - Use a simplified return for hvmemul_send_vm_event.
> ---
>  xen/arch/x86/hvm/emulate.c | 104 -
>  xen/arch/x86/hvm/vm_event.c|   2 +-
>  xen/arch/x86/mm/mem_access.c   |   3 +-
>  xen/arch/x86/x86_emulate/x86_emulate.h |   1 +
>  xen/include/asm-x86/hvm/emulate.h  |   4 +-
>  5 files changed, 109 insertions(+), 5 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index a766eecc8e..3a6bca32fe 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -26,6 +27,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  static void hvmtrace_io_assist(const ioreq_t *p)
>  {
> @@ -530,6 +532,56 @@ static int hvmemul_do_mmio_addr(paddr_t mmio_gpa,
>  return hvmemul_do_io_addr(1, mmio_gpa, reps, size, dir, df, ram_gpa);
>  }
>  
> +static bool hvmemul_send_vm_event(paddr_t gpa, unsigned long gla, gfn_t gfn,
> +  uint32_t pfec, struct hvm_emulate_ctxt 
> *ctxt)
> +{
> +xenmem_access_t access;
> +vm_event_request_t req = {};
> +
> +if ( !ctxt->send_event || !pfec )
> +return false;
> +
> +if ( p2m_get_mem_access(current->domain, gfn, ,
> +altp2m_vcpu_idx(current)) != 0 )

You can join the ifs:

if ( !ctxt->send_event || !pfec ||
  p2m_get_mem_access(current->domain, gfn, ,
 altp2m_vcpu_idx(current)) )
return false;


> +return false;
> +
> +switch ( access ) {

The braces should be on a newline.

> +case XENMEM_access_x:
> +case XENMEM_access_rx:
> +if ( pfec & PFEC_write_access )
> +req.u.mem_access.flags = MEM_ACCESS_R | MEM_ACCESS_W;
> +break;
> +
> +case XENMEM_access_w:
> +case XENMEM_access_rw:
> +if ( pfec & PFEC_insn_fetch )
> +req.u.mem_access.flags = MEM_ACCESS_X;
> +break;
> +
> +case XENMEM_access_r:
> +case XENMEM_access_n:
> +if ( pfec & PFEC_write_access )
> +req.u.mem_access.flags |= MEM_ACCESS_R | MEM_ACCESS_W;
> +if ( pfec & PFEC_insn_fetch )
> +req.u.mem_access.flags |= MEM_ACCESS_X;
> +break;
> +
> +default:
> +return false;
> +}
> +
> +if ( !req.u.mem_access.flags )
> +return false; /* No violation. */
> +
> +req.reason = VM_EVENT_REASON_MEM_ACCESS;
> +req.u.mem_access.gfn = gfn_x(gfn);
> +req.u.mem_access.flags |= MEM_ACCESS_FAULT_WITH_GLA | 
> MEM_ACCESS_GLA_VALID;
> +req.u.mem_access.gla = gla;
> +req.u.mem_access.offset = gpa & ((1 << PAGE_SHIFT) - 1);
> +
> +return monitor_traps(current, true, ) >= 0;
> +}
> +
>  /*
>   * Convert addr from linear to physical form, valid over the range
>   * [addr, addr + *reps * bytes_per_rep]. *reps is adjusted according to
> @@ -636,6 +688,7 @@ static void *hvmemul_map_linear_addr(
>  unsigned int nr_frames = ((linear + bytes - !!bytes) >> PAGE_SHIFT) -
>  (linear >> PAGE_SHIFT) + 1;
>  unsigned int i;
> +gfn_t gfn;
>  
>  /*
>   * mfn points to the next free slot.  All used slots have a page 
> reference
> @@ -674,7 +727,7 @@ static void *hvmemul_map_linear_addr(
>  ASSERT(mfn_x(*mfn) == 0);
>  
>  res = hvm_translate_get_page(curr, addr, true, pfec,
> - , , NULL, );
> + , , , );
>  
>  switch ( res )
>  {
> @@ -704,6 +757,23 @@ static void *hvmemul_map_linear_addr(
>  
>  if ( pfec & PFEC_write_access )
>  {
> +unsigned long reps = 1;
> +struct hvm_emulate_ctxt old;
> +int rc = 0;
> +paddr_t gpa;
> +
> +old = *hvmemul_ctxt;
> +rc = hvmemul_linear_to_phys(
> + addr, , bytes, , pfec, hvmemul_ctxt);

The indentation is weird here, it should be:

rc = hvmemul_linear_to_phys(addr, , bytes, ,
pfec, hvmemul_ctxt);

> +if ( rc == X86EMUL_EXCEPTION )
> +*hvmemul_ctxt = old;
> +
> +if ( 

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Julien Grall]

Hi,

Sorry for the formatting.

On Mon, 4 Feb 2019, 15:52 Andrii Anisov,  wrote:

>
>
> On 04.02.19 13:21, Julien Grall wrote:
> > What I meant is the virtual address stays the same but the guest
> physical address may change. I don't see how this could be broken today,
> can you explain it?
>
> I suppose guest's mapping change is not quite atomic from the hypervisor
> point of view, so domain could be caught in the middle.
>

Well that's an issue with any hypercall using virtual address. You are not
even protected because of shatterring.

Thanksfully that does not seem to happen on Linux. Although, I have seen
error some times on osstest...

Virtual address has other issues if you can't access page-tables. So
ideally, we want to switch all hypercalls to use guest physical address.


> >
> >> Moreover, having that buffer mapped to XEN will reduce context switch
> time as a side effect.
> >
> > I am still unsure whether we really want to keep that always mapped.
> >
> > Each guest can support up to 128 vCPUs. So we would have 128 runstates
> mapped. Each runstate would take up to 2 pages. This means that each guest
> would require up to 1MB of vmap.
>
> Here buffer allocation on XEN side might benefit, even aligning/fitting
> the runstate into one page might work. But I understand it is undesirable
> and requires lot of changes
>

For a new interface,  the way to go is using guest physical address. Any
hypercall using virtual address should be killed.


> > I thought more about it during the week-end. I would actually not
> implement get_gfn but implement a function similar to get_page_from_gva on
> x86. The reason behind this is the function on Arm is quite complex as it
> caters many different use case.
>
> I'll look into this. But I have to massage my yocto first.
>

Thank you!



> --
> Sincerely,
> Andrii Anisov.
>
> ___
> Xen-devel mailing list
> Xen-devel@lists.xenproject.org
> https://lists.xenproject.org/mailman/listinfo/xen-devel
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12] x86/vpmu: Improve documentation and parsing for vpmu=

[Andrew Cooper]

On 04/02/2019 14:44, Jan Beulich wrote:
 On 04.02.19 at 15:22,  wrote:
>> On 04/02/2019 13:53, Jan Beulich wrote:
>> On 04.02.19 at 12:41,  wrote:
 @@ -64,37 +54,37 @@ static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
  static int __init parse_vpmu_params(const char *s)
  {
  const char *ss;
 +int rc = 0, val;
 +
 +do {
 +ss = strchr(s, ',');
 +if ( !ss )
 +ss = strchr(s, '\0');
 +
 +if ( (val = parse_bool(s, ss)) >= 0 )
 +opt_vpmu_enabled = val;
 +else if ( !cmdline_strcmp(s, "bts") )
 +vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
 +else if ( !cmdline_strcmp(s, "ipc") )
 +vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
 +else if ( !cmdline_strcmp(s, "arch") )
 +vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
 +else
 +rc = -EINVAL;
  
 -switch ( parse_bool(s, NULL) )
 -{
 -case 0:
 -break;
 -default:
 -do {
 -ss = strchr(s, ',');
 -if ( !ss )
 -ss = strchr(s, '\0');
 -
 -if ( !cmdline_strcmp(s, "bts") )
 -vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
 -else if ( !cmdline_strcmp(s, "ipc") )
 -vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
 -else if ( !cmdline_strcmp(s, "arch") )
 -vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
 -else
 -return -EINVAL;
 +s = ss + 1;
 +} while ( *ss );
 +
 +/* Selecting bts/ipc/arch forces vpmu to enabled. */
 +if ( vpmu_features )
 +opt_vpmu_enabled = true;
>>> If you want to retain original behavior, the condition here would need
>>> to be "!rc && vpmu_features". It's not clear whether your modification
>>> in this regard is intentional.
>> Oh - that wasn't intentional.
>>
>> An alternative, now I think about it, is to just have the =false
>> case clear vpmu_features.  This is new behaviour, but it is more
>> consistent with how other options work, and it wasn't expressable before.
> Generally - yes. But what would e.g. "vpmu=off,ipc" end up doing in
> your new model?

The use of vpmu_features is somewhat weird.  "bts" acts as an extra
feature on top of "generally on", whereas "ipc" and "arch" act as
restrictions on top of "generally on".

I'd expect "vpmu=off,ipc" to imply "vpmu=off,ipc,on", and result in
opt_vpmu_enabled=1 and vpmu_features=ipc.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Andrii Anisov]

On 04.02.19 13:21, Julien Grall wrote:

What I meant is the virtual address stays the same but the guest physical 
address may change. I don't see how this could be broken today, can you explain 
it?


I suppose guest's mapping change is not quite atomic from the hypervisor point 
of view, so domain could be caught in the middle.




Moreover, having that buffer mapped to XEN will reduce context switch time as a 
side effect.


I am still unsure whether we really want to keep that always mapped.

Each guest can support up to 128 vCPUs. So we would have 128 runstates mapped. 
Each runstate would take up to 2 pages. This means that each guest would 
require up to 1MB of vmap.


Here buffer allocation on XEN side might benefit, even aligning/fitting the 
runstate into one page might work. But I understand it is undesirable and 
requires lot of changes


I thought more about it during the week-end. I would actually not implement 
get_gfn but implement a function similar to get_page_from_gva on x86. The 
reason behind this is the function on Arm is quite complex as it caters many 
different use case.


I'll look into this. But I have to massage my yocto first.

--
Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12] x86/vpmu: Improve documentation and parsing for vpmu=

[Jan Beulich]

>>> On 04.02.19 at 15:22,  wrote:
> On 04/02/2019 13:53, Jan Beulich wrote:
> On 04.02.19 at 12:41,  wrote:
>>> @@ -64,37 +54,37 @@ static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
>>>  static int __init parse_vpmu_params(const char *s)
>>>  {
>>>  const char *ss;
>>> +int rc = 0, val;
>>> +
>>> +do {
>>> +ss = strchr(s, ',');
>>> +if ( !ss )
>>> +ss = strchr(s, '\0');
>>> +
>>> +if ( (val = parse_bool(s, ss)) >= 0 )
>>> +opt_vpmu_enabled = val;
>>> +else if ( !cmdline_strcmp(s, "bts") )
>>> +vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
>>> +else if ( !cmdline_strcmp(s, "ipc") )
>>> +vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
>>> +else if ( !cmdline_strcmp(s, "arch") )
>>> +vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
>>> +else
>>> +rc = -EINVAL;
>>>  
>>> -switch ( parse_bool(s, NULL) )
>>> -{
>>> -case 0:
>>> -break;
>>> -default:
>>> -do {
>>> -ss = strchr(s, ',');
>>> -if ( !ss )
>>> -ss = strchr(s, '\0');
>>> -
>>> -if ( !cmdline_strcmp(s, "bts") )
>>> -vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
>>> -else if ( !cmdline_strcmp(s, "ipc") )
>>> -vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
>>> -else if ( !cmdline_strcmp(s, "arch") )
>>> -vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
>>> -else
>>> -return -EINVAL;
>>> +s = ss + 1;
>>> +} while ( *ss );
>>> +
>>> +/* Selecting bts/ipc/arch forces vpmu to enabled. */
>>> +if ( vpmu_features )
>>> +opt_vpmu_enabled = true;
>> If you want to retain original behavior, the condition here would need
>> to be "!rc && vpmu_features". It's not clear whether your modification
>> in this regard is intentional.
> 
> Oh - that wasn't intentional.
> 
> An alternative, now I think about it, is to just have the =false
> case clear vpmu_features.  This is new behaviour, but it is more
> consistent with how other options work, and it wasn't expressable before.

Generally - yes. But what would e.g. "vpmu=off,ipc" end up doing in
your new model?

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v7 09/15] argo: implement the sendv op; evtchn: expose send_guest_global_virq

[Jan Beulich]

>>> On 31.01.19 at 05:28,  wrote:
> @@ -1237,6 +1864,54 @@ compat_argo_op(unsigned int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) arg1,
>  break;
>  }
>  
> +case XEN_ARGO_OP_sendv:
> +{
> +xen_argo_send_addr_t send_addr;
> +xen_argo_iov_t iovs[XEN_ARGO_MAXIOV];
> +unsigned int i;
> +unsigned int niov;
> +
> +XEN_GUEST_HANDLE_PARAM(xen_argo_send_addr_t) send_addr_hnd =
> +guest_handle_cast(arg1, xen_argo_send_addr_t);
> +/* arg2: iovs, arg3: niov, arg4: message_type */
> +
> +rc = copy_from_guest(_addr, send_addr_hnd, 1) ? -EFAULT : 0;
> +if ( rc )
> +break;
> +
> +if ( unlikely(arg3 > XEN_ARGO_MAXIOV) )
> +{
> +rc = -EINVAL;
> +break;
> +}
> +niov = array_index_nospec(arg3, XEN_ARGO_MAXIOV + 1);
> +
> +/*
> + * Limited scope for compat_iovs array: enables a single 
> copy_from_guest
> + * call and discards the array from the stack before calling sendv.
> + */

What makes you think the array gets removed from the stack again
before the call? The typical way of setting up stack frames for a
function is to allocate the full chunk of space needed at the start
of the function, and remove it before returning. Without the
argo_dprintk() after the switch() there would be the potential of
the sendv() carried out as a tail call, but you can't rely on that.

With the current XEN_ARGO_MAXIOV value of 8 the overall frame
size is still tolerable, I would say. But I think you want to add
BUILD_BUG_ON()s here and in the native handler, such that
careless bumping of the value won't go unnoticed (but also see
below).

> --- a/xen/include/public/argo.h
> +++ b/xen/include/public/argo.h
> @@ -43,6 +43,28 @@
>  /* Fixed-width type for "argo port" number. Nothing to do with evtchns. */
>  typedef uint32_t xen_argo_port_t;
>  
> +/*
> + * XEN_ARGO_MAXIOV : maximum number of iovs accepted in a single sendv.
> + * Caution is required if this value is increased: this determines the size 
> of
> + * an array of xen_argo_iov_t structs on the hypervisor stack, so could cause
> + * stack overflow if the value is too large.
> + * The Linux Argo driver never passes more than two iovs.
> + *
> + * This value should also not exceed 128 to ensure that the total amount of 
> data
> + * posted in a single Argo sendv operation cannot exceed 2^31 bytes, to 
> reduce
> + * risk of integer overflow defects:
> + * Each argo iov can hold ~ 2^24 bytes, so XEN_ARGO_MAXIOV <= 2^(31-24),
> + * ie. keep XEN_ARGO_MAXIOV <= 128.
> +*/
> +#define XEN_ARGO_MAXIOV  8U

How does 2^31 come into play here? uint32_t can hold up to 2^32, and
you shouldn't be using signed arithmetic anywhere by this time anymore.
I'm also struggling to see what the "~ 2^24 bytes" refers to - I see nothing
along these lines added to the public header, and ...

> +typedef struct xen_argo_iov
> +{
> +XEN_GUEST_HANDLE(uint8) iov_hnd;
> +uint32_t iov_len;

... the field here allows for 2^32-1. Oh, it's XEN_ARGO_MAX_RING_SIZE.
It would help if the comment cross referenced that name.

Btw., neither of these two maximum values look to be architectural limits,
so I wonder whether, before declaring the ABI stable, these constants
shouldn't be purged and replaced by settings the guest is to retrieve via
hypercall.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12] x86/vpmu: Improve documentation and parsing for vpmu=

[Andrew Cooper]

On 04/02/2019 13:53, Jan Beulich wrote:
 On 04.02.19 at 12:41,  wrote:
>> --- a/docs/misc/xen-command-line.pandoc
>> +++ b/docs/misc/xen-command-line.pandoc
>> @@ -2088,36 +2088,36 @@ Use Virtual Processor ID support if available.  This 
>> prevents the need for TLB
>>  flushes on VM entry and exit, increasing performance.
>>  
>>  ### vpmu (x86)
>> -> `= (  | { bts | ipc | arch [, ...] } )`
>> += List of [ , bts, ipc, arch ]
>>  
>> -> Default: `off`
>> +Applicability: x86.  Default: false
>>  
>> -Switch on the virtualized performance monitoring unit for HVM guests.
>> +Controls for Performance Monitoring Unit virtualisation.
>>  
>> -If the current cpu isn't supported a message like
>> -'VPMU: Initialization failed. ...'
>> -is printed on the hypervisor serial log.
>> +Performance monitoring facilities tend to be very hardware specific, and
>> +provide access to a wealth of low level processor information.
>>  
>> -For some Intel Nehalem processors a quirk handling exist for an unknown
>> -wrong behaviour (see `handle_pmc_quirk()`).
>> +*   An overall boolean can be used to enable or disable vPMU support.  vPMU 
>> is
>> +disabled by default.  Specifying any of `bts`, `ipc` or `arch` implies
>> +`vpmu=true`.
>>  
>> -If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store 
>> (BTS)
>> -feature is switched on on Intel processors supporting this feature.
>> +Xen's watchdog functionality is implemented using performance counters.
>> +As a result, use of the **watchdog** option will override and disable
>> +vPMU.
>>  
>> -vpmu=ipc enables performance monitoring, but restricts the counters to the
>> -most minimum set possible: instructions, cycles, and reference cycles. These
>> -can be used to calculate instructions per cycle (IPC).
>> +*   The `bts` option enabled performance monitoring, and permits access to 
>> the
> DYM "enables" here (and also below for `ipc`)?

Oops yes.  Fixed.

>
>> --- a/xen/arch/x86/cpu/vpmu.c
>> +++ b/xen/arch/x86/cpu/vpmu.c
>> @@ -42,19 +42,9 @@ CHECK_pmu_cntr_pair;
>>  CHECK_pmu_data;
>>  CHECK_pmu_params;
>>  
>> -/*
>> - * "vpmu" : vpmu generally enabled (all counters)
>> - * "vpmu=off"  : vpmu generally disabled
>> - * "vpmu=bts"  : vpmu enabled and Intel BTS feature switched on.
>> - * "vpmu=ipc"  : vpmu enabled for IPC counters only (most restrictive)
>> - * "vpmu=arch" : vpmu enabled for predef arch counters only (restrictive)
>> - * flag combinations are allowed, eg, "vpmu=ipc,bts".
>> - */
>>  static unsigned int __read_mostly opt_vpmu_enabled;
>>  unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF;
>>  unsigned int __read_mostly vpmu_features = 0;
>> -static int parse_vpmu_params(const char *s);
>> -custom_param("vpmu", parse_vpmu_params);
>>  
>>  static DEFINE_SPINLOCK(vpmu_lock);
>>  static unsigned vpmu_count;
>> @@ -64,37 +54,37 @@ static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
>>  static int __init parse_vpmu_params(const char *s)
>>  {
>>  const char *ss;
>> +int rc = 0, val;
>> +
>> +do {
>> +ss = strchr(s, ',');
>> +if ( !ss )
>> +ss = strchr(s, '\0');
>> +
>> +if ( (val = parse_bool(s, ss)) >= 0 )
>> +opt_vpmu_enabled = val;
>> +else if ( !cmdline_strcmp(s, "bts") )
>> +vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
>> +else if ( !cmdline_strcmp(s, "ipc") )
>> +vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
>> +else if ( !cmdline_strcmp(s, "arch") )
>> +vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
>> +else
>> +rc = -EINVAL;
>>  
>> -switch ( parse_bool(s, NULL) )
>> -{
>> -case 0:
>> -break;
>> -default:
>> -do {
>> -ss = strchr(s, ',');
>> -if ( !ss )
>> -ss = strchr(s, '\0');
>> -
>> -if ( !cmdline_strcmp(s, "bts") )
>> -vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
>> -else if ( !cmdline_strcmp(s, "ipc") )
>> -vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
>> -else if ( !cmdline_strcmp(s, "arch") )
>> -vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
>> -else
>> -return -EINVAL;
>> +s = ss + 1;
>> +} while ( *ss );
>> +
>> +/* Selecting bts/ipc/arch forces vpmu to enabled. */
>> +if ( vpmu_features )
>> +opt_vpmu_enabled = true;
> If you want to retain original behavior, the condition here would need
> to be "!rc && vpmu_features". It's not clear whether your modification
> in this regard is intentional.

Oh - that wasn't intentional.

An alternative, now I think about it, is to just have the =false
case clear vpmu_features.  This is new behaviour, but it is more
consistent with how other options work, and it wasn't expressable before.

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org

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

[osstest service owner]

flight 132841 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132841/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  844293c73685f8198bc2f0c7c5a101b3fcfd538c
baseline version:
 xen  755eb6403ec722db37f1b8f8b51e0b0ab661c003

Last test of basis   132712  2019-02-01 19:04:18 Z2 days
Testing same since   132841  2019-02-04 12:00:30 Z0 days1 attempts


People who touched revisions under test:
  Hans van Kranenburg 
  Wei Liu 

jobs:
 build-arm64-xsm  pass
 build-amd64  pass
 build-armhf  pass
 build-amd64-libvirt  pass
 test-armhf-armhf-xl  pass
 test-arm64-arm64-xl-xsm  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
 test-amd64-amd64-libvirt pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/xen.git
   755eb6403e..844293c736  844293c73685f8198bc2f0c7c5a101b3fcfd538c -> smoke

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12] tools: drop obsolete xen-ringwatch

[Andrew Cooper]

On 04/02/2019 13:58, Wei Liu wrote:
> This utility can't possibly work with modern Xen setup: none of the
> sysfs path used (under /sys/devices/xen-backend) is documented as
> stable ABI in upstream Linux kernel.
>
> Archaeology shows that the path used could have been part of the
> xenolinux fork which never got upstreamed.
>
> It's utility is zero nowadays. Drop it.
>
> Signed-off-by: Wei Liu 

It definitely used to "work" with the classic-xen kernels.

However, its utility was worse than zero.  When it did end up poking the
back drivers, it ended up masking bugs.

XenServer got rather more stable when I dropped this locally, as we
actually found and fixed the missing interrupt bug.

Reviewed-by: Andrew Cooper 

~Andrew

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12] tools: drop obsolete xen-ringwatch

[Wei Liu]

On Mon, Feb 04, 2019 at 01:58:24PM +, Wei Liu wrote:
> This utility can't possibly work with modern Xen setup: none of the
> sysfs path used (under /sys/devices/xen-backend) is documented as
> stable ABI in upstream Linux kernel.
> 
> Archaeology shows that the path used could have been part of the
> xenolinux fork which never got upstreamed.
> 
> It's utility is zero nowadays. Drop it.

"It's" should have been "Its", of course. :-)

Wei.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12] tools: drop obsolete xen-ringwatch

[Juergen Gross]

On 04/02/2019 14:58, Wei Liu wrote:
> This utility can't possibly work with modern Xen setup: none of the
> sysfs path used (under /sys/devices/xen-backend) is documented as
> stable ABI in upstream Linux kernel.
> 
> Archaeology shows that the path used could have been part of the
> xenolinux fork which never got upstreamed.
> 
> It's utility is zero nowadays. Drop it.
> 
> Signed-off-by: Wei Liu 

Release-acked-by: Juergen Gross 


Juergen

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH for-4.12] tools: drop obsolete xen-ringwatch

[Wei Liu]

This utility can't possibly work with modern Xen setup: none of the
sysfs path used (under /sys/devices/xen-backend) is documented as
stable ABI in upstream Linux kernel.

Archaeology shows that the path used could have been part of the
xenolinux fork which never got upstreamed.

It's utility is zero nowadays. Drop it.

Signed-off-by: Wei Liu 
---
 tools/misc/Makefile  |   2 -
 tools/misc/xen-ringwatch | 617 ---
 2 files changed, 619 deletions(-)
 delete mode 100644 tools/misc/xen-ringwatch

diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index fd91202950..51adb6f1a6 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -22,7 +22,6 @@ INSTALL_SBIN-$(CONFIG_X86) += xen-hvmcrash
 INSTALL_SBIN-$(CONFIG_X86) += xen-hvmctx
 INSTALL_SBIN-$(CONFIG_X86) += xen-lowmemd
 INSTALL_SBIN-$(CONFIG_X86) += xen-mfndump
-INSTALL_SBIN   += xen-ringwatch
 INSTALL_SBIN   += xen-tmem-list-parse
 INSTALL_SBIN   += xencov
 INSTALL_SBIN   += xenlockprof
@@ -40,7 +39,6 @@ INSTALL_PRIVBIN+= xenpvnetboot
 TARGETS_ALL := $(INSTALL_BIN) $(INSTALL_SBIN) $(INSTALL_PRIVBIN)
 
 # Everything which only needs copying to install
-TARGETS_COPY += xen-ringwatch
 TARGETS_COPY += xencons
 TARGETS_COPY += xencov_split
 TARGETS_COPY += xenpvnetboot
diff --git a/tools/misc/xen-ringwatch b/tools/misc/xen-ringwatch
deleted file mode 100644
index e6f5361231..00
--- a/tools/misc/xen-ringwatch
+++ /dev/null
@@ -1,617 +0,0 @@
-#!/usr/bin/python
-#
-# Copyright (C) 2011 Citrix Systems, Inc.
-#
-# This library is free software; you can redistribute it and/or modify
-# it under the terms of version 2.1 of the GNU Lesser General Public
-# License as published by the Free Software Foundation.
-#
-# This library is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
-# Lesser General Public License for more details.
-#
-# You should have received a copy of the GNU Lesser General Public
-# License along with this library; If not, see .
-#
-
-"""Overview:
-
-- Gather Xen I/O ring states
-  (from %s/*/ring)
-
-- Update ring states every -T seconds.
-
-- Determine if rings are idle or make progress.
-
-- Determine if idle rings dropped notifications (%s).
-
-- Instruct stuck backends to reissue notifications.
-"""
-
-import os
-import glob
-
-class Pattern(object):
-"""A regex pattern. Compiled on demand, then persisted."""
-
-def __init__(self, regex):
-self.regex = regex
-self.__pattern = None
-
-def get(self):
-import re
-
-if not self.__pattern:
-self.__pattern = re.compile(self.regex)
-
-return self.__pattern
-
-def search(self, s):
-return self.get().search(s)
-
-class XenBackend(object):
-"""A Xen I/O backend."""
-
-SYSFS_BASEDIR = "/sys/devices/xen-backend"
-
-def __init__(self, rd, devid):
-self.rd= int(rd)
-self.devid = int(devid)
-
-def __repr__(self):
-return "%s(%d, %d)" % (type(self).__name__,
-   self.rd, self.devid)
-
-def name(self):
-raise NotImplementedError
-
-def path(self):
-return "%s/%s" % (self.SYSFS_BASEDIR, self.name())
-
-_name_pattern = None
-
-@classmethod
-def from_name(cls, name):
-match = cls._name_pattern.search(name)
-if not match:
-raise Exception, "Malformed %s name: %s" % \
-(type(self).__name__, name)
-
-rd= match.group(1)
-devid = match.group(2)
-
-return cls(rd, devid)
-
-_name_glob = None
-
-@classmethod
-def find(cls):
-paths = glob.glob("%s/%s" % (cls.SYSFS_BASEDIR,
- cls._name_glob))
-for path in paths:
-name = os.path.basename(path)
-yield cls.from_name(name)
-
-def find_rings(self):
-for ring in self.Ring.find(self):
-yield ring
-
-class Ring(object):
-
-def __init__(self, backend, name):
-self.backend = backend
-self.name= name
-
-__size = None
-
-def key(self):
-return "%s/%s" % (self.backend.name(),
-  self.name)
-
-def __str__(self):
-return "%s(%s)" % (type(self).__name__, self.key())
-
-@classmethod
-def from_name(cls, backend, name):
-return cls(backend, name)
-
-_name_glob = None
-
-@classmethod
-def find(cls, backend):
-paths = glob.glob("%s/%s" % (backend.path(),
- cls._name_glob))
-for path in paths:
-name = os.path.basename(path)

Re: [Xen-devel] [PATCH for-4.12] x86/vpmu: Improve documentation and parsing for vpmu=

[Jan Beulich]

>>> On 04.02.19 at 12:41,  wrote:
> --- a/docs/misc/xen-command-line.pandoc
> +++ b/docs/misc/xen-command-line.pandoc
> @@ -2088,36 +2088,36 @@ Use Virtual Processor ID support if available.  This 
> prevents the need for TLB
>  flushes on VM entry and exit, increasing performance.
>  
>  ### vpmu (x86)
> -> `= (  | { bts | ipc | arch [, ...] } )`
> += List of [ , bts, ipc, arch ]
>  
> -> Default: `off`
> +Applicability: x86.  Default: false
>  
> -Switch on the virtualized performance monitoring unit for HVM guests.
> +Controls for Performance Monitoring Unit virtualisation.
>  
> -If the current cpu isn't supported a message like
> -'VPMU: Initialization failed. ...'
> -is printed on the hypervisor serial log.
> +Performance monitoring facilities tend to be very hardware specific, and
> +provide access to a wealth of low level processor information.
>  
> -For some Intel Nehalem processors a quirk handling exist for an unknown
> -wrong behaviour (see `handle_pmc_quirk()`).
> +*   An overall boolean can be used to enable or disable vPMU support.  vPMU 
> is
> +disabled by default.  Specifying any of `bts`, `ipc` or `arch` implies
> +`vpmu=true`.
>  
> -If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
> -feature is switched on on Intel processors supporting this feature.
> +Xen's watchdog functionality is implemented using performance counters.
> +As a result, use of the **watchdog** option will override and disable
> +vPMU.
>  
> -vpmu=ipc enables performance monitoring, but restricts the counters to the
> -most minimum set possible: instructions, cycles, and reference cycles. These
> -can be used to calculate instructions per cycle (IPC).
> +*   The `bts` option enabled performance monitoring, and permits access to 
> the

DYM "enables" here (and also below for `ipc`)?

> --- a/xen/arch/x86/cpu/vpmu.c
> +++ b/xen/arch/x86/cpu/vpmu.c
> @@ -42,19 +42,9 @@ CHECK_pmu_cntr_pair;
>  CHECK_pmu_data;
>  CHECK_pmu_params;
>  
> -/*
> - * "vpmu" : vpmu generally enabled (all counters)
> - * "vpmu=off"  : vpmu generally disabled
> - * "vpmu=bts"  : vpmu enabled and Intel BTS feature switched on.
> - * "vpmu=ipc"  : vpmu enabled for IPC counters only (most restrictive)
> - * "vpmu=arch" : vpmu enabled for predef arch counters only (restrictive)
> - * flag combinations are allowed, eg, "vpmu=ipc,bts".
> - */
>  static unsigned int __read_mostly opt_vpmu_enabled;
>  unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF;
>  unsigned int __read_mostly vpmu_features = 0;
> -static int parse_vpmu_params(const char *s);
> -custom_param("vpmu", parse_vpmu_params);
>  
>  static DEFINE_SPINLOCK(vpmu_lock);
>  static unsigned vpmu_count;
> @@ -64,37 +54,37 @@ static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
>  static int __init parse_vpmu_params(const char *s)
>  {
>  const char *ss;
> +int rc = 0, val;
> +
> +do {
> +ss = strchr(s, ',');
> +if ( !ss )
> +ss = strchr(s, '\0');
> +
> +if ( (val = parse_bool(s, ss)) >= 0 )
> +opt_vpmu_enabled = val;
> +else if ( !cmdline_strcmp(s, "bts") )
> +vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
> +else if ( !cmdline_strcmp(s, "ipc") )
> +vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
> +else if ( !cmdline_strcmp(s, "arch") )
> +vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
> +else
> +rc = -EINVAL;
>  
> -switch ( parse_bool(s, NULL) )
> -{
> -case 0:
> -break;
> -default:
> -do {
> -ss = strchr(s, ',');
> -if ( !ss )
> -ss = strchr(s, '\0');
> -
> -if ( !cmdline_strcmp(s, "bts") )
> -vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
> -else if ( !cmdline_strcmp(s, "ipc") )
> -vpmu_features |= XENPMU_FEATURE_IPC_ONLY;
> -else if ( !cmdline_strcmp(s, "arch") )
> -vpmu_features |= XENPMU_FEATURE_ARCH_ONLY;
> -else
> -return -EINVAL;
> +s = ss + 1;
> +} while ( *ss );
> +
> +/* Selecting bts/ipc/arch forces vpmu to enabled. */
> +if ( vpmu_features )
> +opt_vpmu_enabled = true;

If you want to retain original behavior, the condition here would need
to be "!rc && vpmu_features". It's not clear whether your modification
in this regard is intentional.

Jan


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [qemu-mainline test] 132772: regressions - FAIL

[osstest service owner]

flight 132772 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132772/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install 
fail REGR. vs. 131842

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-arndale   6 xen-install  fail in 132737 pass in 132772
 test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 12 
guest-start/debianhvm.repeat fail pass in 132737

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 131842
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 131842
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 131842
 test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stopfail like 131842
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 131842
 test-amd64-i386-xl-pvshim12 guest-start  fail   never pass
 test-arm64-arm64-xl  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit2  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  13 migrate-support-checkfail   never pass
 test-arm64-arm64-xl-xsm  14 saverestore-support-checkfail   never pass
 test-arm64-arm64-xl-credit1  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit1  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop  fail never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass

version targeted for testing:
 qemuub3fc0af1ff5e922d4dd7c875394dbd26dc7313b4
baseline version:
 qemuu147923b1a901a0370f83a0f4c58ec1baffef22f0

Last test of basis   131842  2019-01-09 00:37:22 Z   26 days
Failing since131892  2019-01-09 23:37:00 Z   25 days   22 attempts
Testing same since   132737  2019-02-02 06:42:28 Z2 days2 attempts


People who touched revisions under test:
  Aaron Lindsay 
  Aaron Lindsay 
  Aaron Lindsay 
  Aaron Lindsay OS 
  Alberto Garcia 
  Aleksandar Markovic 
  Alex Bennée 
  Alex Williamson 
  Alexander Graf 
  Alexander Kanavin 
  Alexandro Sanchez Bach 
  Alexey Kardashevskiy 
  Alistair Francis 
  Andrew Jeffery 
  Anthony 

[Xen-devel] [libvirt test] 132776: tolerable all pass - PUSHED

[osstest service owner]

flight 132776 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/132776/

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 132745
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 132745
 test-arm64-arm64-libvirt 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt 14 saverestore-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-xsm 14 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-arm64-arm64-libvirt-qcow2 12 migrate-support-checkfail never pass
 test-arm64-arm64-libvirt-qcow2 13 saverestore-support-checkfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  7c9dcfed5ae6d5874ea0e67e47a6871707b8446a
baseline version:
 libvirt  18795687447dd55a281d33d24ae0a06c6bc081ee

Last test of basis   132745  2019-02-02 11:36:21 Z2 days
Testing same since   132776  2019-02-03 13:45:39 Z0 days1 attempts


People who touched revisions under test:
  Laine Stump 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-arm64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-arm64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-arm64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-libvirt-xsm pass
 test-arm64-arm64-libvirt-xsm pass
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-arm64-arm64-libvirt pass
 test-armhf-armhf-libvirt pass
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairpass
 test-amd64-i386-libvirt-pair pass
 test-arm64-arm64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-raw pass
 test-amd64-amd64-libvirt-vhd pass



sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images

Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs

Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master

Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary


Pushing revision :

To xenbits.xen.org:/home/xen/git/libvirt.git
   1879568744..7c9dcfed5a  7c9dcfed5ae6d5874ea0e67e47a6871707b8446a -> 
xen-tested-master

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Roger Pau Monné]

On Fri, Feb 01, 2019 at 05:40:14PM +, Julien Grall wrote:
> Hi,
> 
> On 01/02/2019 16:53, Roger Pau Monné wrote:
> > On Thu, Jan 31, 2019 at 11:14:37PM +, Julien Grall wrote:
> > > On 1/31/19 9:56 PM, Stefano Stabellini wrote:
> > > > On Thu, 31 Jan 2019, Julien Grall wrote:
> > > > > On 31/01/2019 12:00, Andrii Anisov wrote:
> > > > > > On 31.01.19 13:37, Julien Grall wrote:
> > So, I've got a hacky patch to 'fix' this on x86, by taking a reference
> > to the mfn behind the virtual address provided when setting up the
> > hypercall and mapping it in Xen.
> 
> That was the idea I had in mind :). Hopefully, no guest is modifying the
> mapping (i.e the virtual address point to a different physical address)
> afterwards.
> 
> > This however doesn't work on ARM due
> > to the lack of paging_gva_to_gfn. I guess there's something similar to
> > translate a guest virtual address into a gfn or a mfn?
> 
> get_page_from_gva should to the job for you.
> > +int map_runstate_area(struct vcpu *v,
> > +  struct vcpu_register_runstate_memory_area *area)
> > +{
> > +unsigned long offset;
> > +unsigned int i;
> > +struct domain *d = v->domain;
> > +size_t size =
> > +#ifdef CONFIG_COMPAT
> > +has_32bit_shinfo((v)->domain) ? sizeof(*v->compat_runstate_guest) :
> > +#endif
> > +sizeof(*v->runstate_guest);
> > +
> > +if ( v->runstate_guest )
> > +{
> > +ASSERT_UNREACHABLE();
> > +return -EBUSY;
> > +}
> > +
> > +offset = area->addr.p & ~PAGE_MASK;
> > +
> > +for ( i = 0; i < ARRAY_SIZE(v->runstate_mfn); i++ )
> > +{
> > +p2m_type_t t;
> > +uint32_t pfec = PFEC_page_present;
> > +gfn_t gfn = _gfn(paging_gva_to_gfn(v, area->addr.p, ));
> > +struct page_info *pg;
> > +
> > +if ( gfn_eq(gfn, INVALID_GFN) )
> > +return -EFAULT;
> > +
> > +v->runstate_mfn[i] = get_gfn(d, gfn_x(gfn), );
> 
> get_gfn would need to be implemented on Arm.
> 
> > +if ( t != p2m_ram_rw || mfn_eq(v->runstate_mfn[i], INVALID_MFN) )
> > +return -EFAULT;
> > +
> > +pg = mfn_to_page(v->runstate_mfn[i]);
> > +if ( !pg || !get_page_type(pg, PGT_writable_page) )
> > +{
> > +put_gfn(d, gfn_x(gfn));
> > +return -EFAULT;
> > +}
> > +
> > +put_gfn(d, gfn_x(gfn));
> > +
> > +if ( PFN_DOWN(gfn_x(gfn) + size) == PFN_DOWN(gfn_x(gfn)) )
> 
> This looks wrong, you seem to mix address and frame. I think you might want:
> 
> if ( gfn_eq(gfn_add(gfn, PFN_DOWN(size)), gfn) )

Thanks!

Here is an updated version which seems to build on ARM. I don't have
an easy way to test this, could you give it a spin?

I don't like adding CONFIG_X86/ARM in common code, so it might be
worth to either try to factor this out into arch specific code, or
even better, provide common functions to translate a guest virtual
address into a gfn, mfn or page.

---8<---
diff --git a/xen/arch/arm/domain.c b/xen/arch/arm/domain.c
index 6dc633ed50..6fb69a9e12 100644
--- a/xen/arch/arm/domain.c
+++ b/xen/arch/arm/domain.c
@@ -275,31 +275,25 @@ static void ctxt_switch_to(struct vcpu *n)
 }
 
 /* Update per-VCPU guest runstate shared memory area (if registered). */
-static void update_runstate_area(struct vcpu *v)
+void update_runstate_area(struct vcpu *v)
 {
-void __user *guest_handle = NULL;
-
-if ( guest_handle_is_null(runstate_guest(v)) )
+if ( !v->runstate_guest )
 return;
 
 if ( VM_ASSIST(v->domain, runstate_update_flag) )
 {
-guest_handle = >runstate_guest.p->state_entry_time + 1;
-guest_handle--;
 v->runstate.state_entry_time |= XEN_RUNSTATE_UPDATE;
-__raw_copy_to_guest(guest_handle,
-(void *)(>runstate.state_entry_time + 1) - 1, 
1);
+v->runstate_guest->state_entry_time |= XEN_RUNSTATE_UPDATE;
 smp_wmb();
 }
 
-__copy_to_guest(runstate_guest(v), >runstate, 1);
+memcpy(v->runstate_guest, >runstate, sizeof(v->runstate));
 
-if ( guest_handle )
+if ( VM_ASSIST(v->domain, runstate_update_flag) )
 {
 v->runstate.state_entry_time &= ~XEN_RUNSTATE_UPDATE;
 smp_wmb();
-__raw_copy_to_guest(guest_handle,
-(void *)(>runstate.state_entry_time + 1) - 1, 
1);
+v->runstate_guest->state_entry_time &= ~XEN_RUNSTATE_UPDATE;
 }
 }
 
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 32dc4253ff..b86d8d94c7 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -1604,26 +1604,22 @@ void paravirt_ctxt_switch_to(struct vcpu *v)
 }
 
 /* Update per-VCPU guest runstate shared memory area (if registered). */
-bool update_runstate_area(struct vcpu *v)
+void update_runstate_area(struct vcpu *v)
 {
-bool rc;
 struct guest_memory_policy policy = { .nested_guest_mode = false };
-void __user *guest_handle = NULL;
 
-if ( 

Re: [Xen-devel] [PATCH RFC v2 1/2] x86/emulate: Move hvmemul_linear_to_phys

[Razvan Cojocaru]

On 2/4/19 1:55 PM, Paul Durrant wrote:

-Original Message-
From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
Sent: 04 February 2019 11:37
To: xen-devel@lists.xenproject.org
Cc: Paul Durrant ; jbeul...@suse.com; Andrew
Cooper ; Wei Liu ; Roger
Pau Monne ; rcojoc...@bitdefender.com;
ta...@tklengyel.com; George Dunlap 
Subject: Re: [PATCH RFC v2 1/2] x86/emulate: Move hvmemul_linear_to_phys

Ping, any thoughts on this are appreciated.

Regards,
Alex

On 11.01.2019 17:37, Alexandru Stefan ISAILA wrote:

This is done so hvmemul_linear_to_phys() can be called from
hvmemul_map_linear_addr()



I have no objection to pure code movement for this purpose. I certainly prefer 
it to forward declaration of statics.

Thanks for the reply!

We're also after thoughts on the whole series (replying to this specific 
patch instead of the cover letter was an accident).


We expect the second patch to be more controversial and in some need of 
detailed scrutiny.



Thanks,
Razvan

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC v2 1/2] x86/emulate: Move hvmemul_linear_to_phys

[Paul Durrant]

> -Original Message-
> From: Alexandru Stefan ISAILA [mailto:aisa...@bitdefender.com]
> Sent: 04 February 2019 11:37
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; jbeul...@suse.com; Andrew
> Cooper ; Wei Liu ; Roger
> Pau Monne ; rcojoc...@bitdefender.com;
> ta...@tklengyel.com; George Dunlap 
> Subject: Re: [PATCH RFC v2 1/2] x86/emulate: Move hvmemul_linear_to_phys
> 
> Ping, any thoughts on this are appreciated.
> 
> Regards,
> Alex
> 
> On 11.01.2019 17:37, Alexandru Stefan ISAILA wrote:
> > This is done so hvmemul_linear_to_phys() can be called from
> > hvmemul_map_linear_addr()
> >

I have no objection to pure code movement for this purpose. I certainly prefer 
it to forward declaration of statics.

  Paul

> > Signed-off-by: Alexandru Isaila 
> > ---
> >   xen/arch/x86/hvm/emulate.c | 181 ++---
> >   1 file changed, 90 insertions(+), 91 deletions(-)
> >
> > diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> > index 2d02ef1521..a766eecc8e 100644
> > --- a/xen/arch/x86/hvm/emulate.c
> > +++ b/xen/arch/x86/hvm/emulate.c
> > @@ -530,6 +530,95 @@ static int hvmemul_do_mmio_addr(paddr_t mmio_gpa,
> >   return hvmemul_do_io_addr(1, mmio_gpa, reps, size, dir, df,
> ram_gpa);
> >   }
> >
> > +/*
> > + * Convert addr from linear to physical form, valid over the range
> > + * [addr, addr + *reps * bytes_per_rep]. *reps is adjusted according to
> > + * the valid computed range. It is always >0 when X86EMUL_OKAY is
> returned.
> > + * @pfec indicates the access checks to be performed during page-table
> walks.
> > + */
> > +static int hvmemul_linear_to_phys(
> > +unsigned long addr,
> > +paddr_t *paddr,
> > +unsigned int bytes_per_rep,
> > +unsigned long *reps,
> > +uint32_t pfec,
> > +struct hvm_emulate_ctxt *hvmemul_ctxt)
> > +{
> > +struct vcpu *curr = current;
> > +unsigned long pfn, npfn, done, todo, i, offset = addr & ~PAGE_MASK;
> > +int reverse;
> > +
> > +/*
> > + * Clip repetitions to a sensible maximum. This avoids extensive
> looping in
> > + * this function while still amortising the cost of I/O trap-and-
> emulate.
> > + */
> > +*reps = min_t(unsigned long, *reps, 4096);
> > +
> > +/* With no paging it's easy: linear == physical. */
> > +if ( !(curr->arch.hvm.guest_cr[0] & X86_CR0_PG) )
> > +{
> > +*paddr = addr;
> > +return X86EMUL_OKAY;
> > +}
> > +
> > +/* Reverse mode if this is a backwards multi-iteration string
> operation. */
> > +reverse = (hvmemul_ctxt->ctxt.regs->eflags & X86_EFLAGS_DF) &&
> (*reps > 1);
> > +
> > +if ( reverse && ((PAGE_SIZE - offset) < bytes_per_rep) )
> > +{
> > +/* Do page-straddling first iteration forwards via recursion.
> */
> > +paddr_t _paddr;
> > +unsigned long one_rep = 1;
> > +int rc = hvmemul_linear_to_phys(
> > +addr, &_paddr, bytes_per_rep, _rep, pfec,
> hvmemul_ctxt);
> > +if ( rc != X86EMUL_OKAY )
> > +return rc;
> > +pfn = _paddr >> PAGE_SHIFT;
> > +}
> > +else if ( (pfn = paging_gva_to_gfn(curr, addr, )) ==
> gfn_x(INVALID_GFN) )
> > +{
> > +if ( pfec & (PFEC_page_paged | PFEC_page_shared) )
> > +return X86EMUL_RETRY;
> > +*reps = 0;
> > +x86_emul_pagefault(pfec, addr, _ctxt->ctxt);
> > +return X86EMUL_EXCEPTION;
> > +}
> > +
> > +done = reverse ? bytes_per_rep + offset : PAGE_SIZE - offset;
> > +todo = *reps * bytes_per_rep;
> > +for ( i = 1; done < todo; i++ )
> > +{
> > +/* Get the next PFN in the range. */
> > +addr += reverse ? -PAGE_SIZE : PAGE_SIZE;
> > +npfn = paging_gva_to_gfn(curr, addr, );
> > +
> > +/* Is it contiguous with the preceding PFNs? If not then we're
> done. */
> > +if ( (npfn == gfn_x(INVALID_GFN)) ||
> > + (npfn != (pfn + (reverse ? -i : i))) )
> > +{
> > +if ( pfec & (PFEC_page_paged | PFEC_page_shared) )
> > +return X86EMUL_RETRY;
> > +done /= bytes_per_rep;
> > +if ( done == 0 )
> > +{
> > +ASSERT(!reverse);
> > +if ( npfn != gfn_x(INVALID_GFN) )
> > +return X86EMUL_UNHANDLEABLE;
> > +*reps = 0;
> > +x86_emul_pagefault(pfec, addr & PAGE_MASK,
> _ctxt->ctxt);
> > +return X86EMUL_EXCEPTION;
> > +}
> > +*reps = done;
> > +break;
> > +}
> > +
> > +done += PAGE_SIZE;
> > +}
> > +
> > +*paddr = ((paddr_t)pfn << PAGE_SHIFT) | offset;
> > +return X86EMUL_OKAY;
> > +}
> > +
> >   /*
> >* Map the frame(s) covering an individual linear access, for
> writeable
> >* access.  May return NULL for MMIO, or ERR_PTR(~X86EMUL_*) for other
> errors
> > @@ -692,97 +781,7 @@ static void hvmemul_unmap_linear_addr(
> >   *mfn++ 

Re: [Xen-devel] [Qemu-devel] [PULL 0/4] Xen queue 20190204

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20190204112803.11645-1-anthony.per...@citrix.com/



Hi,

This series failed the docker-mingw@fedora build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
time make docker-test-mingw@fedora SHOW_ENV=1 J=14
=== TEST SCRIPT END ===


Configure options:
--enable-werror --target-list=x86_64-softmmu,aarch64-softmmu 
--prefix=/tmp/qemu-test/install --python=/usr/bin/python3 
--cross-prefix=x86_64-w64-mingw32- --enable-trace-backends=simple 
--enable-gnutls --enable-nettle --enable-curl --enable-vnc --enable-bzip2 
--enable-guest-agent --with-sdlabi=2.0
ERROR: unknown option --with-sdlabi=2.0
Try '/tmp/qemu-test/src/configure --help' for more information
# QEMU configure log Mon Feb  4 11:46:06 UTC 2019
# Configured with: '/tmp/qemu-test/src/configure' '--enable-werror' 
'--target-list=x86_64-softmmu,aarch64-softmmu' 
'--prefix=/tmp/qemu-test/install' '--python=/usr/bin/python3' 
'--cross-prefix=x86_64-w64-mingw32-' '--enable-trace-backends=simple' 
'--enable-gnutls' '--enable-nettle' '--enable-curl' '--enable-vnc' 
'--enable-bzip2' '--enable-guest-agent' '--with-sdlabi=2.0'
---
funcs: do_compiler do_cc compile_object check_define main
lines: 92 122 617 634 0
x86_64-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99 -c -o 
config-temp/qemu-conf.o config-temp/qemu-conf.c
config-temp/qemu-conf.c:2:2: error: #error __linux__ not defined
 #error __linux__ not defined
  ^

---
funcs: do_compiler do_cc compile_object check_define main
lines: 92 122 617 686 0
x86_64-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99 -c -o 
config-temp/qemu-conf.o config-temp/qemu-conf.c
config-temp/qemu-conf.c:2:2: error: #error __i386__ not defined
 #error __i386__ not defined
  ^

---
funcs: do_compiler do_cc compile_object check_define main
lines: 92 122 617 689 0
x86_64-w64-mingw32-gcc -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE 
-Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings 
-Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv -std=gnu99 -c -o 
config-temp/qemu-conf.o config-temp/qemu-conf.c
config-temp/qemu-conf.c:2:2: error: #error __ILP32__ not defined
 #error __ILP32__ not defined
  ^

---
lines: 92 128 920 0
x86_64-w64-mingw32-gcc -mthreads -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef 
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv 
-std=gnu99 -o config-temp/qemu-conf.exe config-temp/qemu-conf.c -g -liberty
/usr/lib/gcc/x86_64-w64-mingw32/8.2.0/../../../../x86_64-w64-mingw32/bin/ld: 
cannot find -liberty
collect2: error: ld returned 1 exit status
Failed to run 'configure'
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 563, in 


The full log is available at
http://patchew.org/logs/20190204112803.11645-1-anthony.per...@citrix.com/testing.docker-mingw@fedora/?type=message.
---
Email generated automatically by Patchew [http://patchew.org/].
Please send your feedback to patchew-de...@redhat.com
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH RFC v2 1/2] x86/emulate: Move hvmemul_linear_to_phys

[Alexandru Stefan ISAILA]

Ping, any thoughts on this are appreciated.

Regards,
Alex

On 11.01.2019 17:37, Alexandru Stefan ISAILA wrote:
> This is done so hvmemul_linear_to_phys() can be called from
> hvmemul_map_linear_addr()
> 
> Signed-off-by: Alexandru Isaila 
> ---
>   xen/arch/x86/hvm/emulate.c | 181 ++---
>   1 file changed, 90 insertions(+), 91 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
> index 2d02ef1521..a766eecc8e 100644
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -530,6 +530,95 @@ static int hvmemul_do_mmio_addr(paddr_t mmio_gpa,
>   return hvmemul_do_io_addr(1, mmio_gpa, reps, size, dir, df, ram_gpa);
>   }
>   
> +/*
> + * Convert addr from linear to physical form, valid over the range
> + * [addr, addr + *reps * bytes_per_rep]. *reps is adjusted according to
> + * the valid computed range. It is always >0 when X86EMUL_OKAY is returned.
> + * @pfec indicates the access checks to be performed during page-table walks.
> + */
> +static int hvmemul_linear_to_phys(
> +unsigned long addr,
> +paddr_t *paddr,
> +unsigned int bytes_per_rep,
> +unsigned long *reps,
> +uint32_t pfec,
> +struct hvm_emulate_ctxt *hvmemul_ctxt)
> +{
> +struct vcpu *curr = current;
> +unsigned long pfn, npfn, done, todo, i, offset = addr & ~PAGE_MASK;
> +int reverse;
> +
> +/*
> + * Clip repetitions to a sensible maximum. This avoids extensive looping 
> in
> + * this function while still amortising the cost of I/O trap-and-emulate.
> + */
> +*reps = min_t(unsigned long, *reps, 4096);
> +
> +/* With no paging it's easy: linear == physical. */
> +if ( !(curr->arch.hvm.guest_cr[0] & X86_CR0_PG) )
> +{
> +*paddr = addr;
> +return X86EMUL_OKAY;
> +}
> +
> +/* Reverse mode if this is a backwards multi-iteration string operation. 
> */
> +reverse = (hvmemul_ctxt->ctxt.regs->eflags & X86_EFLAGS_DF) && (*reps > 
> 1);
> +
> +if ( reverse && ((PAGE_SIZE - offset) < bytes_per_rep) )
> +{
> +/* Do page-straddling first iteration forwards via recursion. */
> +paddr_t _paddr;
> +unsigned long one_rep = 1;
> +int rc = hvmemul_linear_to_phys(
> +addr, &_paddr, bytes_per_rep, _rep, pfec, hvmemul_ctxt);
> +if ( rc != X86EMUL_OKAY )
> +return rc;
> +pfn = _paddr >> PAGE_SHIFT;
> +}
> +else if ( (pfn = paging_gva_to_gfn(curr, addr, )) == 
> gfn_x(INVALID_GFN) )
> +{
> +if ( pfec & (PFEC_page_paged | PFEC_page_shared) )
> +return X86EMUL_RETRY;
> +*reps = 0;
> +x86_emul_pagefault(pfec, addr, _ctxt->ctxt);
> +return X86EMUL_EXCEPTION;
> +}
> +
> +done = reverse ? bytes_per_rep + offset : PAGE_SIZE - offset;
> +todo = *reps * bytes_per_rep;
> +for ( i = 1; done < todo; i++ )
> +{
> +/* Get the next PFN in the range. */
> +addr += reverse ? -PAGE_SIZE : PAGE_SIZE;
> +npfn = paging_gva_to_gfn(curr, addr, );
> +
> +/* Is it contiguous with the preceding PFNs? If not then we're done. 
> */
> +if ( (npfn == gfn_x(INVALID_GFN)) ||
> + (npfn != (pfn + (reverse ? -i : i))) )
> +{
> +if ( pfec & (PFEC_page_paged | PFEC_page_shared) )
> +return X86EMUL_RETRY;
> +done /= bytes_per_rep;
> +if ( done == 0 )
> +{
> +ASSERT(!reverse);
> +if ( npfn != gfn_x(INVALID_GFN) )
> +return X86EMUL_UNHANDLEABLE;
> +*reps = 0;
> +x86_emul_pagefault(pfec, addr & PAGE_MASK, 
> _ctxt->ctxt);
> +return X86EMUL_EXCEPTION;
> +}
> +*reps = done;
> +break;
> +}
> +
> +done += PAGE_SIZE;
> +}
> +
> +*paddr = ((paddr_t)pfn << PAGE_SHIFT) | offset;
> +return X86EMUL_OKAY;
> +}
> +
>   /*
>* Map the frame(s) covering an individual linear access, for writeable
>* access.  May return NULL for MMIO, or ERR_PTR(~X86EMUL_*) for other 
> errors
> @@ -692,97 +781,7 @@ static void hvmemul_unmap_linear_addr(
>   *mfn++ = _mfn(0);
>   }
>   #endif
> -}
> -
> -/*
> - * Convert addr from linear to physical form, valid over the range
> - * [addr, addr + *reps * bytes_per_rep]. *reps is adjusted according to
> - * the valid computed range. It is always >0 when X86EMUL_OKAY is returned.
> - * @pfec indicates the access checks to be performed during page-table walks.
> - */
> -static int hvmemul_linear_to_phys(
> -unsigned long addr,
> -paddr_t *paddr,
> -unsigned int bytes_per_rep,
> -unsigned long *reps,
> -uint32_t pfec,
> -struct hvm_emulate_ctxt *hvmemul_ctxt)
> -{
> -struct vcpu *curr = current;
> -unsigned long pfn, npfn, done, todo, i, offset = addr & ~PAGE_MASK;
> -int reverse;
> -
> -/*
> - * Clip repetitions 

[Xen-devel] [PATCH for-4.12] x86/vpmu: Improve documentation and parsing for vpmu=

[Andrew Cooper]

The behaviour of vpmu= being exclusive of vpmu=bts|ipc|arch is odd and
contrary to Xen's normal command line parsing behaviour.  Rewrite the parsing
to use the normal form, but retain the previous behaviour where the use of
bts/ipc/arch implies vpmu=true.

Parts of the documenation are stale, most notibly the HVM-only statement.
Update it for consistency and correctness.

Signed-off-by: Andrew Cooper 
---
CC: Jan Beulich 
CC: Wei Liu 
CC: Roger Pau Monné 
CC: Juergen Gross 
---
 docs/misc/xen-command-line.pandoc | 44 +--
 xen/arch/x86/cpu/vpmu.c   | 64 +--
 2 files changed, 49 insertions(+), 59 deletions(-)

diff --git a/docs/misc/xen-command-line.pandoc 
b/docs/misc/xen-command-line.pandoc
index 6a33775..a557353 100644
--- a/docs/misc/xen-command-line.pandoc
+++ b/docs/misc/xen-command-line.pandoc
@@ -2088,36 +2088,36 @@ Use Virtual Processor ID support if available.  This 
prevents the need for TLB
 flushes on VM entry and exit, increasing performance.
 
 ### vpmu (x86)
-> `= (  | { bts | ipc | arch [, ...] } )`
+= List of [ , bts, ipc, arch ]
 
-> Default: `off`
+Applicability: x86.  Default: false
 
-Switch on the virtualized performance monitoring unit for HVM guests.
+Controls for Performance Monitoring Unit virtualisation.
 
-If the current cpu isn't supported a message like
-'VPMU: Initialization failed. ...'
-is printed on the hypervisor serial log.
+Performance monitoring facilities tend to be very hardware specific, and
+provide access to a wealth of low level processor information.
 
-For some Intel Nehalem processors a quirk handling exist for an unknown
-wrong behaviour (see `handle_pmc_quirk()`).
+*   An overall boolean can be used to enable or disable vPMU support.  vPMU is
+disabled by default.  Specifying any of `bts`, `ipc` or `arch` implies
+`vpmu=true`.
 
-If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store (BTS)
-feature is switched on on Intel processors supporting this feature.
+Xen's watchdog functionality is implemented using performance counters.
+As a result, use of the **watchdog** option will override and disable
+vPMU.
 
-vpmu=ipc enables performance monitoring, but restricts the counters to the
-most minimum set possible: instructions, cycles, and reference cycles. These
-can be used to calculate instructions per cycle (IPC).
+*   The `bts` option enabled performance monitoring, and permits access to the
+Branch Trace Store controls.  BTS is an Intel feature where the processor
+can write data into a buffer whenever a branch occurs.  However, as this
+feature isn't virtualised, a misconfiguration by the guest can lock the
+entire system up.
 
-vpmu=arch enables performance monitoring, but restricts the counters to the
-pre-defined architectural events only. These are exposed by cpuid, and listed
-in the Pre-Defined Architectural Performance Events table from the Intel 64
-and IA-32 Architectures Software Developer's Manual, Volume 3B, System
-Programming Guide, Part 2.
+*   The `ipc` option enabled performance monitoring, but restricts the
+counters to the most minimum set possible: instructions, cycles, and
+reference cycles.  These can be used to calculate instructions per cycle
+(IPC).
 
-If a boolean is not used, combinations of flags are allowed, comma separated.
-For example, vpmu=arch,bts.
-
-Note that if **watchdog** option is also specified vpmu will be turned off.
+*   The `arch` option enables performance monitoring, but restricts the
+counters to the pre-defined architectural events only.
 
 *Warning:*
 As the virtualisation is not 100% safe, don't use the vpmu flag on
diff --git a/xen/arch/x86/cpu/vpmu.c b/xen/arch/x86/cpu/vpmu.c
index 13da7d0..dadccf5 100644
--- a/xen/arch/x86/cpu/vpmu.c
+++ b/xen/arch/x86/cpu/vpmu.c
@@ -42,19 +42,9 @@ CHECK_pmu_cntr_pair;
 CHECK_pmu_data;
 CHECK_pmu_params;
 
-/*
- * "vpmu" : vpmu generally enabled (all counters)
- * "vpmu=off"  : vpmu generally disabled
- * "vpmu=bts"  : vpmu enabled and Intel BTS feature switched on.
- * "vpmu=ipc"  : vpmu enabled for IPC counters only (most restrictive)
- * "vpmu=arch" : vpmu enabled for predef arch counters only (restrictive)
- * flag combinations are allowed, eg, "vpmu=ipc,bts".
- */
 static unsigned int __read_mostly opt_vpmu_enabled;
 unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF;
 unsigned int __read_mostly vpmu_features = 0;
-static int parse_vpmu_params(const char *s);
-custom_param("vpmu", parse_vpmu_params);
 
 static DEFINE_SPINLOCK(vpmu_lock);
 static unsigned vpmu_count;
@@ -64,37 +54,37 @@ static DEFINE_PER_CPU(struct vcpu *, last_vcpu);
 static int __init parse_vpmu_params(const char *s)
 {
 const char *ss;
+int rc = 0, val;
+
+do {
+ss = strchr(s, ',');
+if ( !ss )
+ss = strchr(s, '\0');
+
+if ( (val = parse_bool(s, ss)) >= 0 )
+opt_vpmu_enabled = val;
+ 

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Julien Grall]

On 2/4/19 10:32 AM, Andrii Anisov wrote:

Hello Julien,


Hi Andrii,


On 01.02.19 12:51, Julien Grall wrote:

I don't consider polluting your log a real problem.

Unless the system becomes an insane typewriter :)

I don't consider it as a critical issue because of the type of guest 
we currently support, so it is not in my queue for Xen 4.12 fixes.


Feel free to suggest it as a blocker if you think it is.
Well, for us the situation is as following: Renesas requested XEN 4.12 
for the next release of their virtualization package.


That's a good news! Let me try to address your concerns below one by one.

And they employ 
KPTI enabled kernel in the BSP.
KPTI is going to work on Xen. There are no known issue with Linux as the 
virtual address is not going to be re-used for other purpose in the 
virtual address space. The only inconvenience is the message in debug build.


Just in case, I am not saying it should not be fixed :).

That reveals another critical issue for us, in addition to Set/Way issue 


From the discussion on the another thread and with other people, this 
is not entirely the fault of Xen. This was a misuse of the instructions 
by the driver. While you may want to deal with this in your case, I 
would like to avoid promoting bad behavior when using Xen upstream.


and possible performance drops/irq latency raise due to specter 
mitigation measures.


Can you remind me the cores you are using?

Also, when you mean possible, does it mean you haven't looked the 
performance regression?


I'm not sure if this is sufficient a justification to make it the 
release blocker, but we are up to this stuff.


Which one?

Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PULL 2/4] configure: Don't add Xen's libs to LDFLAGS

[Anthony PERARD]

When Xen is detected via pkg-config, it isn't necessary to modify
LDFLAGS as modifying libs_softmmu is enough.

Reported-by: Peter Maydell 
Signed-off-by: Michael Tokarev 
Signed-off-by: Anthony PERARD 
Reviewed-by: Peter Maydell 
Reviewed-by: Michael Tokarev 
Reviewed-by: Philippe Mathieu-Daudé 
---
 configure | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configure b/configure
index ca1986125d..3d89870d99 100755
--- a/configure
+++ b/configure
@@ -2359,7 +2359,6 @@ if test "$xen" != "no" ; then
 fi
 QEMU_CFLAGS="$QEMU_CFLAGS $($pkg_config --cflags $xen_pc)"
 libs_softmmu="$($pkg_config --libs $xen_pc) $libs_softmmu"
-LDFLAGS="$($pkg_config --libs $xen_pc) $LDFLAGS"
   else
 
 xen_libs="-lxenstore -lxenctrl -lxenguest"
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PULL 3/4] xen: fix xen-bus state model to allow frontend re-connection

[Anthony PERARD]

From: Paul Durrant 

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 backend state should remain Closed until the frontend state
transitions to Initialising.

This patch removes the automatic backend state transition from
xen_device_backend_state_changed() and, instead, adds an extra check in
xen_device_frontend_state_changed() to determine whether a frontend is
trying to re-connect to a previously Closed XenDevice. Only if this is
found to be the case is the backend state transitioned from Closed to
InitWait. Note that this transition will be common amongst all XenDevice
classes and hence xen_device_frontend_state_changed() returns immediately
afterwards without calling into the XenDeviceClass frontend_changed()
method.

Signed-off-by: Paul Durrant 
Acked-by: Anthony PERARD 
Signed-off-by: Anthony PERARD 
---
 hw/xen/xen-bus.c | 32 +++-
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/hw/xen/xen-bus.c b/hw/xen/xen-bus.c
index 3aeccec69c..49a725e8c7 100644
--- a/hw/xen/xen-bus.c
+++ b/hw/xen/xen-bus.c
@@ -547,20 +547,15 @@ static void xen_device_backend_changed(void *opaque)
 }
 
 /*
- * If a backend is still 'online' then its state should be cycled
- * back round to InitWait in order for a new frontend instance to
- * connect. This may happen when, for example, a frontend driver is
- * re-installed or updated.
- * If a backend is not 'online' then the device should be destroyed.
+ * If a backend is still 'online' then we should leave it alone but,
+ * if a backend is not 'online', then the device should be destroyed
+ * once the state is Closed.
  */
-if (xendev->backend_online &&
-xendev->backend_state == XenbusStateClosed) {
-xen_device_backend_set_state(xendev, XenbusStateInitWait);
-} else if (!xendev->backend_online &&
-   (xendev->backend_state == XenbusStateClosed ||
-xendev->backend_state == XenbusStateInitialising ||
-xendev->backend_state == XenbusStateInitWait ||
-xendev->backend_state == XenbusStateUnknown)) {
+if (!xendev->backend_online &&
+(xendev->backend_state == XenbusStateClosed ||
+ xendev->backend_state == XenbusStateInitialising ||
+ xendev->backend_state == XenbusStateInitWait ||
+ xendev->backend_state == XenbusStateUnknown)) {
 Error *local_err = NULL;
 
 if (!xen_backend_try_device_destroy(xendev, _err)) {
@@ -715,6 +710,17 @@ static void xen_device_frontend_changed(void *opaque)
 
 xen_device_frontend_set_state(xendev, state);
 
+if (state == XenbusStateInitialising &&
+xendev->backend_state == XenbusStateClosed &&
+xendev->backend_online) {
+/*
+ * The frontend is re-initializing so switch back to
+ * InitWait.
+ */
+xen_device_backend_set_state(xendev, XenbusStateInitWait);
+return;
+}
+
 if (xendev_class->frontend_changed) {
 Error *local_err = NULL;
 
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PULL 0/4] Xen queue 20190204

[Anthony PERARD]

The following changes since commit b3fc0af1ff5e922d4dd7c875394dbd26dc7313b4:

  Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging 
(2019-02-01 17:58:27 +)

are available in the Git repository at:

  https://xenbits.xen.org/git-http/people/aperard/qemu-dm.git 
tags/pull-xen-20190204

for you to fetch changes up to 3149f183d7ca448b1dc30fe3d4acb9e367de01bf:

  xen-block: handle resize callback (2019-02-04 11:04:49 +)


Xen queue

* xen-block, the Xen PV backend, now handles resize.
* configure cleanup.
* xen-bus fix.


Anthony PERARD (2):
  configure: xen: Stop build-testing for xc_domain_create
  configure: Don't add Xen's libs to LDFLAGS

Paul Durrant (2):
  xen: fix xen-bus state model to allow frontend re-connection
  xen-block: handle resize callback

 configure  | 20 
 hw/block/dataplane/xen-block.c |  4 +---
 hw/block/trace-events  |  1 +
 hw/block/xen-block.c   | 40 
 hw/xen/xen-bus.c   | 32 +++-
 5 files changed, 57 insertions(+), 40 deletions(-)

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PULL 1/4] configure: xen: Stop build-testing for xc_domain_create

[Anthony PERARD]

Its last uses was removed by: 6d7c06c213ddcfabcafdc178ccef81736f85a7c2
"Remove broken Xen PV domain builder".

Signed-off-by: Anthony PERARD 
Reviewed-by: Paul Durrant 
---
 configure | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/configure b/configure
index f8176b3c40..ca1986125d 100755
--- a/configure
+++ b/configure
@@ -2474,7 +2474,6 @@ int main(void) {
   xenforeignmemory_handle *xfmem;
   xenevtchn_handle *xe;
   xengnttab_handle *xg;
-  xen_domain_handle_t handle;
   xengnttab_grant_copy_segment_t* seg = NULL;
 
   xs_daemon_open();
@@ -2484,7 +2483,6 @@ int main(void) {
   xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
   xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
   xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL);
-  xc_domain_create(xc, 0, handle, 0, NULL, NULL);
 
   xfmem = xenforeignmemory_open(0, 0);
   xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0);
@@ -2526,7 +2524,6 @@ int main(void) {
   xenforeignmemory_handle *xfmem;
   xenevtchn_handle *xe;
   xengnttab_handle *xg;
-  xen_domain_handle_t handle;
 
   xs_daemon_open();
 
@@ -2535,7 +2532,6 @@ int main(void) {
   xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
   xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
   xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL);
-  xc_domain_create(xc, 0, handle, 0, NULL, NULL);
 
   xfmem = xenforeignmemory_open(0, 0);
   xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0);
@@ -2553,21 +2549,6 @@ EOF
   then
   xen_ctrl_version=40701
   xen=yes
-elif
-cat > $TMPC <
-#include 
-int main(void) {
-  xc_interface *xc = NULL;
-  xen_domain_handle_t handle;
-  xc_domain_create(xc, 0, handle, 0, NULL, NULL);
-  return 0;
-}
-EOF
-compile_prog "" "$xen_libs"
-  then
-  xen_ctrl_version=40700
-  xen=yes
 
 # Xen 4.6
 elif
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PULL 4/4] xen-block: handle resize callback

[Anthony PERARD]

From: Paul Durrant 

Some frontend drivers will handle dynamic resizing of PV disks, so set up
the BlockDevOps resize_cb() method during xen_block_realize() to allow
this to be done.

Signed-off-by: Paul Durrant 
Reviewed-by: Anthony PERARD 
Signed-off-by: Anthony PERARD 
---
 hw/block/dataplane/xen-block.c |  4 +---
 hw/block/trace-events  |  1 +
 hw/block/xen-block.c   | 40 ++
 3 files changed, 38 insertions(+), 7 deletions(-)

diff --git a/hw/block/dataplane/xen-block.c b/hw/block/dataplane/xen-block.c
index d0d8905a33..c6a15da024 100644
--- a/hw/block/dataplane/xen-block.c
+++ b/hw/block/dataplane/xen-block.c
@@ -50,7 +50,6 @@ struct XenBlockDataPlane {
 unsigned int nr_ring_ref;
 void *sring;
 int64_t file_blk;
-int64_t file_size;
 int protocol;
 blkif_back_rings_t rings;
 int more_work;
@@ -189,7 +188,7 @@ static int xen_block_parse_request(XenBlockRequest *request)
request->req.seg[i].first_sect + 1) * dataplane->file_blk;
 request->size += len;
 }
-if (request->start + request->size > dataplane->file_size) {
+if (request->start + request->size > blk_getlength(dataplane->blk)) {
 error_report("error: access beyond end of file");
 goto err;
 }
@@ -638,7 +637,6 @@ XenBlockDataPlane *xen_block_dataplane_create(XenDevice 
*xendev,
 dataplane->xendev = xendev;
 dataplane->file_blk = conf->logical_block_size;
 dataplane->blk = conf->blk;
-dataplane->file_size = blk_getlength(dataplane->blk);
 
 QLIST_INIT(>inflight);
 QLIST_INIT(>freelist);
diff --git a/hw/block/trace-events b/hw/block/trace-events
index d0851953c5..8020f9226a 100644
--- a/hw/block/trace-events
+++ b/hw/block/trace-events
@@ -126,6 +126,7 @@ xen_block_realize(const char *type, uint32_t disk, uint32_t 
partition) "%s d%up%
 xen_block_connect(const char *type, uint32_t disk, uint32_t partition) "%s 
d%up%u"
 xen_block_disconnect(const char *type, uint32_t disk, uint32_t partition) "%s 
d%up%u"
 xen_block_unrealize(const char *type, uint32_t disk, uint32_t partition) "%s 
d%up%u"
+xen_block_size(const char *type, uint32_t disk, uint32_t partition, int64_t 
sectors) "%s d%up%u %"PRIi64
 xen_disk_realize(void) ""
 xen_disk_unrealize(void) ""
 xen_cdrom_realize(void) ""
diff --git a/hw/block/xen-block.c b/hw/block/xen-block.c
index a636487b3e..5012af9cb6 100644
--- a/hw/block/xen-block.c
+++ b/hw/block/xen-block.c
@@ -144,6 +144,38 @@ static void xen_block_unrealize(XenDevice *xendev, Error 
**errp)
 }
 }
 
+static void xen_block_set_size(XenBlockDevice *blockdev)
+{
+const char *type = object_get_typename(OBJECT(blockdev));
+XenBlockVdev *vdev = >props.vdev;
+BlockConf *conf = >props.conf;
+int64_t sectors = blk_getlength(conf->blk) / conf->logical_block_size;
+XenDevice *xendev = XEN_DEVICE(blockdev);
+
+trace_xen_block_size(type, vdev->disk, vdev->partition, sectors);
+
+xen_device_backend_printf(xendev, "sectors", "%"PRIi64, sectors);
+}
+
+static void xen_block_resize_cb(void *opaque)
+{
+XenBlockDevice *blockdev = opaque;
+XenDevice *xendev = XEN_DEVICE(blockdev);
+enum xenbus_state state = xen_device_backend_get_state(xendev);
+
+xen_block_set_size(blockdev);
+
+/*
+ * Mimic the behaviour of Linux xen-blkback and re-write the state
+ * to trigger the frontend watch.
+ */
+xen_device_backend_printf(xendev, "state", "%u", state);
+}
+
+static const BlockDevOps xen_block_dev_ops = {
+.resize_cb = xen_block_resize_cb,
+};
+
 static void xen_block_realize(XenDevice *xendev, Error **errp)
 {
 XenBlockDevice *blockdev = XEN_BLOCK_DEVICE(xendev);
@@ -180,7 +212,7 @@ static void xen_block_realize(XenDevice *xendev, Error 
**errp)
 }
 
 if (!blkconf_apply_backend_options(conf, blockdev->info & VDISK_READONLY,
-   false, errp)) {
+   true, errp)) {
 return;
 }
 
@@ -197,6 +229,7 @@ static void xen_block_realize(XenDevice *xendev, Error 
**errp)
 return;
 }
 
+blk_set_dev_ops(conf->blk, _block_dev_ops, blockdev);
 blk_set_guest_block_size(conf->blk, conf->logical_block_size);
 
 if (conf->discard_granularity > 0) {
@@ -215,9 +248,8 @@ static void xen_block_realize(XenDevice *xendev, Error 
**errp)
 
 xen_device_backend_printf(xendev, "sector-size", "%u",
   conf->logical_block_size);
-xen_device_backend_printf(xendev, "sectors", "%"PRIi64,
-  blk_getlength(conf->blk) /
-  conf->logical_block_size);
+
+xen_block_set_size(blockdev);
 
 blockdev->dataplane =
 xen_block_dataplane_create(xendev, conf, blockdev->props.iothread);
-- 
Anthony PERARD


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 2/2] amd-iommu: use a bitfield for DTE

[Paul Durrant]

The current use of get/set_field_from/in_reg_u32() is both inefficient and
requires some ugly casting.

This patch defines a new bitfield structure (amd_iommu_dte) and uses this
structure in all DTE manipulation, resulting in much more readable and
compact code.

NOTE: This patch also includes some clean-up of get_dma_requestor_id() to
  change the types of the arguments from u16 to uint16_t.

Signed-off-by: Paul Durrant 
---
Cc: Suravee Suthikulpanit 
Cc: Brian Woods 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
---
 xen/drivers/passthrough/amd/iommu_guest.c |  55 ++---
 xen/drivers/passthrough/amd/iommu_map.c   | 199 +-
 xen/drivers/passthrough/amd/pci_amd_iommu.c   |  51 ++---
 xen/include/asm-x86/amd-iommu.h   |   5 -
 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h  | 120 +--
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |  20 +-
 6 files changed, 139 insertions(+), 311 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_guest.c 
b/xen/drivers/passthrough/amd/iommu_guest.c
index 96175bb9ac..328e7509d5 100644
--- a/xen/drivers/passthrough/amd/iommu_guest.c
+++ b/xen/drivers/passthrough/amd/iommu_guest.c
@@ -76,39 +76,10 @@ static void guest_iommu_disable(struct guest_iommu *iommu)
 iommu->enabled = 0;
 }
 
-static uint64_t get_guest_cr3_from_dte(dev_entry_t *dte)
+static uint64_t get_guest_cr3_from_dte(struct amd_iommu_dte *dte)
 {
-uint64_t gcr3_1, gcr3_2, gcr3_3;
-
-gcr3_1 = get_field_from_reg_u32(dte->data[1],
-IOMMU_DEV_TABLE_GCR3_1_MASK,
-IOMMU_DEV_TABLE_GCR3_1_SHIFT);
-gcr3_2 = get_field_from_reg_u32(dte->data[2],
-IOMMU_DEV_TABLE_GCR3_2_MASK,
-IOMMU_DEV_TABLE_GCR3_2_SHIFT);
-gcr3_3 = get_field_from_reg_u32(dte->data[3],
-IOMMU_DEV_TABLE_GCR3_3_MASK,
-IOMMU_DEV_TABLE_GCR3_3_SHIFT);
-
-return ((gcr3_3 << 31) | (gcr3_2 << 15 ) | (gcr3_1 << 12)) >> PAGE_SHIFT;
-}
-
-static uint16_t get_domid_from_dte(dev_entry_t *dte)
-{
-return get_field_from_reg_u32(dte->data[2], IOMMU_DEV_TABLE_DOMAIN_ID_MASK,
-  IOMMU_DEV_TABLE_DOMAIN_ID_SHIFT);
-}
-
-static uint16_t get_glx_from_dte(dev_entry_t *dte)
-{
-return get_field_from_reg_u32(dte->data[1], IOMMU_DEV_TABLE_GLX_MASK,
-  IOMMU_DEV_TABLE_GLX_SHIFT);
-}
-
-static uint16_t get_gv_from_dte(dev_entry_t *dte)
-{
-return get_field_from_reg_u32(dte->data[1],IOMMU_DEV_TABLE_GV_MASK,
-  IOMMU_DEV_TABLE_GV_SHIFT);
+return ((dte->gcr3_trp_51_31 << 31) | (dte->gcr3_trp_30_15 << 15) |
+(dte->gcr3_trp_14_12 << 12)) >> PAGE_SHIFT;
 }
 
 static unsigned int host_domid(struct domain *d, uint64_t g_domid)
@@ -397,7 +368,7 @@ static int do_completion_wait(struct domain *d, cmd_entry_t 
*cmd)
 static int do_invalidate_dte(struct domain *d, cmd_entry_t *cmd)
 {
 uint16_t gbdf, mbdf, req_id, gdom_id, hdom_id;
-dev_entry_t *gdte, *mdte, *dte_base;
+struct amd_iommu_dte *gdte, *mdte, *dte_base;
 struct amd_iommu *iommu = NULL;
 struct guest_iommu *g_iommu;
 uint64_t gcr3_gfn, gcr3_mfn;
@@ -414,23 +385,23 @@ static int do_invalidate_dte(struct domain *d, 
cmd_entry_t *cmd)
 return 0;
 
 /* Sometimes guest invalidates devices from non-exists dtes */
-if ( (gbdf * sizeof(dev_entry_t)) > g_iommu->dev_table.size )
+if ( (gbdf * sizeof(struct amd_iommu_dte)) > g_iommu->dev_table.size )
 return 0;
 
 dte_mfn = guest_iommu_get_table_mfn(d,
 
reg_to_u64(g_iommu->dev_table.reg_base),
-sizeof(dev_entry_t), gbdf);
+sizeof(struct amd_iommu_dte), gbdf);
 ASSERT(mfn_valid(_mfn(dte_mfn)));
 
 /* Read guest dte information */
 dte_base = map_domain_page(_mfn(dte_mfn));
 
-gdte = dte_base + gbdf % (PAGE_SIZE / sizeof(dev_entry_t));
+gdte = _base[gbdf % (PAGE_SIZE / sizeof(struct amd_iommu_dte))];
 
-gdom_id  = get_domid_from_dte(gdte);
+gdom_id = gdte->domain_id;
 gcr3_gfn = get_guest_cr3_from_dte(gdte);
-glx  = get_glx_from_dte(gdte);
-gv   = get_gv_from_dte(gdte);
+glx = gdte->glx;
+gv = gdte->gv;
 
 unmap_domain_page(dte_base);
 
@@ -454,11 +425,11 @@ static int do_invalidate_dte(struct domain *d, 
cmd_entry_t *cmd)
 /* Setup host device entry */
 hdom_id = host_domid(d, gdom_id);
 req_id = get_dma_requestor_id(iommu->seg, mbdf);
-mdte = iommu->dev_table.buffer + (req_id * sizeof(dev_entry_t));
+dte_base = iommu->dev_table.buffer;
+mdte = _base[req_id];
 
 spin_lock_irqsave(>lock, flags);
-iommu_dte_set_guest_cr3((u32 *)mdte, hdom_id,
-gcr3_mfn << PAGE_SHIFT, gv, 

[Xen-devel] [PATCH 0/2] amd-iommu: use bitfields for PTE/PDE and DTE

[Paul Durrant]

Reduce code size by ~300 lines.

Paul Durrant (2):
  amd-iommu: use a bitfield for PTE/PDE
  amd-iommu: use a bitfield for DTE

 xen/drivers/passthrough/amd/iommu_guest.c |  55 +--
 xen/drivers/passthrough/amd/iommu_map.c   | 338 --
 xen/drivers/passthrough/amd/pci_amd_iommu.c   | 101 ++
 xen/include/asm-x86/amd-iommu.h   |   5 -
 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h  | 167 -
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |  35 +-
 6 files changed, 201 insertions(+), 500 deletions(-)

-- 
2.20.1.2.gb21ebb671


___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Julien Grall]

On 2/4/19 10:28 AM, Andrii Anisov wrote:

Hello,


Hi Andrii,



On 01.02.19 19:40, Julien Grall wrote:

On 01/02/2019 16:53, Roger Pau Monné wrote:

On Thu, Jan 31, 2019 at 11:14:37PM +, Julien Grall wrote:

On 1/31/19 9:56 PM, Stefano Stabellini wrote:

On Thu, 31 Jan 2019, Julien Grall wrote:

On 31/01/2019 12:00, Andrii Anisov wrote:

On 31.01.19 13:37, Julien Grall wrote:

So, I've got a hacky patch to 'fix' this on x86, by taking a reference
to the mfn behind the virtual address provided when setting up the
hypercall and mapping it in Xen.


That was the idea I had in mind :). 

Looks interesting.

Hopefully, no guest is modifying the mapping (i.e the virtual address 
point to a different physical address) afterwards.
I guess, that mapping should not be moved around. Otherwise it would be 
broken even with the current implementation.


What I meant is the virtual address stays the same but the guest 
physical address may change. I don't see how this could be broken today, 
can you explain it?


Moreover, having that buffer mapped to XEN will reduce context switch 
time as a side effect.


I am still unsure whether we really want to keep that always mapped.

Each guest can support up to 128 vCPUs. So we would have 128 runstates 
mapped. Each runstate would take up to 2 pages. This means that each 
guest would require up to 1MB of vmap.


The VMAP in Xen is quite limited (1GB at most) and shared with device 
mapping (e.g ITS...).


On the other side, not mapping the pages contiguously is going to be a 
pain. So maybe the downside is worth it. It would be interesting to have 
the pros/cons of each solution written down in the series.





This however doesn't work on ARM due
to the lack of paging_gva_to_gfn. I guess there's something similar to
translate a guest virtual address into a gfn or a mfn?


get_page_from_gva should to the job for you.

+int map_runstate_area(struct vcpu *v,
+  struct vcpu_register_runstate_memory_area *area)
+{
+    unsigned long offset;
+    unsigned int i;
+    struct domain *d = v->domain;
+    size_t size =
+#ifdef CONFIG_COMPAT
+    has_32bit_shinfo((v)->domain) ? 
sizeof(*v->compat_runstate_guest) :

+#endif
+    sizeof(*v->runstate_guest);
+
+    if ( v->runstate_guest )
+    {
+    ASSERT_UNREACHABLE();
+    return -EBUSY;
+    }
+
+    offset = area->addr.p & ~PAGE_MASK;
+
+    for ( i = 0; i < ARRAY_SIZE(v->runstate_mfn); i++ )
+    {
+    p2m_type_t t;
+    uint32_t pfec = PFEC_page_present;
+    gfn_t gfn = _gfn(paging_gva_to_gfn(v, area->addr.p, ));
+    struct page_info *pg;
+
+    if ( gfn_eq(gfn, INVALID_GFN) )
+    return -EFAULT;
+
+    v->runstate_mfn[i] = get_gfn(d, gfn_x(gfn), );


get_gfn would need to be implemented on Arm.

I'm going to step into this, tomorrow I guess. I have to finish smth today.


I thought more about it during the week-end. I would actually not 
implement get_gfn but implement a function similar to get_page_from_gva 
on x86. The reason behind this is the function on Arm is quite complex 
as it caters many different use case.


Cheers,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [PATCH 1/2] amd-iommu: use a bitfield for PTE/PDE

[Paul Durrant]

The current use of get/set_field_from/in_reg_u32() is both inefficient and
requires some ugly casting.

This patch defines a new bitfield structure (amd_iommu_pte) and uses this
structure in all PTE/PDE manipulation, resulting in much more readable
and compact code.

NOTE: This commit also fixes one malformed comment in
  set_iommu_pte_present().

Signed-off-by: Paul Durrant 
---
Cc: Suravee Suthikulpanit 
Cc: Brian Woods 
Cc: Jan Beulich 
Cc: Andrew Cooper 
Cc: Wei Liu 
Cc: "Roger Pau Monné" 
---
 xen/drivers/passthrough/amd/iommu_map.c   | 143 --
 xen/drivers/passthrough/amd/pci_amd_iommu.c   |  50 +++---
 xen/include/asm-x86/hvm/svm/amd-iommu-defs.h  |  47 ++
 xen/include/asm-x86/hvm/svm/amd-iommu-proto.h |  15 --
 4 files changed, 64 insertions(+), 191 deletions(-)

diff --git a/xen/drivers/passthrough/amd/iommu_map.c 
b/xen/drivers/passthrough/amd/iommu_map.c
index 67329b0c95..5fda6063df 100644
--- a/xen/drivers/passthrough/amd/iommu_map.c
+++ b/xen/drivers/passthrough/amd/iommu_map.c
@@ -38,100 +38,45 @@ static unsigned int pfn_to_pde_idx(unsigned long pfn, 
unsigned int level)
 static unsigned int clear_iommu_pte_present(unsigned long l1_mfn,
 unsigned long dfn)
 {
-uint64_t *table, *pte;
+struct amd_iommu_pte *table, *pte;
 unsigned int flush_flags;
 
 table = map_domain_page(_mfn(l1_mfn));
+pte = [pfn_to_pde_idx(dfn, 1)];
 
-pte = (table + pfn_to_pde_idx(dfn, 1));
+flush_flags = pte->pr ? IOMMU_FLUSHF_modified : 0;
+memset(pte, 0, sizeof(*pte));
 
-flush_flags = get_field_from_reg_u32(*pte, IOMMU_PTE_PRESENT_MASK,
- IOMMU_PTE_PRESENT_SHIFT) ?
- IOMMU_FLUSHF_modified : 0;
-
-*pte = 0;
 unmap_domain_page(table);
 
 return flush_flags;
 }
 
-static unsigned int set_iommu_pde_present(uint32_t *pde,
+static unsigned int set_iommu_pde_present(struct amd_iommu_pte *pte,
   unsigned long next_mfn,
   unsigned int next_level, bool iw,
   bool ir)
 {
-uint64_t maddr_next;
-uint32_t addr_lo, addr_hi, entry;
-bool old_present;
 unsigned int flush_flags = IOMMU_FLUSHF_added;
 
-maddr_next = __pfn_to_paddr(next_mfn);
-
-old_present = get_field_from_reg_u32(pde[0], IOMMU_PTE_PRESENT_MASK,
- IOMMU_PTE_PRESENT_SHIFT);
-if ( old_present )
-{
-bool old_r, old_w;
-unsigned int old_level;
-uint64_t maddr_old;
-
-addr_hi = get_field_from_reg_u32(pde[1],
- IOMMU_PTE_ADDR_HIGH_MASK,
- IOMMU_PTE_ADDR_HIGH_SHIFT);
-addr_lo = get_field_from_reg_u32(pde[0],
- IOMMU_PTE_ADDR_LOW_MASK,
- IOMMU_PTE_ADDR_LOW_SHIFT);
-old_level = get_field_from_reg_u32(pde[0],
-   IOMMU_PDE_NEXT_LEVEL_MASK,
-   IOMMU_PDE_NEXT_LEVEL_SHIFT);
-old_w = get_field_from_reg_u32(pde[1],
-   IOMMU_PTE_IO_WRITE_PERMISSION_MASK,
-   IOMMU_PTE_IO_WRITE_PERMISSION_SHIFT);
-old_r = get_field_from_reg_u32(pde[1],
-   IOMMU_PTE_IO_READ_PERMISSION_MASK,
-   IOMMU_PTE_IO_READ_PERMISSION_SHIFT);
-
-maddr_old = ((uint64_t)addr_hi << 32) |
-((uint64_t)addr_lo << PAGE_SHIFT);
-
-if ( maddr_old != maddr_next || iw != old_w || ir != old_r ||
- old_level != next_level )
+if ( pte->pr &&
+ (pte->mfn != next_mfn ||
+  pte->iw != iw ||
+  pte->ir != ir ||
+  pte->next_level != next_level) )
 flush_flags |= IOMMU_FLUSHF_modified;
-}
 
-addr_lo = maddr_next & DMA_32BIT_MASK;
-addr_hi = maddr_next >> 32;
-
-/* enable read/write permissions,which will be enforced at the PTE */
-set_field_in_reg_u32(addr_hi, 0,
- IOMMU_PDE_ADDR_HIGH_MASK,
- IOMMU_PDE_ADDR_HIGH_SHIFT, );
-set_field_in_reg_u32(iw, entry,
- IOMMU_PDE_IO_WRITE_PERMISSION_MASK,
- IOMMU_PDE_IO_WRITE_PERMISSION_SHIFT, );
-set_field_in_reg_u32(ir, entry,
- IOMMU_PDE_IO_READ_PERMISSION_MASK,
- IOMMU_PDE_IO_READ_PERMISSION_SHIFT, );
-
-/* FC bit should be enabled in PTE, this helps to solve potential
+/*
+ * FC bit should be enabled in PTE, this helps to solve potential
  * issues with ATS devices
  */
-if ( next_level == 0 )
-set_field_in_reg_u32(IOMMU_CONTROL_ENABLED, entry,
-  

Re: [Xen-devel] [PATCH] tools/misc: Remove obsolete xen-bugtool

[Wei Liu]

On Sun, Feb 03, 2019 at 09:35:18PM +0100, Hans van Kranenburg wrote:
> xen-bugtool relies on code that has been removed in commit 9e8672f1c3
> "tools: remove xend and associated python modules", more than 5 years
> ago. Remove it, since it confuses users.
> 
> -$ /usr/sbin/xen-bugtool
> Traceback (most recent call last):
>   File "/usr/sbin/xen-bugtool", line 9, in 
>   from xen.util import bugtool
> ImportError: No module named xen.util
> 
> Signed-off-by: Hans van Kranenburg 
> Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866380

Acked-by: Wei Liu 

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.9-testing bisection] complete build-i386

[osstest service owner]

branch xen-4.9-testing
xenbranch xen-4.9-testing
job build-i386
testid xen-build

Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  678920e58463a27c0878b3d070e18811a294cce8
  Bug not present: 3a3f48a59e4269c6111e2c30f31a49d76322bf65
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/132837/


  commit 678920e58463a27c0878b3d070e18811a294cce8
  Author: Jan Beulich 
  Date:   Fri Feb 1 12:05:11 2019 +0100
  
  x86emul: fix 3-operand IMUL
  
  While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
  as its title says, it broke the 3-operand form by uniformly using AL/AX/
  EAX/RAX as second source operand. Fix this and add tests covering both
  cases.
  
  Reported-by: Andrei Lutas 
  Signed-off-by: Jan Beulich 
  Tested-by: Razvan Cojocaru 
  Reviewed-by: Andrew Cooper 
  master commit: 19232b378fab04997c0612e5c19e82c29b59d99e
  master date: 2018-12-18 14:27:09 +0100


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.9-testing/build-i386.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.9-testing/build-i386.xen-build 
--summary-out=tmp/132837.bisection-summary --basis-template=130954 
--blessings=real,real-bisect xen-4.9-testing build-i386 xen-build
Searching for failure / basis pass:
 132747 fail [host=albana1] / 132582 ok.
Failure / basis pass flights: 132747 / 132582
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
04f7fbcc8fcab7f3a59e33798b74582b55dd735a
Basis pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
0437ba0e578d089eb24fc493575cd0e8f2584ec7
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen-traditional.git#8051789e982499050680a26febeada7467e18a8d-8051789e982499050680a26febeada7467e18a8d
 
git://xenbits.xen.org/qemu-xen.git#aad23066e4b27296d219b9123393fbe2a5a885bb-aad23066e4b27296d219b9123393fbe2a5a885bb
 
git://xenbits.xen.org/xen.git#0437ba0e578d089eb24fc493575cd0e8f2584ec7-04f7fbcc8fcab7f3a59e33798b74582b55dd735a
Loaded 1001 nodes in revision graph
Searching for test results:
 132606 [host=albana0]
 132602 [host=chardonnay0]
 132582 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
0437ba0e578d089eb24fc493575cd0e8f2584ec7
 132747 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
04f7fbcc8fcab7f3a59e33798b74582b55dd735a
 132784 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
0437ba0e578d089eb24fc493575cd0e8f2584ec7
 132813 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
04f7fbcc8fcab7f3a59e33798b74582b55dd735a
 132828 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
3a3f48a59e4269c6111e2c30f31a49d76322bf65
 132814 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
78b2732ec5ce883f7061fa2b766b359bb08bba19
 132817 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
 132833 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
 132818 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
4f9a486899b643a3143a77a032f6c2069cb1e40a
 132822 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
3a3f48a59e4269c6111e2c30f31a49d76322bf65
 132835 pass 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
3a3f48a59e4269c6111e2c30f31a49d76322bf65
 132837 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
 132823 fail 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 
678920e58463a27c0878b3d070e18811a294cce8
Searching for interesting versions
 Result found: flight 132582 (pass), for basis pass
 Result found: flight 132747 (fail), for basis failure
 Repro found: flight 132784 (pass), for basis pass
 Repro found: flight 132813 (fail), for basis failure
 0 revisions at 8051789e982499050680a26febeada7467e18a8d 
aad23066e4b27296d219b9123393fbe2a5a885bb 

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Andrii Anisov]

Hello Julien,

On 01.02.19 12:51, Julien Grall wrote:

I don't consider polluting your log a real problem.

Unless the system becomes an insane typewriter :)


I don't consider it as a critical issue because of the type of guest we 
currently support, so it is not in my queue for Xen 4.12 fixes.

Feel free to suggest it as a blocker if you think it is.

Well, for us the situation is as following: Renesas requested XEN 4.12 for the 
next release of their virtualization package. And they employ KPTI enabled 
kernel in the BSP.
That reveals another critical issue for us, in addition to Set/Way issue and 
possible performance drops/irq latency raise due to specter mitigation measures.
I'm not sure if this is sufficient a justification to make it the release 
blocker, but we are up to this stuff.

--
Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] RT Xen on ARM - R-Car series

[Andrii Anisov]

Hello,

On 01.02.19 19:40, Julien Grall wrote:

On 01/02/2019 16:53, Roger Pau Monné wrote:

On Thu, Jan 31, 2019 at 11:14:37PM +, Julien Grall wrote:

On 1/31/19 9:56 PM, Stefano Stabellini wrote:

On Thu, 31 Jan 2019, Julien Grall wrote:

On 31/01/2019 12:00, Andrii Anisov wrote:

On 31.01.19 13:37, Julien Grall wrote:

So, I've got a hacky patch to 'fix' this on x86, by taking a reference
to the mfn behind the virtual address provided when setting up the
hypercall and mapping it in Xen.


That was the idea I had in mind :). 

Looks interesting.


Hopefully, no guest is modifying the mapping (i.e the virtual address point to 
a different physical address) afterwards.

I guess, that mapping should not be moved around. Otherwise it would be broken 
even with the current implementation.
Moreover, having that buffer mapped to XEN will reduce context switch time as a 
side effect.


This however doesn't work on ARM due
to the lack of paging_gva_to_gfn. I guess there's something similar to
translate a guest virtual address into a gfn or a mfn?


get_page_from_gva should to the job for you.

+int map_runstate_area(struct vcpu *v,
+  struct vcpu_register_runstate_memory_area *area)
+{
+    unsigned long offset;
+    unsigned int i;
+    struct domain *d = v->domain;
+    size_t size =
+#ifdef CONFIG_COMPAT
+    has_32bit_shinfo((v)->domain) ? sizeof(*v->compat_runstate_guest) :
+#endif
+    sizeof(*v->runstate_guest);
+
+    if ( v->runstate_guest )
+    {
+    ASSERT_UNREACHABLE();
+    return -EBUSY;
+    }
+
+    offset = area->addr.p & ~PAGE_MASK;
+
+    for ( i = 0; i < ARRAY_SIZE(v->runstate_mfn); i++ )
+    {
+    p2m_type_t t;
+    uint32_t pfec = PFEC_page_present;
+    gfn_t gfn = _gfn(paging_gva_to_gfn(v, area->addr.p, ));
+    struct page_info *pg;
+
+    if ( gfn_eq(gfn, INVALID_GFN) )
+    return -EFAULT;
+
+    v->runstate_mfn[i] = get_gfn(d, gfn_x(gfn), );


get_gfn would need to be implemented on Arm.

I'm going to step into this, tomorrow I guess. I have to finish smth today.

--
Sincerely,
Andrii Anisov.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[Xen-devel] [xen-4.10-testing bisection] complete build-amd64

[osstest service owner]

branch xen-4.10-testing
xenbranch xen-4.10-testing
job build-amd64
testid xen-build

Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git

*** Found and reproduced problem changeset ***

  Bug is in tree:  xen git://xenbits.xen.org/xen.git
  Bug introduced:  500ceac0a2df2c80c77d3b60ad284dc46f4a364b
  Bug not present: 5f428061a5b2dd980b3047c197b5ff9d9757e010
  Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/132829/


  commit 500ceac0a2df2c80c77d3b60ad284dc46f4a364b
  Author: Jan Beulich 
  Date:   Fri Feb 1 11:46:37 2019 +0100
  
  x86emul: fix 3-operand IMUL
  
  While commit 75066cd4ea ("x86emul: fix {,i}mul and {,i}div") indeed did
  as its title says, it broke the 3-operand form by uniformly using AL/AX/
  EAX/RAX as second source operand. Fix this and add tests covering both
  cases.
  
  Reported-by: Andrei Lutas 
  Signed-off-by: Jan Beulich 
  Tested-by: Razvan Cojocaru 
  Reviewed-by: Andrew Cooper 
  master commit: 19232b378fab04997c0612e5c19e82c29b59d99e
  master date: 2018-12-18 14:27:09 +0100


For bisection revision-tuple graph see:
   
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-4.10-testing/build-amd64.xen-build.html
Revision IDs in each graph node refer, respectively, to the Trees above.


Running cs-bisection-step 
--graph-out=/home/logs/results/bisect/xen-4.10-testing/build-amd64.xen-build 
--summary-out=tmp/132829.bisection-summary --basis-template=132630 
--blessings=real,real-bisect xen-4.10-testing build-amd64 xen-build
Searching for failure / basis pass:
 132762 fail [host=debina1] / 132630 [host=albana0] 132577 [host=baroque0] 
132485 [host=godello1] 131257 [host=godello1] 131223 [host=godello0] 131191 
[host=godello1] 131151 [host=godello1] 131108 [host=godello0] 131061 
[host=godello1] 130893 [host=albana0] 130854 [host=rimava1] 130820 
[host=godello0] 129676 [host=huxelrebe0] 129462 [host=huxelrebe0] 128983 
[host=albana0] 128967 [host=albana0] 128855 [host=debina0] 128829 
[host=huxelrebe1] 128702 [host=godello1] 128656 [host=chardonnay1] 128607 \
 [host=fiano1] 128524 [host=elbling1] 128505 [host=godello0] 128108 
[host=fiano1] 128055 [host=huxelrebe1] 127761 [host=huxelrebe1] 127607 
[host=debina0] 126553 [host=debina0] 126288 [host=fiano0] 126165 [host=albana0] 
125948 [host=godello0] 125908 [host=joubertin1] 125698 [host=rimava1] 125677 
[host=fiano1] 125037 [host=albana0] 124988 [host=albana0] 124940 
[host=huxelrebe0] 124345 [host=albana1] 124266 [host=joubertin1] 124211 
[host=godello0] 124181 [host=elbling1] 123389 [host=godello0] 123344\
  [host=italia0] 123086 [host=debina0] 122987 [host=fiano1] 122837 
[host=godello1] 122560 [host=godello1] 122490 [host=godello0] 122449 
[host=godello0] 122356 [host=huxelrebe0] 122255 [host=elbling0] 121848 
[host=godello0] 121756 [host=godello0] 121045 [host=godello1] 120967 
[host=baroque0] 120821 [host=godello1] 120559 [host=godello0] 120352 
[host=huxelrebe0] 120244 [host=baroque0] 120065 [host=godello1] 119859 
[host=godello1] 119777 [host=godello1] 118771 [host=huxelrebe0] 118673 
[host=godello1\
 ] 118529 [host=godello1] 118490 [host=fiano0] 118315 [host=pinot1] 118244 
[host=huxelrebe1] 118218 [host=huxelrebe0] 118165 [host=italia0] 117870 
[host=elbling1] 117741 [host=baroque0] 117713 [host=godello1] 117647 
[host=chardonnay1] 117130 [host=italia0] 116961 [host=nobling0] 116940 
[host=nobling0] 116762 [host=nobling1] 116747 [host=italia0] template as basis? 
using template as basis.
Failure / basis pass flights: 132762 / 132630
(tree with no url: minios)
(tree with no url: ovmf)
(tree with no url: seabios)
Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
Latest c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
0695e67102de6b737baf1b88e2cdfccbb2cb56fa
Basis pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
316e4426a185efefa078dd087c89a694b2149be8
Generating revisions with ./adhoc-revtuple-generator  
git://xenbits.xen.org/qemu-xen-traditional.git#c8ea0457495342c417c3dc033bba25148b279f60-c8ea0457495342c417c3dc033bba25148b279f60
 
git://xenbits.xen.org/qemu-xen.git#6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2-6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2
 
git://xenbits.xen.org/xen.git#316e4426a185efefa078dd087c89a694b2149be8-0695e67102de6b737baf1b88e2cdfccbb2cb56fa
Loaded 1001 nodes in revision graph
Searching for test results:
 132628 [host=albana1]
 132577 [host=baroque0]
 132630 [host=albana0]
 132682 [host=joubertin0]
 132763 pass c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 
316e4426a185efefa078dd087c89a694b2149be8
 132700 fail c8ea0457495342c417c3dc033bba25148b279f60 
6ea4cef2bd717045ac0e84b52a5b1b7716feb0c2 

Re: [Xen-devel] [PATCH v5 00/15] Argo: hypervisor-mediated interdomain communication

[Roger Pau Monné]

On Sun, Feb 03, 2019 at 10:04:29AM -0800, Christopher Clark wrote:
> On Thu, Jan 31, 2019 at 5:39 AM Roger Pau Monné  wrote:
> >
> > On Wed, Jan 30, 2019 at 08:05:30PM -0800, Christopher Clark wrote:
> > > On Tue, Jan 22, 2019 at 6:19 AM Roger Pau Monné  
> > > wrote:
> > > >
> > > > On Mon, Jan 21, 2019 at 01:59:40AM -0800, Christopher Clark wrote:
> > > > > Version five of this patch series:
> > > > >
> > > > > * Changes are primarily addressing feedback from the v4 series 
> > > > > reviews.
> > > > >   Many points noted on the invididual commit posts.
> > > > >
> > > > > * Critical sections have been shrunk, with allocations and frees
> > > > >   pulled outside where possible, reordering logic within hypercall 
> > > > > ops.
> > > > >
> > > > > * A new ring hash function implemented, derived from the djb2 string
> > > > >   hash function.
> > > > >
> > > > > * Flags returned by the notify op have been simplified.
> > > > >
> > > > > * Now uses a single argo boot parameter, taking a list:
> > > > >   - top level boolean to enable/disable Argo
> > > > >   - mac-permissive option to enable/disable wildcard rings
> > > > >   - command line doc edit: no "CONFIG_ARGO" but refers to build config
> > > > >
> > > > > * Switched to use the standard list data structures used by Xen's
> > > > >   common code.
> > > >
> > > > AFAIK this was not requested by any reviewer, so I wonder why you made
> > > > such change. The more that you open coded some of the list_ macros
> > > > instead of just doing a s/hlist_/list_/ replacement.
> > > > I'm fine with using list instead of hlist,
> > >
> > > At your request, v7 replaces open coding with Xen's list macros. The
> > > hlist macros were not used by any of the common code in Xen.
> > >
> > > > but I don't understand why
> > > > you decided to open code list_for_each and list_for_each_safe instead
> > > > of using the macros provided by Xen. Is there an issue with such
> > > > macros?
> > >
> > > As discussed offline:
> > >
> > > - Using Xen's list macros will expedite Argo's merge for Xen 4.12
> > > - List macros in Xen list.h originated in Linux list.h and have diverged
> > > - OpenXT has use cases for measured launch and nested virtualization,
> > >   which influence downstream performance and security requirements for
> > >   Argo and Xen
> > > - OpenXT can temporarily patch Xen 4.12 for downstream use
> > >
> > > > I've made a couple of minor comments, but I think the current status
> > > > is good, and fixing those minor comments is going to be trivial.
> > >
> > > Ack, thanks. Hopefully v7 looks good.
> >
> > As a note, the common flow of interactions usually involves the
> > contributor replying to the comments made by the reviewer in order to
> > try to reach an agreement before sending a new version.
> 
> Yes, v7 was sent to address Jan and Julien's review comments in parallel
> with our ongoing discussion on v5 macros. v7 also provided a checkpoint
> for Argo testers to maximize test coverage as the series converges into
> a Xen 4.12 merge candidate for Juergen. It addressed:
> 
>  - Jan's v6 review comments
>  - Julien's v1 review comment
>  - most of your xen-devel and offline review comments

I think it will benefit the community to give this review in public,
so other reviewers know whats going on. IMO getting this private
review makes it harder for me (as a reviewer) to know the motivation
of some of the changes between versions, and likely also makes it
harder for you since you have to keep track of comments from multiple
sources on different channels.

Is there anything that prevents those people from making the review
comments publicly on xen-devel?

We should very much try to fix that so everyone can make review
comments on the public mailing list.

> > There are comments from v5 that haven't been fixed in v7
> > (the mask usage and list_first_entry_or_null for example)
> > and the reply to the reviewer's comment was sent at the same time as
> > v7, leaving no time for further discussion (and for reaching an
> > agreement suitable to both parties) before sending v7.
> 
> Code changes from our ongoing discussion will be addressed in v8. A
> proposal to address mask usage has been put forward in the parallel
> thread. Your proposed usage of list_first_entry_or_null will be made in
> v8, subject to the previous offline discussion about list macros
> (duplicated here for convenience):
> 
> > > As discussed offline:
> > >
> > > - Using Xen's list macros will expedite Argo's merge for Xen 4.12
> > > - List macros in Xen list.h originated in Linux list.h and have diverged
> > > - OpenXT has use cases for measured launch and nested virtualization,
> > >   which influence downstream performance and security requirements for
> > >   Argo and Xen

FWIW, I don't see the connection between nested virtualization or
measured launch and the list macros. I think a little bit more context
would be helpful here in order to understand the issue.

> > > - OpenXT can 

Re: [Xen-devel] [PATCH v6 1/4] xen: introduce SYMBOL

[Jan Beulich]

>>> On 01.02.19 at 19:52,  wrote:

I'm not going to reply in detail to all of what you wrote about fanatics,
but I would like to say that I think compiler people less of that than
you appear to imply, at least the ones I know. In particular, they can
be convinced of there being bugs by pointing out what aspect of the
standard their implementation violates. (Of course there are also
going to be areas where interpretations of the standard vary too
much to come to an agreement.)

> Improvements this series seeks to make, as I understand it, include
> (in order of urgency):
> 
> 1. Fixing one concrete instance of "UB hazard"

Right, and we want to work around compiler bugs here.

> 2. Minimize risk of further "UB hazard" in this bit of functionality
> 3. Retain the effort Stefano has put in identifying all the places
> where such UB hazards need to be addressed.
> 4. Move towards MISRA-C compliance.
> 
> As far as I can tell, primary objections you've leveled at the options
> which try to address 2-4 are:
> 
> a. "UB hazard" still not zero
> b. MISRA compliancy no 100%
> c. Ugly
> d. Inefficient
> 
> (Obviously some proposals have had more technical discussion.)
> 
> Anything I missed?

I don't think so, especially since various aspects can fall under "ugly"
and/or "inefficient". What I'm not sure I see is what you mean to
express with all you wrote in terms of finding a way out of the
current situation (besides requesting a vote): Improving on a. and
b. is not a good excuse to extend c., at least not unequivocally.
Whether d. actually matters is a separate aspect, partly because it
may mean different things (it could e.g. be taken as another
wording for a. and b.).

And btw - I can't judge on b. anyway, as I still don't know what
exactly MISRA compliance is to mean, with the rules to adhere to
suitably justified.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH v5 09/15] argo: implement the sendv op; evtchn: expose send_guest_global_virq

[Roger Pau Monné]

On Sun, Feb 03, 2019 at 09:56:26AM -0800, Christopher Clark wrote:
> On Thu, Jan 31, 2019 at 3:01 AM Roger Pau Monné  wrote:
> >
> > On Thu, Jan 31, 2019 at 03:35:23AM -0700, Jan Beulich wrote:
> > > >>> On 31.01.19 at 11:18,  wrote:
> > > > On Wed, Jan 30, 2019 at 08:10:28PM -0800, Christopher Clark wrote:
> > > >> On Tue, Jan 22, 2019 at 4:08 AM Roger Pau Monné  
> > > >> wrote:
> > > >> > On Mon, Jan 21, 2019 at 01:59:49AM -0800, Christopher Clark wrote:
> > > >> > > +/*
> > > >> > > + * Check padding is zeroed. Reject niov above limit or 
> > > >> > > message_types
> > > >> > > + * that are outside 32 bit range.
> > > >> > > + */
> > > >> > > +if ( unlikely(send_addr.src.pad || send_addr.dst.pad ||
> > > >> > > +  (arg3 > XEN_ARGO_MAXIOV) || (arg4 & 
> > > >> > > ~0xUL)) )
> > > >> >
> > > >> > arg4 & (GB(4) - 1)
> > > >> >
> > > >> > Is clearer IMO, or:
> > > >> >
> > > >> > arg4 > UINT32_MAX
> > > >>
> > > >> I've left the code unchanged, as the mask constant is used multiple
> > > >> places elsewhere in Xen. UINT32_MAX is only used as a threshold value.
> > > >
> > > > The fact that others parts of the code could be improved is not an
> > > > excuse to follow suit. I'm having a hard time believing that you find
> > > > "arg4 & ~0xUL" easier to read than "arg4 & ~(GB(4) - 1)" or
> > > > even "arg4 >= GB(4)".
> 
> 
> Below, I propose an alternative way of achieving our correctness and
> readability goals.
> 
> On the topic of readability, this self-contained definition
> does stand out: ~0xUL,
> encouraging caution and careful counting of 'f's. However, no other
> source files are involved, making the code independent of changes in
> (macro) definitions in other files.
> 
> In comparison, to understand GB, I have find the external definition,
> and then parse this:
> 
> #define GB(_gb) (_AC(_gb, ULL) << 30)
> 
> (which seems to have a different type? ULL vs UL?) and then find and
> understand this, in another file:
> 
> #ifdef __ASSEMBLY__
> #define _AC(X,Y)X
> #define _AT(T,X)X
> #else
> #define __AC(X,Y)   (X##Y)
> #define _AC(X,Y)__AC(X,Y)
> #define _AT(T,X)((T)(X))
> #endif
> 
> so I'm saying: it's at least somewhat arguable which is easier to understand.
> Regardless, I think there's a better option than either.
> 
> > > > IMO it's much more likely to miss an 'f' in the first construct, and
> > > > thus get the value wrong and introduce a bug.
> > >
> > > I agree with this last statement, but I'm having trouble to see how
> > > message _type_ is related to a size construct like GB(4) is. I see
> > > only UINT32_MAX as a viable alternative for something that's not
> > > expressing the size of anything.
> >
> > I've suggested the GB construct as an alternative because the comment
> > above mentions the 32bit range. IMO anything that avoids using
> > 0xUL is fine.
> 
> Jan and Andrew have employed a useful technique in recent changes where such a
> test was required.  This could work:
> 
> (arg4 != (uint32_t)arg4))
> 
> It is self-contained, readable and clearly expresses the intent of the check
> being performed. I have tested a series with this applied, and have it ready
> to post if you approve.

Yes, that's fine. As said in v7 anything that doesn't involve an
open-coded mask is fine with me.

Roger.

___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] [PATCH for-4.12] x86/svm: Fix handling of ICEBP intercepts

[Jan Beulich]

>>> On 01.02.19 at 18:09,  wrote:
> On 01/02/2019 16:55, Jan Beulich wrote:
> On 01.02.19 at 17:25,  wrote:
>>> If it were just getting insn_len incorrectly as 0, then the guest would
>>> livelock as we wouldn't inject the #DB with trap semantics it requires,
>> I'm confused again: Why trap semantics? The ICEBP has fault
>> semantics as you confirmed above.
> 
> The ICEBP intercept has fault semantics.  An ICEBP instruction executing
> in the guest has trap semantics.

Oh, okay - I was mis-remembering this aspect.

>>> but as the #GP is already raised, this will combine to #DF.
>> How that? #DB is a benign exception, so according to the table on the
>> #DF page in the SDM, with #GP it shouldn't combine to #DF.
> 
> #GP is raised first.  It is contributory.
> 
> A subsequent #DB getting raised causes #GP to turn into #DF.

That's based on what? The table on the #DF page clearly says
otherwise, at least according to my reading.

But in the end there shouldn't be any attempt to inject #DB anyway
when #GP is already pending, irrespective of the fact that this #GP
is non-architectural.

Jan



___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [Xen-devel] Scheduling and the periodic timer

[Dario Faggioli]

On Fri, 2019-02-01 at 10:59 +0100, Juergen Gross wrote:
> On 01/02/2019 10:50, Jan Beulich wrote:
> > > > > On 01.02.19 at 08:26,  wrote:
> > > 
> > > The periodic timer is used via VCPUOP_set_periodic_timer only,
> > > and
> > > today's Linux kernel isn't using it at all. So I guess this timer
> > > not
> > > really working as it should is no big issue.
> > 
> > Interesting. Our kernels have been using it until SLE11 SP1, as
> > did the old 2.6.18 one that all of our old kernels were derived
> > from. Yet the same code is present already in 3.2.0's schedule().
> > Are you sure this timer is meant to wake the vCPU at the set
> > rate, rather than just surfacing events if the vCPU is running?
> > Looking at vcpu_periodic_timer_work()'s calculation of the
> > next event time also suggests to me that there's no guarantee
> > that the event will indeed surface at the set rate.
> 
> That's correct. The set rate just is the minimum time between two
> interrupts.
> 
> The usability of such a timer is questionable in the best case IMO.
> 
Yes, I vaguely recall discussing about this with someone, and the
outcome being <>, and then we probably dropped the ball (I can't
find the thread right now, maybe it was on IRC). :-(

IAC, I do agree that it does not make any sense to stop the timer for
the vcpu being descheduled. And we really should either fix this... or
we can get just get rid of the timer entirely, as it's basically
delivering events at pseudo-random rate! :-O

I can look into that.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/


signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel