Re: [Xen-devel] [PATCH v3 25/62] acpi/table: Introduce acpi_get_entry to get specified entry
On 2015/11/24 15:22, Jan Beulich wrote:
On 24.11.15 at 04:08, wrote:
>> On 2015/11/24 0:59, Jan Beulich wrote:
>> On 17.11.15 at 10:40, wrote:
+ if ( !table_header )
+ {
+ printk("Table header not present\n");
+ return NULL;
+ }
+
+ table_end = (unsigned long)table_header + table_header->length;
>>>
>>> So here you use ->length, ...
>>>
+ /* Parse all entries looking for a match. */
+ entry = (struct acpi_subtable_header *)
+ ((unsigned long)table_header + table_size);
>>>
>>> ... but here table_size. Why?
>>>
>> Here it just skips the main table size at the beginning. Then it could
>> point to the start of sub-table.
>> For example, to MADT table, the table_size is sizeof(struct
>> acpi_table_madt).
>
> Well, but for one then the parameter name is kind of wrong, and
> second - is it really reasonable for the caller to tell the function?
>
I think the caller knows which table it wants to parse and could
calculate the size. But within this function, there is no clue to get
the main table size.
Thanks,
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 11/17] vt-d: Add API to update IRTE when VT-d PI is used
> From: Wu, Feng > Sent: Tuesday, November 24, 2015 3:54 PM > > > > -Original Message- > > From: Tian, Kevin > > Sent: Tuesday, November 24, 2015 3:45 PM > > To: Wu, Feng ; xen-devel@lists.xen.org > > Cc: Zhang, Yang Z ; Keir Fraser ; Jan > > Beulich ; Andrew Cooper > > Subject: RE: [PATCH v9 11/17] vt-d: Add API to update IRTE when VT-d PI is > > used > > > > > + > > > +iommu = drhd->iommu; > > > +ir_ctrl = iommu_ir_ctrl(iommu); > > > +if ( !ir_ctrl ) > > > +return -ENODEV; > > > + > > > +spin_lock_irq(&ir_ctrl->iremap_lock); > > > + > > > +GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, remap_index, > > iremap_entries, p); > > > + > > > +old_ire = *p; > > > + > > > +/* Setup/Update interrupt remapping table entry. */ > > > +setup_posted_irte(&new_ire, &old_ire, pi_desc, gvec); > > > +ret = cmpxchg16b(p, &old_ire, &new_ire); > > > + > > > +/* > > > + * In the above, we use cmpxchg16 to atomically update the 128-bit > > IRTE, > > > + * and the hardware cannot update the IRTE behind us, so the return > > value > > > > hardware can DEFINITELY update IRTE behind us, right? e.g. after the IRTE > > entry > > is fully up, when interrupt is posted, etc. Here you might mean hardware > > cannot > > update the IRTE at this point? > > Yes, you description above is more accurate. But why hardware needs to > update IRTE when interrupt is posted? I think it needs to update the > posted interrupt descriptor when posting an interrupt, not the IRTE, > right? > sorry mess IRTE and posted descriptor together. but using "behind" is still not accurate to state your point here. :-) Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 08/17] vmx: Suppress posting interrupts when 'SN' is set
> -Original Message-
> From: Tian, Kevin
> Sent: Tuesday, November 24, 2015 3:53 PM
> To: Wu, Feng ; xen-devel@lists.xen.org
> Cc: Keir Fraser ; Jan Beulich ; Andrew
> Cooper
> Subject: RE: [PATCH v9 08/17] vmx: Suppress posting interrupts when 'SN' is
> set
>
> > From: Wu, Feng
> > Sent: Tuesday, November 24, 2015 3:47 PM
> >
> >
> > > -Original Message-
> > > From: Tian, Kevin
> > > Sent: Tuesday, November 24, 2015 3:30 PM
> > > To: Wu, Feng ; xen-devel@lists.xen.org
> > > Cc: Keir Fraser ; Jan Beulich ;
> Andrew
> > > Cooper
> > > Subject: RE: [PATCH v9 08/17] vmx: Suppress posting interrupts when 'SN'
> is
> > > set
> > >
> > > > From: Wu, Feng
> > > > Sent: Tuesday, November 03, 2015 4:43 PM
> > > N' is set
> > > >
> > > > Currently, we don't support urgent interrupt, all interrupts
> > > > are recognized as non-urgent interrupt, so we cannot send
> > > > posted-interrupt when 'SN' is set.
> > > >
> > > > CC: Kevin Tian
> > > > CC: Keir Fraser
> > > > CC: Jan Beulich
> > > > CC: Andrew Cooper
> > > > Signed-off-by: Feng Wu
> > > > Reviewed-by: Konrad Rzeszutek Wilk
> > > > Reviewed-by: Jan Beulich
> > >
> > > Acked-by: Kevin Tian , with one small comment:
> > >
> > > > +do {
> > > > +/*
> > > > + * Currently, we don't support urgent interrupt, all
> > > > + * interrupts are recognized as non-urgent interrupt,
> > > > + * so we cannot send posted-interrupt when 'SN' is set.
> > > > + * Besides that, if 'ON' is already set, we cannot set
> > > > + * posted-interrupts as well.
> > > > + */
> > >
> > > Is above comment accurate. "cannot set" is too strong for 'ON'
> > > already set, right? Ideally there's no correctness issue if you
> > > still deliver another posted-interrupt even when ON is already set.
> > > To me it's more like an optimization then it's cleaner to say
> > > "we can avoid"...
> >
> > Here, we just emulate the hardware's behavior, in hardware p.o.v,
> > if 'ON' is set, the notification event will not be delivered, so here
> > I try to follow the hardware, is this reasonable for you?
> >
>
> I understand it's hardware behavior, just thought whether the comment
> is too strong. Could we rephrase it as "Besides that, if 'ON' is already
> set, no need to set posted-interrupts as well, according to hardware
> behavior"?
Sure, that should be great! Thanks a lot:)
Thanks,
Feng
>
> Thanks
> Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 11/17] vt-d: Add API to update IRTE when VT-d PI is used
> -Original Message- > From: Tian, Kevin > Sent: Tuesday, November 24, 2015 3:45 PM > To: Wu, Feng ; xen-devel@lists.xen.org > Cc: Zhang, Yang Z ; Keir Fraser ; Jan > Beulich ; Andrew Cooper > Subject: RE: [PATCH v9 11/17] vt-d: Add API to update IRTE when VT-d PI is > used > > > + > > +iommu = drhd->iommu; > > +ir_ctrl = iommu_ir_ctrl(iommu); > > +if ( !ir_ctrl ) > > +return -ENODEV; > > + > > +spin_lock_irq(&ir_ctrl->iremap_lock); > > + > > +GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, remap_index, > iremap_entries, p); > > + > > +old_ire = *p; > > + > > +/* Setup/Update interrupt remapping table entry. */ > > +setup_posted_irte(&new_ire, &old_ire, pi_desc, gvec); > > +ret = cmpxchg16b(p, &old_ire, &new_ire); > > + > > +/* > > + * In the above, we use cmpxchg16 to atomically update the 128-bit > IRTE, > > + * and the hardware cannot update the IRTE behind us, so the return > value > > hardware can DEFINITELY update IRTE behind us, right? e.g. after the IRTE > entry > is fully up, when interrupt is posted, etc. Here you might mean hardware > cannot > update the IRTE at this point? Yes, you description above is more accurate. But why hardware needs to update IRTE when interrupt is posted? I think it needs to update the posted interrupt descriptor when posting an interrupt, not the IRTE, right? Thanks, Feng ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 08/17] vmx: Suppress posting interrupts when 'SN' is set
> From: Wu, Feng
> Sent: Tuesday, November 24, 2015 3:47 PM
>
>
> > -Original Message-
> > From: Tian, Kevin
> > Sent: Tuesday, November 24, 2015 3:30 PM
> > To: Wu, Feng ; xen-devel@lists.xen.org
> > Cc: Keir Fraser ; Jan Beulich ; Andrew
> > Cooper
> > Subject: RE: [PATCH v9 08/17] vmx: Suppress posting interrupts when 'SN' is
> > set
> >
> > > From: Wu, Feng
> > > Sent: Tuesday, November 03, 2015 4:43 PM
> > N' is set
> > >
> > > Currently, we don't support urgent interrupt, all interrupts
> > > are recognized as non-urgent interrupt, so we cannot send
> > > posted-interrupt when 'SN' is set.
> > >
> > > CC: Kevin Tian
> > > CC: Keir Fraser
> > > CC: Jan Beulich
> > > CC: Andrew Cooper
> > > Signed-off-by: Feng Wu
> > > Reviewed-by: Konrad Rzeszutek Wilk
> > > Reviewed-by: Jan Beulich
> >
> > Acked-by: Kevin Tian , with one small comment:
> >
> > > +do {
> > > +/*
> > > + * Currently, we don't support urgent interrupt, all
> > > + * interrupts are recognized as non-urgent interrupt,
> > > + * so we cannot send posted-interrupt when 'SN' is set.
> > > + * Besides that, if 'ON' is already set, we cannot set
> > > + * posted-interrupts as well.
> > > + */
> >
> > Is above comment accurate. "cannot set" is too strong for 'ON'
> > already set, right? Ideally there's no correctness issue if you
> > still deliver another posted-interrupt even when ON is already set.
> > To me it's more like an optimization then it's cleaner to say
> > "we can avoid"...
>
> Here, we just emulate the hardware's behavior, in hardware p.o.v,
> if 'ON' is set, the notification event will not be delivered, so here
> I try to follow the hardware, is this reasonable for you?
>
I understand it's hardware behavior, just thought whether the comment
is too strong. Could we rephrase it as "Besides that, if 'ON' is already
set, no need to set posted-interrupts as well, according to hardware
behavior"?
Thanks
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 16/17] VT-d: Dump the posted format IRTE
> From: Wu, Feng > Sent: Tuesday, November 03, 2015 4:43 PM > > Add the utility to dump the posted format IRTE. > > CC: Yang Zhang > CC: Kevin Tian > Signed-off-by: Feng Wu Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/3] VMX: allocate VMCS pages from domain heap
>>> On 24.11.15 at 06:04, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Monday, November 23, 2015 10:28 PM
>>
>> >>> On 21.10.15 at 05:16, wrote:
>> >> From: Jan Beulich [mailto:jbeul...@suse.com]
>> >> Sent: Tuesday, October 20, 2015 6:36 PM
>> >> >>> On 20.10.15 at 12:12, wrote:
>> >> > On 19/10/15 16:22, Jan Beulich wrote:
>> >> >> @@ -580,7 +583,7 @@ int vmx_cpu_up_prepare(unsigned int cpu)
>> >> >> void vmx_cpu_dead(unsigned int cpu)
>> >> >> {
>> >> >> vmx_free_vmcs(per_cpu(vmxon_region, cpu));
>> >> >> -per_cpu(vmxon_region, cpu) = NULL;
>> >> >> +per_cpu(vmxon_region, cpu) = 0;
>> >> >
>> >> > While this is currently safe (as pa 0 is not part of the available heap
>> >> > allocation range), might it be worth introducing a named sentential? I
>> >> > can forsee a DMLite nested Xen scenario where we definitely don't need
>> >> > to treat the low 1MB magically.
>> >>
>> >> I guess there are more things to adjust if we ever cared to recover
>> >> the few hundred kb below 1Mb. And then I don't see why nested
>> >> Xen would matter here: One major main reason for reserving that
>> >> space is that we want to put the trampoline there. Do you think
>> >> DMlite would allow us to get away without? But even if so, this
>> >> would again fall under what I've said in the first sentence.
>> >
>> > Could you at least introduce a macro first? Regardless of how much
>> > things to adjust, this way makes future change simple.
>>
>> So I've made an attempt, but this is really getting unwieldy: Setting
>> per-CPU data to non-zero initial values is not possible; making sure
>> cleanup code avoids assuming such variables got initialized is quite
>> error prone. Same goes at least to a certain extent for struct vcpu
>> members (see e.g. nvmx_vcpu_destroy(), which currently is
>> correct no matter whether nvmx_vcpu_initialise() ran at all, or to
>> completion).
>>
>> I also don't see what a macro would help here, or how/where it
>> should be used. paddr_valid()? Yes, I could do this, but it wouldn't
>> simplify much when later wanting to convert to a non-zero value
>> for above reasons (it would instead give the wrong impression that
>> changing the value is all it takes).
>>
>
> Thanks for looking into this attempt. Based on your explanation
> I think your original code is reasonable to go. Here is my ack:
>
> Acked-by: Kevin Tian
Thanks Kevin. Andrew - please indicate whether your previous
comment is to be considered a NAK, or "just a comment".
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 08/17] vmx: Suppress posting interrupts when 'SN' is set
> -Original Message-
> From: Tian, Kevin
> Sent: Tuesday, November 24, 2015 3:30 PM
> To: Wu, Feng ; xen-devel@lists.xen.org
> Cc: Keir Fraser ; Jan Beulich ; Andrew
> Cooper
> Subject: RE: [PATCH v9 08/17] vmx: Suppress posting interrupts when 'SN' is
> set
>
> > From: Wu, Feng
> > Sent: Tuesday, November 03, 2015 4:43 PM
> N' is set
> >
> > Currently, we don't support urgent interrupt, all interrupts
> > are recognized as non-urgent interrupt, so we cannot send
> > posted-interrupt when 'SN' is set.
> >
> > CC: Kevin Tian
> > CC: Keir Fraser
> > CC: Jan Beulich
> > CC: Andrew Cooper
> > Signed-off-by: Feng Wu
> > Reviewed-by: Konrad Rzeszutek Wilk
> > Reviewed-by: Jan Beulich
>
> Acked-by: Kevin Tian , with one small comment:
>
> > +do {
> > +/*
> > + * Currently, we don't support urgent interrupt, all
> > + * interrupts are recognized as non-urgent interrupt,
> > + * so we cannot send posted-interrupt when 'SN' is set.
> > + * Besides that, if 'ON' is already set, we cannot set
> > + * posted-interrupts as well.
> > + */
>
> Is above comment accurate. "cannot set" is too strong for 'ON'
> already set, right? Ideally there's no correctness issue if you
> still deliver another posted-interrupt even when ON is already set.
> To me it's more like an optimization then it's cleaner to say
> "we can avoid"...
Here, we just emulate the hardware's behavior, in hardware p.o.v,
if 'ON' is set, the notification event will not be delivered, so here
I try to follow the hardware, is this reasonable for you?
Thanks,
Feng
>
> Thanks
> Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 11/17] vt-d: Add API to update IRTE when VT-d PI is used
> From: Wu, Feng
> Sent: Tuesday, November 03, 2015 4:43 PM
>
> This patch adds an API which is used to update the IRTE
> for posted-interrupt when guest changes MSI/MSI-X information.
>
> CC: Yang Zhang
> CC: Kevin Tian
> CC: Keir Fraser
> CC: Jan Beulich
> CC: Andrew Cooper
> Signed-off-by: Feng Wu
> Reviewed-by: Jan Beulich
> ---
> v8:
> - Some minor adjustment
>
> v7:
> - Remove __uint128_t cast
> - Remove Kevin's Ack due to a bug fix for v6
> - Reword some comments
> - Setup posted IRTE from zeroed structure
>
> v6:
> - In some error cases, the desc->lock will be unlocked twice, fix it.
> - Coding style fix.
> - Add some comments.
>
> v5:
> - Make some function parameters const
> - Call "spin_unlock_irq(&desc->lock);" a little eariler
> - Add "ASSERT(spin_is_locked(&pcidevs_lock))"
> - -EBADSLT -> -ENODEV, EBADSLT is removed in the lasted Xen
>
> v4:
> - Don't inline setup_posted_irte()
> - const struct pi_desc *pi_desc for setup_posted_irte()
> - return -EINVAL when pirq_spin_lock_irq_desc() fails.
> - Make some variables const
> - Release irq desc lock earlier in pi_update_irte()
> - Remove the pointless do-while() loop when doing cmpxchg16b()
>
> v3:
> - Remove "adding PDA_MASK()" when updating 'pda_l' and 'pda_h' for IRTE.
> - Change the return type of pi_update_irte() to int.
> - Remove some pointless printk message in pi_update_irte().
> - Use structure assignment instead of memcpy() for irte copy.
>
> xen/drivers/passthrough/vtd/intremap.c | 120
> +
> xen/drivers/passthrough/vtd/iommu.h| 6 ++
> xen/include/asm-x86/iommu.h| 2 +
> 3 files changed, 128 insertions(+)
>
> diff --git a/xen/drivers/passthrough/vtd/intremap.c
> b/xen/drivers/passthrough/vtd/intremap.c
> index 8f135e1..67e4f6d 100644
> --- a/xen/drivers/passthrough/vtd/intremap.c
> +++ b/xen/drivers/passthrough/vtd/intremap.c
> @@ -899,3 +899,123 @@ void iommu_disable_x2apic_IR(void)
> for_each_drhd_unit ( drhd )
> disable_qinval(drhd->iommu);
> }
> +
> +static void setup_posted_irte(
> +struct iremap_entry *new_ire, const struct iremap_entry *old_ire,
> +const struct pi_desc *pi_desc, const uint8_t gvec)
> +{
> +memset(new_ire, sizeof(*new_ire), 0);
> +
> +if ( !old_ire->remap.im )
> +{
> +new_ire->post.p = old_ire->remap.p;
> +new_ire->post.fpd = old_ire->remap.fpd;
> +new_ire->post.sid = old_ire->remap.sid;
> +new_ire->post.sq = old_ire->remap.sq;
> +new_ire->post.svt = old_ire->remap.svt;
> +}
> +else
> +{
> +new_ire->post.p = old_ire->post.p;
> +new_ire->post.fpd = old_ire->post.fpd;
> +new_ire->post.sid = old_ire->post.sid;
> +new_ire->post.sq = old_ire->post.sq;
> +new_ire->post.svt = old_ire->post.svt;
> +new_ire->post.urg = old_ire->post.urg;
> +}
An comment here is preferred, otherwise it's not straightforward to
know what 'im' is and why branches are used for it.
> +
> +new_ire->post.im = 1;
> +new_ire->post.vector = gvec;
> +new_ire->post.pda_l = virt_to_maddr(pi_desc) >> (32 - PDA_LOW_BIT);
> +new_ire->post.pda_h = virt_to_maddr(pi_desc) >> 32;
> +}
> +
> +/*
> + * This function is used to update the IRTE for posted-interrupt
> + * when guest changes MSI/MSI-X information.
> + */
> +int pi_update_irte(const struct vcpu *v, const struct pirq *pirq,
> +const uint8_t gvec)
> +{
> +struct irq_desc *desc;
> +const struct msi_desc *msi_desc;
> +int remap_index;
> +int rc = 0;
> +const struct pci_dev *pci_dev;
> +const struct acpi_drhd_unit *drhd;
> +struct iommu *iommu;
> +struct ir_ctrl *ir_ctrl;
> +struct iremap_entry *iremap_entries = NULL, *p = NULL;
> +struct iremap_entry new_ire, old_ire;
> +const struct pi_desc *pi_desc = &v->arch.hvm_vmx.pi_desc;
> +__uint128_t ret;
> +
> +desc = pirq_spin_lock_irq_desc(pirq, NULL);
> +if ( !desc )
> +return -EINVAL;
> +
> +msi_desc = desc->msi_desc;
> +if ( !msi_desc )
> +{
> +rc = -ENODEV;
> +goto unlock_out;
> +}
> +
> +pci_dev = msi_desc->dev;
> +if ( !pci_dev )
> +{
> +rc = -ENODEV;
> +goto unlock_out;
> +}
> +
> +remap_index = msi_desc->remap_index;
> +
> +spin_unlock_irq(&desc->lock);
> +
> +ASSERT(spin_is_locked(&pcidevs_lock));
> +
> +/*
> + * FIXME: For performance reasons we should store the 'iommu' pointer in
> + * 'struct msi_desc' in some other place, so we don't need to waste
> + * time searching it here.
> + */
> +drhd = acpi_find_matched_drhd_unit(pci_dev);
> +if ( !drhd )
> +return -ENODEV;
> +
> +iommu = drhd->iommu;
> +ir_ctrl = iommu_ir_ctrl(iommu);
> +if ( !ir_ctrl )
> +return -ENODEV;
> +
> +spin_lock_irq(&ir_ctrl->iremap_lock);
> +
> +GET_IREMAP_ENTRY(ir_ctrl->iremap_maddr, remap_index, iremap_entries, p);
> +
> +old_ire = *p;
> +
>
Re: [Xen-devel] [PATCH v3 57/62] hvm/params: Add a new dilivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
>>> On 17.11.15 at 10:40, wrote: > From: Shannon Zhao > > Add a new dilivery type: > val[63:56] == 3: val[15:8] is flag: val[7:0] is a PPI. > To the flag, bit 0 stands the interrupt mode is edge(1) or level(0) and > bit 1 stands the interrupt polarity is active low(1) or high(0). > > Signed-off-by: Shannon Zhao Please sync up with Andrew's cleaning up of the modified comment; I definitely will want that to go in first. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] public/hvm: Export the HVM_PARAM_CALLBACK_VIA ABI in the API
>>> On 20.11.15 at 19:20, wrote:
> --- a/xen/include/public/hvm/params.h
> +++ b/xen/include/public/hvm/params.h
> @@ -29,18 +29,21 @@
> * Parameter space for HVMOP_{set,get}_param.
> */
>
> +#define HVM_PARAM_CALLBACK_IRQ 0
> +
> /*
> * How should CPU0 event-channel notifications be delivered?
> - * val[63:56] == 0: val[55:0] is a delivery GSI (Global System Interrupt).
> - * val[63:56] == 1: val[55:0] is a delivery PCI INTx line, as follows:
> - * Domain = val[47:32], Bus = val[31:16],
> - * DevFn = val[15: 8], IntX = val[ 1: 0]
> - * val[63:56] == 2: val[7:0] is a vector number, check for
> - * XENFEAT_hvm_callback_vector to know if this delivery
> - * method is available.
> + *
> * If val == 0 then CPU0 event-channel notifications are not delivered.
> + * If val != 0, val[63:56] encodes the type, as follows:
> */
> -#define HVM_PARAM_CALLBACK_IRQ 0
> +#define HVM_PARAM_CALLBACK_TYPE_GSI 0 /* val[55:0] is a delivery GSI */
> +#define HVM_PARAM_CALLBACK_TYPE_PCI_INTX 1 /* val[55:0] is a delivery PCI
> INTx line:
> + Domain = val[47:32], Bus =
> val[31:16],
> + DevFn = val[15: 8], IntX =
> val[ 1: 0] */
> +#define HVM_PARAM_CALLBACK_TYPE_VECTOR 2 /* val[7:0] is a vector number,
> check for
> + XENFEAT_hvm_callback_vector to
> know if
> + this delivery method is
> available. */
Would you not think that while cleaning this up, doing some
re-formatting would also help? I.e. Putting the comments on lines of
their own instead of at the end (even more deeply indented than
they were before)? Also the first two of these last three comments
are missing full stops.
Also considering
* Attempting to use GSI 0 will actually disable callbacks
in your patch comments, I'd suggest extending the GSI comment to
state that it has to be a non-zero one.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 09/17] VT-d: Remove pointless casts
> From: Wu, Feng > Sent: Tuesday, November 03, 2015 4:43 PM > > Remove pointless casts. > > CC: Yang Zhang > CC: Kevin Tian > Suggested-by: Jan Beulich > Signed-off-by: Feng Wu > Reviewed-by: Konrad Rzeszutek Wilk Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 08/17] vmx: Suppress posting interrupts when 'SN' is set
> From: Wu, Feng
> Sent: Tuesday, November 03, 2015 4:43 PM
N' is set
>
> Currently, we don't support urgent interrupt, all interrupts
> are recognized as non-urgent interrupt, so we cannot send
> posted-interrupt when 'SN' is set.
>
> CC: Kevin Tian
> CC: Keir Fraser
> CC: Jan Beulich
> CC: Andrew Cooper
> Signed-off-by: Feng Wu
> Reviewed-by: Konrad Rzeszutek Wilk
> Reviewed-by: Jan Beulich
Acked-by: Kevin Tian , with one small comment:
> +do {
> +/*
> + * Currently, we don't support urgent interrupt, all
> + * interrupts are recognized as non-urgent interrupt,
> + * so we cannot send posted-interrupt when 'SN' is set.
> + * Besides that, if 'ON' is already set, we cannot set
> + * posted-interrupts as well.
> + */
Is above comment accurate. "cannot set" is too strong for 'ON'
already set, right? Ideally there's no correctness issue if you
still deliver another posted-interrupt even when ON is already set.
To me it's more like an optimization then it's cleaner to say
"we can avoid"...
Thanks
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 25/62] acpi/table: Introduce acpi_get_entry to get specified entry
>>> On 24.11.15 at 04:08, wrote:
> On 2015/11/24 0:59, Jan Beulich wrote:
> On 17.11.15 at 10:40, wrote:
>>> + if ( !table_header )
>>> + {
>>> + printk("Table header not present\n");
>>> + return NULL;
>>> + }
>>> +
>>> + table_end = (unsigned long)table_header + table_header->length;
>>
>> So here you use ->length, ...
>>
>>> + /* Parse all entries looking for a match. */
>>> + entry = (struct acpi_subtable_header *)
>>> + ((unsigned long)table_header + table_size);
>>
>> ... but here table_size. Why?
>>
> Here it just skips the main table size at the beginning. Then it could
> point to the start of sub-table.
> For example, to MADT table, the table_size is sizeof(struct
> acpi_table_madt).
Well, but for one then the parameter name is kind of wrong, and
second - is it really reasonable for the caller to tell the function?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 05/62] acpi: Don't do traditional BIOS table scan for ARM64
>>> On 24.11.15 at 04:39, wrote:
> On 2015/11/23 19:35, Jan Beulich wrote:
> On 23.11.15 at 12:24, wrote:
>>> On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -78,7 +78,9 @@ acpi_physical_address __init
acpi_os_get_root_pointer(void)
} else {
acpi_physical_address pa = 0;
+ #ifdef CONFIG_X86
acpi_find_root_pointer(&pa);
+ #endif
return pa;
}
>>>
>>> I think it might be best to error out earlier if acpi and !efi_enabled
>>> on arm and arm64. If we do that we'll never enter this "else".
>>>
>>> If acpi_find_root_pointer doesn't build on arm, we should move it to an
>>> x86 specific location, such as xen/arch/x86/efi.
>>
>> No, definitely not (or if anything, then xen/arch/x86/acpi/). Instead
>> the function itself should be stubbed out to do nothing on ARM. (And
>> of course also the #ifdef placement is rather odd).
>>
> How about adding a new CONFIG_ACPI_LEGACY_TABLES_LOOKUP like Linux
> kernel for x86?
Unless you know of an architecture other than x86 potentially
needing this, I think this would go too far. Plus the suggested name
would imply "old style" lookup only, whereas per-arch customization
also allows for other "modern" (or simply "alternative") mechanisms
to be used.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 06/17] vmx: Add some helper functions for Posted-Interrupts
> From: Wu, Feng > Sent: Tuesday, November 03, 2015 4:43 PM > > This patch adds some helper functions to manipulate the > Posted-Interrupts Descriptor. > > CC: Kevin Tian > CC: Keir Fraser > CC: Jan Beulich > CC: Andrew Cooper > Signed-off-by: Feng Wu > Reviewed-by: Konrad Rzeszutek Wilk Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 04/17] vt-d: VT-d Posted-Interrupts feature detection
> From: Wu, Feng > Sent: Tuesday, November 03, 2015 4:43 PM > > VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt. > With VT-d Posted-Interrupts enabled, external interrupts from > direct-assigned devices can be delivered to guests without VMM > intervention when guest is running in non-root mode. > > CC: Yang Zhang > CC: Kevin Tian > Signed-off-by: Feng Wu > Reviewed-by: Konrad Rzeszutek Wilk > Reviewed-by: Jan Beulich Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] crash tool - problem with new Xen linear virtual mapped sparse p2m list
On 23/11/15 21:18, Daniel Kiper wrote: > Hi all, > > Some time ago Linux kernel commit 054954eb051f35e74b75a566a96fe756015352c8 > (xen: switch to linear virtual mapped sparse p2m list) introduced linear > virtual mapped sparse p2m list. It fixed some issues, however, it broke > crash tool too. I tried to fix this issue but the problem looks more > difficult than I expected. > > Let's focus on "crash vmcore vmlinux". vmcore file was generated from dom0. > "crash vmcore xen-syms" works without any issue. > > At first sight problem looks simple. Just add a function which reads p2m list > from vmcore and voila. I have done it. Then another issue arisen. > > Please take a look at following backtrace: > > #24426 0x0048b0f6 in readmem (addr=18446683600570023936, memtype=1, > buffer=0x3c0a060, size=4096, > type=0x900b2f "xen_p2m_addr page", error_handle=2) at memory.c:2157 > #24427 0x0050f746 in __xen_pvops_m2p_vma (machine=5323599872, > mfn=1299707) at kernel.c:9050 > #24428 0x0050edb7 in __xen_m2p (machine=5323599872, mfn=1299707) at > kernel.c:8867 > #24429 0x0050e948 in xen_m2p (machine=5323599872) at kernel.c:8796 > #24430 0x00528fca in x86_64_kvtop_xen_wpt (tc=0x0, > kvaddr=18446683600570023936, paddr=0x7fff51c7c100, verbose=0) > at x86_64.c:1997 > #24431 0x00528890 in x86_64_kvtop (tc=0x0, > kvaddr=18446683600570023936, paddr=0x7fff51c7c100, verbose=0) > at x86_64.c:1887 > #24432 0x0048d708 in kvtop (tc=0x0, kvaddr=18446683600570023936, > paddr=0x7fff51c7c100, verbose=0) at memory.c:2900 > #24433 0x0048b0f6 in readmem (addr=18446683600570023936, memtype=1, > buffer=0x3c0a060, size=4096, > type=0x900b2f "xen_p2m_addr page", error_handle=2) at memory.c:2157 > #24434 0x0050f746 in __xen_pvops_m2p_vma (machine=5323599872, > mfn=1299707) at kernel.c:9050 > #24435 0x0050edb7 in __xen_m2p (machine=5323599872, mfn=1299707) at > kernel.c:8867 > #24436 0x0050e948 in xen_m2p (machine=5323599872) at kernel.c:8796 > #24437 0x00528fca in x86_64_kvtop_xen_wpt (tc=0x0, > kvaddr=18446683600570023936, paddr=0x7fff51c7ca60, verbose=0) > at x86_64.c:1997 > #24438 0x00528890 in x86_64_kvtop (tc=0x0, > kvaddr=18446683600570023936, paddr=0x7fff51c7ca60, verbose=0) > at x86_64.c:1887 > #24439 0x0048d708 in kvtop (tc=0x0, kvaddr=18446683600570023936, > paddr=0x7fff51c7ca60, verbose=0) at memory.c:2900 > #24440 0x0048b0f6 in readmem (addr=18446683600570023936, memtype=1, > buffer=0x3c0a060, size=4096, > type=0x900b2f "xen_p2m_addr page", error_handle=2) at memory.c:2157 > #24441 0x0050f746 in __xen_pvops_m2p_vma (machine=6364917760, > mfn=1553935) at kernel.c:9050 > #24442 0x0050edb7 in __xen_m2p (machine=6364917760, mfn=1553935) at > kernel.c:8867 > #24443 0x0050e948 in xen_m2p (machine=6364917760) at kernel.c:8796 > #2 0x00528fca in x86_64_kvtop_xen_wpt (tc=0x0, > kvaddr=18446744072099176512, paddr=0x7fff51c7d3c0, verbose=0) > at x86_64.c:1997 > #24445 0x00528890 in x86_64_kvtop (tc=0x0, > kvaddr=18446744072099176512, paddr=0x7fff51c7d3c0, verbose=0) > at x86_64.c:1887 > #24446 0x0048d708 in kvtop (tc=0x0, kvaddr=18446744072099176512, > paddr=0x7fff51c7d3c0, verbose=0) at memory.c:2900 > #24447 0x0048b0f6 in readmem (addr=18446744072099176512, memtype=1, > buffer=0xfbb500, size=768, > type=0x8fd772 "module struct", error_handle=6) at memory.c:2157 > #24448 0x004fb0ab in module_init () at kernel.c:3355 > > As you can see module_init() calls readmem() which attempts to read virtual > address > which lies outside of kernel text mapping (0x8000 - > 0xa000). > In this case addr=18446744072099176512 == 0xa003a040 which is known > as module > mapping space. readmem() needs physical address, so, it calls kvtop() then > kvtop() > calls x86_64_kvtop(). x86_64_kvtop() is not able to easily calculate, using > simple > arithmetic like in case of kernel text mapping space, physical address from > virtual > address. Hence it calls x86_64_kvtop_xen_wpt() to calculate it by traversing > page > tables. x86_64_kvtop_xen_wpt() needs to do some m2p translation so it calls > xen_m2p() > which calls __xen_m2p() and finally it calls __xen_pvops_m2p_vma() (my > function which > tries to read linear virtual mapped sparse p2m list). Then > __xen_pvops_m2p_vma() calls > readmem() which tries to read addr=18446683600570023936 == 0xc900 > which > is VMA used for m2p list. Well, once again physical address must be > calculated by > traversing page tables. However, this requires access to m2p list which leads > to > another readmem() call. Starting from here we are in the loop. After > thousands of > repetitions crash dies due to stack overflow. Not nice... :-((( > > Do we have any viable fix for this issue? I considered a few but I have not > found prefe
Re: [Xen-devel] [PATCH v9 01/17] VT-d Posted-intterrupt (PI) design
> -Original Message- > From: Tian, Kevin > Sent: Tuesday, November 24, 2015 2:35 PM > To: Wu, Feng ; xen-devel@lists.xen.org > Cc: Zhang, Yang Z ; Jan Beulich > ; Keir Fraser ; Andrew Cooper > ; George Dunlap > > Subject: RE: [PATCH v9 01/17] VT-d Posted-intterrupt (PI) design > > > From: Wu, Feng > > Sent: Tuesday, November 03, 2015 4:43 PM > > > > > > diff --git a/docs/misc/vtd-pi.txt b/docs/misc/vtd-pi.txt > > new file mode 100644 > > index 000..f9b4637 > > --- /dev/null > > +++ b/docs/misc/vtd-pi.txt > > @@ -0,0 +1,329 @@ > > +Authors: Feng Wu > > + > > +VT-d Posted-interrupt (PI) design for XEN > > + > > +Background > > +== > > +With the development of virtualization, there are more and more device > > +assignment requirements. However, today when a VM is running with > > +assigned devices (such as, NIC), external interrupt handling for the > assigned > > +devices always needs VMM intervention. > > + > > +VT-d Posted-interrupt is a more enhanced method to handle interrupts > > +in the virtualization environment. Interrupt posting is the process by > > +which an interrupt request is recorded in a memory-resident > > +posted-interrupt-descriptor structure by the root-complex, followed by > > +an optional notification event issued to the CPU complex. > > Some clarification required here. Is "Interrupt Posting" only used to > represent the process of VT-d Posted-interrupt, or also for CPU-side > posting through IPI? From above context, and later explanation about > "Processor Support" and "Root-complex Support", looks the former > is true. Then how do we call CPU-side posting? Thanks for the comments. "Interrupt posting" in fact contains vt-d side and cpu side. So I will reword this to make it clear. Thanks, Feng > > I think a one-sentence definition about those terms in the start would > be helpful. > > > + > > +With VT-d Posted-interrupt we can get the following advantages: > > +- Direct delivery of external interrupts to running vCPUs without VMM > > +intervention > > +- Decrease the interrupt migration complexity. On vCPU migration, > software > > +can atomically co-migrate all interrupts targeting the migrating vCPU. For > > +virtual machines with assigned devices, migrating a vCPU across pCPUs > > +either incurs the overhead of forwarding interrupts in software (e.g. via > VMM > > +generated IPIs), or complexity to independently migrate each interrupt > targeting > > +the vCPU to the new pCPU. However, after enabling VT-d PI, the > destination vCPU > > +of an external interrupt from assigned devices is stored in the IRTE (i.e. > > +Posted-interrupt Descriptor Address), when vCPU is migrated to another > pCPU, > > +we will set this new pCPU in the 'NDST' filed of Posted-interrupt > descriptor, this > > +make the interrupt migration automatic. > > + > > +Here is what Xen currently does for external interrupts from assigned > devices: > > + > > +When a VM is running and an external interrupt from an assigned device > occurs > > +for it. VM-EXIT happens, then: > > + > > +vmx_do_extint() --> do_IRQ() --> __do_IRQ_guest() --> hvm_do_IRQ_dpci() > --> > > +raise_softirq_for(pirq_dpci) --> raise_softirq(HVM_DPCI_SOFTIRQ) > > + > > +softirq HVM_DPCI_SOFTIRQ is bound to dpci_softirq() > > + > > +dpci_softirq() --> hvm_dirq_assist() --> vmsi_deliver_pirq() --> > vmsi_deliver() --> > > +vmsi_inj_irq() --> vlapic_set_irq() > > + > > +vlapic_set_irq() does the following things: > > +1. If CPU-side posted-interrupt is supported, call > vmx_deliver_posted_intr() to deliver > > +the virtual interrupt via posted-interrupt infrastructure. > > +2. Else if CPU-side posted-interrupt is not supported, set the related vIRR > in vLAPIC > > +page and call vcpu_kick() to kick the related vCPU. Before VM-Entry, > vmx_intr_assist() > > +will help to inject the interrupt to guests. > > + > > +However, after VT-d PI is supported, when a guest is running in non-root > and an > > +external interrupt from an assigned device occurs for it. No VM-Exit is > needed, > > ". No VM-Exit ..." -> ", no VM-Exit..." > > > +the guest can handle this totally in non-root mode, thus avoiding all the > above > > +code flow. > > + > > +Posted-interrupt Introduction > > + > > +There are two components to the Posted-interrupt architecture: > > "to the" -> "in the" > > > Thanks > Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 01/17] VT-d Posted-intterrupt (PI) design
> From: Wu, Feng > Sent: Tuesday, November 03, 2015 4:43 PM > > > diff --git a/docs/misc/vtd-pi.txt b/docs/misc/vtd-pi.txt > new file mode 100644 > index 000..f9b4637 > --- /dev/null > +++ b/docs/misc/vtd-pi.txt > @@ -0,0 +1,329 @@ > +Authors: Feng Wu > + > +VT-d Posted-interrupt (PI) design for XEN > + > +Background > +== > +With the development of virtualization, there are more and more device > +assignment requirements. However, today when a VM is running with > +assigned devices (such as, NIC), external interrupt handling for the assigned > +devices always needs VMM intervention. > + > +VT-d Posted-interrupt is a more enhanced method to handle interrupts > +in the virtualization environment. Interrupt posting is the process by > +which an interrupt request is recorded in a memory-resident > +posted-interrupt-descriptor structure by the root-complex, followed by > +an optional notification event issued to the CPU complex. Some clarification required here. Is "Interrupt Posting" only used to represent the process of VT-d Posted-interrupt, or also for CPU-side posting through IPI? From above context, and later explanation about "Processor Support" and "Root-complex Support", looks the former is true. Then how do we call CPU-side posting? I think a one-sentence definition about those terms in the start would be helpful. > + > +With VT-d Posted-interrupt we can get the following advantages: > +- Direct delivery of external interrupts to running vCPUs without VMM > +intervention > +- Decrease the interrupt migration complexity. On vCPU migration, software > +can atomically co-migrate all interrupts targeting the migrating vCPU. For > +virtual machines with assigned devices, migrating a vCPU across pCPUs > +either incurs the overhead of forwarding interrupts in software (e.g. via VMM > +generated IPIs), or complexity to independently migrate each interrupt > targeting > +the vCPU to the new pCPU. However, after enabling VT-d PI, the destination > vCPU > +of an external interrupt from assigned devices is stored in the IRTE (i.e. > +Posted-interrupt Descriptor Address), when vCPU is migrated to another pCPU, > +we will set this new pCPU in the 'NDST' filed of Posted-interrupt > descriptor, this > +make the interrupt migration automatic. > + > +Here is what Xen currently does for external interrupts from assigned > devices: > + > +When a VM is running and an external interrupt from an assigned device occurs > +for it. VM-EXIT happens, then: > + > +vmx_do_extint() --> do_IRQ() --> __do_IRQ_guest() --> hvm_do_IRQ_dpci() --> > +raise_softirq_for(pirq_dpci) --> raise_softirq(HVM_DPCI_SOFTIRQ) > + > +softirq HVM_DPCI_SOFTIRQ is bound to dpci_softirq() > + > +dpci_softirq() --> hvm_dirq_assist() --> vmsi_deliver_pirq() --> > vmsi_deliver() --> > +vmsi_inj_irq() --> vlapic_set_irq() > + > +vlapic_set_irq() does the following things: > +1. If CPU-side posted-interrupt is supported, call vmx_deliver_posted_intr() > to deliver > +the virtual interrupt via posted-interrupt infrastructure. > +2. Else if CPU-side posted-interrupt is not supported, set the related vIRR > in vLAPIC > +page and call vcpu_kick() to kick the related vCPU. Before VM-Entry, > vmx_intr_assist() > +will help to inject the interrupt to guests. > + > +However, after VT-d PI is supported, when a guest is running in non-root and > an > +external interrupt from an assigned device occurs for it. No VM-Exit is > needed, ". No VM-Exit ..." -> ", no VM-Exit..." > +the guest can handle this totally in non-root mode, thus avoiding all the > above > +code flow. > + > +Posted-interrupt Introduction > + > +There are two components to the Posted-interrupt architecture: "to the" -> "in the" Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v9 01/17] VT-d Posted-intterrupt (PI) design
> From: Dario Faggioli [mailto:dario.faggi...@citrix.com] > Sent: Tuesday, November 10, 2015 10:52 PM > > > > +Here are what we do for the blocked vCPU: > > +1. Define a per-cpu list 'pi_blocked_vcpu', which stored the blocked > > +vCPU on the pCPU. > > +2. When the vCPU is going to block, insert the vCPU > > +to the per-cpu list belonging to the pCPU it was running. > > +3. When the vCPU is unblocked, remove the vCPU from the related pCPU > > list. > > + > > +In the handler of 'pi_wakeup_vector', we do: > > +1. Get the physical CPU. > > +2. Iterate the list 'pi_blocked_vcpu' of the current pCPU, if 'ON' > > is set, > > +we unblock the associated vCPU. > > + > This is indeed more general, and the fact that it does no longer > mentions RUNSTATEs, makes it more adherent to the actual implementation > (and hence more useful), so thanks for doing this. > > Personally, I'd add a quick comment about how this, despite being > related to blocking and unblocking, happens actually inside VMX > handlers, i.e., (quickly) what is the relationship within these sets of > events (blocking/unblocking VMENTER/EXIT) and why it is ok to do things > like they are done. > > I'm not too fussed about this, though. So, if others don't think > something like this is necessary, I'm fine with what you have here. > That type of information is welcomed. Thanks Kevin ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen 4.5.0 rtds scheduler perform poorly with 2vms
2015-11-23 23:57 GMT-05:00 Yu-An(Victor) Chen : > Hi Meng, > Hi, > Thank you again for your kindly reply! No problem :-) > I am currently using "litmus-rt-2014.2.patch" and with my labmates' patch > for IPI interrupt (https://github.com/LITMUS-RT/liblitmus/pull/1/files) > I asked my labmate about it, he said he was not sure if there is more IPI > interrupt bug other than then one he fixed. > > I can am using "st_trace" to check the success rate of the tasks. it only > gives me the how much of the deadline I am missing for each job. > which TRACE function in LITMUS, do you mean? Yes! If it is the IPI issue, you should see the destination cpu is not repsonding to the IPI in LITMUS, not Xen. > > litmus_log?ft_cpu_traceX?ft_msg_traceX?sched_trace? > or > st_trace? > > https://wiki.litmus-rt.org/litmus/Tracing > > > At this point I think the best way is to install the newest litmus-rt > (litmus-rt-2015.1.patch) ? Yes. :-) Another way to rule out the IPI delay issue is to have a background task running on each VCPU of the VM with small period to see if it improve the schedulablity. If it does, the IPI issue may still exist in LITMUS. :-( Then you have to look at the TRACE to figure out which part misses the IPI in LITMUS. > > Again, thank you very much, I really appreciate your help! No problem. Meng > > Victor > > > > > > > On Mon, Nov 23, 2015 at 6:23 PM, Meng Xu wrote: >> >> Hi, >> >> 2015-11-23 11:35 GMT-05:00 Yu-An(Victor) Chen : >> > Hi Meng, >> > >> > Thank you very much for replying! >> > >> > The RT tasks I am running for each trial at a certain utilization rate >> > is a >> > collection of real-time tasks, and each real-time task is a sequence of >> > jobs >> > that are released periodically. All jobs are periodic, where each job is >> > defined by a period (and deadline) and a worse-case execution time. Each >> > job >> > is just running of a number of iterations of floating point operations. >> > This >> > is based on the base task.c provided with the LITMUSRT userspace >> > library. So >> > Yes they are independent and not I/O or memory intensive. >> >> Ah, I see. Which version of LITMUSRT did you use? LITMUS^RT has a bug >> in Xen environment. The IPI interrupt is not handled properly in >> LITMUS on Xen. With the bug, the system performance is worse than >> when the system is loaded, because LITMUS scheduler just fails to >> respond due to the IPI ignorance. >> >> IIRC, this bug was fixed in the latest LITMUSRT code. >> Did you use the latest LITMUS code? >> >> One way to debug the issue is: >> Can you enable the TRACE in LITMUS and collact the scheduling log in >> the scenario when you see the bad performance? >> >> > >> > The period distribution I have for each task is (10ms,100ms) which is >> > bigger >> > than the VM period I specified using xl sched-rtds (1us), but I >> > guess >> > the lower bound is too close to the VM period. So by your suggestion, >> > maybe >> > shorten the period for VM can improve the performance? >> >> Yes. At least it shorten the starvation interval. >> >> Meng > > -- --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [linux-next test] 65036: regressions - FAIL
flight 65036 linux-next real [real] http://logs.test-lab.xenproject.org/osstest/logs/65036/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 64985 test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 64985 test-armhf-armhf-xl-cubietruck 6 xen-bootfail REGR. vs. 64985 test-armhf-armhf-xl-vhd 6 xen-boot fail REGR. vs. 64985 test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 64985 test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 64985 test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 64985 Regressions which are regarded as allowable (not blocking): test-armhf-armhf-libvirt-qcow2 6 xen-bootfail REGR. vs. 64985 test-armhf-armhf-libvirt-raw 6 xen-boot fail REGR. vs. 64985 test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 64985 test-armhf-armhf-xl-rtds 6 xen-boot fail REGR. vs. 64985 test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 64985 test-amd64-i386-xl6 xen-boot fail like 64985 test-amd64-i386-rumpuserxen-i386 6 xen-boot fail like 64985 test-amd64-amd64-rumpuserxen-amd64 6 xen-boot fail like 64985 test-amd64-amd64-xl 6 xen-boot fail like 64985 test-amd64-i386-freebsd10-amd64 6 xen-bootfail like 64985 test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail like 64985 test-amd64-amd64-xl-qemut-winxpsp3 6 xen-boot fail like 64985 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail like 64985 test-amd64-amd64-xl-multivcpu 6 xen-boot fail like 64985 test-amd64-i386-xl-raw6 xen-boot fail like 64985 test-amd64-amd64-xl-pvh-amd 6 xen-boot fail like 64985 test-amd64-amd64-xl-xsm 6 xen-boot fail like 64985 test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail like 64985 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail like 64985 test-amd64-i386-qemut-rhel6hvm-amd 6 xen-boot fail like 64985 test-amd64-amd64-pygrub 6 xen-boot fail like 64985 test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail like 64985 test-amd64-amd64-xl-rtds 6 xen-boot fail like 64985 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail like 64985 test-amd64-i386-xl-qemuu-win7-amd64 6 xen-bootfail like 64985 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail like 64985 test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail like 64985 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail like 64985 test-amd64-i386-libvirt 6 xen-boot fail like 64985 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail like 64985 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail like 64985 test-amd64-amd64-libvirt-vhd 6 xen-boot fail like 64985 test-amd64-i386-libvirt-xsm 6 xen-boot fail like 64985 test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-boot fail like 64985 test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail like 64985 test-amd64-i386-xl-xsm6 xen-boot fail like 64985 test-amd64-i386-xl-qemut-win7-amd64 6 xen-bootfail like 64985 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail like 64985 test-amd64-amd64-xl-qemuu-win7-amd64 6 xen-boot fail like 64985 test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail like 64985 test-amd64-amd64-xl-qcow2 6 xen-boot fail like 64985 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail like 64985 test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-bootfail like 64985 test-amd64-i386-freebsd10-i386 6 xen-boot fail like 64985 test-amd64-amd64-libvirt-xsm 6 xen-boot fail like 64985 test-amd64-i386-qemuu-rhel6hvm-amd 6 xen-boot fail like 64985 test-amd64-amd64-i386-pvgrub 6 xen-boot fail like 64985 test-amd64-amd64-xl-pvh-intel 6 xen-boot fail like 64985 test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail like 64985 test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail like 64985 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail like 64985 test-amd64-amd64-pair10 xen-boot/dst_hostfail like 64985 test-amd64-amd64-
Re: [Xen-devel] [PATCH 2/3] VMX: allocate VMCS pages from domain heap
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: Monday, November 23, 2015 10:28 PM
>
> >>> On 21.10.15 at 05:16, wrote:
> >> From: Jan Beulich [mailto:jbeul...@suse.com]
> >> Sent: Tuesday, October 20, 2015 6:36 PM
> >> >>> On 20.10.15 at 12:12, wrote:
> >> > On 19/10/15 16:22, Jan Beulich wrote:
> >> >> @@ -580,7 +583,7 @@ int vmx_cpu_up_prepare(unsigned int cpu)
> >> >> void vmx_cpu_dead(unsigned int cpu)
> >> >> {
> >> >> vmx_free_vmcs(per_cpu(vmxon_region, cpu));
> >> >> -per_cpu(vmxon_region, cpu) = NULL;
> >> >> +per_cpu(vmxon_region, cpu) = 0;
> >> >
> >> > While this is currently safe (as pa 0 is not part of the available heap
> >> > allocation range), might it be worth introducing a named sentential? I
> >> > can forsee a DMLite nested Xen scenario where we definitely don't need
> >> > to treat the low 1MB magically.
> >>
> >> I guess there are more things to adjust if we ever cared to recover
> >> the few hundred kb below 1Mb. And then I don't see why nested
> >> Xen would matter here: One major main reason for reserving that
> >> space is that we want to put the trampoline there. Do you think
> >> DMlite would allow us to get away without? But even if so, this
> >> would again fall under what I've said in the first sentence.
> >
> > Could you at least introduce a macro first? Regardless of how much
> > things to adjust, this way makes future change simple.
>
> So I've made an attempt, but this is really getting unwieldy: Setting
> per-CPU data to non-zero initial values is not possible; making sure
> cleanup code avoids assuming such variables got initialized is quite
> error prone. Same goes at least to a certain extent for struct vcpu
> members (see e.g. nvmx_vcpu_destroy(), which currently is
> correct no matter whether nvmx_vcpu_initialise() ran at all, or to
> completion).
>
> I also don't see what a macro would help here, or how/where it
> should be used. paddr_valid()? Yes, I could do this, but it wouldn't
> simplify much when later wanting to convert to a non-zero value
> for above reasons (it would instead give the wrong impression that
> changing the value is all it takes).
>
Thanks for looking into this attempt. Based on your explanation
I think your original code is reasonable to go. Here is my ack:
Acked-by: Kevin Tian
Thanks
Kevin
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] VMX: fix/adjust trap injection
> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, November 23, 2015 8:49 PM > > In the course of investigating the 4.1.6 backport issue of the XSA-156 > patch I realized that #DB injection has always been broken, but with it > now getting always intercepted the problem has got worse: Documentation > clearly states that neither DR7.GD nor DebugCtl.LBR get cleared before > the intercept, so this is something we need to do before reflecting the > intercepted exception. > > While adjusting this (and also with 4.1.6's strange use of > X86_EVENTTYPE_SW_EXCEPTION for #DB in mind) I further realized that > the special casing of individual vectors shouldn't be done for > software interrupts (resulting from INT $nn). > > And then some code movement: Setting of CR2 for #PF can be done in the > same switch() statement (no need for a separate if()), and reading of > intr_info is better done close the the consumption of the variable > (allowing the compiler to generate better code / use fewer registers > for variables). > > Signed-off-by: Jan Beulich > Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen 4.5.0 rtds scheduler perform poorly with 2vms
Hi Meng, Thank you again for your kindly reply! I am currently using "litmus-rt-2014.2.patch" and with my labmates' patch for IPI interrupt (https://github.com/LITMUS-RT/liblitmus/pull/1/files) I asked my labmate about it, he said he was not sure if there is more IPI interrupt bug other than then one he fixed. I can am using "st_trace" to check the success rate of the tasks. it only gives me the how much of the deadline I am missing for each job. which TRACE function in LITMUS, do you mean? litmus_log?ft_cpu_traceX?ft_msg_traceX?sched_trace? or st_trace? https://wiki.litmus-rt.org/litmus/Tracing At this point I think the best way is to install the newest litmus-rt (litmus-rt-2015.1.patch) ? Again, thank you very much, I really appreciate your help! Victor On Mon, Nov 23, 2015 at 6:23 PM, Meng Xu wrote: > Hi, > > 2015-11-23 11:35 GMT-05:00 Yu-An(Victor) Chen : > > Hi Meng, > > > > Thank you very much for replying! > > > > The RT tasks I am running for each trial at a certain utilization rate > is a > > collection of real-time tasks, and each real-time task is a sequence of > jobs > > that are released periodically. All jobs are periodic, where each job is > > defined by a period (and deadline) and a worse-case execution time. Each > job > > is just running of a number of iterations of floating point operations. > This > > is based on the base task.c provided with the LITMUSRT userspace > library. So > > Yes they are independent and not I/O or memory intensive. > > Ah, I see. Which version of LITMUSRT did you use? LITMUS^RT has a bug > in Xen environment. The IPI interrupt is not handled properly in > LITMUS on Xen. With the bug, the system performance is worse than > when the system is loaded, because LITMUS scheduler just fails to > respond due to the IPI ignorance. > > IIRC, this bug was fixed in the latest LITMUSRT code. > Did you use the latest LITMUS code? > > One way to debug the issue is: > Can you enable the TRACE in LITMUS and collact the scheduling log in > the scenario when you see the bad performance? > > > > > The period distribution I have for each task is (10ms,100ms) which is > bigger > > than the VM period I specified using xl sched-rtds (1us), but I guess > > the lower bound is too close to the VM period. So by your suggestion, > maybe > > shorten the period for VM can improve the performance? > > Yes. At least it shorten the starvation interval. > > Meng > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/HVM: type adjustments
> From: Jan Beulich [mailto:jbeul...@suse.com] > Sent: Monday, November 23, 2015 9:51 PM > > - constify struct hvm_trap * function parameters > - width reduce and shuffle some struct hvm_trap members > - use bool_t for boolean fields struct hvm_function_table > - use unsigned for struct hvm_function_table's hap_capabilities field > > Signed-off-by: Jan Beulich Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 13/13] ARM: XEN: Move xen_early_init() before efi_init()
On 2015/11/21 1:30, Stefano Stabellini wrote:
>> +struct xen_node_info {
>> > + const char *compat;
>> > + const char *prefix;
>> > + const char *version;
>> > + bool found;
>> > +};
>> > +
>> > +static int __init fdt_find_xen_node(unsigned long node, const char *uname,
>> > + int depth, void *data)
>> > +{
>> > + struct xen_node_info *info = data;
>> > + const void *s = NULL;
>> > + int len;
>> > +
>> > + if (depth != 1 || strcmp(uname, "hypervisor") != 0)
>> > + return 0;
>> > +
>> > + if (of_flat_dt_is_compatible(node, info->compat))
>> > + info->found = true;
>> > +
>> > + s = of_get_flat_dt_prop(node, "compatible", &len);
>> > + if (strlen(info->prefix) + 3 < len &&
>> > +!strncmp(info->prefix, s, strlen(info->prefix)))
>> > +info->version = s + strlen(info->prefix);
>> > + return 0;
>> > +}
>> > +
>> > /*
>> > * see Documentation/devicetree/bindings/arm/xen.txt for the
>> > * documentation of the Xen Device Tree format.
>> > @@ -149,26 +176,25 @@ static irqreturn_t xen_arm_callback(int irq, void
>> > *arg)
>> > #define GRANT_TABLE_PHYSADDR 0
>> > void __init xen_early_init(void)
>> > {
>> > - int len;
>> > - const char *s = NULL;
>> > - const char *version = NULL;
>> > - const char *xen_prefix = "xen,xen-";
>> > + struct xen_node_info info;
>> > +
>> > + info.compat = "xen,xen";
>> > + info.prefix = "xen,xen-";
>> > + info.version = NULL;
>> > + info.found = false;
> Can you initialize the fields directly when you define xen_node_info and
> make it static?
Sure.
Thanks,
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 12/13] arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
On 2015/11/21 1:11, Stefano Stabellini wrote:
> On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
>> From: Shannon Zhao
>>
>> When booting with ACPI, it could get the event-channel irq through
>> HVM_PARAM_CALLBACK_IRQ.
>>
>> Signed-off-by: Shannon Zhao
>> ---
>> arch/arm/xen/enlighten.c | 23 +++
>> 1 file changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
>> index 1373d6d..b8e9db8 100644
>> --- a/arch/arm/xen/enlighten.c
>> +++ b/arch/arm/xen/enlighten.c
>> @@ -25,6 +25,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -190,10 +191,24 @@ static int __init xen_guest_init(void)
>> if (!xen_domain())
>> return 0;
>>
>> -xen_events_irq = irq_of_parse_and_map(xen_node, 0);
>> -if (!xen_events_irq) {
>> -pr_err("Xen event channel interrupt not found\n");
>> -return -ENODEV;
>> +if (!acpi_disabled) {
>> +struct xen_hvm_param a;
>> +
>> +a.domid = DOMID_SELF;
>> +a.index = HVM_PARAM_CALLBACK_IRQ;
>> +if (HYPERVISOR_hvm_op(HVMOP_get_param, &a)) {
>
> If HYPERVISOR_hvm_op returns an error (ret != 0), I wouldn't bother
> checking for the returned value and simply return error.
>
> On the other hand, if HYPERVISOR_hvm_op is successful (ret == 0), then
> it might make sense to check for (a.value >> 56) == 3.
>
Ok.
>
>> +if ((a.value >> 56) != 3) {
>> +pr_err("Can't get Xen event-channel irq\n");
>> +return -ENODEV;
>> +}
>> +}
>> +xen_events_irq = a.value & 0xff;
>> +} else {
>> +xen_events_irq = irq_of_parse_and_map(xen_node, 0);
>> +if (!xen_events_irq) {
>> +pr_err("Xen event channel interrupt not found\n");
>> +return -ENODEV;
>
> Please make the error message common and move it out of the if/else.
>
Sure. Thanks.
>
>> +}
>> }
>>
>> shared_info_page = (struct shared_info *)get_zeroed_page(GFP_KERNEL);
>> --
>> 2.1.0
>>
>
> .
>
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 05/62] acpi: Don't do traditional BIOS table scan for ARM64
On 2015/11/23 19:35, Jan Beulich wrote:
On 23.11.15 at 12:24, wrote:
>> On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
>>> From: Shannon Zhao
>>>
>>> With the addition of ARM64 that does not have a traditional BIOS to
>>> scan, add a #ifdef option for x86 to do the traditional BIOS scanning
>>> for tables.
>>>
>>> Signed-off-by: Shannon Zhao
>>> ---
>>> xen/drivers/acpi/osl.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
>>> index ce15470..db74a90 100644
>>> --- a/xen/drivers/acpi/osl.c
>>> +++ b/xen/drivers/acpi/osl.c
>>> @@ -78,7 +78,9 @@ acpi_physical_address __init
>>> acpi_os_get_root_pointer(void)
>>> } else {
>>> acpi_physical_address pa = 0;
>>>
>>> + #ifdef CONFIG_X86
>>> acpi_find_root_pointer(&pa);
>>> + #endif
>>> return pa;
>>> }
>>
>> I think it might be best to error out earlier if acpi and !efi_enabled
>> on arm and arm64. If we do that we'll never enter this "else".
>>
>> If acpi_find_root_pointer doesn't build on arm, we should move it to an
>> x86 specific location, such as xen/arch/x86/efi.
>
> No, definitely not (or if anything, then xen/arch/x86/acpi/). Instead
> the function itself should be stubbed out to do nothing on ARM. (And
> of course also the #ifdef placement is rather odd).
>
How about adding a new CONFIG_ACPI_LEGACY_TABLES_LOOKUP like Linux
kernel for x86?
Thanks,
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 0/6] xen: sched: fix locking of {insert, remove}_vcpu()
If I can jump in the conversion... 2015-11-23 10:00 GMT-05:00 Jan Beulich : On 23.11.15 at 15:50, wrote: >> On 23/11/15 14:40, Jan Beulich wrote: >> On 23.11.15 at 15:03, wrote: > --- > Dario Faggioli (6): > xen: sched: fix locking of remove_vcpu() in credit1 > xen: sched: fix locking for insert_vcpu() in credit1 and RTDS > xen: sched: clarify use cases of schedule_cpu_switch() > xen: sched: better handle (not) inserting idle vCPUs in runqueues > xen: sched: get rid of the per domain vCPU list in RTDS > xen: sched: get rid of the per domain vCPU list in Credit2 Committers, It looks to me like this series has all the Acks and Reviews it needs to be checked in, but (as far as I can see) hasn't yet. Can someone double-check and check it in? (See the git tree above if you want to make it easier.) >>> >>> I've been waiting for an ack on patch 2 (and I've just checked again >>> and still can't find any); with this diffstat >>> >>> xen/common/sched_credit.c |6 ++ >>> xen/common/sched_rt.c |3 +++ >>> xen/common/schedule.c |6 ++ >>> >>> Meng's alone isn't sufficient afaict. I've once made an attempt to >>> commit later patches in this series, but failed and then didn't want >>> to waste time retrying. Hmm, I can help do some quick tests on the patch. At least, make sure it has no problem in applying on the latest commit point. >> >> What are the rules again, then? Dario is a scheduler maintainer, and >> Meng is an established contributor. I thought that was enough. > > My understanding is that patches by maintainers need an ack > by another maintainer as long as there is one. When there's > none, things become more fuzzy. I think George is the maintainer for the whole scheduler. If George could ack, it may be enough? Best, Meng --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf baseline-only test] 38327: all pass
This run is configured for baseline tests only. flight 38327 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38327/ Perfect :-) All tests in this flight passed version targeted for testing: ovmf 8084b26e926ba3bf12b8110e7d49d3c928bb17d6 baseline version: ovmf 3b1495156a3576992b31a77e799db207cb61d9de Last test of basis38321 2015-11-22 03:49:53 Z1 days Testing same since38327 2015-11-24 01:20:56 Z0 days1 attempts People who touched revisions under test: Ruiyu Ni jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 pass test-amd64-i386-xl-qemuu-ovmf-amd64 pass sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary Push not applicable. commit 8084b26e926ba3bf12b8110e7d49d3c928bb17d6 Author: Ruiyu Ni Date: Mon Nov 23 00:48:46 2015 + MdeModulePkg/BootLogoLib: Fix GCC build failure Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni Reviewed-by: Feng Tian git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18916 6f19259b-4bc3-4df7-8a09-765794883524 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 25/62] acpi/table: Introduce acpi_get_entry to get specified entry
On 2015/11/24 0:59, Jan Beulich wrote:
On 17.11.15 at 10:40, wrote:
>> --- a/xen/drivers/acpi/tables.c
>> +++ b/xen/drivers/acpi/tables.c
>> @@ -221,6 +221,51 @@ void __init acpi_table_print_madt_entry(struct
>> acpi_subtable_header *header)
>> }
>> }
>>
>> +struct acpi_subtable_header * __init
>> +acpi_get_entry(char *id, unsigned long table_size,
>> + struct acpi_table_header *table_header, int entry_id,
>> + unsigned int entry_index)
>> +{
>> +struct acpi_subtable_header *entry;
>> +unsigned int count = 0;
>> +unsigned long table_end;
>> +
>> +if ( !table_size )
>
> Linux coding style please in this file.
>
Sure.
>> +return NULL;
>> +
>> +if ( !table_header )
>> +{
>> +printk("Table header not present\n");
>> +return NULL;
>> +}
>> +
>> +table_end = (unsigned long)table_header + table_header->length;
>
> So here you use ->length, ...
>
>> +/* Parse all entries looking for a match. */
>> +entry = (struct acpi_subtable_header *)
>> +((unsigned long)table_header + table_size);
>
> ... but here table_size. Why?
>
Here it just skips the main table size at the beginning. Then it could
point to the start of sub-table.
For example, to MADT table, the table_size is sizeof(struct
acpi_table_madt).
Thanks,
--
Shannon
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] MAINTAINERS: change the vt-d maintainer
> From: Zhang, Yang Z > Sent: Monday, November 23, 2015 1:35 PM > > add Feng as the new maintainer of VT-d stuff > > Signed-off-by: Yang Zhang Acked-by: Kevin Tian ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-unstable test] 65029: regressions - FAIL
flight 65029 xen-unstable real [real] http://logs.test-lab.xenproject.org/osstest/logs/65029/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-rumpuserxen-i386 10 guest-start fail REGR. vs. 64035 test-amd64-amd64-i386-pvgrub 10 guest-start fail REGR. vs. 64035 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-qemuu-nested 16 debian-hvm-install/l1/l2 fail baseline untested test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 fail like 63911 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 64035 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 64035 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail like 64035 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-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-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass version targeted for testing: xen aec38117171b1fef50d6c3cf42dbd176907c7e18 baseline version: xen 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c Last test of basis64035 2015-11-10 08:01:11 Z 13 days Failing since 64149 2015-11-11 19:15:29 Z 12 days8 attempts Testing same since64990 2015-11-21 15:13:59 Z2 days2 attempts People who touched revisions under test: Andrew Cooper Aravind Gopalakrishnan Bob Liu Boris Ostrovsky David Scott Feng Wu Ian Campbell Ian Jackson Jan Beulich Jim Fehlig Jonathan Davies Juergen Gross Oleksandr Tyshchenko Razvan Cojocaru Riku Voipio Roger Pau Monné Shannon Zhao Simon Rowe Stefano Stabellini Wei Liu jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt
Re: [Xen-devel] xen 4.5.0 rtds scheduler perform poorly with 2vms
Hi, 2015-11-23 11:35 GMT-05:00 Yu-An(Victor) Chen : > Hi Meng, > > Thank you very much for replying! > > The RT tasks I am running for each trial at a certain utilization rate is a > collection of real-time tasks, and each real-time task is a sequence of jobs > that are released periodically. All jobs are periodic, where each job is > defined by a period (and deadline) and a worse-case execution time. Each job > is just running of a number of iterations of floating point operations. This > is based on the base task.c provided with the LITMUSRT userspace library. So > Yes they are independent and not I/O or memory intensive. Ah, I see. Which version of LITMUSRT did you use? LITMUS^RT has a bug in Xen environment. The IPI interrupt is not handled properly in LITMUS on Xen. With the bug, the system performance is worse than when the system is loaded, because LITMUS scheduler just fails to respond due to the IPI ignorance. IIRC, this bug was fixed in the latest LITMUSRT code. Did you use the latest LITMUS code? One way to debug the issue is: Can you enable the TRACE in LITMUS and collact the scheduling log in the scenario when you see the bad performance? > > The period distribution I have for each task is (10ms,100ms) which is bigger > than the VM period I specified using xl sched-rtds (1us), but I guess > the lower bound is too close to the VM period. So by your suggestion, maybe > shorten the period for VM can improve the performance? Yes. At least it shorten the starvation interval. Meng ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [libvirt test] 65035: regressions - FAIL
flight 65035 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/65035/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-armhf-libvirt 5 libvirt-build fail REGR. vs. 63340 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass version targeted for testing: libvirt e4ab3b5d38bfbaef3cfe9da07ffafca0904e69da baseline version: libvirt 3c7590e0a435d833895fc7b5be489e53e223ad95 Last test of basis63340 2015-10-28 04:19:47 Z 26 days Failing since 63352 2015-10-29 04:20:29 Z 25 days 21 attempts Testing same since65035 2015-11-23 09:15:20 Z0 days1 attempts People who touched revisions under test: Andrea Bolognani Chen Hanxiao Cole Robinson Daniel P. Berrange Daniel Veillard Guido Günther Jim Fehlig Jiri Denemark Joao Martins John Ferlan Laine Stump Luyao Huang Maxim Perevedentsev Michal Privoznik Michel Normand Mikhail Feoktistov Nikolay Shirokovskiy Pavel Hrdina Peter Krempa Richard Weinberger Roman Bogorodskiy Stefan Berger Stefan Berger jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt fail build-i386-libvirt pass build-amd64-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-armhf-armhf-libvirt-xsm blocked test-amd64-i386-libvirt-xsm pass test-amd64-amd64-libvirt pass test-armhf-armhf-libvirt blocked test-amd64-i386-libvirt pass test-amd64-amd64-libvirt-pairpass test-amd64-i386-libvirt-pair pass test-armhf-armhf-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw blocked 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 Not pushing. (No revision log; it would be 1562 lines long.) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] What kind of page mode can Xen use?
What kind of page mode can Xen use? What's the default page size of xen or how can I get it? Is hugetable used? I'm using a x64 CPU and the xen version is 4.4.2 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [libvirt] [PATCH RFC] libxl: use libxl_event_wait to process libxl events
On 11/23/2015 01:59 PM, Jim Fehlig wrote: > > Thanks for your comments and ACK'ing the change . I'll submit a V2 that > retains > handling of shutdown event in a thread. While testing V2, I noticed occasionally missing a shutdown event. I can see from the logs that domain_death_xswatch_callback is called, a matching domain is found, and shutdown is being reported 2015-11-23 17:01:09 MST libxl: debug: libxl.c:1227:domain_death_xswatch_callback: [evg=0x7fa2fc002570:0] nentries=200 rc=2 0..61 2015-11-23 17:01:09 MST libxl: debug: libxl.c:1238:domain_death_xswatch_callback: [evg=0x7fa2fc002570:0] got=domaininfos[0] got->domain=0 2015-11-23 17:01:09 MST libxl: debug: libxl.c:1264:domain_death_xswatch_callback: exists shutdown_reported=0 dominf.flags=0020 2015-11-23 17:01:09 MST libxl: debug: libxl.c:1238:domain_death_xswatch_callback: [evg=0x7fa34c007e20:61] got=domaininfos[0] got->domain=0 2015-11-23 17:01:09 MST libxl: debug: libxl.c:1238:domain_death_xswatch_callback: [evg=0x7fa34c007e20:61] got=domaininfos[1] got->domain=61 2015-11-23 17:01:09 MST libxl: debug: libxl.c:1264:domain_death_xswatch_callback: exists shutdown_reported=0 dominf.flags=4 2015-11-23 17:01:09 MST libxl: debug: libxl.c:1276:domain_death_xswatch_callback: shutdown reporting Seems the call to libxl__event_occurred never pokes libvirt's call to libxl_event_wait. Interestingly, starting another domain does cause libxl_event_wait to return with the missing shutdown event. I'm testing on a fairly recent (2 weeks) git master. I'm not familiar with the libxl poller code and will need to instrument that a bit to understand why libxl_event_wait isn't poked. Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [ovmf test] 65031: all pass - PUSHED
flight 65031 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/65031/
Perfect :-)
All tests in this flight passed
version targeted for testing:
ovmf 8084b26e926ba3bf12b8110e7d49d3c928bb17d6
baseline version:
ovmf 3b1495156a3576992b31a77e799db207cb61d9de
Last test of basis64963 2015-11-20 17:04:12 Z3 days
Testing same since65031 2015-11-23 02:12:10 Z0 days1 attempts
People who touched revisions under test:
Ruiyu Ni
jobs:
build-amd64-xsm pass
build-i386-xsm pass
build-amd64 pass
build-i386 pass
build-amd64-libvirt pass
build-i386-libvirt pass
build-amd64-pvopspass
build-i386-pvops pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 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 :
+ branch=ovmf
+ revision=8084b26e926ba3bf12b8110e7d49d3c928bb17d6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push ovmf
8084b26e926ba3bf12b8110e7d49d3c928bb17d6
+ branch=ovmf
+ revision=8084b26e926ba3bf12b8110e7d49d3c928bb17d6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
getconfig Repos
perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=ovmf
+ xenbranch=xen-unstable
+ '[' xovmf = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-unstable
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable
+ prevxenbranch=xen-4.6-testing
+ '[' x8084b26e926ba3bf12b8110e7d49d3c928bb17d6 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osst...@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/libvirt.git
++ : osst...@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osst...@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
'[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
getconfig GitCacheProxy
perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo
'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ :
'git://cache:9419/https://githu
[Xen-devel] [xen-4.6-testing test] 65028: regressions - FAIL
flight 65028 xen-4.6-testing real [real] http://logs.test-lab.xenproject.org/osstest/logs/65028/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail REGR. vs. 63379 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 fail in 64988 REGR. vs. 63449 Tests which are failing intermittently (not blocking): test-armhf-armhf-libvirt-qcow2 6 xen-boot fail in 64988 pass in 65028 test-amd64-i386-rumpuserxen-i386 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail in 64988 pass in 65028 test-armhf-armhf-xl-multivcpu 6 xen-boot fail in 64988 pass in 65028 test-armhf-armhf-libvirt-xsm 11 guest-start fail pass in 64988 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate fail pass in 64988 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail in 64988 never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestore fail in 64988 never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-armhf-armhf-xl-rtds 16 guest-start/debian.repeatfail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass version targeted for testing: xen 78833c04250416f1870c458309d3ac0e5cf915fd baseline version: xen 40d7a7454835c2f7c639c78f6c09e7b6f0e4a4e2 Last test of basis63449 2015-11-01 10:09:20 Z 22 days Failing since 64055 2015-11-10 11:39:11 Z 13 days9 attempts Testing same since64935 2015-11-20 02:51:37 Z3 days3 attempts People who touched revisions under test: Andrew Cooper Ian Campbell Ian Jackson Jan Beulich Kevin Tian jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pa
[Xen-devel] [linux-linus test] 65024: regressions - FAIL
flight 65024 linux-linus real [real] http://logs.test-lab.xenproject.org/osstest/logs/65024/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-amd 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-freebsd10-i386 6 xen-bootfail REGR. vs. 59254 test-amd64-amd64-xl-pvh-intel 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 59254 test-amd64-i386-qemuu-rhel6hvm-amd 6 xen-bootfail REGR. vs. 59254 test-amd64-amd64-rumpuserxen-amd64 6 xen-bootfail REGR. vs. 59254 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-rumpuserxen-i386 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-qemut-rhel6hvm-amd 6 xen-bootfail REGR. vs. 59254 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-credit2 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-arndale 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-pair10 xen-boot/dst_host fail REGR. vs. 59254 test-amd64-amd64-pair 9 xen-boot/src_host fail REGR. vs. 59254 test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-multivcpu 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 59254 test-amd64-i386-pair 9 xen-boot/src_host fail REGR. vs. 59254 test-amd64-amd64-xl-qemuu-win7-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-credit2 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-multivcpu 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-freebsd10-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-win7-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-cubietruck 6 xen-bootfail REGR. vs. 59254 test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-bootfail REGR. vs. 59254 test-amd64-amd64-xl-qemut-winxpsp3 6 xen-bootfail REGR. vs. 59254 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-libvirt-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-libvirt-xsm 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-libvirt-xsm 6 xen-boot fail REGR. vs. 59254 test-armhf-armhf-xl-rtds 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 59254 test-amd64-amd64-libvirt 6 xen-boot fail REGR. vs. 59254 test-amd64-i386-xl-raw6 xen-bootfail baseline untested test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail baseline untested test-armhf-armhf-xl-vhd 6 xen-bootfail baseline untested
Re: [Xen-devel] patch for restricted vPMU modes
On 11/23/2015 05:01 PM, Brendan Gregg wrote: On Mon, Nov 23, 2015 at 6:35 AM, Boris Ostrovsky mailto:boris.ostrov...@oracle.com>> wrote: On 11/20/2015 07:21 PM, Brendan Gregg wrote: These new features would need a corresponding change in Linux for PV guests (or for dom0 to change feature set globally). But before that do_xenpmu_op()'s XENPMU_feature_set clause will have to be updated to deal with new modes. Ok, thanks. For now this is HVM, and I can EINVAL in do_xenpmu_op() for the new modes, like with BTS. (Do you know if the later Linux changes would be more than a feature version of pmu_mode_store/pmu_mode_show?) You are right --- Linux doesn't need anything, it just passes the features directly to the hypervisor. pmu_mode_store/show convert strings to numbers but we don't use strings for features. So the only thing that's needed is to allow hypervisor set/clear those two bits in vpmu_features in do_xenpmu_op(). Also, if either of those two flags is set we probably want to block MSR_IA32_DS_AREA and MSR_IA32_PEBS_ENABLE accesses as well. Ok, yes, good idea. But: DS area is needed by BTS so if that feature is set we want to allow guests to write it (and as for PEBS (which also uses DS area) --- that's really a nop so whether or not you block it won't make any difference. But we should probably still do it). I don't know whether anyone else uses debug store. The way SDM's section 18.11.4 describes it there doesn't seem to be any other users. -boris ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] patch for restricted vPMU modes
On Mon, Nov 23, 2015 at 6:35 AM, Boris Ostrovsky wrote:
> (+ Dietmar)
>
> On 11/20/2015 07:21 PM, Brendan Gregg wrote:
>
>> G'Day,
>>
>> The vpmu feature of Xen is incredibly useful for performance analysis,
>> however, it's currently all counters or nothing. In secure environments,
>> there can be hesitation to enable access to all PMCs (there are hundreds of
>> them). I've included a prototype patch that introduces two new restricted
>> vpmu modes:
>>
>> vpmu=ipc: As the most restricted minimum set. This enables cycles,
>> reference cycles, and instructions only. This is enough to calculate
>> instructions per cycle (IPC).
>>
>> vpm=arch: This enables the 7 pre-defined architectural events as listed
>> in cpuid, and in Table 18-1 of the Intel software developer's manual, vol
>> 3B.
>>
>> There can be a third mode added later on, with a larger set (including
>> micro-ops PMCs).
>>
>
> These new features would need a corresponding change in Linux for PV
> guests (or for dom0 to change feature set globally). But before that
> do_xenpmu_op()'s XENPMU_feature_set clause will have to be updated to deal
> with new modes.
>
Ok, thanks. For now this is HVM, and I can EINVAL in do_xenpmu_op() for the
new modes, like with BTS. (Do you know if the later Linux changes would be
more than a feature version of pmu_mode_store/pmu_mode_show?)
>
>
>> I've included the short patch below for Xen 4.6.0, which provides these
>> modes (it also fixes a minor copy-and-paste error with
>> core2_get_fixed_pmc_count(), which I believe was accessing the wrong
>> register). I am not a veteran Xen programmer, so please feel free to edit
>> or rewrite this patch. In case this email messes it up, it's also on:
>> https://github.com/brendangregg/Misc/blob/master/xen/xen-4.6.0-vpmu-filter.diff
>>
>> I've shown testing of four modes (off, on, ipc, arch) here:
>> https://gist.github.com/brendangregg/b7318c0f49bf906dc8df
>>
>> For example, here is Linux perf running in a PVHVM guest with the new
>> vpmu=ipc mode:
>>
>> root@vm0hvm:~# perf stat -d ./noploop
>>
>> Performance counter stats for './noploop':
>>
>>1511.326375 task-clock (msec) #0.999 CPUs utilized
>> 24 context-switches #0.016 K/sec
>> 0 cpu-migrations#0.000 K/sec
>>113 page-faults #0.075 K/sec
>> 5,028,638,883 cycles#3.327 GHz
>> 0 stalled-cycles-frontend #0.00% frontend cycles
>> idle
>> 0 stalled-cycles-backend#0.00% backend cycles
>> idle
>> 20,043,427,933 instructions #3.99 insns per cycle
>> 0 branches #0.000 K/sec
>> 0 branch-misses #0.00% of all branches
>> 0 L1-dcache-loads #0.000 K/sec
>> 0 L1-dcache-load-misses #0.00% of all L1-dcache
>> hits
>> 0 LLC-loads #0.000 K/sec
>> LLC-load-misses:HG
>>
>> Note that IPC is shown ("insns per cycle"), but other counters are not.
>>
>>
>> ---patch---
>> diff -ur xen-4.6.0-clean/docs/misc/xen-command-line.markdown
>> xen-4.6.0-brendan/docs/misc/xen-command-line.markdown
>> --- xen-4.6.0-clean/docs/misc/xen-command-line.markdown2015-10-05
>> 07:33:39.0 -0700
>> +++ xen-4.6.0-brendan/docs/misc/xen-command-line.markdown2015-11-20
>> 15:29:05.663781176 -0800
>> @@ -1444,7 +1444,7 @@
>> flushes on VM entry and exit, increasing performance.
>> ### vpmu
>> -> `= ( bts )`
>> +> `= ( | bts | ipc | arch )`
>> > Default: `off`
>> @@ -1460,6 +1460,15 @@
>> If 'vpmu=bts' is specified the virtualisation of the Branch Trace Store
>> (BTS)
>> feature is switched on on Intel processors supporting this feature.
>> +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).
>> +
>> +vpmu=arch enables performance monitoring, but restricts the counters to
>> the
>> +pre-defined architectural events only. These are exposed by cpuid, and
>> listed
>> +in Table 18-1 from the Intel 64 and IA-32 Architectures Software
>> Developer's
>> +Manual, Volume 3B, System Programming Guide, Part 2.
>> +
>> Note that if **watchdog** option is also specified vpmu will be turned
>> off.
>> *Warning:*
>> diff -ur xen-4.6.0-clean/xen/arch/x86/cpu/vpmu.c
>> xen-4.6.0-brendan/xen/arch/x86/cpu/vpmu.c
>> --- xen-4.6.0-clean/xen/arch/x86/cpu/vpmu.c2015-10-05 07:33:39.0
>> -0700
>> +++ xen-4.6.0-brendan/xen/arch/x86/cpu/vpmu.c2015-11-20
>> 15:29:50.847781176 -0800
>>
>> @@ -43,9 +43,11 @@
>> CHECK_pmu_params;
>> /*
>> - * "vpmu" : vpmu generally enabled
>> - * "vpmu=off" : vpmu generally disabled
>> - * "vpmu=bts" : vpmu enabled and Intel BTS feature switched on.
>> + * "vpmu" : vpmu generally enabled (a
Re: [Xen-devel] [PATCH RFC] libxl: use libxl_event_wait to process libxl events
On 11/23/2015 04:24 AM, Ian Jackson wrote:
> Jim Fehlig writes ("[PATCH RFC] libxl: use libxl_event_wait to process libxl
> events"):
>> Prior to this patch, libxl events were delivered to libvirt via
>> the libxlDomainEventHandler callback registered with libxl.
>> Documenation in $xensrc/tools/libxl/libxl_event.h states that the
>> callback "may occur on any thread in which the application calls
>> libxl". This can result in deadlock since many of the libvirt
>> callees of libxl hold a lock on the virDomainObj they are working
>> on. When the callback is invoked, it attempts to find a virDomainObj
>> corresponding to the domain ID provided by libxl. Searching the
>> domain obj list results in locking each obj before checking if it is
>> active, and its ID equals the requested ID. Deadlock is possible
>> when attempting to lock an obj that is already locked further up
>> the call stack. Indeed, Max Ustermann recently reported an instance
>> of this deadlock
> This sounds like a very plausible failure mode.
>
>> https://www.redhat.com/archives/libvir-list/2015-November/msg00130.html
>>
>> This patch moves processing of libxl events to a thread, where
>> libxl_event_wait() is used to collect events. This allows processing
>> libxl events asynchronously in libvirt, avoiding the deadlock.
> The reasoning is sound and the remedy is IMO correct. (However, you
> mean "this allows processing libxl events _synchronously_", since what
> you are doing is serialising them all into your main loop.)
Ah yes, poor choice of words. The last sentence should read:
This approach gives libvirt more control over event processing, ensuring object
locking constraints can be met.
But your comment exposes a flaw in the patch, one that had already been fixed in
the event_occurs approach. Shutting down a large memory domain can take
considerable time due to memory scrubbing, meanwhile stalling reception of other
events. The patch was a bit aggressive in removing libxlDomainShutdownThread().
>
> So:
>
> Acked-by: Ian Jackson
>
> NB that I have not reviewed the patch in detail. I can do that if you
> like, although of course my knowledge of the innards of libvirt is not
> wonderful.
>
>> The only reservations I have about this patch come from comments
>> about libxl_event_wait in libxl_event.h
>>
>> Like libxl_event_check but blocks if no suitable events are
>> available, until some are. Uses libxl_osevent_beforepoll/
>> _afterpoll so may be inefficient if very many domains are being
>> handled by a single program.
> If this turns out to be a problem in practice, we will improve libxl's
> data structures to not involve so many linear searches. (In fact I
> think you are probably already calling synchronous libxl ao functions,
> which have the same performance properties, although this is not
> documented.)
>
> Given what you say above I don't think there is a reasonable
> alternative remedy. So you should go ahead with this patch.
Thanks for your comments and ACK'ing the change . I'll submit a V2 that retains
handling of shutdown event in a thread.
Regards,
Jim
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] crash tool - problem with new Xen linear virtual mapped sparse p2m list
Hi all, Some time ago Linux kernel commit 054954eb051f35e74b75a566a96fe756015352c8 (xen: switch to linear virtual mapped sparse p2m list) introduced linear virtual mapped sparse p2m list. It fixed some issues, however, it broke crash tool too. I tried to fix this issue but the problem looks more difficult than I expected. Let's focus on "crash vmcore vmlinux". vmcore file was generated from dom0. "crash vmcore xen-syms" works without any issue. At first sight problem looks simple. Just add a function which reads p2m list from vmcore and voila. I have done it. Then another issue arisen. Please take a look at following backtrace: #24426 0x0048b0f6 in readmem (addr=18446683600570023936, memtype=1, buffer=0x3c0a060, size=4096, type=0x900b2f "xen_p2m_addr page", error_handle=2) at memory.c:2157 #24427 0x0050f746 in __xen_pvops_m2p_vma (machine=5323599872, mfn=1299707) at kernel.c:9050 #24428 0x0050edb7 in __xen_m2p (machine=5323599872, mfn=1299707) at kernel.c:8867 #24429 0x0050e948 in xen_m2p (machine=5323599872) at kernel.c:8796 #24430 0x00528fca in x86_64_kvtop_xen_wpt (tc=0x0, kvaddr=18446683600570023936, paddr=0x7fff51c7c100, verbose=0) at x86_64.c:1997 #24431 0x00528890 in x86_64_kvtop (tc=0x0, kvaddr=18446683600570023936, paddr=0x7fff51c7c100, verbose=0) at x86_64.c:1887 #24432 0x0048d708 in kvtop (tc=0x0, kvaddr=18446683600570023936, paddr=0x7fff51c7c100, verbose=0) at memory.c:2900 #24433 0x0048b0f6 in readmem (addr=18446683600570023936, memtype=1, buffer=0x3c0a060, size=4096, type=0x900b2f "xen_p2m_addr page", error_handle=2) at memory.c:2157 #24434 0x0050f746 in __xen_pvops_m2p_vma (machine=5323599872, mfn=1299707) at kernel.c:9050 #24435 0x0050edb7 in __xen_m2p (machine=5323599872, mfn=1299707) at kernel.c:8867 #24436 0x0050e948 in xen_m2p (machine=5323599872) at kernel.c:8796 #24437 0x00528fca in x86_64_kvtop_xen_wpt (tc=0x0, kvaddr=18446683600570023936, paddr=0x7fff51c7ca60, verbose=0) at x86_64.c:1997 #24438 0x00528890 in x86_64_kvtop (tc=0x0, kvaddr=18446683600570023936, paddr=0x7fff51c7ca60, verbose=0) at x86_64.c:1887 #24439 0x0048d708 in kvtop (tc=0x0, kvaddr=18446683600570023936, paddr=0x7fff51c7ca60, verbose=0) at memory.c:2900 #24440 0x0048b0f6 in readmem (addr=18446683600570023936, memtype=1, buffer=0x3c0a060, size=4096, type=0x900b2f "xen_p2m_addr page", error_handle=2) at memory.c:2157 #24441 0x0050f746 in __xen_pvops_m2p_vma (machine=6364917760, mfn=1553935) at kernel.c:9050 #24442 0x0050edb7 in __xen_m2p (machine=6364917760, mfn=1553935) at kernel.c:8867 #24443 0x0050e948 in xen_m2p (machine=6364917760) at kernel.c:8796 #2 0x00528fca in x86_64_kvtop_xen_wpt (tc=0x0, kvaddr=18446744072099176512, paddr=0x7fff51c7d3c0, verbose=0) at x86_64.c:1997 #24445 0x00528890 in x86_64_kvtop (tc=0x0, kvaddr=18446744072099176512, paddr=0x7fff51c7d3c0, verbose=0) at x86_64.c:1887 #24446 0x0048d708 in kvtop (tc=0x0, kvaddr=18446744072099176512, paddr=0x7fff51c7d3c0, verbose=0) at memory.c:2900 #24447 0x0048b0f6 in readmem (addr=18446744072099176512, memtype=1, buffer=0xfbb500, size=768, type=0x8fd772 "module struct", error_handle=6) at memory.c:2157 #24448 0x004fb0ab in module_init () at kernel.c:3355 As you can see module_init() calls readmem() which attempts to read virtual address which lies outside of kernel text mapping (0x8000 - 0xa000). In this case addr=18446744072099176512 == 0xa003a040 which is known as module mapping space. readmem() needs physical address, so, it calls kvtop() then kvtop() calls x86_64_kvtop(). x86_64_kvtop() is not able to easily calculate, using simple arithmetic like in case of kernel text mapping space, physical address from virtual address. Hence it calls x86_64_kvtop_xen_wpt() to calculate it by traversing page tables. x86_64_kvtop_xen_wpt() needs to do some m2p translation so it calls xen_m2p() which calls __xen_m2p() and finally it calls __xen_pvops_m2p_vma() (my function which tries to read linear virtual mapped sparse p2m list). Then __xen_pvops_m2p_vma() calls readmem() which tries to read addr=18446683600570023936 == 0xc900 which is VMA used for m2p list. Well, once again physical address must be calculated by traversing page tables. However, this requires access to m2p list which leads to another readmem() call. Starting from here we are in the loop. After thousands of repetitions crash dies due to stack overflow. Not nice... :-((( Do we have any viable fix for this issue? I considered a few but I have not found prefect one. 1) In theory we can use p2m tree to solve that problem because it is available in parallel with VMA mapped p2m right now. However, this is temporary solution and it will be phased out sooner or later. We need long term soluti
[Xen-devel] Early x86 boot code build system questions
Hi all,
During work on multiboot2 protocol support for Xen others and I spotted some
issues and/or deficiencies in early x86 boot code build system.
Some people reported that after applying v2 of my patches they cannot build
xen.gz due to following error:
objdump -h reloc.o | sed -n '/[0-9]/{s,00*,0,g;p;}' |\
while read idx name sz rest; do \
case "$name" in \
.data|.data.*|.rodata|.rodata.*|.bss|.bss.*) \
test $sz != 0 || continue; \
echo "Error: non-empty $name: 0x$sz" >&2; \
exit $(expr $idx + 1);; \
esac; \
done
Error: non-empty .rodata: 0x01c
build32.mk:22: recipe for target 'reloc.o' failed
Surprisingly second run usually builds xen.gz without any issue. The problem is
in xen/arch/x86/boot/build32.mk %.o: %.c recipe and I will post relevant fix
for this in v3.
Anyway, issue was introduced by "[PATCH v2 08/23] x86: add multiboot2 protocol
support" patch
(http://lists.xen.org/archives/html/xen-devel/2015-07/msg03828.html)
and "[PATCH v2 21/23] x86/boot: implement early command line parser in C" patch
(http://lists.xen.org/archives/html/xen-devel/2015-07/msg03838.html). The
problem
is that optimization engine in newer GCC versions try to optimize switch/case
construct by putting some data in .rodata section (try GCC with -S option and
look for labels starting with "CSWTCH"). As you can see this is not allowed by
our build rules.
Potentially we can avoid switch/case construct and use ifs. Not nice. After some
search I found that problematic GCC optimization feature could be disabled by
-fno-tree-switch-conversion option. However, I am not happy with that because if
newer GCC version will once again create not allowed sections then we will be
hit
by the same problem.
So, I asked myself why we do not allow .rodata sections (and others) in
intermediate
*.o files? I did some tests with relevant checks disabled and xen.gz works
without
any issue. Of course final image is larger due to some alignments but I do not
believe
that this is real explanation for this restriction. So, I would like to ask why
these
constraints were put here and in other places? Could we safely remove them? If
yes then how?
During later discussion about patches Jan suggested another change in Xen build
system
(check http://lists.xen.org/archives/html/xen-devel/2015-09/msg02877.html for
more details):
**
[...]
> Ditto. So, what is your decision? Include or define? If include then
> we should think how to generate relevant dependencies automatically.
I think the question should rather be whether we can't make cmdline.c
build the normal way, not the reloc.c one.
[...]
**
Ha! The simplest way looks like direct linking with other object files. No way!
Early x86 boot code object files are 32-bit and others are 64-bit. I have not
found anything which allows us such weired things. However, I am sure that guys
in other OS related projects were hit by the same problem. I am right. Linux
kernel looks like good example (yep, I know that there are others in the wild
but I have relevant sources under my feet and I am lazy). As I saw x86-64 Linux
kernel contains 32-bit early boot code and 64-bit main code. However, both of
them are not linked together by binutils linker. They are linked to separate ELF
executables at first. Later special tool reads them and creates proper vmlinuz
file.
Potentially we can go Linux way and avoid all above mentioned issues. However,
this requires huge changes in our build system. So, I think that right now we
can use workaround with -fno-tree-switch-conversion GCC option. Later, during
work on new PE file (this thing requires also substantial changes in build
system)
which will support three boot protocols we could revisit the issue and resolve
it by building 32-bit and 64-bit code separately. Then linking both of them
with our special tool. What do you think about that?
Daniel
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/2] libxl: implement virDomainInterfaceStats
Introduce support for domainInterfaceStats API call for querying
network interface statistics. Consequently it also enables the
use of `virsh domifstat ` command plus
seeing the interfaces names instead of "-" when doing
`virsh domiflist `.
After successful guest creation we fill the network
interfaces names based on domain, device id and append suffix
if it's emulated in the following form: vif.[-emu].
We extract the network interfaces info from libxl in
libxlDomainStartCallback() and make ifname . On domain
cleanup we also clear ifname, in case it was set by libvirt (i.e.
being prefixed with "vif"). We also skip these two steps in case the name
of the interface was manually inserted by the adminstrator.
For getting the interface statistics we resort to virNetInterfaceStats
and let libvirt handle the platform specific nits. Note that the latter
is not yet supported in FreeBSD.
Signed-off-by: Joao Martins
---
Changes since v3:
- Use libxl_device_nic_list() for getting each network interface
devid in DomainStartCallback.
- Improve error reporting by appropriately setting the right error
when no interface is known.
- Do not unlock vm if libxlDomainObjEndJob() returns false
- Set vm->def->net[i]->ifname on DomainStartCallback instead of
DomainStart.
- Change commit message reflecting the changes on the previous
item and mention correct interface names when doing domiflist.
Changes since v2:
- Clear ifname if it's autogenerated, since otherwise will persist
on successive domain starts. Change commit message reflecting this
change.
Changes since v1:
- Fill .ifname after domain start with generated
name from libxl based on domain id and devid returned by libxl.
After that path validation don interfaceStats is enterily based
on ifname pretty much like the other drivers.
- Modify commit message reflecting the changes mentioned in
the previous item.
- Bump version to 1.2.22
---
src/libxl/libxl_domain.c | 29 +++
src/libxl/libxl_driver.c | 52
2 files changed, 81 insertions(+)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index a7267b0..141f241 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -728,6 +728,17 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver,
}
}
+if ((vm->def->nnets)) {
+ssize_t i;
+
+for (i = 0; i < vm->def->nnets; i++) {
+virDomainNetDefPtr net = vm->def->nets[i];
+
+if (STRPREFIX(net->ifname, "vif"))
+VIR_FREE(net->ifname);
+}
+}
+
if (virAsprintf(&file, "%s/%s.xml", cfg->stateDir, vm->def->name) > 0) {
if (unlink(file) < 0 && errno != ENOENT && errno != ENOTDIR)
VIR_DEBUG("Failed to remove domain XML for %s", vm->def->name);
@@ -857,6 +868,8 @@ static void
libxlDomainStartCallback(libxl_ctx *ctx, libxl_event *ev, void *for_callback)
{
virDomainObjPtr vm = for_callback;
+libxl_device_nic *nics;
+int nnics;
size_t i;
virObjectLock(vm);
@@ -883,6 +896,22 @@ libxlDomainStartCallback(libxl_ctx *ctx, libxl_event *ev,
void *for_callback)
VIR_FREE(console);
}
}
+
+if ((nics = libxl_device_nic_list(ctx, ev->domid, &nnics)) != NULL) {
+for (i = 0; i < vm->def->nnets && i < nnics; i++) {
+virDomainNetDefPtr net = vm->def->nets[i];
+libxl_device_nic *x_nic = &nics[i];
+const char *suffix =
+x_nic->nictype != LIBXL_NIC_TYPE_VIF ? "-emu" : "";
+
+if (net->ifname)
+continue;
+
+if (virAsprintf(&net->ifname, "vif%d.%d%s",
+ev->domid, x_nic->devid, suffix) < 0)
+continue;
+}
+}
virObjectUnlock(vm);
libxl_event_free(ctx, ev);
}
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index d77a0e4..55d991b 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -58,6 +58,7 @@
#include "virhostdev.h"
#include "network/bridge_driver.h"
#include "locking/domain_lock.h"
+#include "virstats.h"
#define VIR_FROM_THIS VIR_FROM_LIBXL
@@ -4643,6 +4644,56 @@ libxlDomainIsUpdated(virDomainPtr dom)
}
static int
+libxlDomainInterfaceStats(virDomainPtr dom,
+ const char *path,
+ virDomainInterfaceStatsPtr stats)
+{
+libxlDriverPrivatePtr driver = dom->conn->privateData;
+virDomainObjPtr vm;
+ssize_t i;
+int ret = -1;
+
+if (!(vm = libxlDomObjFromDomain(dom)))
+goto cleanup;
+
+if (virDomainInterfaceStatsEnsureACL(dom->conn, vm->def) < 0)
+goto cleanup;
+
+if (libxlDomainObjBeginJob(driver, vm, LIBXL_JOB_QUERY) < 0)
+goto cleanup;
+
+if (!virDomainObjIsActive(vm)) {
+virReportError(VIR_ERR_OPERATION_INVALID,
+ "%s", _("domain is not running"));
+goto endjob;
+}
+
+/* C
[Xen-devel] [PATCH v2 1/2] libxl: rename libxlConsoleCallback
. to a more generic name i.e. libxlDomainStartCallback,
since it will now cover another case other than the console.
Signed-off-by: Joao Martins
---
src/libxl/libxl_domain.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 40dcea1..a7267b0 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -854,7 +854,7 @@ libxlDomainFreeMem(libxl_ctx *ctx, libxl_domain_config
*d_config)
}
static void
-libxlConsoleCallback(libxl_ctx *ctx, libxl_event *ev, void *for_callback)
+libxlDomainStartCallback(libxl_ctx *ctx, libxl_event *ev, void *for_callback)
{
virDomainObjPtr vm = for_callback;
size_t i;
@@ -988,7 +988,7 @@ libxlDomainStart(libxlDriverPrivatePtr driver,
virDomainObjPtr vm,
virObjectUnlock(vm);
aop_console_how.for_callback = vm;
-aop_console_how.callback = libxlConsoleCallback;
+aop_console_how.callback = libxlDomainStartCallback;
if (restore_fd < 0) {
ret = libxl_domain_create_new(cfg->ctx, &d_config,
&domid, NULL, &aop_console_how);
--
2.1.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/2] libxl: implement virDomainInterfaceStats
Hey, This patch series implements virDomainInterfaceStats but based on "ConsoleCallback" as opposed of doing it in libxlDomainStart. The series is divided as following: Patch 1 renames console callback to something more generic and Patch 2 implements virDomainInterfaceStats also taking the previous review (v3 statistics) comments. Changes since v1: - Improve error reporting in case interface is not known - Use libxl_device_nic_list as opposed to libxl_domain_config Regards, Joao Joao Martins (2): libxl: rename libxlConsoleCallback libxl: implement virDomainInterfaceStats src/libxl/libxl_domain.c | 33 -- src/libxl/libxl_driver.c | 52 2 files changed, 83 insertions(+), 2 deletions(-) -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [qemu-mainline test] 65005: regressions - FAIL
flight 65005 qemu-mainline real [real] http://logs.test-lab.xenproject.org/osstest/logs/65005/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-qemuu-winxpsp3 9 windows-install fail REGR. vs. 64579 test-amd64-i386-xl-qemuu-winxpsp3 9 windows-install fail REGR. vs. 64579 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail REGR. vs. 64579 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 64579 test-armhf-armhf-xl-rtds 11 guest-start fail like 64579 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 12 migrate-support-checkfail never pass test-armhf-armhf-xl-arndale 13 saverestore-support-checkfail never pass test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass test-armhf-armhf-xl-xsm 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass test-amd64-amd64-qemuu-nested 16 debian-hvm-install/l1/l2 fail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail never pass test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail never pass test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-amd64-i386-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never pass test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass test-amd64-amd64-libvirt-vhd 9 debian-di-installfail never pass version targeted for testing: qemuu541abd10a01da56c5f16582cd32d67114ec22a5c baseline version: qemuu9be060f5278dc0d732ebfcf2bf0a293f88b833eb Last test of basis64579 2015-11-17 15:37:49 Z6 days Failing since 64797 2015-11-19 03:03:30 Z4 days3 attempts Testing same since65005 2015-11-22 11:32:23 Z1 days1 attempts People who touched revisions under test: "Dr. David Alan Gilbert" Alberto Garcia Andreas Färber Bandan Das Daniel P. Berrange Denis V. Lunev Dr. David Alan Gilbert Eduardo Habkost François Baldassari Gerd Hoffmann Greg Kurz Ildar Isaev John Snow Juan Quintela Kevin Wolf Marc-André Lureau Max Reitz Michael Roth Michael S. Tsirkin Pavel Fedin Peter Lieven Peter Maydell Rabin Vincent Richard Henderson Sergey Fedorov Victor Kaplansky Yuanhan Liu Yuri Pudgorodskiy jobs: build-amd64-xsm pass build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-armhf pass build-i386 pass build-amd64-libvirt pass build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvopspass build-armhf-pvopspass build-i386-pvops pass test-amd64-amd64-xl
Re: [Xen-devel] Update upstream qemu to 2.4.1 for xen-unstable
On Fri, 20 Nov 2015, Fabio Fantoni wrote: > I saw that upstream qemu for xen-unstable is still not updated at least to > latest stable version. > I tested qemu 2.4.0.1 for some weeks on 2 systems backporting this 2 patches: > spice: surface switch fast path requires same format too (I think is good > backport it also on future update in xen as it fix a spice regression) > xen/HVM: atomically access pointers in bufioreq handling (I suppose that this > will be added in xen git too) > > I also recently tested 2.4.1 (also backporting same 2 patches above) without > finding regression for now. Thanks for the pointers. I have done the upgrade. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [adhoc test] 64951: regressions - trouble: blocked/broken/fail/pass
i...@xenbits.xen.org writes ("[adhoc test] 64951: regressions - trouble:
blocked/broken/fail/pass"):
> [adhoc commission-nocera] <2testing.git master /dev/pts/9>
> harness 2f02c43: Nested hosts: Use hostnamepath() in create_webfile
> 64951: regressions - trouble: blocked/broken/fail/pass
>
> flight 64951 xen-unstable commission-nocera [commission-nocera]
> http://logs.test-lab.xenproject.org/osstest/logs/64951/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-armhf 3 capture-logs !broken [st=!broken!]
> build-armhf-xsm 3 capture-logs !broken [st=!broken!]
> build-armhf-pvops 3 capture-logs !broken [st=!broken!]
> test-amd64-i386-qemut-rhel6hvm-intel 2 hosts-allocate broken REGR. vs.
> 64314
> build-armhf 2 hosts-allocate broken REGR. vs. 64314
> test-amd64-amd64-xl-pvh-intel 2 hosts-allocate broken REGR. vs. 64314
> build-armhf-xsm 2 hosts-allocate broken REGR. vs. 64314
> test-amd64-i386-qemuu-rhel6hvm-intel 2 hosts-allocate broken REGR. vs.
> 64314
> build-armhf-pvops 2 hosts-allocate broken REGR. vs. 64314
> test-amd64-amd64-qemuu-nested 16 debian-hvm-install/l1/l2 fail REGR. vs.
> 64314
Based on this report I can see no trace of a problem which would
explain why I hadn't blessed nocera for tests. I am going to do that
now.
Ian.
> Regressions which are regarded as allowable (not blocking):
> test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 64314
> test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install
> fail like 64314
> test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail like 64314
>
> Tests which did not succeed, but are not blocking:
> test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a
> test-armhf-armhf-libvirt-xsm 1 build-check(1) blocked n/a
> test-armhf-armhf-xl-arndale 1 build-check(1) blocked n/a
> test-armhf-armhf-xl-cubietruck 1 build-check(1) blocked n/a
> test-armhf-armhf-xl-vhd 1 build-check(1) blocked n/a
> test-armhf-armhf-libvirt 1 build-check(1) blocked n/a
> test-armhf-armhf-xl-rtds 1 build-check(1) blocked n/a
> test-armhf-armhf-xl-xsm 1 build-check(1) blocked n/a
> test-armhf-armhf-xl 1 build-check(1) blocked n/a
> test-armhf-armhf-xl-credit2 1 build-check(1) blocked n/a
> build-armhf-libvirt 1 build-check(1) blocked n/a
> test-armhf-armhf-xl-multivcpu 1 build-check(1) blocked n/a
> test-armhf-armhf-libvirt-qcow2 1 build-check(1) blocked n/a
> test-amd64-amd64-xl-pvh-amd 11 guest-start fail never
> pass
> test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail never
> pass
> test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
> fail never pass
> test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never
> pass
> test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never
> pass
> test-amd64-i386-libvirt-xsm 12 migrate-support-checkfail never
> pass
> test-amd64-amd64-libvirt 12 migrate-support-checkfail never
> pass
> test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check
> fail never pass
> test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never
> pass
> test-amd64-i386-libvirt 12 migrate-support-checkfail never
> pass
>
> baseline version:
> flight 64314
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH V8 3/7] libxl: add pvusb API
On 19/11/15 06:24, Chun Yan Liu wrote: > > On 11/19/2015 at 09:33 AM, in message > <564d9761026600085...@relay2.provo.novell.com>, "Chun Yan Liu" > wrote: > >> > On 11/18/2015 at 05:44 PM, in message <20151118094410.gb21...@aepfle.de>, > Olaf >> Hering wrote: >>> On Tue, Nov 17, Chun Yan Liu wrote: >>> I think libxl_device_usb doesn't need to be changed into >>> libxl_device_usbdev? > > George & Olaf, > > About the naming, can we get to a decision? > e.g. > * usb controller and everything related, using "usbctrl" > * usb device and everything related, using "usbdev" (?) > Currently in pvusb, almost everywhere referring to a usb device, we use "usb". > Like: libxl_device_usb, libxl_device_usb_add/remove, etc. > > If we decide, I can update all together. So I finally went back and spent some time mulling over the e-mail thread we had before about designing the interface. Just as a reminder, SCSI has a topology of host / bus / target / LUN; USB has a topology controller / hub[bus] / [port]device / interface. At the moment in USB we're not dealing with virtual hubs, so each controller will have a single bus. Additionally, we are only passing through and/or creating devices; a physical device with more than one interface will have all of its interfaces passed through transparently. So we're only effectively exposing two levels in our API. In the previous discussion, for pvscsi, Juergen argued it makes sense to be able to assign LUNs from the same physical target to different virtual targets; and it also makes sense to be able to assign newly-created physical LUNs to existing virtual targets. (Please people correct me if I've misunderstood something anywhere.) So for SCSI, there may be three levels at which people want to be able to do things. Given, that, I wonder if it would make sense to name the different "levels" for these multi-level devices after the name for that level in their respective specificaitons. I.e., libxl_device_usbctrl, libxl_device_usbdev, libxl_device_scsihost, libxl_device_scsitgt, libxl_device_scsilun or something like that. In which case, "usbdev" would be indicated (since it's the "device" we're talking about). Thoughts? -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [xen-4.5-testing baseline-only test] 38324: regressions - FAIL
This run is configured for baseline tests only. flight 38324 xen-4.5-testing real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/38324/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386-prev 5 xen-build fail REGR. vs. 38297 build-i3865 xen-build fail REGR. vs. 38297 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate.2 fail REGR. vs. 38297 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail blocked in 38297 test-amd64-amd64-xl-rtds 6 xen-boot fail like 38297 test-amd64-amd64-xl-credit2 21 guest-start/debian.repeatfail like 38297 Tests which did not succeed, but are not blocking: build-i386-rumpuserxen1 build-check(1) blocked n/a build-i386-libvirt1 build-check(1) blocked n/a test-amd64-i386-xl1 build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-i386 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a test-amd64-i386-rumpuserxen-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-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-intel 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 test-amd64-i386-pair 1 build-check(1) blocked n/a test-amd64-i386-freebsd10-amd64 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-debianhvm-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a test-armhf-armhf-libvirt-qcow2 9 debian-di-installfail never pass test-armhf-armhf-xl-vhd 9 debian-di-installfail never pass test-armhf-armhf-libvirt-raw 9 debian-di-installfail never pass test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass test-armhf-armhf-libvirt 14 guest-saverestorefail never pass test-armhf-armhf-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass test-amd64-amd64-rumpuserxen-amd64 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail never pass test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail never pass test-armhf-armhf-xl-midway 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-midway 12 migrate-support-checkfail never pass test-armhf-armhf-xl-credit2 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-credit2 12 migrate-support-checkfail never pass test-armhf-armhf-xl 12 migrate-support-checkfail never pass test-armhf-armhf-xl 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail never pass test-armhf-armhf-xl-rtds 12 migrate-support-checkfail never pass test-amd64-amd64-libvirt 12 migrate-support-checkfail never pass test-amd64-amd64-qemuu-nested 16 debian-hvm-install/l1/l2 fail never pass test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail never pass test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass version targeted for testing: xen 0cabed0a0b322fbef30f3519465538df4ab1d9f2 baseline version: xen f299bd482c6f53c61776cc8a408f8394df92ddd1 Last test of basis38297 2015-11-17 02:49:25 Z6 days Testing same since38324 2015-11-23 12:49:06 Z0 days1 attempts People who touched revisions under test: Ian Campbell Ian Jackson jobs: build-amd64
Re: [Xen-devel] [PATCH XEN v5 07/23] tools: Refactor /dev/xen/gnt{dev, shr} wrappers into libxengnttab.
On Wed, 2015-11-11 at 15:03 +, Ian Jackson wrote:
> > XXX consider combining into a single namespace (i.e. with
> > xengnttab_handle having two open fd's in it on Linux)
>
[...]
> I conclude it would be better to unify them.
Starting to look into this I have some queries on the direction I ought to
take.
Currently the real world implementations are such that a given installation
either provides:
* Neither gnttab nor gntshr (*BSD)
* Only gnttab, not gntshr (mini-os, older Linux versions)
* Both gnttab and ghtshr (newer Linux versions)
In particular gntshr but not gnttab is not found in any real world system.
Should I plan for such systems existing in the API? I think I probably
should.
A second question is then what functionality should be provided for callers
who only want either gnttab or gntshr, but not both. (The canonical example
would be the xc_gntshr_* compat layer in libxenctrl, there may be others).
Previously code could rely on either xc_gnt{tab,shr}_open failing if the
underlying interface was not present, and react accordingly, which might
involve disabling functionality entirely (in such a way as the other calls
to xc_gnt{tab,shr}_* do not need to handle ENOSYS, including by calling
exit(1)).
Now xengnttab_open could succeed because the other interface is available,
which may cause these applications to think they have an interface which
they in reality do not => confusion.
Options I can think of:
* A set of open flags, either FOO_MANDATORY or FOO_ONLY (the latter
allowing us to skip opening the relevant interface).
* Provide an interface to query the actual functionality which a given
handle supports, so apps can react accordingly (e.g. by closing it again
and erroring)
* Force all callers to adjust to handling ENOSYS as part of this
transition
Opinions?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] libxl: add libxl_domain_config to libxlDomainObjPrivate
On 11/23/2015 03:35 PM, Jim Fehlig wrote: > On 11/20/2015 05:40 PM, Joao Martins wrote: >> >> On 11/20/2015 07:05 PM, Jim Fehlig wrote: >>> On 11/19/2015 04:45 PM, Joao Martins wrote: >>> >>> You're not going to be happy with me... >>> This new field in libxlDomainObjPrivate is named "config" and is kept while the domain is active. >>> While this sounded like a good idea when I mentioned it, I'm now worried >>> that >>> the config will quickly become stale and cause problems if used elsewhere >>> (e.g. >>> see my yet-to-be-written comment in 3/3). IIUC correctly, >>> libxl_domain_config >>> is only useful when creating the domain. Subsequently adding/removing >>> devices, >>> memory, vcpus, etc. would not be reflected in the libxl_domain_config >>> object. I >>> suppose it would useful (and still valid) in the start callback, but IMO >>> including it in the libxlDomainPrivate struct fools us into believing it >>> could >>> be used elsewhere throughout the life of the domain. I now have second >>> doubts >>> about this. What do you think? >> I agree with you, and since there a libxl_device_nic_list as you suggested, >> it >> would actually be much cleaner and safer compared to libxl_domain_config >> alternative (though with a small performance cost). And we would avoid end up >> having config just lying there with no additional use (besides StartCallback) >> and inconsistent info. >> >> The only thing that the libxlDomainObjPrivate approach is better than >> libxl_device_nic_list() would be that we don't need to refetch the devid, >> since >> the nics array has it correctly filled already when console callback is >> invoked. >> Whereas libxl_device_nic_list will refetch the same info (in additiona to all >> entries in the backend directory) from xenstore thus adding up overhead. But >> given that this is only once and in domain create I think it's not a big >> deal. > > Right. I think the extra overhead is in the noise relative to the other > activities involved in starting a domain. > >> Would you agree then to resend this series without this patch and using >> libxl_device_nic_list, as the final approach? Thanks for pointing out this >> issue! > > I think so. If you dislike the extra overhead of libxl_device_nic_list, > another > option would be something like a libxlDomainStartCallbackInfo struct that > contains the virDomainObj and libxl_domain_config, and is passed to the start > callback via for_callback of libxl_asyncop_how. That would allow us to use the > libxl_domain_config object in the callback, but still dispose it after the > start > completes. I did a quick measurement to double-check and have a rough idea of the "libxl_device_nic_list" cost. Each line is in the form of VIFs: / 1 VIF : 1066 us / 0.315 s 2 VIF : 1762 us / 0.375 s 4 VIF : 3528 us / 0.560 s 8 VIF : 6726 us / 0.953 s 16 VIF : 13378 us / 1.653 s It almost grows linearly with the number of NICs having ~1ms per NIC. And given the numbers above, I think the extra overhead is indeed small and neglible, so I'll be sending with the libxl_device_nic_list approach as also agreed in your previous comment. Regards, Joao > > Regards, > Jim > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 25/62] acpi/table: Introduce acpi_get_entry to get specified entry
>>> On 17.11.15 at 10:40, wrote:
> --- a/xen/drivers/acpi/tables.c
> +++ b/xen/drivers/acpi/tables.c
> @@ -221,6 +221,51 @@ void __init acpi_table_print_madt_entry(struct
> acpi_subtable_header *header)
> }
> }
>
> +struct acpi_subtable_header * __init
> +acpi_get_entry(char *id, unsigned long table_size,
> +struct acpi_table_header *table_header, int entry_id,
> +unsigned int entry_index)
> +{
> + struct acpi_subtable_header *entry;
> + unsigned int count = 0;
> + unsigned long table_end;
> +
> + if ( !table_size )
Linux coding style please in this file.
> + return NULL;
> +
> + if ( !table_header )
> + {
> + printk("Table header not present\n");
> + return NULL;
> + }
> +
> + table_end = (unsigned long)table_header + table_header->length;
So here you use ->length, ...
> + /* Parse all entries looking for a match. */
> + entry = (struct acpi_subtable_header *)
> + ((unsigned long)table_header + table_size);
... but here table_size. Why?
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2] Add $gho->{Suite} field to guest objects from {prepare, select}guest()
On Mon, 2015-11-23 at 16:48 +, Ian Jackson wrote:
> Ian Campbell writes ("Re: [PATCH OSSTEST v2] Add $gho->{Suite} field to
> guest objects from {prepare,select}guest()"):
> > On Mon, 2015-11-23 at 16:12 +, Ian Jackson wrote:
> > > Perhaps ts-debian*install could call some new function
> > > debian_guest_suite in Debian.pm ?
> >
> > Sure. Should it return the suite (to be put into $gho->{Suite} by the
> > caller) or initialise $gho->{Suite} itself? I lean towards the latter.
>
> It could do both so you can write
> $gsuite = debian_guest_set_suite($gho)
> or whatever ?
Good plan.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 23/62] acpi/table: Introduce acpi_parse_entries
>>> On 17.11.15 at 10:40, wrote:
> From: Parth Dixit
>
> Add new function acpi_parse_entries which takes acpi table as argument.
> This will avoid fetching table everytime in acpi_table_parse_entries.
> This function will be used in acpi_gicv2_init within another patch.
>
> Signed-off-by: Naresh Bhat
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
Please clarify authorship: From and first S-o-b aren't really in line.
> --- a/xen/drivers/acpi/tables.c
> +++ b/xen/drivers/acpi/tables.c
> @@ -221,29 +221,27 @@ void __init acpi_table_print_madt_entry(struct
> acpi_subtable_header *header)
> }
> }
>
> -
> int __init
> -acpi_table_parse_entries(char *id,
> - unsigned long table_size,
> - int entry_id,
> - acpi_table_entry_handler handler,
> - unsigned int max_entries)
> +acpi_parse_entries(char *id,
> + unsigned long table_size,
> + acpi_table_entry_handler handler,
> + struct acpi_table_header *table_header,
> + int entry_id,
> + unsigned int max_entries)
> {
> - struct acpi_table_header *table_header = NULL;
Looks like Linux has gained similar functionality. Can't you simply
pull in one or more Linux commits?
> - if (!handler)
> + if ( !handler )
But in any event please don't change the file's coding style.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2] Add $gho->{Suite} field to guest objects from {prepare, select}guest()
Ian Campbell writes ("Re: [PATCH OSSTEST v2] Add $gho->{Suite} field to guest
objects from {prepare,select}guest()"):
> On Mon, 2015-11-23 at 16:12 +, Ian Jackson wrote:
> > Perhaps ts-debian*install could call some new function
> > debian_guest_suite in Debian.pm ?
>
> Sure. Should it return the suite (to be put into $gho->{Suite} by the
> caller) or initialise $gho->{Suite} itself? I lean towards the latter.
It could do both so you can write
$gsuite = debian_guest_set_suite($gho)
or whatever ?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] Crash in set_cpu_sibling_map() booting Xen 4.6.0 on Fusion
I instrumented detect_extended_topology() and ran again with 4 CPUs. Loading xen-4.6-amd64.gz... ok Loading vmlinuz-3.14.51-grsec-dock... ok Loading initrd.img-3.14.51-grsec-dock... ok (XEN) Xen version 4.6.1-pre (Debian 4.6.1~pre-1skyport1) ( eswi...@skyportsystems.com) (gcc (Debian 4.9.3-4) 4.9.3) debug=y Mon Nov 23 07:18:36 PST 2015 (XEN) Bootloader: SYSLINUX 4.05 20140113 (XEN) Command line: console=com1,vga com1=115200 no-bootscrub dom0_mem=2048M,max:2048M loglvl=all cpuinfo=1 apic_verbosity=debug (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) Disc information: (XEN) Found 1 MBR signatures (XEN) Found 1 EDD information structures (XEN) Xen-e820 RAM map: (XEN) - 0009f800 (usable) (XEN) 0009f800 - 000a (reserved) (XEN) 000dc000 - 0010 (reserved) (XEN) 0010 - bfef (usable) (XEN) bfef - bfeff000 (ACPI data) (XEN) bfeff000 - bff0 (ACPI NVS) (XEN) bff0 - c000 (usable) (XEN) f000 - f800 (reserved) (XEN) fec0 - fec1 (reserved) (XEN) fee0 - fee01000 (reserved) (XEN) fffe - 0001 (reserved) (XEN) 0001 - 0001c000 (usable) (XEN) ACPI: RSDP 000F6A10, 0024 (r2 PTLTD ) (XEN) ACPI: XSDT BFEF030B, 0054 (r1 INTEL 440BX 604 VMW 1324272) (XEN) ACPI: FACP BFEFEE73, 00F4 (r4 INTEL 440BX 604 PTL F4240) (XEN) ACPI: DSDT BFEF05B1, E8C2 (r1 PTLTD Custom604 MSFT 301) (XEN) ACPI: FACS BFEFFFC0, 0040 (XEN) ACPI: BOOT BFEF0589, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) (XEN) ACPI: APIC BFEF050F, 007A (r1 PTLTD APIC604 LTP0) (XEN) ACPI: MCFG BFEF04D3, 003C (r1 PTLTD $PCITBL$ 604 LTP1) (XEN) ACPI: SRAT BFEF03C3, 0110 (r2 VMWARE MEMPLUG 604 VMW 1) (XEN) ACPI: WAET BFEF039B, 0028 (r1 VMWARE VMW WAET 604 VMW 1) (XEN) System RAM: 6143MB (6291004kB) (XEN) SRAT: PXM 0 -> APIC 00 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 02 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 04 -> Node 0 (XEN) SRAT: PXM 0 -> APIC 06 -> Node 0 (XEN) SRAT: Node 0 PXM 0 0-a (XEN) SRAT: Node 0 PXM 0 10-1000 (XEN) SRAT: Node 0 PXM 0 1000-c000 (XEN) SRAT: Node 0 PXM 0 1-1c000 (XEN) NUMA: Allocated memnodemap from 1bd8f8000 - 1bd8fa000 (XEN) NUMA: Using 8 for the hash shift. (XEN) Domain heap initialised (XEN) found SMP MP-table at 000f6a80 (XEN) DMI present. (XEN) APIC boot state is 'xapic' (XEN) Using APIC driver default (XEN) ACPI: PM-Timer IO Port: 0x1008 (XEN) ACPI: SLEEP INFO: pm1x_cnt[1:1004,1:0], pm1x_evt[1:1000,1:0] (XEN) ACPI: wakeup_vec[bfefffcc], vec_size[20] (XEN) ACPI: Local APIC address 0xfee0 (XEN) ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) (XEN) Processor #0 6:6 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x02] enabled) (XEN) Processor #2 6:6 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x02] lapic_id[0x04] enabled) (XEN) Processor #4 6:6 APIC version 21 (XEN) ACPI: LAPIC (acpi_id[0x03] lapic_id[0x06] enabled) (XEN) Processor #6 6:6 APIC version 21 (XEN) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1]) (XEN) ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1]) (XEN) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) (XEN) IOAPIC[0]: apic_id 1, version 17, address 0xfec0, GSI 0-23 (XEN) ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) (XEN) ACPI: IRQ0 used by override. (XEN) ACPI: IRQ2 used by override. (XEN) Enabling APIC mode: Flat. Using 1 I/O APICs (XEN) ERST table was not found (XEN) Using ACPI (MADT) for SMP configuration information (XEN) SMP: Allowing 4 CPUs (0 hotplug CPUs) (XEN) mapped APIC to 82cfffdfb000 (fee0) (XEN) mapped IOAPIC to 82cfffdfa000 (fec0) (XEN) IRQ limits: 24 GSI, 760 MSI/MSI-X (XEN) Not enabling x2APIC: depends on iommu_supports_eim. (XEN) detect_extended_topology cpuid_count op=0xb count=0 eax=0x0 ebx=0x1 ecx=0x100 edx=0x0 (XEN) detect_extended_topology initial_apicid=0 core_plus_mask_width=0 core_level_siblings=1 (XEN) detect_extended_topology cpuid_count op=0xb count=1 eax=0x0 ebx=0x1 ecx=0x201 edx=0x0 (XEN) detect_extended_topology ht_mask_width=0 core_plus_mask_width=0 core_select_mask=0x0 core_level_siblings=1 (XEN) CPU: Physical Processor ID: 0 (XEN) CPU: L1 I cache: 32K, L1 D cache: 32K (XEN) CPU: L2 cache: 256K (XEN) CPU: L3 cache: 6144K (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) CPU0: No MCE banks present. Machine check support disabled (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Initializing CPU#0 (XEN) Detected 2592.632 MHz processor. (XEN) Initing memory sharing. (XEN) alt table 82d0802e7f90 -> 82d0802e9244 (XEN) PCI: MCFG configuration 0: base f000 segment 00
[Xen-devel] [PATCH MINI-OS] Add a .gitignore
Signed-off-by: Ian Campbell --- .gitignore | 6 ++ 1 file changed, 6 insertions(+) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 000..1c655a0 --- /dev/null +++ b/.gitignore @@ -0,0 +1,6 @@ +*~ +*.o +*.a +include/list.h +mini-os +mini-os.gz -- 2.1.4 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH MINI-OS] Add a .gitignore
Ian Campbell, on Mon 23 Nov 2015 16:34:31 +, wrote: > Signed-off-by: Ian Campbell Acked-by: Samuel Thibault > --- > .gitignore | 6 ++ > 1 file changed, 6 insertions(+) > create mode 100644 .gitignore > > diff --git a/.gitignore b/.gitignore > new file mode 100644 > index 000..1c655a0 > --- /dev/null > +++ b/.gitignore > @@ -0,0 +1,6 @@ > +*~ > +*.o > +*.a > +include/list.h > +mini-os > +mini-os.gz > -- > 2.1.4 > -- Samuel c> [ ] morning [ ] afternoon [ ] evening [ ] night , everyone (choose as applicable) ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen 4.5.0 rtds scheduler perform poorly with 2vms
Hi Meng, Thank you very much for replying! The RT tasks I am running for each trial at a certain utilization rate is a collection of real-time tasks, and each real-time task is a sequence of jobs that are released periodically. All jobs are periodic, where each job is defined by a period (and deadline) and a worse-case execution time. Each job is just running of a number of iterations of floating point operations. This is based on the base task.c provided with the LITMUSRT userspace library. So Yes they are independent and not I/O or memory intensive. The period distribution I have for each task is (10ms,100ms) which is bigger than the VM period I specified using xl sched-rtds (1us), but I guess the lower bound is too close to the VM period. So by your suggestion, maybe shorten the period for VM can improve the performance? Thank you! Victor On Mon, Nov 23, 2015 at 8:07 AM, Meng Xu wrote: > Hi Yu-An, > > 2015-11-23 10:42 GMT-05:00 Yu-An(Victor) Chen : > > > > Hi all, > > > > So I was doing some experiments to evaluate RTDS scheduler schedubility > of real time tasks using 1vm with period of 1 and budget of 1. The > experiment results turn out as expected(perform better than xen-credit). > > > Thank you very much for doing this test and trying RTDS scheduler. :-) > > > > > > > But when I tried to perform similar experiments with 2 vms (both with > now period of 1 and budget of 5000). The schedubility of real time > tasks turn out really bad. Even if I have one vm idling and the other vm > running the real time tasks, the schedubility of that vm is still really > poor(worse than xen-credit). > > > RTDS scheduler is not work-conserving, while credit scheduler is. Even > if you keep one VM idling, the real-time VM that you run the RT tasks > will still get 5000 budget in each 1. This is what the budget > replenish policy requires. However, credit scheduler will try to use > all budget (in its best effort) when there is no others running. > > Another factor that may affect the performance is the period of the > VM. The VM period should be smaller than the tasks' period inside. > Keep in mind that in the worst case, the VM may not get resource for > 2*(period - budget) time, when the VM's first VCPU get budget at the > beginning of the first period but get budget at the end of the next > period. > > > > > > Am I missing some configuration I should have set for 2vm cases? Thank > you > > > > my setup is the following: > > Using Xen 4.5.0. > > 2vm sharing core 0-7, with RTDS scheduler, both has period of 1 and > budget of 5000 > > Dom0 using one core from CPU 8-15, with RTDS scheduler, period of 1 > and budget of 1 > > The experiment I am doing is running real time tasks with different > total utilization rate and measure the task success rate in the vm. > > > Which kind of RT tasks are you running inside VM? Are they > independent? Are they involving a lot of I/O or memory? > > Thanks, > > Meng > > > > > -- > > > --- > Meng Xu > PhD Student in Computer and Information Science > University of Pennsylvania > http://www.cis.upenn.edu/~mengxu/ > ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2] Add $gho->{Suite} field to guest objects from {prepare, select}guest()
On Mon, 2015-11-23 at 16:12 +, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v2] Add $gho->{Suite} field to guest
> objects from {prepare,select}guest()"):
> > Currently those places which want this open code a lookup of the
> > {ident}_suite runvar with a fallback to the configuration file.
> >
> > However selecthost was missing such a lookup in the case where it is
> > constructing a nested L1 host (which begins from the selectguest
> > template), which lead to ts-xen-install on Jessie missing the
> > installation of libnl-route-3-200.
> >
> > Fix this by having prepareguest() store a {ident}_suite runvar (taking
> > care to handle the case where one is already set by e.g. make-flight)
> > and have selectguest() initialise $gho->Suite from it.
>
> Having thought about this, ISTM that this will cause strangenesses
> such as runvars called `redhat_suite' with value `jessie' (or
> whatever).
>
> Perhaps ts-debian*install could call some new function
> debian_guest_suite in Debian.pm ?
Sure. Should it return the suite (to be put into $gho->{Suite} by the
caller) or initialise $gho->{Suite} itself? I lean towards the latter.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [OSSTEST PATCH] sg-run-job: Make nested-layer-descend insist on $ok
On Mon, 2015-11-23 at 15:56 +, Ian Jackson wrote: > per-host-ts does nothing if !$ok, so per-host-prep's individual steps > become no-ops if the host prep fails, which prevents blundering on. > But per-host-prep does not throw. > > The other call site explicitly avoids calling the recipe script if > !$ok. nested-layer-descend is for calling from within a recipe, so we > need to throw an exception to abort the script, if !$ok. > > Reported-by: Ian Campbell > Signed-off-by: Ian Jackson Acked-by: Ian Campbell ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH OSSTEST v2] Add $gho->{Suite} field to guest objects from {prepare, select}guest()
Ian Campbell writes ("[PATCH OSSTEST v2] Add $gho->{Suite} field to guest
objects from {prepare,select}guest()"):
> Currently those places which want this open code a lookup of the
> {ident}_suite runvar with a fallback to the configuration file.
>
> However selecthost was missing such a lookup in the case where it is
> constructing a nested L1 host (which begins from the selectguest
> template), which lead to ts-xen-install on Jessie missing the
> installation of libnl-route-3-200.
>
> Fix this by having prepareguest() store a {ident}_suite runvar (taking
> care to handle the case where one is already set by e.g. make-flight)
> and have selectguest() initialise $gho->Suite from it.
Having thought about this, ISTM that this will cause strangenesses
such as runvars called `redhat_suite' with value `jessie' (or
whatever).
Perhaps ts-debian*install could call some new function
debian_guest_suite in Debian.pm ?
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] 9p file system for xen
On Mon, Nov 23, 2015 at 10:51:04AM -0500, Neil Sikka wrote: > Wei, based on our discussions, you will review as much as possible before > leaving for vacation, and have started last Wednesday. Could you please > share what you are reviewing so I (and anyone else interested) can also > assist in reviewing it? > What I meant was "when patches are posted to xen-devel I will try to review as much as possible". There is no patch on xen-devel so I haven't actually reviewed anything, nor can anyone else who is interested in getting it work review anything. What I started last Wednesday was refactoring some QEMU code (only renaming files and making QEMU build), so that QEMU 9pfs doesn't just assume it is using virtio transport. I didn't mean I started review anything. Further discussion should go to xen-devel. There is definitely a need to get input from wider community to better coordinate this work. Wei. > As you said, the front/back end negotiation protocols need to be designed > and agreed upon, and we can start that now in parallel with the code review. > > On Thu, Nov 19, 2015 at 11:23 AM, Linda wrote: > > > Hi Wei, > > > > On 11/19/2015 8:03 AM, Wei Liu wrote: > > > >> On Thu, Nov 19, 2015 at 09:55:00AM -0500, Neil Sikka wrote: > >> > >>> Is there any documentation about planned interfaces and API contracts for > >>> people building around the virtio/9pfs layers? For example, while this is > >>> > >> I assume that you're interested in getting 9pfs to work but don't care > >> much about how it is made to work? I ask because I'm a bit confused by > >> the notion of "virtio/9pfs" because what Linda did wasn't based on > >> virtio transport. > >> > > A clarification: If you mean the virtio 9pfs transport, my code is based > > on that, and sits on top of it. > > > > > >> still getting debugged/checked in, in order to build DomU support for > >>> these > >>> devices, the expected API contracts/interfaces would need to be known. > >>> > >>> I'm not sure I get your question. What do you mean by "build DomU > >> support"? What kind of DomU support needs insider knowledge of how 9pfs > >> is setup? Are you talking about your own management stack that starts > >> VM? > >> > >> Wei. > >> > >> > > > > > -- > My Blog: http://www.neilscomputerblog.blogspot.com/ > Twitter: @neilsikka ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] xen 4.5.0 rtds scheduler perform poorly with 2vms
Hi Yu-An, 2015-11-23 10:42 GMT-05:00 Yu-An(Victor) Chen : > > Hi all, > > So I was doing some experiments to evaluate RTDS scheduler schedubility of > real time tasks using 1vm with period of 1 and budget of 1. The > experiment results turn out as expected(perform better than xen-credit). Thank you very much for doing this test and trying RTDS scheduler. :-) > > > But when I tried to perform similar experiments with 2 vms (both with now > period of 1 and budget of 5000). The schedubility of real time tasks turn > out really bad. Even if I have one vm idling and the other vm running the > real time tasks, the schedubility of that vm is still really poor(worse than > xen-credit). RTDS scheduler is not work-conserving, while credit scheduler is. Even if you keep one VM idling, the real-time VM that you run the RT tasks will still get 5000 budget in each 1. This is what the budget replenish policy requires. However, credit scheduler will try to use all budget (in its best effort) when there is no others running. Another factor that may affect the performance is the period of the VM. The VM period should be smaller than the tasks' period inside. Keep in mind that in the worst case, the VM may not get resource for 2*(period - budget) time, when the VM's first VCPU get budget at the beginning of the first period but get budget at the end of the next period. > > Am I missing some configuration I should have set for 2vm cases? Thank you > > my setup is the following: > Using Xen 4.5.0. > 2vm sharing core 0-7, with RTDS scheduler, both has period of 1 and > budget of 5000 > Dom0 using one core from CPU 8-15, with RTDS scheduler, period of 1 and > budget of 1 > The experiment I am doing is running real time tasks with different total > utilization rate and measure the task success rate in the vm. Which kind of RT tasks are you running inside VM? Are they independent? Are they involving a lot of I/O or memory? Thanks, Meng > > -- --- Meng Xu PhD Student in Computer and Information Science University of Pennsylvania http://www.cis.upenn.edu/~mengxu/ ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [OSSTEST PATCH] sg-run-job: Make nested-layer-descend insist on $ok
per-host-ts does nothing if !$ok, so per-host-prep's individual steps
become no-ops if the host prep fails, which prevents blundering on.
But per-host-prep does not throw.
The other call site explicitly avoids calling the recipe script if
!$ok. nested-layer-descend is for calling from within a recipe, so we
need to throw an exception to abort the script, if !$ok.
Reported-by: Ian Campbell
Signed-off-by: Ian Jackson
---
sg-run-job |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/sg-run-job b/sg-run-job
index a2527ca..d9b2e38 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -260,10 +260,11 @@ proc per-host-ts {iffail ident script args} {
proc nested-layer-descend {nested_hosts} {
# We save need_xen_hosts on a stack in nested_layers_hosts
# It gets popped again during the cleanup part of run-job
-global nested_layers_hosts need_xen_hosts
+global nested_layers_hosts need_xen_hosts ok
lappend nested_layers_hosts $need_xen_hosts
set need_xen_hosts $nested_hosts
per-host-prep
+if {!$ok} { error "host prep ($nested_hosts) (or something else) failed" }
}
#-- test recipes --
--
1.7.10.4
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] 9p file system for xen
Wei, based on our discussions, you will review as much as possible before leaving for vacation, and have started last Wednesday. Could you please share what you are reviewing so I (and anyone else interested) can also assist in reviewing it? As you said, the front/back end negotiation protocols need to be designed and agreed upon, and we can start that now in parallel with the code review. On Thu, Nov 19, 2015 at 11:23 AM, Linda wrote: > Hi Wei, > > On 11/19/2015 8:03 AM, Wei Liu wrote: > >> On Thu, Nov 19, 2015 at 09:55:00AM -0500, Neil Sikka wrote: >> >>> Is there any documentation about planned interfaces and API contracts for >>> people building around the virtio/9pfs layers? For example, while this is >>> >> I assume that you're interested in getting 9pfs to work but don't care >> much about how it is made to work? I ask because I'm a bit confused by >> the notion of "virtio/9pfs" because what Linda did wasn't based on >> virtio transport. >> > A clarification: If you mean the virtio 9pfs transport, my code is based > on that, and sits on top of it. > > >> still getting debugged/checked in, in order to build DomU support for >>> these >>> devices, the expected API contracts/interfaces would need to be known. >>> >>> I'm not sure I get your question. What do you mean by "build DomU >> support"? What kind of DomU support needs insider knowledge of how 9pfs >> is setup? Are you talking about your own management stack that starts >> VM? >> >> Wei. >> >> > -- My Blog: http://www.neilscomputerblog.blogspot.com/ Twitter: @neilsikka ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] x86/HVM: type adjustments
On 11/23/2015 08:51 AM, Jan Beulich wrote:
- constify struct hvm_trap * function parameters
- width reduce and shuffle some struct hvm_trap members
- use bool_t for boolean fields struct hvm_function_table
- use unsigned for struct hvm_function_table's hap_capabilities field
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1181,7 +1181,7 @@ static void svm_vcpu_destroy(struct vcpu
passive_domain_destroy(v);
}
-static void svm_inject_trap(struct hvm_trap *trap)
+static void svm_inject_trap(const struct hvm_trap *trap)
{
struct vcpu *curr = current;
struct vmcb_struct *vmcb = curr->arch.hvm_svm.vmcb;
@@ -1442,7 +1442,7 @@ const struct hvm_function_table * __init
if ( !printed )
printk(" - none\n");
-svm_function_table.hap_supported = cpu_has_svm_npt;
+svm_function_table.hap_supported = !!cpu_has_svm_npt;
Reviewed-by: Boris Ostrovsky
(Should we redefine constant_test_bit/variable_test_bit (which is what
cpu_has_* is) to return bool_t?)
-boris
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [linux-mingo-tip-master test] 64999: regressions - FAIL
flight 64999 linux-mingo-tip-master real [real] http://logs.test-lab.xenproject.org/osstest/logs/64999/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-amd64-xl-pvh-intel 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-amd64-pvgrub 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-rumpuserxen-amd64 6 xen-bootfail REGR. vs. 60684 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-qemuu-rhel6hvm-intel 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemuu-debianhvm-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemut-winxpsp3 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-pvh-amd 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-freebsd10-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-credit2 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemuu-debianhvm-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-i386-pvgrub 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-multivcpu 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qcow2 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-qemut-rhel6hvm-amd 6 xen-bootfail REGR. vs. 60684 test-amd64-i386-freebsd10-i386 6 xen-bootfail REGR. vs. 60684 test-amd64-i386-xl-qemuu-win7-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-pygrub 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-xsm6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemuu-ovmf-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-qemuu-rhel6hvm-amd 6 xen-bootfail REGR. vs. 60684 test-amd64-i386-xl-qemuu-winxpsp3 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-raw6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemut-debianhvm-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemut-winxpsp3 6 xen-bootfail REGR. vs. 60684 test-amd64-i386-xl-qemut-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemuu-win7-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemuu-winxpsp3 6 xen-bootfail REGR. vs. 60684 test-amd64-i386-xl6 xen-boot fail REGR. vs. 60684 test-amd64-i386-rumpuserxen-i386 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-qemut-rhel6hvm-intel 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemut-win7-amd64 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-pair 10 xen-boot/dst_host fail REGR. vs. 60684 test-amd64-i386-pair 9 xen-boot/src_host fail REGR. vs. 60684 test-amd64-amd64-pair10 xen-boot/dst_host fail REGR. vs. 60684 test-amd64-amd64-pair 9 xen-boot/src_host fail REGR. vs. 60684 Regressions which are regarded as allowable (not blocking): test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-libvirt 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-libvirt-vhd 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-libvirt 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-libvirt-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-xl-rtds 6 xen-boot fail REGR. vs. 60684 test-amd64-i386-libvirt-xsm 6 xen-boot fail REGR. vs. 60684 test-amd64-amd64-libvirt-pair 10 xen-boot/dst_hostfail REGR. vs. 60684 test-amd64-amd64-libvirt-pair 9 xen-boot/src_hostfail REGR. vs. 60684 test-amd64-i386-libvirt-pair 10 xen-boot/dst_host fail REGR. vs. 60684 test-amd64-i386-libvirt-pair 9 xen-boot/src_host fail RE
Re: [Xen-devel] [PATCH v3 03/62] acpi/pmstat: Build pmstat for x86 only
>>> On 17.11.15 at 10:40, wrote: > --- a/xen/common/sysctl.c > +++ b/xen/common/sysctl.c > @@ -171,7 +171,7 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) > u_sysctl) > op->u.availheap.avail_bytes <<= PAGE_SHIFT; > break; > > -#ifdef HAS_ACPI > +#ifdef HAS_CPUFREQ You should combine the two instead of replacing one with the other. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] xen 4.5.0 rtds scheduler perform poorly with 2vms
Hi all, So I was doing some experiments to evaluate RTDS scheduler schedubility of real time tasks using 1vm with period of 1 and budget of 1. The experiment results turn out as expected(perform better than xen-credit). But when I tried to perform similar experiments with 2 vms (both with now period of 1 and budget of 5000). The schedubility of real time tasks turn out really bad. Even if I have one vm idling and the other vm running the real time tasks, the schedubility of that vm is still really poor(worse than xen-credit). Am I missing some configuration I should have set for 2vm cases? Thank you my setup is the following: Using Xen 4.5.0. 2vm sharing core 0-7, with RTDS scheduler, both has period of 1 and budget of 5000 Dom0 using one core from CPU 8-15, with RTDS scheduler, period of 1 and budget of 1 The experiment I am doing is running real time tasks with different total utilization rate and measure the task success rate in the vm. Please let me know if you need any more information. Thank you! Victor ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 21/62] arm/gic-v2: Refactor gicv2_init into generic and dt specific parts
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Refactor gic-v2 related functions into dt and generic parts. This will be
> helpful when adding acpi support for gic.
>
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
> ---
> xen/arch/arm/gic-v2.c | 21 ++---
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/xen/arch/arm/gic-v2.c b/xen/arch/arm/gic-v2.c
> index 01e36b5..e31d38e 100644
> --- a/xen/arch/arm/gic-v2.c
> +++ b/xen/arch/arm/gic-v2.c
> @@ -628,13 +628,12 @@ static bool_t gicv2_is_aliased(paddr_t cbase, paddr_t
> csize)
> return ((val_low & 0xfff0fff) == 0x0202043B && val_low == val_high);
> }
>
> -static int __init gicv2_init(void)
> +static paddr_t __initdata hbase, dbase, cbase, csize, vbase;
> +
> +static void __init dt_gicv2_init(void)
> {
> int res;
> -paddr_t hbase, dbase;
> -paddr_t cbase, csize;
> -paddr_t vbase, vsize;
> -uint32_t aliased_offset = 0;
> +paddr_t vsize;
> const struct dt_device_node *node = gicv2_info.node;
>
> res = dt_device_get_address(node, 0, &dbase, NULL);
> @@ -680,6 +679,13 @@ static int __init gicv2_init(void)
> if ( csize != vsize )
> panic("GICv2: Sizes of GICC (%#"PRIpaddr") and GICV (%#"PRIpaddr")
> don't match\n",
> csize, vsize);
> +}
> +
> +static int __init gicv2_init(void)
> +{
> +uint32_t aliased_offset = 0;
> +
> +dt_gicv2_init();
>
> printk("GICv2 initialization:\n"
>"gic_dist_addr=%"PRIpaddr"\n"
> @@ -765,7 +771,8 @@ const static struct gic_hw_operations gicv2_ops = {
> };
>
> /* Set up the GIC */
> -static int __init gicv2_preinit(struct dt_device_node *node, const void
> *data)
> +static int __init dt_gicv2_preinit(struct dt_device_node *node,
> + const void *data)
> {
> gicv2_info.hw_version = GIC_V2;
> gicv2_info.node = node;
> @@ -783,7 +790,7 @@ static const struct dt_device_match gicv2_dt_match[]
> __initconst =
>
> DT_DEVICE_START(gicv2, "GICv2", DEVICE_GIC)
> .dt_match = gicv2_dt_match,
> -.init = gicv2_preinit,
> +.init = dt_gicv2_preinit,
Maybe it would make sense to call this gicv2_dt_preinit for consistency,
nonetheless
Acked-by: Stefano Stabellini
> DT_DEVICE_END
>
> /*
> --
> 2.1.0
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 00/13] Add VMX TSC scaling support
On 11/22/2015 12:54 PM, Haozhong Zhang wrote:
Hi Jan, Boris and Aravind,
(Sorry for sending such a long email and thanks for your patience)
First, thank you very much for doing this.
Because this patchset also touches the existing SVM TSC ratio code, I
tested it on an AMD machine with an AMD A10-7700K CPU (3.4 GHz) that
supports SVM TSC ratio. There are two goals of the test:
(1) Check whether this patchset works well for SVM TSC ratio.
(2) Check whether the existing SVM TSC ratio code works correctly.
* TL;DR
The detailed testing process is boring and long, so I put the
conclusions first.
According to the following test,
(1) this patchset works well for SVM TSC ratio, and
(2) the existing SVM TSC ratio code does not work correctly.
* Preliminary bug fix
Before testing (specially for goal (2)), I have to fix another bug
found in the current svm_get_tsc_offset() (commit e08f383):
static uint64_t svm_get_tsc_offset(uint64_t host_tsc, uint64_t guest_tsc,
uint64_t ratio)
{
uint64_t offset;
if (ratio == DEFAULT_TSC_RATIO)
return guest_tsc - host_tsc;
/* calculate hi,lo parts in 64bits to prevent overflow */
offset = (((host_tsc >> 32U) * (ratio >> 32U)) << 32U) +
~~~
(host_tsc & 0xULL) * (ratio & 0xULL);
~
^^ wrong
return guest_tsc - offset;
}
Looking at the AMD's spec about TSC ratio MSR and where this function is
called, it's expected to calculate
guest_tsc - (host_tsc * ratio) >> 32
but above underlined code is definitely not "(host_tsc * ratio) >> 32",
and above function will return a much larger result than
expected if (guest TSC rate / host TSC rate) > 1. In practice, it
could result the guest TSC jumping to several years later after
migration (which I came across and was confuse by in this test).
Yes, this is obviously wrong.
This bug can be fixed either later by patch 5 which introduces a
common function hvm_scale_tsc() to scale TSC, or by replacing above
underlined code with a simplified and inlined version of
hvm_scale_tsc() as below:
uint64_t mult, frac;
mult= ratio >> 32;
frac= ratio & ((1ULL << 32) - 1);
offset = host_tsc * mult;
offset += (host_tsc >> 32) * frac;
offset += ((host_tsc & ((1ULL << 32) - 1)) * frac) >> 32;
I am not sure I understand the last line (or maybe 2 lines)
If by 'offset' here you are trying to calculate the scaled version of
host TSC then I think it would be
(host_tsc * (ratio >> 32)) + ( (host_tsc * (ratio & 0x)) >> 32 )
(sanity check: assuming host_tsc is 8 and the ratio is 1.5 (i.e.
0x18000) we get 12)
-boris
For testing goal (2), I apply the latter fix.
* Test for goal (1)
* Environment
(1) Xen (commit e08f383)
(2) Host Linux kernel 3.19.0
(3) Guest Linux kernel 3.19.0 & 4.2.0
* Process
(1) Apply the whole patchset on commit e08f383.
(2) Launch a HVM domain from the configuration xl-high.cfg (in
attachment).
Expected: The guest Linux should boot normally in the domain.
(3) Execute the command "dmesg | grep -i tsc" in the guest Linux
to check the TSC rate detected by the guest Linux.
Expected: Suppose the detected TSC rate is 'gtsc_khz' in KHz,
then it should be as close to the value of 'vtsc_khz'
option in xl-high.cfg as possible.
(4) Execute the program "./test_tsc gtsc_khz" to check
whether the guest TSC rate is synchronized with the wall clock.
The code of test_tsc is also in the attachment. It records the
beginning and ending TSC values (tsc0 and tsc1) for a period
of nr_secs and outputs the result of
(tsc1 - tsc0) / (gtsc_khz * 1000).
Expected: The output should be as close to nr_secs as possible.
Follows test the migration.
(5) Save the current domain by "xl save hvm-test saved_domain".
(6) Restore the domain.
(7) Take above step (4) again to check whether the guest TSC rate
is still synchronized with the wall clock.
Expected: the same as step (5)
(8) Switch to the configuration xl-low.cfg and take above
steps (2) ~ (6) again.
* Results (OK: All as expected)
First round w/ xl-high.cfg (vtsc_khz = 400):
(3) gtsc_khz = 400 KHz
(4) ./test_tsc 10 400 outputs: Passed 9.99895 s
./test_tsc 3600 400 outputs: Passed 3599.99754 s
(7) ./test_tsc 10 400 outputs: Passed 9.99885 s
./test_tsc 3600 400 outputs: Passed 3599.98987 s
Second round w/ xl-low.cfg (vtsc_khz = 200):
(3) gtsc_khz = 200 KHz
(4) ./test_tsc 10 400 outputs: Passed 9.99886 s
Re: [Xen-devel] [PATCH 1/3] libxl: add libxl_domain_config to libxlDomainObjPrivate
On 11/20/2015 05:40 PM, Joao Martins wrote: > > On 11/20/2015 07:05 PM, Jim Fehlig wrote: >> On 11/19/2015 04:45 PM, Joao Martins wrote: >> >> You're not going to be happy with me... >> >>> This new field in libxlDomainObjPrivate is named "config" >>> and is kept while the domain is active. >> While this sounded like a good idea when I mentioned it, I'm now worried that >> the config will quickly become stale and cause problems if used elsewhere >> (e.g. >> see my yet-to-be-written comment in 3/3). IIUC correctly, >> libxl_domain_config >> is only useful when creating the domain. Subsequently adding/removing >> devices, >> memory, vcpus, etc. would not be reflected in the libxl_domain_config >> object. I >> suppose it would useful (and still valid) in the start callback, but IMO >> including it in the libxlDomainPrivate struct fools us into believing it >> could >> be used elsewhere throughout the life of the domain. I now have second doubts >> about this. What do you think? > I agree with you, and since there a libxl_device_nic_list as you suggested, it > would actually be much cleaner and safer compared to libxl_domain_config > alternative (though with a small performance cost). And we would avoid end up > having config just lying there with no additional use (besides StartCallback) > and inconsistent info. > > The only thing that the libxlDomainObjPrivate approach is better than > libxl_device_nic_list() would be that we don't need to refetch the devid, > since > the nics array has it correctly filled already when console callback is > invoked. > Whereas libxl_device_nic_list will refetch the same info (in additiona to all > entries in the backend directory) from xenstore thus adding up overhead. But > given that this is only once and in domain create I think it's not a big deal. Right. I think the extra overhead is in the noise relative to the other activities involved in starting a domain. > Would you agree then to resend this series without this patch and using > libxl_device_nic_list, as the final approach? Thanks for pointing out this > issue! I think so. If you dislike the extra overhead of libxl_device_nic_list, another option would be something like a libxlDomainStartCallbackInfo struct that contains the virDomainObj and libxl_domain_config, and is passed to the start callback via for_callback of libxl_asyncop_how. That would allow us to use the libxl_domain_config object in the callback, but still dispose it after the start completes. Regards, Jim ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 20/62] arm/acpi: Add ACPI support for SMP initialization
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> ACPI 5.1 only has two explicit methods to boot up SMP, PSCI and Parking
> protocol, but the Parking protocol is only specified for ARMv7 now, so
> make PSCI as the only way for the SMP boot protocol before some updates
> for the ACPI spec or the Parking protocol spec.
>
> Signed-off-by: Hanjun Guo
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
> ---
> xen/arch/arm/arm64/smpboot.c | 7 ++-
> xen/arch/arm/psci.c | 30 +++---
> xen/arch/arm/smpboot.c | 7 ++-
> 3 files changed, 35 insertions(+), 9 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/smpboot.c b/xen/arch/arm/arm64/smpboot.c
> index 7928f69..93cb6b3 100644
> --- a/xen/arch/arm/arm64/smpboot.c
> +++ b/xen/arch/arm/arm64/smpboot.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
>
> struct smp_enable_ops {
> int (*prepare_cpu)(int);
> @@ -96,7 +97,11 @@ static int __init dt_arch_cpu_init(int cpu, struct
> dt_device_node *dn)
>
> int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
> {
> -return dt_arch_cpu_init(cpu, dn);
> +if( acpi_disabled )
> +return dt_arch_cpu_init(cpu, dn);
> +else
> +/* acpi only supports psci at present */
> +return smp_psci_init(cpu);
> }
>
> int __init arch_cpu_up(int cpu)
> diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
> index d800cb6..dede0e1 100644
> --- a/xen/arch/arm/psci.c
> +++ b/xen/arch/arm/psci.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> /*
> * While a 64-bit OS can make calls with SMC32 calling conventions, for
> @@ -86,6 +87,9 @@ int __init psci_init_0_1(void)
> int ret;
> const struct dt_device_node *psci;
>
> +if ( !acpi_disabled )
> +return -EINVAL;
It might be worth printing an error message here
> psci = dt_find_compatible_node(NULL, NULL, "arm,psci");
> if ( !psci )
> return -EOPNOTSUPP;
> @@ -116,15 +120,24 @@ int __init psci_init_0_2(void)
> { /* sentinel */ },
> };
> int ret;
> -const struct dt_device_node *psci;
>
> -psci = dt_find_matching_node(NULL, psci_ids);
> -if ( !psci )
> -return -EOPNOTSUPP;
> +if( acpi_disabled )
> +{
> +const struct dt_device_node *psci;
>
> -ret = psci_is_smc_method(psci);
> -if ( ret )
> -return -EINVAL;
> +psci = dt_find_matching_node(NULL, psci_ids);
> +if ( !psci )
> +return -EOPNOTSUPP;
> +
> +ret = psci_is_smc_method(psci);
> +if ( ret )
> +return -EINVAL;
> +}
> +else
> +{
> +if ( acpi_psci_hvc_present() )
> +return -EINVAL;
and also here
> +}
>
> psci_ver = call_smc(PSCI_0_2_FN_PSCI_VERSION, 0, 0, 0);
>
> @@ -148,6 +161,9 @@ int __init psci_init(void)
> {
> int ret;
>
> +if( !acpi_disabled && !acpi_psci_present() )
> +return -EOPNOTSUPP;
> +
> ret = psci_init_0_2();
> if ( ret )
> ret = psci_init_0_1();
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index d115228..513f1f6 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> cpumask_t cpu_online_map;
> cpumask_t cpu_present_map;
> @@ -247,7 +248,11 @@ void __init smp_init_cpus(void)
> return;
> }
>
> -dt_smp_init_cpus();
> +if ( acpi_disabled )
> +dt_smp_init_cpus();
> +else
> +acpi_smp_init_cpus();
> +
> }
>
> int __init
> --
> 2.1.0
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] VMX: fix/adjust trap injection
>>> On 23.11.15 at 16:01, wrote:
> On 23/11/15 12:49, Jan Beulich wrote:
>> @@ -1525,6 +1516,16 @@ static void vmx_inject_trap(struct hvm_t
>> __restore_debug_registers(curr);
>> write_debugreg(6, read_debugreg(6) | DR_STEP);
>> }
>> +if ( !nestedhvm_vcpu_in_guestmode(curr) ||
>> + !nvmx_intercepts_exception(curr, TRAP_debug, _trap.error_code)
>> )
>> +{
>> +unsigned long val;
>> +
>> +__vmread(GUEST_DR7, &val);
>> +__vmwrite(GUEST_DR7, val & ~DR_GENERAL_DETECT);
>> +__vmread(GUEST_IA32_DEBUGCTL, &val);
>> +__vmwrite(GUEST_IA32_DEBUGCTL, val & ~IA32_DEBUGCTLMSR_LBR);
>
> Is it worth eliding the __vmwrite's if possible? It will be fewer
> VMexits if this Xen is running nested, and ISTR it will avoid slowing
> down the vmentry with further consistency checks.
I've considered this, but then decided #DB shouldn't really be
raised on any fast paths (or such paths become non-fast anyway
due to the many exceptions). The code certainly is easier to read
without further conditionals.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 19/62] arm/smpboot: Move dt specific code in smp to seperate functions
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Parth Dixit
>
> Partition smp initialization functions into generic and dt specific
> parts, this will be useful when introducing new functions for smp
> initialization based on acpi.
>
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
Acked-by: Stefano Stabellini
> xen/arch/arm/arm64/smpboot.c | 7 ++-
> xen/arch/arm/smpboot.c | 29 ++---
> 2 files changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/xen/arch/arm/arm64/smpboot.c b/xen/arch/arm/arm64/smpboot.c
> index 62e6abb..7928f69 100644
> --- a/xen/arch/arm/arm64/smpboot.c
> +++ b/xen/arch/arm/arm64/smpboot.c
> @@ -70,7 +70,7 @@ int __init arch_smp_init(void)
> return 0;
> }
>
> -int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
> +static int __init dt_arch_cpu_init(int cpu, struct dt_device_node *dn)
> {
> const char *enable_method;
>
> @@ -94,6 +94,11 @@ int __init arch_cpu_init(int cpu, struct dt_device_node
> *dn)
> return 0;
> }
>
> +int __init arch_cpu_init(int cpu, struct dt_device_node *dn)
> +{
> +return dt_arch_cpu_init(cpu, dn);
> +}
> +
> int __init arch_cpu_up(int cpu)
> {
> if ( !smp_enable_ops[cpu].prepare_cpu )
> diff --git a/xen/arch/arm/smpboot.c b/xen/arch/arm/smpboot.c
> index a96cda2..d115228 100644
> --- a/xen/arch/arm/smpboot.c
> +++ b/xen/arch/arm/smpboot.c
> @@ -92,7 +92,7 @@ smp_clear_cpu_maps (void)
> * MPIDR values related to logical cpus
> * Code base on Linux arch/arm/kernel/devtree.c
> */
> -void __init smp_init_cpus(void)
> +static void __init dt_smp_init_cpus(void)
> {
> register_t mpidr;
> struct dt_device_node *cpus = dt_find_node_by_path("/cpus");
> @@ -106,16 +106,6 @@ void __init smp_init_cpus(void)
> bool_t bootcpu_valid = 0;
> int rc;
>
> -/* scan the DTB for a PSCI node and set a global variable */
> -psci_init();
> -
> -if ( (rc = arch_smp_init()) < 0 )
> -{
> -printk(XENLOG_WARNING "SMP init failed (%d)\n"
> - "Using only 1 CPU\n", rc);
> -return;
> -}
> -
> mpidr = boot_cpu_data.mpidr.bits & MPIDR_HWID_MASK;
>
> if ( !cpus )
> @@ -243,6 +233,23 @@ void __init smp_init_cpus(void)
> }
> }
>
> +void __init smp_init_cpus(void)
> +{
> +int rc;
> +
> +/* initialize PSCI and set a global variable */
> +psci_init();
> +
> +if ( (rc = arch_smp_init()) < 0 )
> +{
> +printk(XENLOG_WARNING "SMP init failed (%d)\n"
> + "Using only 1 CPU\n", rc);
> +return;
> +}
> +
> +dt_smp_init_cpus();
> +}
> +
> int __init
> smp_get_max_cpus (void)
> {
> --
> 2.1.0
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 18/62] arm/acpi: Parse MADT to map logical cpu to MPIDR and get cpu_possible_map
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Parth Dixit
>
> MADT contains the information for MPIDR which is essential for SMP
> initialization, parse the GIC cpu interface structures to get the MPIDR
> value and map it to cpu_logical_map(), and add enabled cpu with valid
> MPIDR into cpu_possible_map.
>
> Signed-off-by: Hanjun Guo
> Signed-off-by: Tomasz Nowicki
> Signed-off-by: Naresh Bhat
> Signed-off-by: Parth Dixit
> Signed-off-by: Shannon Zhao
> ---
> xen/arch/arm/acpi/boot.c | 121
> +
> xen/include/asm-arm/acpi.h | 2 +
> xen/include/xen/acpi.h | 4 ++
> 3 files changed, 127 insertions(+)
>
> diff --git a/xen/arch/arm/acpi/boot.c b/xen/arch/arm/acpi/boot.c
> index 0fabe7d..913d2a5 100644
> --- a/xen/arch/arm/acpi/boot.c
> +++ b/xen/arch/arm/acpi/boot.c
> @@ -32,6 +32,127 @@
> #include
>
> #include
> +#include
> +
> +/* Processors with enabled flag and sane MPIDR */
> +static int enabled_cpus;
unsigned int
> +/* Boot CPU is valid or not in MADT */
> +static bool_t __initdata bootcpu_valid;
> +
> +/* total number of cpus in this system */
> +static unsigned int __initdata total_cpus = 0;
no need to explicitly initialize to 0
> +/*
> + * acpi_map_gic_cpu_interface - generates a logical cpu number
> + * and map to MPIDR represented by GICC structure
> + */
> +static void __init
> +acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
> +{
> +int i;
> +u64 mpidr = processor->arm_mpidr & MPIDR_HWID_MASK;
> +bool enabled = !!(processor->flags & ACPI_MADT_ENABLED);
bool_t
> +if (mpidr == MPIDR_INVALID) {
> +printk("Skip MADT cpu entry with invalid MPIDR\n");
> +return;
> +}
I am not sure which coding style we are supposed to follow in this file.
This is the Linux coding style, not the Xen coding style.
> +total_cpus++;
> +if (!enabled)
> +return;
> +
> +if (enabled_cpus >= NR_CPUS) {
unnecessary space
> +printk("NR_CPUS limit of %d reached, Processor %d/0x%"PRIx64"
> ignored.\n",
> + NR_CPUS, total_cpus, mpidr);
> +return;
> +}
> +
> +/* Check if GICC structure of boot CPU is available in the MADT */
> +if (cpu_logical_map(0) == mpidr) {
> +if (bootcpu_valid) {
> +printk("Firmware bug, duplicate CPU MPIDR: 0x%"PRIx64" in
> MADT\n",
> + mpidr);
> +return;
> +}
> +
> +bootcpu_valid = true;
> +}
> +
> +/*
> + * Duplicate MPIDRs are a recipe for disaster. Scan
> + * all initialized entries and check for
> + * duplicates. If any is found just ignore the CPU.
> + */
> +for (i = 1; i < enabled_cpus; i++) {
> +if (cpu_logical_map(i) == mpidr) {
> +printk("Firmware bug, duplicate CPU MPIDR: 0x%"PRIx64" in
> MADT\n",
> + mpidr);
> +return;
> +}
> +}
I would merge this loop with the previous if statement and just add one
cpu_logical_map(0) check to set bootcpu_valid.
> +if (!acpi_psci_present())
> +return;
> +
> +/* CPU 0 was already initialized */
> +if (enabled_cpus) {
> +if (arch_cpu_init(enabled_cpus, NULL) < 0)
> +return;
> +
> +/* map the logical cpu id to cpu MPIDR */
> +cpu_logical_map(enabled_cpus) = mpidr;
> +}
> +
> +enabled_cpus++;
> +}
> +
> +static int __init
> +acpi_parse_gic_cpu_interface(struct acpi_subtable_header *header,
> + const unsigned long end)
> +{
> +struct acpi_madt_generic_interrupt *processor;
> +
> +processor = (struct acpi_madt_generic_interrupt *)header;
struct acpi_madt_generic_interrupt *processor =
container_of(header, struct acpi_madt_generic_interrupt,
header);
> +if (BAD_MADT_ENTRY(processor, end))
> +return -EINVAL;
> +
> +acpi_table_print_madt_entry(header);
> +acpi_map_gic_cpu_interface(processor);
> +return 0;
> +}
> +
> +/* Parse GIC cpu interface entries in MADT for SMP init */
> +void __init acpi_smp_init_cpus(void)
> +{
> +int count, i;
> +
> +/*
> + * do a partial walk of MADT to determine how many CPUs
> + * we have including disabled CPUs, and get information
> + * we need for SMP init
> + */
> +count = acpi_table_parse_madt(ACPI_MADT_TYPE_GENERIC_INTERRUPT,
> +acpi_parse_gic_cpu_interface, 0);
> +
> +if (count <= 0) {
> +printk("Error parsing GIC CPU interface entry\n");
> +return;
> +}
> +
> +if (!bootcpu_valid) {
> +printk("MADT missing boot CPU MPIDR, not enabling secondaries\n");
> +return;
> +}
> +
> +for (i = 0; i < enabled_cpus; i++)
> +cpumask_set_cpu(i, &cpu_possible_map);
> +
> +/* Make boot-up look pretty */
> +printk("%d CPUs enabled, %d CPUs total\n", enabled_cpus, total_cpus);
> +}
>
> static int __init acpi_parse_fadt
Re: [Xen-devel] [PATCH] x86/HVM: type adjustments
On 23/11/15 13:51, Jan Beulich wrote: > - constify struct hvm_trap * function parameters > - width reduce and shuffle some struct hvm_trap members > - use bool_t for boolean fields struct hvm_function_table > - use unsigned for struct hvm_function_table's hap_capabilities field > > Signed-off-by: Jan Beulich Reviewed-by: Andrew Cooper ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] VMX: fix/adjust trap injection
On 23/11/15 12:49, Jan Beulich wrote:
> In the course of investigating the 4.1.6 backport issue of the XSA-156
> patch I realized that #DB injection has always been broken, but with it
> now getting always intercepted the problem has got worse: Documentation
> clearly states that neither DR7.GD nor DebugCtl.LBR get cleared before
> the intercept, so this is something we need to do before reflecting the
> intercepted exception.
>
> While adjusting this (and also with 4.1.6's strange use of
> X86_EVENTTYPE_SW_EXCEPTION for #DB in mind) I further realized that
> the special casing of individual vectors shouldn't be done for
> software interrupts (resulting from INT $nn).
>
> And then some code movement: Setting of CR2 for #PF can be done in the
> same switch() statement (no need for a separate if()), and reading of
> intr_info is better done close the the consumption of the variable
> (allowing the compiler to generate better code / use fewer registers
> for variables).
>
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -1508,16 +1508,7 @@ static void vmx_inject_trap(struct hvm_t
> struct vcpu *curr = current;
> struct hvm_trap _trap = *trap;
>
> -if ( (_trap.vector == TRAP_page_fault) &&
> - (_trap.type == X86_EVENTTYPE_HW_EXCEPTION) )
> -curr->arch.hvm_vcpu.guest_cr[2] = _trap.cr2;
> -
> -if ( nestedhvm_vcpu_in_guestmode(curr) )
> -intr_info = vcpu_2_nvmx(curr).intr.intr_info;
> -else
> -__vmread(VM_ENTRY_INTR_INFO, &intr_info);
> -
> -switch ( _trap.vector )
> +switch ( _trap.vector | -(_trap.type == X86_EVENTTYPE_SW_INTERRUPT) )
> {
> case TRAP_debug:
> if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF )
> @@ -1525,6 +1516,16 @@ static void vmx_inject_trap(struct hvm_t
> __restore_debug_registers(curr);
> write_debugreg(6, read_debugreg(6) | DR_STEP);
> }
> +if ( !nestedhvm_vcpu_in_guestmode(curr) ||
> + !nvmx_intercepts_exception(curr, TRAP_debug, _trap.error_code) )
> +{
> +unsigned long val;
> +
> +__vmread(GUEST_DR7, &val);
> +__vmwrite(GUEST_DR7, val & ~DR_GENERAL_DETECT);
> +__vmread(GUEST_IA32_DEBUGCTL, &val);
> +__vmwrite(GUEST_IA32_DEBUGCTL, val & ~IA32_DEBUGCTLMSR_LBR);
Is it worth eliding the __vmwrite's if possible? It will be fewer
VMexits if this Xen is running nested, and ISTR it will avoid slowing
down the vmentry with further consistency checks.
~Andrew
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 0/6] xen: sched: fix locking of {insert, remove}_vcpu()
>>> On 23.11.15 at 15:50, wrote: > On 23/11/15 14:40, Jan Beulich wrote: > On 23.11.15 at 15:03, wrote: --- Dario Faggioli (6): xen: sched: fix locking of remove_vcpu() in credit1 xen: sched: fix locking for insert_vcpu() in credit1 and RTDS xen: sched: clarify use cases of schedule_cpu_switch() xen: sched: better handle (not) inserting idle vCPUs in runqueues xen: sched: get rid of the per domain vCPU list in RTDS xen: sched: get rid of the per domain vCPU list in Credit2 >>> >>> Committers, >>> >>> It looks to me like this series has all the Acks and Reviews it needs >>> to be checked in, but (as far as I can see) hasn't yet. Can someone >>> double-check and check it in? (See the git tree above if you want to >>> make it easier.) >> >> I've been waiting for an ack on patch 2 (and I've just checked again >> and still can't find any); with this diffstat >> >> xen/common/sched_credit.c |6 ++ >> xen/common/sched_rt.c |3 +++ >> xen/common/schedule.c |6 ++ >> >> Meng's alone isn't sufficient afaict. I've once made an attempt to >> commit later patches in this series, but failed and then didn't want >> to waste time retrying. > > What are the rules again, then? Dario is a scheduler maintainer, and > Meng is an established contributor. I thought that was enough. My understanding is that patches by maintainers need an ack by another maintainer as long as there is one. When there's none, things become more fuzzy. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 17/62] arm/acpi: Print GIC information when MADT is parsed
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Naresh Bhat
>
> When MADT is parsed, print GIC information to make the boot
> log look pretty.
>
> Signed-off-by: Hanjun Guo
> Signed-off-by: Tomasz Nowicki
> Signed-off-by: Naresh Bhat
> Signed-off-by: Shannon Zhao
> ---
> xen/drivers/acpi/tables.c | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/xen/drivers/acpi/tables.c b/xen/drivers/acpi/tables.c
> index 60c4ab1..6573175 100644
> --- a/xen/drivers/acpi/tables.c
> +++ b/xen/drivers/acpi/tables.c
> @@ -189,6 +189,30 @@ void __init acpi_table_print_madt_entry(struct
> acpi_subtable_header *header)
> }
> break;
>
> + case ACPI_MADT_TYPE_GENERIC_INTERRUPT:
> + {
> + struct acpi_madt_generic_interrupt *p =
> + (struct acpi_madt_generic_interrupt *)header;
> + printk(KERN_INFO PREFIX
> +"GICC (acpi_id[0x%04x] address[%llx]
> MPIDR[0x%llx] %s)\n",
> +p->uid, (long long unsigned int)p->base_address,
> +(long long unsigned int)p->arm_mpidr,
> +(p->flags & ACPI_MADT_ENABLED) ? "enabled" :
> "disabled");
PRIx64?
> + }
> + break;
> +
> + case ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR:
> + {
> + struct acpi_madt_generic_distributor *p =
> + (struct acpi_madt_generic_distributor *)header;
> + printk(KERN_INFO PREFIX
> +"GIC Distributor (gic_id[0x%04x] address[%llx]
> gsi_base[%d])\n",
> +p->gic_id, (long long unsigned
> int)p->base_address,
> +p->global_irq_base);
ditto
> + }
> + break;
> +
> default:
> printk(KERN_WARNING PREFIX
> "Found unsupported MADT entry (type = %#x)\n",
> --
> 2.1.0
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 16/62] ACPICA: ACPI 6.0: Add values for MADT GIC version field
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Hanjun Guo
>
> ACPICA commit 4b100dc43e8baee8c8b4891b23bc7ad03eba6a28
>
> Support for the new version field in the generic distributor
> subtable. Hanjun Guo
>
> Link: https://github.com/acpica/acpica/commit/4b100dc4
> Signed-off-by: Hanjun Guo
> Signed-off-by: Bob Moore
> Signed-off-by: Lv Zheng
> Signed-off-by: Rafael J. Wysocki
> [Linux commit a8bd0f07eb594df51845d33f272fb1952fec1a6f]
> Signed-off-by: Shannon Zhao
Acked-by: Stefano Stabellini
> xen/include/acpi/actbl1.h | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
> index 7dd6960..cf31837 100644
> --- a/xen/include/acpi/actbl1.h
> +++ b/xen/include/acpi/actbl1.h
> @@ -804,6 +804,17 @@ struct acpi_madt_generic_distributor {
> u8 reserved2[3]; /* reserved - must be zero */
> };
>
> +/* Values for Version field above */
> +
> +enum acpi_madt_gic_version {
> + ACPI_MADT_GIC_VERSION_NONE = 0,
> + ACPI_MADT_GIC_VERSION_V1 = 1,
> + ACPI_MADT_GIC_VERSION_V2 = 2,
> + ACPI_MADT_GIC_VERSION_V3 = 3,
> + ACPI_MADT_GIC_VERSION_V4 = 4,
> + ACPI_MADT_GIC_VERSION_RESERVED = 5 /* 5 and greater are reserved */
> +};
> +
> /* 13: GIC MSI Frame (ACPI 5.1) */
>
> struct acpi_madt_generic_msi_frame {
> --
> 2.1.0
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 15/62] ACPICA: ACPI 6.0: Add changes for MADT table.
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Bob Moore
>
> ACPICA commit 02cbb41232bccf7a91967140cab95d5f48291f21
>
> New subtable type. Some additions to existing subtables.
>
> Link: https://github.com/acpica/acpica/commit/02cbb412
> Signed-off-by: Bob Moore
> Signed-off-by: Lv Zheng
> Signed-off-by: Rafael J. Wysocki
> [Linux commit 0cff8dc0099f6d4f7431181918b37a472bcd1bbb]
> Signed-off-by: Shannon Zhao
These are the ACPI 6.0 changes. I am OK both with them being folded in
the previous patch or kept separate.
Acked-by: Stefano Stabellini
> xen/include/acpi/actbl1.h | 22 ++
> 1 file changed, 18 insertions(+), 4 deletions(-)
>
> diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
> index 2fb2ad7..7dd6960 100644
> --- a/xen/include/acpi/actbl1.h
> +++ b/xen/include/acpi/actbl1.h
> @@ -643,7 +643,8 @@ enum acpi_madt_type {
> ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
> ACPI_MADT_TYPE_GENERIC_MSI_FRAME = 13,
> ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR = 14,
> - ACPI_MADT_TYPE_RESERVED = 15/* 15 and greater are reserved */
> + ACPI_MADT_TYPE_GENERIC_TRANSLATOR = 15,
> + ACPI_MADT_TYPE_RESERVED = 16/* 16 and greater are reserved */
> };
>
> /*
> @@ -764,7 +765,7 @@ struct acpi_madt_local_x2apic_nmi {
> u8 reserved[3];
> };
>
> -/* 11: Generic Interrupt (ACPI 5.0) */
> +/* 11: Generic Interrupt (ACPI 5.0 + ACPI 6.0 changes) */
>
> struct acpi_madt_generic_interrupt {
> struct acpi_subtable_header header;
> @@ -781,6 +782,8 @@ struct acpi_madt_generic_interrupt {
> u32 vgic_interrupt;
> u64 gicr_base_address;
> u64 arm_mpidr;
> + u8 efficiency_class;
> + u8 reserved2[3];
> };
>
> /* Masks for Flags field above */
> @@ -789,7 +792,7 @@ struct acpi_madt_generic_interrupt {
> #define ACPI_MADT_PERFORMANCE_IRQ_MODE (1<<1) /* 01: Performance Interrupt
> Mode */
> #define ACPI_MADT_VGIC_IRQ_MODE (1<<2) /* 02: VGIC Maintenance
> Interrupt mode */
>
> -/* 12: Generic Distributor (ACPI 5.0) */
> +/* 12: Generic Distributor (ACPI 5.0 + ACPI 6.0 changes) */
>
> struct acpi_madt_generic_distributor {
> struct acpi_subtable_header header;
> @@ -797,7 +800,8 @@ struct acpi_madt_generic_distributor {
> u32 gic_id;
> u64 base_address;
> u32 global_irq_base;
> - u32 reserved2; /* reserved - must be zero */
> + u8 version;
> + u8 reserved2[3]; /* reserved - must be zero */
> };
>
> /* 13: GIC MSI Frame (ACPI 5.1) */
> @@ -825,6 +829,16 @@ struct acpi_madt_generic_redistributor {
> u32 length;
> };
>
> +/* 15: Generic Translator (ACPI 6.0) */
> +
> +struct acpi_madt_generic_translator {
> + struct acpi_subtable_header header;
> + u16 reserved; /* reserved - must be zero */
> + u32 translation_id;
> + u64 base_address;
> + u32 reserved2;
> +};
> +
> /*
> * Common flags fields for MADT subtables
> */
> --
> 2.1.0
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 2/4] x86/PoD: Identify when a domain has already been killed from PoD exhaustion
>>> On 02.11.15 at 15:32, wrote: > On 02/11/15 14:07, George Dunlap wrote: >> On 30/10/15 18:33, Andrew Cooper wrote: >>> --- a/xen/arch/x86/mm/p2m-pod.c >>> +++ b/xen/arch/x86/mm/p2m-pod.c >>> @@ -1048,7 +1048,7 @@ p2m_pod_demand_populate(struct p2m_domain *p2m, >>> unsigned long gfn, >>> /* This check is done with the pod lock held. This will make sure that >>> * even if d->is_dying changes under our feet, p2m_pod_empty_cache() >>> * won't start until we're done. */ >>> -if ( unlikely(d->is_dying) ) >>> +if ( unlikely(d->is_dying) || p2m->pod.dead ) >> So after getting lost in a maze of twisty passages, it looks like >> "d->is_dying" might be the wrong thing to check here. d->is_dying is >> *only* set, AFAICT, in two places: >> - in domain_kill(), which is only called for XEN_DOMCTL_destroydomain >> - in domain_create(), if the creation failed for some reason. > > d->is_dying indicates that the domains resources are starting to be torn > down. It is the correct check here. > >> >> Would it make more sense to check d->is_shutting_down instead? > > A domain resume hypercall can clear d->is_shutting_down, making it an > inappropriate check. > >> >> Having some sort of pod-specific flag seems like the wrong solution. > > All of this patch is the wrong solution, but is necessary until the > generic p2m interface can properly represent errors. George, I still have the patch at the root of this thread in my to be applied queue, but the discussion having abruptly ended here makes it hard for me to tell whether I should keep or drop it. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 0/6] xen: sched: fix locking of {insert, remove}_vcpu()
On 23/11/15 14:40, Jan Beulich wrote: On 23.11.15 at 15:03, wrote: >>> --- >>> Dario Faggioli (6): >>> xen: sched: fix locking of remove_vcpu() in credit1 >>> xen: sched: fix locking for insert_vcpu() in credit1 and RTDS >>> xen: sched: clarify use cases of schedule_cpu_switch() >>> xen: sched: better handle (not) inserting idle vCPUs in runqueues >>> xen: sched: get rid of the per domain vCPU list in RTDS >>> xen: sched: get rid of the per domain vCPU list in Credit2 >> >> Committers, >> >> It looks to me like this series has all the Acks and Reviews it needs >> to be checked in, but (as far as I can see) hasn't yet. Can someone >> double-check and check it in? (See the git tree above if you want to >> make it easier.) > > I've been waiting for an ack on patch 2 (and I've just checked again > and still can't find any); with this diffstat > > xen/common/sched_credit.c |6 ++ > xen/common/sched_rt.c |3 +++ > xen/common/schedule.c |6 ++ > > Meng's alone isn't sufficient afaict. I've once made an attempt to > commit later patches in this series, but failed and then didn't want > to waste time retrying. What are the rules again, then? Dario is a scheduler maintainer, and Meng is an established contributor. I thought that was enough. -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 14/62] arm/acpi: Add Generic Interrupt and Distributor struct
On Tue, 17 Nov 2015, shannon.z...@linaro.org wrote:
> From: Shannon Zhao
>
> Add Generic Interrupt and Distributor (ACPI 5.0) structure.
> Add new features for MADT introduced by ACPI 5.1.
> Comment on the GIC ID field of the GIC structure which is replaced
> by CPU Interface Number.
> Add new fields: Redistributor Base Address, GICV, GICH, and MPIDR.
> Add new structures for GIC MSI frame and GICR.
> Add flag definition for GICC flags.
>
> Signed-off-by: Tomasz Nowicki
> Signed-off-by: Hanjun Guo
> Signed-off-by: Naresh Bhat
> Signed-off-by: Shannon Zhao
Acked-by: Stefano Stabellini
Would it make sense to add the changes for ACPI 6.0 compatibility too?
> xen/include/acpi/actbl1.h | 69
> +--
> 1 file changed, 67 insertions(+), 2 deletions(-)
>
> diff --git a/xen/include/acpi/actbl1.h b/xen/include/acpi/actbl1.h
> index 9311e3a..2fb2ad7 100644
> --- a/xen/include/acpi/actbl1.h
> +++ b/xen/include/acpi/actbl1.h
> @@ -639,7 +639,11 @@ enum acpi_madt_type {
> ACPI_MADT_TYPE_INTERRUPT_SOURCE = 8,
> ACPI_MADT_TYPE_LOCAL_X2APIC = 9,
> ACPI_MADT_TYPE_LOCAL_X2APIC_NMI = 10,
> - ACPI_MADT_TYPE_RESERVED = 11/* 11 and greater are reserved */
> + ACPI_MADT_TYPE_GENERIC_INTERRUPT = 11,
> + ACPI_MADT_TYPE_GENERIC_DISTRIBUTOR = 12,
> + ACPI_MADT_TYPE_GENERIC_MSI_FRAME = 13,
> + ACPI_MADT_TYPE_GENERIC_REDISTRIBUTOR = 14,
> + ACPI_MADT_TYPE_RESERVED = 15/* 15 and greater are reserved */
> };
>
> /*
> @@ -760,11 +764,72 @@ struct acpi_madt_local_x2apic_nmi {
> u8 reserved[3];
> };
>
> +/* 11: Generic Interrupt (ACPI 5.0) */
> +
> +struct acpi_madt_generic_interrupt {
> + struct acpi_subtable_header header;
> + u16 reserved; /* reserved - must be zero */
> + u32 cpu_interface_number;
> + u32 uid;
> + u32 flags;
> + u32 parking_version;
> + u32 performance_interrupt;
> + u64 parked_address;
> + u64 base_address;
> + u64 gicv_base_address;
> + u64 gich_base_address;
> + u32 vgic_interrupt;
> + u64 gicr_base_address;
> + u64 arm_mpidr;
> +};
> +
> +/* Masks for Flags field above */
> +
> +/* ACPI_MADT_ENABLED(1) Processor is usable if set
> */
> +#define ACPI_MADT_PERFORMANCE_IRQ_MODE (1<<1) /* 01: Performance Interrupt
> Mode */
> +#define ACPI_MADT_VGIC_IRQ_MODE (1<<2) /* 02: VGIC Maintenance
> Interrupt mode */
> +
> +/* 12: Generic Distributor (ACPI 5.0) */
> +
> +struct acpi_madt_generic_distributor {
> + struct acpi_subtable_header header;
> + u16 reserved; /* reserved - must be zero */
> + u32 gic_id;
> + u64 base_address;
> + u32 global_irq_base;
> + u32 reserved2; /* reserved - must be zero */
> +};
> +
> +/* 13: GIC MSI Frame (ACPI 5.1) */
> +
> +struct acpi_madt_generic_msi_frame {
> + struct acpi_subtable_header header;
> + u16 reserved; /* reserved - must be zero */
> + u32 msi_frame_id;
> + u64 base_address;
> + u32 flags;
> + u16 spi_count;
> + u16 spi_base;
> +};
> +
> +/* Masks for Flags field above */
> +
> +#define ACPI_MADT_OVERRIDE_SPI_VALUES (1)
> +
> +/* 14: GIC Redistributor (ACPI 5.1) */
> +
> +struct acpi_madt_generic_redistributor {
> + struct acpi_subtable_header header;
> + u16 reserved; /* reserved - must be zero */
> + u64 base_address;
> + u32 length;
> +};
> +
> /*
> * Common flags fields for MADT subtables
> */
>
> -/* MADT Local APIC flags (lapic_flags) */
> +/* MADT Local APIC flags */
>
> #define ACPI_MADT_ENABLED (1) /* 00: Processor is usable if
> set */
>
> --
> 2.1.0
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 0/6] xen: sched: fix locking of {insert, remove}_vcpu()
>>> On 23.11.15 at 15:03, wrote: >> --- >> Dario Faggioli (6): >> xen: sched: fix locking of remove_vcpu() in credit1 >> xen: sched: fix locking for insert_vcpu() in credit1 and RTDS >> xen: sched: clarify use cases of schedule_cpu_switch() >> xen: sched: better handle (not) inserting idle vCPUs in runqueues >> xen: sched: get rid of the per domain vCPU list in RTDS >> xen: sched: get rid of the per domain vCPU list in Credit2 > > Committers, > > It looks to me like this series has all the Acks and Reviews it needs > to be checked in, but (as far as I can see) hasn't yet. Can someone > double-check and check it in? (See the git tree above if you want to > make it easier.) I've been waiting for an ack on patch 2 (and I've just checked again and still can't find any); with this diffstat xen/common/sched_credit.c |6 ++ xen/common/sched_rt.c |3 +++ xen/common/schedule.c |6 ++ Meng's alone isn't sufficient afaict. I've once made an attempt to commit later patches in this series, but failed and then didn't want to waste time retrying. Jan ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] patch for restricted vPMU modes
(+ Dietmar)
On 11/20/2015 07:21 PM, Brendan Gregg wrote:
G'Day,
The vpmu feature of Xen is incredibly useful for performance analysis,
however, it's currently all counters or nothing. In secure
environments, there can be hesitation to enable access to all PMCs
(there are hundreds of them). I've included a prototype patch that
introduces two new restricted vpmu modes:
vpmu=ipc: As the most restricted minimum set. This enables cycles,
reference cycles, and instructions only. This is enough to calculate
instructions per cycle (IPC).
vpm=arch: This enables the 7 pre-defined architectural events as
listed in cpuid, and in Table 18-1 of the Intel software developer's
manual, vol 3B.
There can be a third mode added later on, with a larger set (including
micro-ops PMCs).
These new features would need a corresponding change in Linux for PV
guests (or for dom0 to change feature set globally). But before that
do_xenpmu_op()'s XENPMU_feature_set clause will have to be updated to
deal with new modes.
I've included the short patch below for Xen 4.6.0, which provides
these modes (it also fixes a minor copy-and-paste error with
core2_get_fixed_pmc_count(), which I believe was accessing the wrong
register). I am not a veteran Xen programmer, so please feel free to
edit or rewrite this patch. In case this email messes it up, it's also
on:
https://github.com/brendangregg/Misc/blob/master/xen/xen-4.6.0-vpmu-filter.diff
I've shown testing of four modes (off, on, ipc, arch) here:
https://gist.github.com/brendangregg/b7318c0f49bf906dc8df
For example, here is Linux perf running in a PVHVM guest with the new
vpmu=ipc mode:
root@vm0hvm:~# perf stat -d ./noploop
Performance counter stats for './noploop':
1511.326375 task-clock (msec) #0.999 CPUs utilized
24 context-switches #0.016 K/sec
0 cpu-migrations#0.000 K/sec
113 page-faults #0.075 K/sec
5,028,638,883 cycles#3.327 GHz
0 stalled-cycles-frontend #0.00% frontend
cycles idle
0 stalled-cycles-backend#0.00% backend
cycles idle
20,043,427,933 instructions #3.99 insns per cycle
0 branches #0.000 K/sec
0 branch-misses #0.00% of all branches
0 L1-dcache-loads #0.000 K/sec
0 L1-dcache-load-misses #0.00% of all
L1-dcache hits
0 LLC-loads #0.000 K/sec
LLC-load-misses:HG
Note that IPC is shown ("insns per cycle"), but other counters are not.
---patch---
diff -ur xen-4.6.0-clean/docs/misc/xen-command-line.markdown
xen-4.6.0-brendan/docs/misc/xen-command-line.markdown
--- xen-4.6.0-clean/docs/misc/xen-command-line.markdown2015-10-05
07:33:39.0 -0700
+++ xen-4.6.0-brendan/docs/misc/xen-command-line.markdown2015-11-20
15:29:05.663781176 -0800
@@ -1444,7 +1444,7 @@
flushes on VM entry and exit, increasing performance.
### vpmu
-> `= ( bts )`
+> `= ( | bts | ipc | arch )`
> Default: `off`
@@ -1460,6 +1460,15 @@
If 'vpmu=bts' is specified the virtualisation of the Branch Trace
Store (BTS)
feature is switched on on Intel processors supporting this feature.
+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).
+
+vpmu=arch enables performance monitoring, but restricts the counters
to the
+pre-defined architectural events only. These are exposed by cpuid,
and listed
+in Table 18-1 from the Intel 64 and IA-32 Architectures Software
Developer's
+Manual, Volume 3B, System Programming Guide, Part 2.
+
Note that if **watchdog** option is also specified vpmu will be
turned off.
*Warning:*
diff -ur xen-4.6.0-clean/xen/arch/x86/cpu/vpmu.c
xen-4.6.0-brendan/xen/arch/x86/cpu/vpmu.c
--- xen-4.6.0-clean/xen/arch/x86/cpu/vpmu.c2015-10-05
07:33:39.0 -0700
+++ xen-4.6.0-brendan/xen/arch/x86/cpu/vpmu.c2015-11-20
15:29:50.847781176 -0800
@@ -43,9 +43,11 @@
CHECK_pmu_params;
/*
- * "vpmu" : vpmu generally enabled
- * "vpmu=off" : vpmu generally disabled
- * "vpmu=bts" : vpmu enabled and Intel BTS feature switched on.
+ * "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)
*/
static unsigned int __read_mostly opt_vpmu_enabled;
unsigned int __read_mostly vpmu_mode = XENPMU_MODE_OFF;
@@ -67,6 +69,10 @@
default:
if ( !strcmp(s, "bts") )
vpmu_features |= XENPMU_FEATURE_INTEL_BTS;
+else if ( !strcmp(s, "ipc"
Re: [Xen-devel] [PATCH 2/3] VMX: allocate VMCS pages from domain heap
>>> On 21.10.15 at 05:16, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Tuesday, October 20, 2015 6:36 PM
>> >>> On 20.10.15 at 12:12, wrote:
>> > On 19/10/15 16:22, Jan Beulich wrote:
>> >> @@ -580,7 +583,7 @@ int vmx_cpu_up_prepare(unsigned int cpu)
>> >> void vmx_cpu_dead(unsigned int cpu)
>> >> {
>> >> vmx_free_vmcs(per_cpu(vmxon_region, cpu));
>> >> -per_cpu(vmxon_region, cpu) = NULL;
>> >> +per_cpu(vmxon_region, cpu) = 0;
>> >
>> > While this is currently safe (as pa 0 is not part of the available heap
>> > allocation range), might it be worth introducing a named sentential? I
>> > can forsee a DMLite nested Xen scenario where we definitely don't need
>> > to treat the low 1MB magically.
>>
>> I guess there are more things to adjust if we ever cared to recover
>> the few hundred kb below 1Mb. And then I don't see why nested
>> Xen would matter here: One major main reason for reserving that
>> space is that we want to put the trampoline there. Do you think
>> DMlite would allow us to get away without? But even if so, this
>> would again fall under what I've said in the first sentence.
>
> Could you at least introduce a macro first? Regardless of how much
> things to adjust, this way makes future change simple.
So I've made an attempt, but this is really getting unwieldy: Setting
per-CPU data to non-zero initial values is not possible; making sure
cleanup code avoids assuming such variables got initialized is quite
error prone. Same goes at least to a certain extent for struct vcpu
members (see e.g. nvmx_vcpu_destroy(), which currently is
correct no matter whether nvmx_vcpu_initialise() ran at all, or to
completion).
I also don't see what a macro would help here, or how/where it
should be used. paddr_valid()? Yes, I could do this, but it wouldn't
simplify much when later wanting to convert to a non-zero value
for above reasons (it would instead give the wrong impression that
changing the value is all it takes).
Jan
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 0/6] xen: sched: fix locking of {insert, remove}_vcpu()
On Wed, Nov 4, 2015 at 5:17 PM, Dario Faggioli wrote: > Hi, > > This series, improves how inserting vCPUs in schedulers runqueues is done, > including fixing a couple of bugs, and paving the way for more improvement in > Credit2 runqueue handling (will be submitted as a separate series). > > v3 is here: > http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg03278.html > Message-Id: <20151029225158.25219.4625.stgit@Solace.station> > > Only patch 1 really changed from v3, and patches 1 and 2 are the only one that > seem to me to be missing suitable Ack-s. > > There is a git branch for this series here: > git://xenbits.xen.org/people/dariof/xen.git rel/sched/fix-vcpu-ins-rem-v4 > > Regards, > Dario > --- > Dario Faggioli (6): > xen: sched: fix locking of remove_vcpu() in credit1 > xen: sched: fix locking for insert_vcpu() in credit1 and RTDS > xen: sched: clarify use cases of schedule_cpu_switch() > xen: sched: better handle (not) inserting idle vCPUs in runqueues > xen: sched: get rid of the per domain vCPU list in RTDS > xen: sched: get rid of the per domain vCPU list in Credit2 Committers, It looks to me like this series has all the Acks and Reviews it needs to be checked in, but (as far as I can see) hasn't yet. Can someone double-check and check it in? (See the git tree above if you want to make it easier.) Thanks, -George ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] x86/HVM: type adjustments
- constify struct hvm_trap * function parameters
- width reduce and shuffle some struct hvm_trap members
- use bool_t for boolean fields struct hvm_function_table
- use unsigned for struct hvm_function_table's hap_capabilities field
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -2826,7 +2826,7 @@ void hvm_triple_fault(void)
domain_shutdown(d, reason);
}
-void hvm_inject_trap(struct hvm_trap *trap)
+void hvm_inject_trap(const struct hvm_trap *trap)
{
struct vcpu *curr = current;
--- a/xen/arch/x86/hvm/svm/nestedsvm.c
+++ b/xen/arch/x86/hvm/svm/nestedsvm.c
@@ -821,7 +821,7 @@ nsvm_vcpu_vmexit_inject(struct vcpu *v,
}
int
-nsvm_vcpu_vmexit_trap(struct vcpu *v, struct hvm_trap *trap)
+nsvm_vcpu_vmexit_trap(struct vcpu *v, const struct hvm_trap *trap)
{
ASSERT(vcpu_nestedhvm(v).nv_vvmcx != NULL);
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -1181,7 +1181,7 @@ static void svm_vcpu_destroy(struct vcpu
passive_domain_destroy(v);
}
-static void svm_inject_trap(struct hvm_trap *trap)
+static void svm_inject_trap(const struct hvm_trap *trap)
{
struct vcpu *curr = current;
struct vmcb_struct *vmcb = curr->arch.hvm_svm.vmcb;
@@ -1442,7 +1442,7 @@ const struct hvm_function_table * __init
if ( !printed )
printk(" - none\n");
-svm_function_table.hap_supported = cpu_has_svm_npt;
+svm_function_table.hap_supported = !!cpu_has_svm_npt;
svm_function_table.hap_capabilities = HVM_HAP_SUPERPAGE_2MB |
((cpuid_edx(0x8001) & 0x0400) ? HVM_HAP_SUPERPAGE_1GB : 0);
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1416,7 +1416,7 @@ void nvmx_enqueue_n2_exceptions(struct v
nvmx->intr.intr_info, nvmx->intr.error_code);
}
-static int nvmx_vmexit_trap(struct vcpu *v, struct hvm_trap *trap)
+static int nvmx_vmexit_trap(struct vcpu *v, const struct hvm_trap *trap)
{
nvmx_enqueue_n2_exceptions(v, trap->vector, trap->error_code,
hvm_intsrc_none);
@@ -1502,7 +1502,7 @@ void vmx_inject_nmi(void)
* - #DB is X86_EVENTTYPE_HW_EXCEPTION, except when generated by
*opcode 0xf1 (which is X86_EVENTTYPE_PRI_SW_EXCEPTION)
*/
-static void vmx_inject_trap(struct hvm_trap *trap)
+static void vmx_inject_trap(const struct hvm_trap *trap)
{
unsigned long intr_info;
struct vcpu *curr = current;
--- a/xen/include/asm-x86/hvm/hvm.h
+++ b/xen/include/asm-x86/hvm/hvm.h
@@ -72,10 +72,10 @@ enum hvm_intblk {
#define HVM_HAP_SUPERPAGE_1GB 0x0002
struct hvm_trap {
-int vector;
-unsigned int type; /* X86_EVENTTYPE_* */
-int error_code; /* HVM_DELIVER_NO_ERROR_CODE if n/a */
-int insn_len; /* Instruction length */
+int16_t vector;
+uint8_t type; /* X86_EVENTTYPE_* */
+uint8_t insn_len; /* Instruction length */
+uint32_t error_code; /* HVM_DELIVER_NO_ERROR_CODE if n/a */
unsigned long cr2; /* Only for TRAP_page_fault h/w exception */
};
@@ -88,17 +88,16 @@ struct hvm_function_table {
char *name;
/* Support Hardware-Assisted Paging? */
-int hap_supported;
+bool_t hap_supported;
/* Necessary hardware support for PVH mode? */
-int pvh_supported;
+bool_t pvh_supported;
/* Necessary hardware support for alternate p2m's? */
bool_t altp2m_supported;
/* Indicate HAP capabilities. */
-int hap_capabilities;
-
+unsigned int hap_capabilities;
/*
* Initialise/destroy HVM domain/vcpu resources
@@ -142,7 +141,7 @@ struct hvm_function_table {
void (*set_tsc_offset)(struct vcpu *v, u64 offset, u64 at_tsc);
-void (*inject_trap)(struct hvm_trap *trap);
+void (*inject_trap)(const struct hvm_trap *trap);
void (*init_hypercall_page)(struct domain *d, void *hypercall_page);
@@ -175,7 +174,7 @@ struct hvm_function_table {
int (*nhvm_vcpu_initialise)(struct vcpu *v);
void (*nhvm_vcpu_destroy)(struct vcpu *v);
int (*nhvm_vcpu_reset)(struct vcpu *v);
-int (*nhvm_vcpu_vmexit_trap)(struct vcpu *v, struct hvm_trap *trap);
+int (*nhvm_vcpu_vmexit_trap)(struct vcpu *v, const struct hvm_trap *trap);
uint64_t (*nhvm_vcpu_p2m_base)(struct vcpu *v);
bool_t (*nhvm_vmcx_guest_intercepts_trap)(struct vcpu *v,
unsigned int trapnr,
@@ -371,7 +370,7 @@ bool_t hvm_io_pending(struct vcpu *v);
void hvm_do_resume(struct vcpu *v);
void hvm_migrate_pirqs(struct vcpu *v);
-void hvm_inject_trap(struct hvm_trap *trap);
+void hvm_inject_trap(const struct hvm_trap *trap);
void hvm_inject_hw_exception(unsigned int trapnr, int errcode);
void hvm_inject_page_fault(int errcode, unsigned long cr2);
@@ -495,7 +494,8 @@ int hvm_x2apic_msr_write(struct vcpu *v,
/* inject vmexit into l1 guest. l1 guest will see a VMEXIT due to
* 'trapnr' exceptio
Re: [Xen-devel] [PATCH XEN v5 19/23] tools/libs/call: Update some log messages to not refer to xc.
On Fri, 2015-11-13 at 16:20 +, Andrew Cooper wrote:
> On 09/11/15 12:00, Ian Campbell wrote:
> > Signed-off-by: Ian Campbell
> > Acked-by: Wei Liu
>
> I agree with the sentiment, but the error message refer to the
> libxencall entry API, so a developer can match it back to the call in
> their code.
The PERROR will prepend "xencall" onto the message.
This osdep_alloc_pages can be called from either xencall_alloc_buffer_pages
or xencall_alloc_buffer, so I don't think it is possible to make them more
specific than that "xencall: alloc_pages". (The old message was similarly
misleading in that regard)
Ian.
>
> ~Andrew
>
> > ---
> > tools/libs/call/linux.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/tools/libs/call/linux.c b/tools/libs/call/linux.c
> > index 906ca7e..80b505c 100644
> > --- a/tools/libs/call/linux.c
> > +++ b/tools/libs/call/linux.c
> > @@ -88,7 +88,7 @@ void *osdep_alloc_pages(xencall_handle *xcall,
> > unsigned int npages)
> > p = mmap(NULL, size, PROT_READ|PROT_WRITE,
> > MAP_PRIVATE|MAP_ANONYMOUS|MAP_LOCKED, -1, 0);
> > if ( p == MAP_FAILED )
> > {
> > -PERROR("xc_alloc_hypercall_buffer: mmap failed");
> > +PERROR("alloc_pages: mmap failed");
> > return NULL;
> > }
> >
> > @@ -97,7 +97,7 @@ void *osdep_alloc_pages(xencall_handle *xcall,
> > unsigned int npages)
> > rc = madvise(p, npages * PAGE_SIZE, MADV_DONTFORK);
> > if ( rc < 0 )
> > {
> > -PERROR("xc_alloc_hypercall_buffer: madvise failed");
> > +PERROR("alloc_pages: madvise failed");
> > goto out;
> > }
> >
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [Minios-devel] [PATCH v4 0/] Begin to disentangle libxenctrl and provide some stable libraries
On Fri, 2015-11-20 at 13:49 +, Stefano Stabellini wrote: > > > If we were to just say "xc_domain_add_to_physmap and > > xc_domain_pin_memory_cacheattr are now stable" then having them in a > > libxendevicemodel would be incorrect, since they are not in any way > > specific to device models. > > > > > > > Keep > > > in mind that we already have stable wrappers in QEMU in > > > include/hw/xen/xen_common.h. I don't think we need two layers of > > > wrappers :-) > > > > Indeed, but part of the purpose of Xen providing stable libraries is > > that > > external components/users should not need wrappers. > > > > IOW IMHO the current wrappers in QEMU should, as part of this exercise > > in > > providing stable interfaces, be deprecated and remain only to retain > > compatibility with older versions of Xen which lacked the stable > > interfaces, with a view to them eventually being removed as support for > > those older Xen's is removed from QEMU. > > I agree that it would be nicer to have the wrapper in Xen, but > realistically we won't be able to get rid of the ones in QEMU anytime > soon. It's certainly a long term thing, but in the meantime it does mean that the QEMU wrappers should never need to be touched again until their removal. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] VMX: fix/adjust trap injection
In the course of investigating the 4.1.6 backport issue of the XSA-156
patch I realized that #DB injection has always been broken, but with it
now getting always intercepted the problem has got worse: Documentation
clearly states that neither DR7.GD nor DebugCtl.LBR get cleared before
the intercept, so this is something we need to do before reflecting the
intercepted exception.
While adjusting this (and also with 4.1.6's strange use of
X86_EVENTTYPE_SW_EXCEPTION for #DB in mind) I further realized that
the special casing of individual vectors shouldn't be done for
software interrupts (resulting from INT $nn).
And then some code movement: Setting of CR2 for #PF can be done in the
same switch() statement (no need for a separate if()), and reading of
intr_info is better done close the the consumption of the variable
(allowing the compiler to generate better code / use fewer registers
for variables).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1508,16 +1508,7 @@ static void vmx_inject_trap(struct hvm_t
struct vcpu *curr = current;
struct hvm_trap _trap = *trap;
-if ( (_trap.vector == TRAP_page_fault) &&
- (_trap.type == X86_EVENTTYPE_HW_EXCEPTION) )
-curr->arch.hvm_vcpu.guest_cr[2] = _trap.cr2;
-
-if ( nestedhvm_vcpu_in_guestmode(curr) )
-intr_info = vcpu_2_nvmx(curr).intr.intr_info;
-else
-__vmread(VM_ENTRY_INTR_INFO, &intr_info);
-
-switch ( _trap.vector )
+switch ( _trap.vector | -(_trap.type == X86_EVENTTYPE_SW_INTERRUPT) )
{
case TRAP_debug:
if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF )
@@ -1525,6 +1516,16 @@ static void vmx_inject_trap(struct hvm_t
__restore_debug_registers(curr);
write_debugreg(6, read_debugreg(6) | DR_STEP);
}
+if ( !nestedhvm_vcpu_in_guestmode(curr) ||
+ !nvmx_intercepts_exception(curr, TRAP_debug, _trap.error_code) )
+{
+unsigned long val;
+
+__vmread(GUEST_DR7, &val);
+__vmwrite(GUEST_DR7, val & ~DR_GENERAL_DETECT);
+__vmread(GUEST_IA32_DEBUGCTL, &val);
+__vmwrite(GUEST_IA32_DEBUGCTL, val & ~IA32_DEBUGCTLMSR_LBR);
+}
if ( cpu_has_monitor_trap_flag )
break;
/* fall through */
@@ -1535,8 +1536,19 @@ static void vmx_inject_trap(struct hvm_t
domain_pause_for_debugger();
return;
}
+break;
+
+case TRAP_page_fault:
+ASSERT(_trap.type == X86_EVENTTYPE_HW_EXCEPTION);
+curr->arch.hvm_vcpu.guest_cr[2] = _trap.cr2;
+break;
}
+if ( nestedhvm_vcpu_in_guestmode(curr) )
+intr_info = vcpu_2_nvmx(curr).intr.intr_info;
+else
+__vmread(VM_ENTRY_INTR_INFO, &intr_info);
+
if ( unlikely(intr_info & INTR_INFO_VALID_MASK) &&
(MASK_EXTR(intr_info, INTR_INFO_INTR_TYPE_MASK) ==
X86_EVENTTYPE_HW_EXCEPTION) )
VMX: fix/adjust trap injection
In the course of investigating the 4.1.6 backport issue of the XSA-156
patch I realized that #DB injection has always been broken, but with it
now getting always intercepted the problem has got worse: Documentation
clearly states that neither DR7.GD nor DebugCtl.LBR get cleared before
the intercept, so this is something we need to do before reflecting the
intercepted exception.
While adjusting this (and also with 4.1.6's strange use of
X86_EVENTTYPE_SW_EXCEPTION for #DB in mind) I further realized that
the special casing of individual vectors shouldn't be done for
software interrupts (resulting from INT $nn).
And then some code movement: Setting of CR2 for #PF can be done in the
same switch() statement (no need for a separate if()), and reading of
intr_info is better done close the the consumption of the variable
(allowing the compiler to generate better code / use fewer registers
for variables).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -1508,16 +1508,7 @@ static void vmx_inject_trap(struct hvm_t
struct vcpu *curr = current;
struct hvm_trap _trap = *trap;
-if ( (_trap.vector == TRAP_page_fault) &&
- (_trap.type == X86_EVENTTYPE_HW_EXCEPTION) )
-curr->arch.hvm_vcpu.guest_cr[2] = _trap.cr2;
-
-if ( nestedhvm_vcpu_in_guestmode(curr) )
-intr_info = vcpu_2_nvmx(curr).intr.intr_info;
-else
-__vmread(VM_ENTRY_INTR_INFO, &intr_info);
-
-switch ( _trap.vector )
+switch ( _trap.vector | -(_trap.type == X86_EVENTTYPE_SW_INTERRUPT) )
{
case TRAP_debug:
if ( guest_cpu_user_regs()->eflags & X86_EFLAGS_TF )
@@ -1525,6 +1516,16 @@ static void vmx_inject_trap(struct hvm_t
__restore_debug_registers(curr);
write_debugreg(6, read_debugreg(6) | DR_STEP);
}
+if ( !nestedhvm_vcpu_in_guestmode(curr) ||
+ !nvmx_intercepts_exception(curr, TRAP_debug, _trap.error_code) )
+
