Re: [Xen-devel] [PATCH v4] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

[Tian, Kevin]

> From: Gao, Chao
> Sent: Wednesday, July 5, 2017 12:28 PM
> 
> On Wed, Jul 05, 2017 at 10:46:39AM +0800, Tian, Kevin wrote:
> >> From: Gao, Chao
> >> Sent: Monday, July 3, 2017 12:37 PM
> >>
> >> On Fri, Jun 30, 2017 at 05:19:52PM +0800, Tian, Kevin wrote:
> >> >> From: Gao, Chao
> >> >> Sent: Friday, June 30, 2017 9:17 AM
> >> >>
> >> >> The problem is for a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
> >> >> we would wrongly use 00:00.0 to search VT-d unit.
> >> >>
> >> >> From SRIOV spec REV 1.0 section 3.7.3, it says:
> >> >> "ARI is not applicable to Root Complex integrated Endpoints; all other
> >> >> SR-IOV Capable Devices (Devices that include at least one PF) shall
> >> >> implement the ARI Capability in each Function.". So PFs can be
> classified
> >> to
> >> >> two kinds: one is RC integrated PF and the other is non-RC integrated
> PF.
> >> The
> >> >> former can't support ARI and the latter shall support ARI. For Extended
> >> >> Functions, one traditional function's BDF should be used to search VT-d
> >> unit.
> >> >> And according to PCIe spec, Extened Function means within an ARI
> device,
> >> a
> >> >> Function whose Function Number is greater than 7. Thus, the former
> can't
> >> be
> >> >> an
> >> >> extended function, while the latter is as long as its devfn > 7, this 
> >> >> check
> is
> >> >> exactly what the original code did; The original code wasn't aware the
> >> former.
> >> >>
> >> >> This patch directly looks up the 'is_extfn' field of PF's struct pci_dev
> >> >> to decide whether the PF is a extended function.
> >> >
> >> >Above description looks like the bug is caused by ARI problem. But
> >> >if you look at the original code (and the problem you described), it's
> >> >not related to ARI. ARI comes just when adding a clean fix, so please
> >> >revise the description to make that part clear
> >> >
> >>
> >> How about this:
> >>
> >> The problem is for a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
> >> we would wrongly use 00:00.0 to search VT-d unit.
> >>
> >> If a PF is an extended function, a traditional function's BDF should be
> >> used to search VT-d unit. Previous code only checks whether Function
> >> Number is greater than 7, without checking the prerequisite that the
> >
> >where did above check come from in original code?
> >
> >-devfn = PCI_SLOT(pdev->info.physfn.devfn) ? 0 : pdev-
> >info.physfn.devfn;
> >
> 
> Yes. It is the check I described. This line assigns 0 to 'devfn' if PF's
> function number > 7. Otherwise, use PF's real devfn.
> 

sorry I overlooked PCI_SLOT. However your description is still about
the wrong behavior if PF is an extended function. You didn't explain
it's also wrong even when PF is not an extended function.

Thanks
Kevin

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

[Xen-devel] make tools error

[Chen, Farrah]

Hi,


When I compile xen with commit a7d802bca13489d303749177127089af48844f29, it 
failed when make tools.

"ERROR 404: Not Found" showed when wget 
http://xenbits.xen.org/xen-extfiles/ipxe-git-356f6c1b64d7a97746d1816cef8ca22bdd8d0b5d.tar.gz
Then I checked above URL, the following error occurred:
Not Found
The requested URL 
/xen-extfiles/ipxe-git-356f6c1b64d7a97746d1816cef8ca22bdd8d0b5d.tar.gz was not 
found on this server.

Apache/2.4.10 (Debian) Server at xenbits.xen.org Port 80


Best Regards,
Fan Chen

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

Re: [Xen-devel] [PATCH v4] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

[Chao Gao]

On Wed, Jul 05, 2017 at 10:46:39AM +0800, Tian, Kevin wrote:
>> From: Gao, Chao
>> Sent: Monday, July 3, 2017 12:37 PM
>> 
>> On Fri, Jun 30, 2017 at 05:19:52PM +0800, Tian, Kevin wrote:
>> >> From: Gao, Chao
>> >> Sent: Friday, June 30, 2017 9:17 AM
>> >>
>> >> The problem is for a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
>> >> we would wrongly use 00:00.0 to search VT-d unit.
>> >>
>> >> From SRIOV spec REV 1.0 section 3.7.3, it says:
>> >> "ARI is not applicable to Root Complex integrated Endpoints; all other
>> >> SR-IOV Capable Devices (Devices that include at least one PF) shall
>> >> implement the ARI Capability in each Function.". So PFs can be classified
>> to
>> >> two kinds: one is RC integrated PF and the other is non-RC integrated PF.
>> The
>> >> former can't support ARI and the latter shall support ARI. For Extended
>> >> Functions, one traditional function's BDF should be used to search VT-d
>> unit.
>> >> And according to PCIe spec, Extened Function means within an ARI device,
>> a
>> >> Function whose Function Number is greater than 7. Thus, the former can't
>> be
>> >> an
>> >> extended function, while the latter is as long as its devfn > 7, this 
>> >> check is
>> >> exactly what the original code did; The original code wasn't aware the
>> former.
>> >>
>> >> This patch directly looks up the 'is_extfn' field of PF's struct pci_dev
>> >> to decide whether the PF is a extended function.
>> >
>> >Above description looks like the bug is caused by ARI problem. But
>> >if you look at the original code (and the problem you described), it's
>> >not related to ARI. ARI comes just when adding a clean fix, so please
>> >revise the description to make that part clear
>> >
>> 
>> How about this:
>> 
>> The problem is for a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
>> we would wrongly use 00:00.0 to search VT-d unit.
>> 
>> If a PF is an extended function, a traditional function's BDF should be
>> used to search VT-d unit. Previous code only checks whether Function
>> Number is greater than 7, without checking the prerequisite that the
>
>where did above check come from in original code? 
>
>-devfn = PCI_SLOT(pdev->info.physfn.devfn) ? 0 : 
>pdev->info.physfn.devfn;
>

Yes. It is the check I described. This line assigns 0 to 'devfn' if PF's
function number > 7. Otherwise, use PF's real devfn.

Thanks
Chao

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

Re: [Xen-devel] [PATCH v1 3/6] vmx: refactor vmx_init_vmcs_config()

[Tian, Kevin]

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Monday, June 26, 2017 6:45 PM
> 
> 1. Remove RDMSRs of VMX MSRs since all values are already available in
>raw_vmx_msr_policy.
> 2. Replace bit operations involving VMX bitmasks with accessing VMX
>features by name and using vmx_msr_available() where appropriate.
> 
> Signed-off-by: Sergey Dyasli 
> ---
>  xen/arch/x86/hvm/vmx/vmcs.c | 56 +---
> -
>  1 file changed, 26 insertions(+), 30 deletions(-)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index 00fbc0ccb8..dbf6eb7433 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -227,7 +227,8 @@ static u32 adjust_vmx_controls(
>  {
>  u32 vmx_msr_low, vmx_msr_high, ctl = ctl_min | ctl_opt;
> 
> -rdmsr(msr, vmx_msr_low, vmx_msr_high);
> +vmx_msr_low = raw_vmx_msr_policy.msr[msr - MSR_IA32_VMX_BASIC];
> +vmx_msr_high = raw_vmx_msr_policy.msr[msr -
> MSR_IA32_VMX_BASIC] >> 32;

also need check vmx_msr_available() here?

Thanks
Kevin

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

Re: [Xen-devel] [PATCH 5/25] Xen/doc: Add Xen virtual IOMMU doc

[Lan Tianyu]

Hi Julien:
Thanks for your review.

On 2017年07月04日 18:39, Julien Grall wrote:
>> +vIOMMU hypercall
>> +
>> +Introduce new domctl hypercall "xen_domctl_viommu_op" to create/destroy
>> +vIOMMU and query vIOMMU capabilities that device model can support.
>> +
>> +* vIOMMU hypercall parameter structure
>> +struct xen_domctl_viommu_op {
>> +uint32_t cmd;
>> +#define XEN_DOMCTL_create_viommu  0
>> +#define XEN_DOMCTL_destroy_viommu 1
>> +#define XEN_DOMCTL_query_viommu_caps  2
> 
> I am a bit confused. This is only creating the vIOMMU. However, there
> might be multiple host IOMMUs, how do you link them together?
> 
>> +union {
>> +struct {
>> +/* IN - vIOMMU type */
>> +uint64_t viommu_type;
> 
> This is a bit confusing, you don't define what should be the value of
> viommu_type, ...
> 
>> +/* IN - MMIO base address of vIOMMU. */
>> +uint64_t base_address;
>> +/* IN - Length of MMIO region */
>> +uint64_t length; > +/* IN - Capabilities with
>> which we want to create */
>> +uint64_t capabilities;
> 
> ... capabilities ...
> 

Sorry. miss the type and capability definition here.

/* VIOMMU type */
#define VIOMMU_TYPE_INTEL_VTD (1u << 0)

/* VIOMMU capabilities*/
#define VIOMMU_CAP_IRQ_REMAPPING  (1u << 0)

"viommu_type" means vendor vIOMMU device model. So far, we just support
virtual Intel VTD.

"capabilities" means the feature that vIOMMU supports. We just add
interrupt remapping for virtual VTD.


>> +/* OUT - vIOMMU identity */
>> +uint32_t viommu_id;
>> +} create_viommu; > +
>> +struct {
>> +/* IN - vIOMMU identity */
>> +uint32_t viommu_id;
>> +} destroy_viommu;
>> +
>> +struct {
>> +/* IN - vIOMMU type */
>> +uint64_t viommu_type; > +/* OUT - vIOMMU
>> Capabilities */
>> +uint64_t caps;
> 
> ... and caps. I see you have defined them in a separate header
> (viommu.h). But there are no way for the developer to know that they
> should be used.

Macros of "Capabilities" and "type" are defined under public directory
in order to tool stack also can use them to pass vIOMMU type and
capabilities.


> 
>> +} query_caps;
>> +} u;
>> +};
>> +
>> +- XEN_DOMCTL_query_viommu_caps
>> +Query capabilities of vIOMMU device model. vIOMMU_type specifies
>> +which vendor vIOMMU device model(E,G Intel VTD) is targeted and
>> hypervisor
> 
> "E,G" did you mean "e.g"?

Yes. Will update.

> 
>> +returns capability bits(E,G interrupt remapping bit).
> 
> Ditto.
> 
> A given platform may have multiple IOMMUs with different features. Are
> we expecting

So far, our patchset just supports VM with one vIOMMU as starter.

Do you mean emulation of some vIOMMU capabilities rely on physical IOMMU
and there are multiple IOMMUs with different feature?

If yes, we need to emulate mult-vIOMMU for different assigned devices
under different pIOMMU. Vendor vIOMMU device model needs to check
whether the assigned device and support given capabilities passed by
tool stack.

> 
>> +
>> +- XEN_DOMCTL_create_viommu
>> +Create vIOMMU device with vIOMMU_type, capabilities, MMIO
>> +base address and length. Hypervisor returns viommu_id. Capabilities
>> should
>> +be in range of value returned by query_viommu_caps hypercall.
> 
> Can you explain what mmio and length are here for? Do you expect to trap
> and emulate the MMIO region in Xen?

Yes, we need to emulate VTD MMIO register in the Xen hypervisor and this
is agreement under design stage. The MMIO base address is passed to
guest via ACPI table which is built by tool stack and so tool stack
manages vIOMMU MMIO region. When create vIOMMU, base address and length
needs to be passed.

For arm, the base address maybe passed by device tree?

> 
> From just looking at the document. I am struggling to understand how
> this is going to be useful.
> 
>> +
>> +- XEN_DOMCTL_destroy_viommu
>> +Destroy vIOMMU in Xen hypervisor with viommu_id as parameters.
>> +
>> +xl vIOMMU configuration
>> +===
>> +viommu="type=vtd,intremap=1,x2apic=1"
>> +
>> +"type" - Specify vIOMMU device model type. Currently only supports
>> Intel vtd
>> +device model.
>> +"intremap" - Enable vIOMMU interrupt remapping function.
>> +"x2apic" - Support x2apic mode with interrupt remapping function.


-- 
Best regards
Tianyu Lan

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

[Xen-devel] [PATCH v6 06/11] x86/vmce: emulate MSR_IA32_MCG_EXT_CTL

[Haozhong Zhang]

If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, then allow guest
to read/write MSR_IA32_MCG_EXT_CTL.

Signed-off-by: Haozhong Zhang 
---
Changes in v6:
 * Remove Jan's R-b.
 * Handle hvm_vmce_vcpu::mcg_ext_ctl in XEN_DOMCTL_{set,get}_ext_vcpucontext.
---
 xen/arch/x86/cpu/mcheck/vmce.c | 34 +-
 xen/arch/x86/domctl.c  | 19 +--
 xen/include/asm-x86/mce.h  |  1 +
 xen/include/public/arch-x86/hvm/save.h |  1 +
 4 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/vmce.c b/xen/arch/x86/cpu/mcheck/vmce.c
index 1356f611ab..060e2d0582 100644
--- a/xen/arch/x86/cpu/mcheck/vmce.c
+++ b/xen/arch/x86/cpu/mcheck/vmce.c
@@ -91,6 +91,7 @@ int vmce_restore_vcpu(struct vcpu *v, const struct 
hvm_vmce_vcpu *ctxt)
 v->arch.vmce.mcg_cap = ctxt->caps;
 v->arch.vmce.bank[0].mci_ctl2 = ctxt->mci_ctl2_bank0;
 v->arch.vmce.bank[1].mci_ctl2 = ctxt->mci_ctl2_bank1;
+v->arch.vmce.mcg_ext_ctl = ctxt->mcg_ext_ctl;
 
 return 0;
 }
@@ -200,6 +201,26 @@ int vmce_rdmsr(uint32_t msr, uint64_t *val)
 mce_printk(MCE_VERBOSE, "MCE: %pv: rd MCG_CTL %#"PRIx64"\n", cur, 
*val);
 break;
 
+case MSR_IA32_MCG_EXT_CTL:
+/*
+ * If MCG_LMCE_P is present in guest MSR_IA32_MCG_CAP, the LMCE and 
LOCK
+ * bits are always set in guest MSR_IA32_FEATURE_CONTROL by Xen, so it
+ * does not need to check them here.
+ */
+if ( cur->arch.vmce.mcg_cap & MCG_LMCE_P )
+{
+*val = cur->arch.vmce.mcg_ext_ctl;
+mce_printk(MCE_VERBOSE, "MCE: %pv: rd MCG_EXT_CTL %#"PRIx64"\n",
+   cur, *val);
+}
+else
+{
+ret = -1;
+mce_printk(MCE_VERBOSE, "MCE: %pv: rd MCG_EXT_CTL, not 
supported\n",
+   cur);
+}
+break;
+
 default:
 ret = mce_bank_msr(cur, msr) ? bank_mce_rdmsr(cur, msr, val) : 0;
 break;
@@ -309,6 +330,16 @@ int vmce_wrmsr(uint32_t msr, uint64_t val)
 mce_printk(MCE_VERBOSE, "MCE: %pv: MCG_CAP is r/o\n", cur);
 break;
 
+case MSR_IA32_MCG_EXT_CTL:
+if ( (cur->arch.vmce.mcg_cap & MCG_LMCE_P) &&
+ !(val & ~MCG_EXT_CTL_LMCE_EN) )
+cur->arch.vmce.mcg_ext_ctl = val;
+else
+ret = -1;
+mce_printk(MCE_VERBOSE, "MCE: %pv: wr MCG_EXT_CTL %"PRIx64"%s\n",
+   cur, val, (ret == -1) ? ", not supported" : "");
+break;
+
 default:
 ret = mce_bank_msr(cur, msr) ? bank_mce_wrmsr(cur, msr, val) : 0;
 break;
@@ -327,7 +358,8 @@ static int vmce_save_vcpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 struct hvm_vmce_vcpu ctxt = {
 .caps = v->arch.vmce.mcg_cap,
 .mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2,
-.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2
+.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2,
+.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl,
 };
 
 err = hvm_save_entry(VMCE_VCPU, v->vcpu_id, h, );
diff --git a/xen/arch/x86/domctl.c b/xen/arch/x86/domctl.c
index f40e989fd8..4ae9fc6451 100644
--- a/xen/arch/x86/domctl.c
+++ b/xen/arch/x86/domctl.c
@@ -871,6 +871,7 @@ long arch_do_domctl(
 evc->vmce.caps = v->arch.vmce.mcg_cap;
 evc->vmce.mci_ctl2_bank0 = v->arch.vmce.bank[0].mci_ctl2;
 evc->vmce.mci_ctl2_bank1 = v->arch.vmce.bank[1].mci_ctl2;
+evc->vmce.mcg_ext_ctl = v->arch.vmce.mcg_ext_ctl;
 
 ret = 0;
 vcpu_unpause(v);
@@ -878,6 +879,8 @@ long arch_do_domctl(
 }
 else
 {
+static const unsigned long vmce_off = offsetof(typeof(*evc), vmce);
+
 if ( d == currd ) /* no domain_pause() */
 break;
 ret = -EINVAL;
@@ -917,9 +920,21 @@ long arch_do_domctl(
  offsetof(struct xen_domctl_ext_vcpucontext,
   vmce.caps));
 BUILD_BUG_ON(sizeof(evc->mcg_cap) != sizeof(evc->vmce.caps));
-if ( evc->size >= offsetof(typeof(*evc), vmce) +
-  sizeof(evc->vmce) )
+if ( evc->size >= vmce_off + sizeof(evc->vmce) )
 ret = vmce_restore_vcpu(v, >vmce);
+else if ( evc->size >= vmce_off +
+   offsetof(typeof(evc->vmce), mcg_ext_ctl) )
+{
+/*
+ * If migrating from old Xen that uses a smaller 'struct
+ * hvm_vmce_vcpu', only restore the components in the
+ * old version.
+ */
+struct hvm_vmce_vcpu vmce = { 0 };
+
+memcpy(, >vmce, evc->size - vmce_off);
+ret = vmce_restore_vcpu(v, );
+}
 else if ( evc->size >= offsetof(typeof(*evc), 

Re: [Xen-devel] [PATCH v1 1/6] vmx: add struct vmx_msr_policy

[Tian, Kevin]

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Monday, June 26, 2017 6:45 PM
> 
> This structure provides a convenient way of accessing contents of
> VMX MSRs: every bit value is accessible by its name.  Bit names match
> existing Xen's definitions as close as possible.
> 
> The structure also contains the bitmap of available MSRs since not all
> of them may be available on a particular H/W.
> 
> Signed-off-by: Sergey Dyasli 
> ---
>  xen/arch/x86/hvm/vmx/vmcs.c|  47 +
>  xen/include/asm-x86/hvm/vmx/vmcs.h | 344
> +
>  2 files changed, 391 insertions(+)
> 
> diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
> index 8103b20d29..e6ea197230 100644
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -144,6 +144,14 @@ static void __init vmx_display_features(void)
>  printk(" - none\n");
>  }
> 
> +bool vmx_msr_available(struct vmx_msr_policy *p, uint32_t msr)
> +{
> +if ( msr < MSR_IA32_VMX_BASIC || msr > MSR_IA32_VMX_VMFUNC )
> +return 0;
> +
> +return p->available & (1u << (msr - MSR_IA32_VMX_BASIC));

can you add a BUILD_BUG_ON to detect size of available won't be
overloaded?

[...]
> +
> +struct vmx_msr_policy
> +{
> +/*
> + * Bitmap of readable MSRs, starting from MSR_IA32_VMX_BASIC,
> + * derived from contents of MSRs in this structure.
> + */
> +uint32_t available;
> +
> +union {
> +uint64_t msr[MSR_IA32_VMX_VMFUNC - MSR_IA32_VMX_BASIC + 1];
> +
> +struct {
> +/* MSR 0x480 */

use actual MSR name please

Thanks
Kevin

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

Re: [Xen-devel] [PATCH v1 0/6] VMX MSRs policy for Nested Virt: part 1

[Tian, Kevin]

> From: Sergey Dyasli [mailto:sergey.dya...@citrix.com]
> Sent: Monday, June 26, 2017 6:44 PM
> 
> The end goal of having VMX MSRs policy is to be able to manage
> L1 VMX features. This patch series is the first part of this work.
> There is no functional change to what L1 sees in VMX MSRs at this
> point. But each domain will have a policy object which allows to
> sensibly query what VMX features the domain has. This will unblock
> some other nested virt work items.
> 
> Currently, when nested virt is enabled, the set of L1 VMX features
> is fixed and calculated by nvmx_msr_read_intercept() as an intersection
> between the full set of Xen's supported L1 VMX features, the set of
> actual H/W features and, for MSR_IA32_VMX_EPT_VPID_CAP, the set of
> features that Xen uses.
> 
> The above makes L1 VMX feature set inconsistent between different H/W
> and there is no ability to control what features are available to L1.
> The overall set of issues has much in common with CPUID policy.
> 
> Part 1 introduces struct vmx_msr_policy and the following instances:
> 
> * Raw policy (raw_vmx_msr_policy) -- the actual contents of H/W VMX MSRs
> * HVM max policy (hvm_max_vmx_msr_policy) -- the end result of
>nvmx_msr_read_intercept() on current H/W
> * Per-domain policy (d->arch.vmx_msr) -- the copy of HVM max policy
>  (for now)

confirm here. So per-domain policy is what you plan to use to
solve inconsistency issue in the future? to make the description
complete, you may want to elaborate a bit for future usages
of new knobs.

> 
> There is no "Host policy" because Xen already has a set of variables
> (vmx_pin_based_exec_control and others) which represent the set of
> VMX features that Xen uses.  There are features that Xen doesn't use
> (i.g. CPU_BASED_PAUSE_EXITING) but they are available to L1.  This makes
> it not worthy to introduce "Host policy" at this stage.
> 
> Sergey Dyasli (6):
>   vmx: add struct vmx_msr_policy
>   vmx: add raw_vmx_msr_policy
>   vmx: refactor vmx_init_vmcs_config()
>   vvmx: add hvm_max_vmx_msr_policy
>   vvmx: add per domain vmx msr policy
>   vmx: print H/W VMX MSRs values during startup
> 
>  xen/arch/x86/domain.c  |   6 +
>  xen/arch/x86/hvm/vmx/vmcs.c| 639
> -
>  xen/arch/x86/hvm/vmx/vmx.c |   4 +
>  xen/arch/x86/hvm/vmx/vvmx.c| 309 +-
>  xen/include/asm-x86/domain.h   |   2 +
>  xen/include/asm-x86/hvm/vmx/vmcs.h | 346 
>  xen/include/asm-x86/hvm/vmx/vvmx.h |   3 +
>  7 files changed, 1070 insertions(+), 239 deletions(-)
> 
> --
> 2.11.0


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-pvh-intel 16 guest-localmigrate  fail REGR. vs. 110515
 test-amd64-amd64-xl-multivcpu 15 guest-saverestore   fail REGR. vs. 110515
 test-amd64-amd64-pair21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-amd64-libvirt-pair 21 guest-start/debian  fail REGR. vs. 110515
 test-amd64-amd64-xl-xsm  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-i386-pair 21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-amd64-xl-credit2  15 guest-saverestorefail REGR. vs. 110515
 test-amd64-amd64-xl  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-i386-libvirt-pair 21 guest-start/debian   fail REGR. vs. 110515
 test-amd64-i386-xl-xsm   16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-i386-libvirt-xsm  16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-libvirt  16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-amd64-xl-pvh-amd  16 guest-localmigrate   fail REGR. vs. 110515
 test-amd64-amd64-libvirt 16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515
 test-amd64-amd64-libvirt-xsm 16 guest-saverestore.2  fail REGR. vs. 110515
 test-amd64-i386-xl   16 guest-localmigrate   fail REGR. vs. 110515

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 12 guest-start  fail REGR. vs. 110515

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

Re: [Xen-devel] [PATCH v4] VT-d: fix VF of RC integrated PF matched to wrong VT-d unit

[Tian, Kevin]

> From: Gao, Chao
> Sent: Monday, July 3, 2017 12:37 PM
> 
> On Fri, Jun 30, 2017 at 05:19:52PM +0800, Tian, Kevin wrote:
> >> From: Gao, Chao
> >> Sent: Friday, June 30, 2017 9:17 AM
> >>
> >> The problem is for a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
> >> we would wrongly use 00:00.0 to search VT-d unit.
> >>
> >> From SRIOV spec REV 1.0 section 3.7.3, it says:
> >> "ARI is not applicable to Root Complex integrated Endpoints; all other
> >> SR-IOV Capable Devices (Devices that include at least one PF) shall
> >> implement the ARI Capability in each Function.". So PFs can be classified
> to
> >> two kinds: one is RC integrated PF and the other is non-RC integrated PF.
> The
> >> former can't support ARI and the latter shall support ARI. For Extended
> >> Functions, one traditional function's BDF should be used to search VT-d
> unit.
> >> And according to PCIe spec, Extened Function means within an ARI device,
> a
> >> Function whose Function Number is greater than 7. Thus, the former can't
> be
> >> an
> >> extended function, while the latter is as long as its devfn > 7, this 
> >> check is
> >> exactly what the original code did; The original code wasn't aware the
> former.
> >>
> >> This patch directly looks up the 'is_extfn' field of PF's struct pci_dev
> >> to decide whether the PF is a extended function.
> >
> >Above description looks like the bug is caused by ARI problem. But
> >if you look at the original code (and the problem you described), it's
> >not related to ARI. ARI comes just when adding a clean fix, so please
> >revise the description to make that part clear
> >
> 
> How about this:
> 
> The problem is for a VF of RC integrated PF (e.g. PF's BDF is 00:02.0),
> we would wrongly use 00:00.0 to search VT-d unit.
> 
> If a PF is an extended function, a traditional function's BDF should be
> used to search VT-d unit. Previous code only checks whether Function
> Number is greater than 7, without checking the prerequisite that the

where did above check come from in original code? 

-devfn = PCI_SLOT(pdev->info.physfn.devfn) ? 0 : 
pdev->info.physfn.devfn;

> function should be within an ARI device. This incurs wrongly using
> traditional function's BDF when the PF is RC integrated and thus cannot
> be within an ARI device.
> 
> Considering 'is_extfn' field of struct pci_dev has been passed down from
> Domain0 to indicate whether the function is an extended function, this
> patch just looks up that field of PF's struct pci_dev and adjust BDF
> used to search VT-d unit accordingly.
> 

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

Re: [Xen-devel] [PATCH v12 13/23] x86: refactor psr: CDP: implement CPU init flow.

[Yi Sun]

On 17-07-04 01:28:32, Jan Beulich wrote:
> >>> On 04.07.17 at 03:40,  wrote:
> > On 17-06-30 03:18:53, Jan Beulich wrote:
> >> >>> Yi Sun  06/30/17 10:05 AM >>>
> >> >On 17-06-30 01:33:02, Jan Beulich wrote:
> >> >> >>> Yi Sun  06/30/17 9:01 AM >>>
> > There will be problem if we substract 1 before doing the shift for the even
> > number. E.g. the original cos_max is 2, (2-1)>>1 will be 0. That is not we
> > want. For the odd number, direct right shift is good too. E.g. the original
> > cos_max is 3, 3 >> 1 is 1 which is what we want.
> 
> What we want is
> 
>   raw CDP
>   0   unusable
>   1   0
>   2   0
>   3   1
>   4   1
>   5   2
>   6   2
> 
> Other than what you say, for original cos_max = 2 we indeed need
> to convert it to 0, or else CDP would use indexes 2 ( = 1 * 2 + 0)
> and 3 ( = 1 * 2 + 1), exceeding the mandated upper bound.
> 
> >> insufficient for the CDP case?
> > 
> > We do not need check if cos_max > 1 because the 'cos_max = 0' works for us.
> > That means only COS ID 0 can be used. You can see, we use "cos <= cos_max" 
> > to
> > find COS ID. Of course, the ID 0 saves the default value which cannot be
> > overwritten.
> 
> Please see the (current) check in init_psr_cat(), which your series
> moves into init_psr(). Logically in the CDP case we should require
> cos_max >= 3 to have at least one usable COS ID.
> 
> Jan

Thank you! You are right. I will modify codes to do so.

BRs,
Sun Yi

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

[Xen-devel] [xen-unstable baseline-only test] 71641: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71641 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71641/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail REGR. vs. 
71626
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 17 guest-start/win.repeat fail REGR. 
vs. 71626
 test-amd64-i386-xl-qemut-winxpsp3 16 guest-stop   fail REGR. vs. 71626
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail REGR. vs. 
71626

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop   fail blocked in 71626
 build-i386-libvirt5 libvirt-buildfail   like 71626
 build-armhf-libvirt   5 libvirt-buildfail   like 71626
 build-amd64-libvirt   5 libvirt-buildfail   like 71626
 test-amd64-i386-xl-qemut-winxpsp3-vcpus1 17 guest-start/win.repeat fail like 
71626
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10  fail like 71626
 test-amd64-amd64-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail like 71626
 test-amd64-amd64-xl-qemut-winxpsp3  9 windows-install  fail like 71626

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-libvirt-vhd  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-armhf-armhf-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 build-arm64-libvirt   1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt-qcow2  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt   1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-raw  1 build-check(1)   blocked  n/a
 test-arm64-arm64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
 test-arm64-arm64-xl-rtds  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-multivcpu  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64-xsm   2 hosts-allocate   broken never pass
 build-arm64-xsm   3 capture-logs broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-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-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass

version targeted for testing:
 xen  a7d802bca13489d303749177127089af48844f29
baseline version:
 xen  d468f4299cef469d882f4bed8530fca53ebf2ebd

Last test of basis71626  2017-07-03 07:15:51 Z1 days
Testing same since71641  2017-07-04 18:16:25 Z0 days1 attempts

Re: [Xen-devel] OOPS new Xen 4.9.0_08 / kernel 4.12.0 Dom0 crash @ domain_crash_sync called from entry.S: fault at ffff82d080342328 entry.o#create_bounce_frame+0x135/0x14d

[PGNet Dev]

Hi

On 7/4/17 12:54 PM, Andrew Cooper wrote:
> On 04/07/17 20:48, PGNet Dev wrote:
>>  [0.00] NX (Execute Disable) protection: active
>>  [0.00] efi: EFI v2.31 by American Megatrends
>>  [0.00] efi:  ESRT=0x9ef8d998  ACPI 2.0=0x9e819000  
>> ACPI=0x9e819000  SMBIOS=0xf04c0  MPS=0xfd490
>>  (XEN) [2017-07-04 19:08:39] d0v0 Unhandled invalid opcode fault/trap 
>> [#6, ec=]
>>  (XEN) [2017-07-04 19:08:39] domain_crash_sync called from entry.S: 
>> fault at 82d080342328 entry.o#create_bounce_frame+0x135/0x14d
>>  (XEN) [2017-07-04 19:08:39] Domain 0 (vcpu#0) crashed on cpu#0:
>>  (XEN) [2017-07-04 19:08:39] [ Xen-4.9.0_08-512  x86_64  debug=n   
>> Tainted:  C   ]
>>  (XEN) [2017-07-04 19:08:39] CPU:0
>>  (XEN) [2017-07-04 19:08:39] RIP:e033:[]
> 
> Please look up 0x822b8e5b in your dom0 kernel debug symbols.

rpm -ql kernel-default-debuginfo | grep -i vmlinux
/usr/lib/debug/boot/vmlinux-4.12.0-2.gb8e7496-default.debug

addr2line -e /usr/lib/debug/boot/vmlinux-4.12.0-2.gb8e7496-default.debug 
822b8e5b

/usr/src/debug/kernel-default-4.12.0/linux-4.12/linux-obj/../mm/early_ioremap.c:137

cd /usr/src/linux
cat mm/early_ioremap.c

...
/*
 * Mappings have to be page-aligned
 */
offset = offset_in_page(phys_addr);
phys_addr &= PAGE_MASK;
size = PAGE_ALIGN(last_addr + 1) - phys_addr;

/*
 * Mappings have to fit in the FIX_BTMAP area.
 */
nrpages = size >> PAGE_SHIFT;
137 if (WARN_ON(nrpages > NR_FIX_BTMAPS))
return NULL;

/*
 * Ok, go for it..
 */
...





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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 111359
 test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail REGR. vs. 
111359

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 111359
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stopfail REGR. vs. 111359

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

version targeted for testing:
 qemuu0c7a8b9baa744ae4323bb46cb4fe942355beaa85
baseline version:
 qemuufd479c60f5766f7fb247ad146b9e3c33d03d2055

Last test of basis   111359  2017-07-03 10:28:02 Z1 days
Testing same since   111373  2017-07-04 12:14:51 Z0 days1 attempts


People who touched revisions under test:
  Aleksandr Bezzubikov 
  Ben Warren 
  Gabriel Somlo 
  Ladi Prosek 
  Mao Zhongyi 
  Mark Cave-Ayland 
  Maxime Coquelin 
  Michael S. Tsirkin 
  Peter Maydell 
  Peter Xu 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111255 
REGR. vs. 110441

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-amd64 17 guest-localmigrate/x10 fail in 111255 pass 
in 111375
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 111255 
pass in 111375
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail in 111365 pass in 
111255
 test-armhf-armhf-examine  5 xen-install  fail in 111365 pass in 111375
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail pass in 111255
 test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm 17 guest-stop fail pass in 111365
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail pass in 
111365

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111255 
blocked in 110441
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111255 
like 110441
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail in 111365 blocked in 
110441
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110441
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail like 110441
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110441
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux

Re: [Xen-devel] I was able to cross-compile the hypervisor on an amd64 host for the aarch64 target ... However, I can't build the Xen toolset

[Nick Garnett]

From: Julien Grall [mailto:julien.gr...@arm.com] 
Sent: Tuesday, July 04, 2017 09:47

On 07/04/2017 05:42 PM, Nick Garnett wrote:
> I tried installing the tools with an ARM64 chroot also and had a similar 
> issue.  In that case, the package 
> "crossbuild_essential_arm64" wouldn't install because it depended on a 
> package that was not installable.

I don't use crossbuild within the chroot. My chroot contains ARM64 binaries 
only and QEMU is used to run ARM64 binaries.

Which distributions are you targeting?

[nickgarnett 1707041454PDT]  I am using Xen 4.9.0




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

Re: [Xen-devel] [PATCH v5 08/12] arm/mem_access: Introduce GENMASK_ULL bit operation

[Sergej Proskurin]

Hi Julien,

On 07/04/2017 10:46 PM, Sergej Proskurin wrote:
> Hi Julien,
> 
> On 07/04/2017 06:28 PM, Julien Grall wrote:
>> Hi Sergej,
>>
>> On 06/27/2017 12:52 PM, Sergej Proskurin wrote:
>>> The current implementation of GENMASK is capable of creating bitmasks of
>>> 32-bit values on AArch32 and 64-bit values on AArch64. As we need to
>>> create masks for 64-bit values on AArch32 as well, in this commit we
>>> introduce the GENMASK_ULL bit operation.
>>>
>>> Signed-off-by: Sergej Proskurin  > ---
>>> Cc: Stefano Stabellini 
>>> Cc: Julien Grall 
>>> ---
>>>   xen/include/asm-arm/config.h | 2 ++ >   xen/include/xen/bitops.h
>>> | 2 ++
>>
>> This is common code and the relevant maintainers should have been CCed.
>>
> 
> According to ./scripts/get_maintainer.pl Stefano Stabellini and you were
> the only maintainers to put on Cc. I would appreciate it if you would
> point out what I am missing. Thank you very much in advance.
> 
>> This is not the first time we are trying to introduce GENMASK_ULL. I
>> would recommend you to read the following discussion:
>>
>> https://patchwork.kernel.org/patch/9665869/
>>
> 

While I agree with you that GENMASK_ULL reduces potential mistakes by
generating ULL masks manually, I don't think that we have more arguments
for introducing GENMASK_ULL this time than the last two times..

So, anyway, I will gladly put the other maintainers on Cc and retry the
submission one more time (it would be great if you would provide me with
the list of the respective maintainers, as ./scripts/get_maintainer.pl
apparently did not involve all parties). Thank you.

Cheers,
~Sergej

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

Re: [Xen-devel] [PATCH v5 03/12] arm/mem_access: Add defines supporting PTs with varying page sizes

[Sergej Proskurin]

Hi Julien,

On 07/04/2017 06:15 PM, Julien Grall wrote:
> Hi Sergej,
> 

[...]

>> +
>> +#define GUEST_TABLE_OFFSET(offs, gran)  ((paddr_t)(offs) &
>> lpae_entry_mask(gran))
>> +#define
>> GUEST_TABLE_OFFSET_HELPERS(gran) 
>>   
>> \
>> +static inline vaddr_t third_guest_table_offset_##gran##K(vaddr_t
>> gva)   \
> 
> Sorry I haven't spot it before. This is not going to work properly on
> 32-bit if you use vaddr_t. Indeed, input for stage-2 page-table (i.e
> IPA) will be 40-bit. But vaddr_t is 32-bit. So you to use paddr_t here
> and in all the helpers below.
> 

I agree that IPAs won't work properly on AArch32. However, we don't walk
the second stage translation tables with the introduced code (yet?). In
fact, second stage translation walks in software are not supported at
the moment. I understand why you would think in this direction, with
ARM's nested virtualization support coming up, where we might need to
walk the second stage translation tables in sw. Yet, with the current
implementation, we work on on GVAs (not IPAs) and hence the vaddr_t
should not present an issue (except that the now missing CONFIG_ARM_64
#ifdef's in the long-descriptor translation table walk create compile
issues as we need to support both different page granularities and
zeroeth-level offsets which work on gva's > 32bit on AArch64).

If you wish to see the implementation extended in the future to support
walking the 2nd stage address translation, then I will gladly change
vaddr_t to paddr_t.

Cheers,
~Sergej

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

Re: [Xen-devel] [PATCH v5 08/12] arm/mem_access: Introduce GENMASK_ULL bit operation

[Sergej Proskurin]

Hi Julien,

On 07/04/2017 06:28 PM, Julien Grall wrote:
> Hi Sergej,
> 
> On 06/27/2017 12:52 PM, Sergej Proskurin wrote:
>> The current implementation of GENMASK is capable of creating bitmasks of
>> 32-bit values on AArch32 and 64-bit values on AArch64. As we need to
>> create masks for 64-bit values on AArch32 as well, in this commit we
>> introduce the GENMASK_ULL bit operation.
>>
>> Signed-off-by: Sergej Proskurin  > ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>>   xen/include/asm-arm/config.h | 2 ++ >   xen/include/xen/bitops.h
>> | 2 ++
> 
> This is common code and the relevant maintainers should have been CCed.
> 

According to ./scripts/get_maintainer.pl Stefano Stabellini and you were
the only maintainers to put on Cc. I would appreciate it if you would
point out what I am missing. Thank you very much in advance.

> This is not the first time we are trying to introduce GENMASK_ULL. I
> would recommend you to read the following discussion:
> 
> https://patchwork.kernel.org/patch/9665869/
> 

Thank you.

Cheers,
~Sergej

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

[Xen-devel] Possible bug on ARM with irq passthrough

[Ivan Pavić2]

Hello,

I'm testing IRQ latency on exynos5422. I'm using Xen 4.10-unstable. I used 
device passthrough for SPI irq 64. For guest domain I used  FreeRTOS. When I 
use credit scheduler after destruction of domain, IRQ is released. I changed 
scheduler to credit2 and rtds at boot time and IRQ wasn't released after 
destruction. xl create dom-free-rtos.cfg fails with:

libxl: error: libxl_create.c:1278:domcreate_launch_dm: Domain 5:failed give 
domain access to irq 64: Device or resource busy

This is very strange because it doesn't happen with credit scheduler. This is 
output of xl dmesg:

(XEN) IRQ 64 is already used by domain 1

Everything works first time but when I destroy domain and try to create again 
it fails. It works normally with credit scheduler. In dom-free-rtos.cfg:
...
irqs = [64]


Regards,
Ivan Pavic

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

Re: [Xen-devel] [PATCH v5 09/12] arm/mem_access: Add software guest-page-table walk

[Sergej Proskurin]

Hi Julien,

On 07/04/2017 06:58 PM, Julien Grall wrote:
> Hi Sergej,
> 
> On 06/27/2017 12:52 PM, Sergej Proskurin wrote:
>> The function p2m_mem_access_check_and_get_page in mem_access.c
>> translates a gva to an ipa by means of the hardware functionality of the
>> ARM architecture. This is implemented in the function gva_to_ipa. If
>> mem_access is active, hardware-based gva to ipa translation might fail,
>> as gva_to_ipa uses the guest's translation tables, access to which might
>> be restricted by the active VTTBR. To address this issue, in this commit
>> we add a software-based guest-page-table walk, which will be used by the
>> function p2m_mem_access_check_and_get_page perform the gva to ipa
>> translation in software in one of the following commits.
>>
>> Note: The introduced function guest_walk_tables assumes that the domain,
>> the gva of which is to be translated, is running on the currently active
>> vCPU. To walk the guest's page tables on a different vCPU, the following
>> registers would need to be loaded: TCR_EL1, TTBR0_EL1, TTBR1_EL1, and
>> SCTLR_EL1.
>>
>> Signed-off-by: Sergej Proskurin 
>> Acked-by: Julien Grall 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>> v2: Rename p2m_gva_to_ipa to p2m_walk_gpt and move it to p2m.c.
>>
>>  Move the functionality responsible for walking long-descriptor based
>>  translation tables out of the function p2m_walk_gpt. Also move out
>>  the long-descriptor based translation out of this commit.
>>
>>  Change function parameters in order to return access access rights
>>  to a requested gva.
>>
>>  Cosmetic fixes.
>>
>> v3: Rename the introduced functions to guest_walk_(tables|sd|ld) and
>>  move the implementation to guest_copy.(c|h).
>>
>>  Set permissions in guest_walk_tables also if the MMU is disabled.
>>
>>  Change the function parameter of type "struct p2m_domain *" to
>>  "struct vcpu *" in the function guest_walk_tables.
>>
>> v4: Change the function parameter of type "struct p2m_domain *" to
>>  "struct vcpu *" in the functions guest_walk_(sd|ld) as well.
>>
>> v5: Merge two if-statements in guest_walk_tables to ease readability.
>>
>>  Set perms to GV2M_READ as to avoid undefined permissions.
> 
> I would appreciate if you mention that you kept my tag even with the
> change made and asked whether I am happy with it...
> 

Sorry for not mentioning that. Since it was your suggestion right after
you have acked this patch, I thought it would be sufficient to just
state the changes. I will consider that in the future.

> In this case, you need a bit more rationale to explain why setting to
> GV2M_READ by default is fine... If it is just a random value, then say it.
> 

I will add a comment in the change log stating that we set perms to
GV2M_READ (that equals to 0) by default to avoid having potentially
random values returned on errors.

Shall I remove your ack for this patch in the next version?

Thanks,
~Sergej

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

Re: [Xen-devel] OOPS new Xen 4.9.0_08 / kernel 4.12.0 Dom0 crash @ domain_crash_sync called from entry.S: fault at ffff82d080342328 entry.o#create_bounce_frame+0x135/0x14d

[Andrew Cooper]

On 04/07/17 20:48, PGNet Dev wrote:
>   [0.00] NX (Execute Disable) protection: active
>   [0.00] efi: EFI v2.31 by American Megatrends
>   [0.00] efi:  ESRT=0x9ef8d998  ACPI 2.0=0x9e819000  
> ACPI=0x9e819000  SMBIOS=0xf04c0  MPS=0xfd490
>   (XEN) [2017-07-04 19:08:39] d0v0 Unhandled invalid opcode fault/trap 
> [#6, ec=]
>   (XEN) [2017-07-04 19:08:39] domain_crash_sync called from entry.S: 
> fault at 82d080342328 entry.o#create_bounce_frame+0x135/0x14d
>   (XEN) [2017-07-04 19:08:39] Domain 0 (vcpu#0) crashed on cpu#0:
>   (XEN) [2017-07-04 19:08:39] [ Xen-4.9.0_08-512  x86_64  debug=n   
> Tainted:  C   ]
>   (XEN) [2017-07-04 19:08:39] CPU:0
>   (XEN) [2017-07-04 19:08:39] RIP:e033:[]

Please look up 0x822b8e5b in your dom0 kernel debug symbols.

~Andrew

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

[Xen-devel] OOPS new Xen 4.9.0_08 / kernel 4.12.0 Dom0 crash @ domain_crash_sync called from entry.S: fault at ffff82d080342328 entry.o#create_bounce_frame+0x135/0x14d

[PGNet Dev]

> As a general remark, I think such issues should rather be brought up on 
> xen-devel.

upgrading a working Xen server to

kernel 4.12.0-2.gb8e7496-default
Xen 4.9.0_08-512

now, boot crashes @

domain_crash_sync called from entry.S: fault at 82d080342328 
entry.o#create_bounce_frame+0x135/0x14d

serial output

Loading Xen 4.9.0_08-512 with Linux 4.12.0-2.gb8e7496-default 
...Loading Xen 4.9.0_08-512 with Linux 4.12.0-2.gb8e7496-default ...

/EndEntire
/EndEntire
file path: file path: 
/ACPI(a0341d0,0)/ACPI(a0341d0,0)/PCI(1,1c)/PCI(1,1c)/PCI(0,0)/PCI(0,0)/PCI(0,1)/PCI(0,1)/PCI(0,0)/PCI(0,0)/HardwareVendor
(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 
/HardwareVendor(cf31fac5-c24e-11d2-85f3-00a0c93ec93b)[1: 88 88 
]]/HD(2,1000,96000,c5cc9661271ee648
,2,2)/HD(2,1000,96000,c5cc9661271ee648,2,2)/File(\EFI\OPENSUSE)

/File(\EFI\OPENSUSE)/File(xen-4.9.0_08-512.efi)/File(xen-4.9.0_08-512.efi)/EndEntire
/EndEntire
Xen 4.9.0_08-512 (c/s ) EFI loader
Using configuration file 'xen-4.9.0_08-512.cfg'
vmlinuz-4.12.0-2.gb8e7496-default: 0x8b925000-0x8c0a2f60
initrd-4.12.0-2.gb8e7496-default: 0x63395000-0x65fafacc
0x:0x00:0x19.0x0: ROM: 0x1 bytes at 0x928b9018
0x:0x04:0x00.0x0: ROM: 0x8000 bytes at 0x928b0018
0x:0x10:0x00.0x0: ROM: 0x10800 bytes at 0x92894018
 __  ___  _   ___   ___ ___   ___  _   
 \ \/ /___ _ __   | || | / _ \ / _ \   / _ \ ( _ )  | ___|/ |___ \ 
  \  // _ \ '_ \  | || || (_) | | | | | | | |/ _ \ _|___ \| | __) |
  /  \  __/ | | | |__   _\__, | |_| | | |_| | (_) |__|__) | |/ __/ 
 /_/\_\___|_| |_||_|(_)/_(_)___/___\___/ \___/  |/|_|_|
  |_|  
(XEN) Xen version 4.9.0_08-512 (abu...@suse.de) (gcc (SUSE Linux) 7.1.1 
20170629 [gcc-7-branch revision 249772]) debug=n  Wed Jun 28 07:40:43 UTC 2017
(XEN) Latest ChangeSet: 
(XEN) Console output is synchronous.
(XEN) Bootloader: EFI
(XEN) Command line: dom0_mem=4G,max:4G bootscrub=false dom0_max_vcpus=4 
vga=gfx-1920x1080x16 com1=115200,8n1,pci console=com1,vga console_timestamps 
console_to_ring conring_size=64 sched=cr
edit2 reboot=acpi log_buf_len=16M loglvl=all guest_loglvl=all 
noreboot=false sync_console=true sched_debug iommu=verbose 
apic_verbosity=verbose
(XEN) Xen image load base address: 0x8c20
(XEN) Video information:
(XEN)  VGA is graphics mode 800x600, 32 bpp
(XEN) Disc information:
(XEN)  Found 0 MBR signatures
(XEN)  Found 6 EDD information structures
(XEN) EFI RAM map:
(XEN)   - 8000 (reserved)
(XEN)  8000 - 00048000 (usable)
(XEN)  00048000 - 00059000 (reserved)
(XEN)  00059000 - 0005f000 (usable)
(XEN)  0005f000 - 000a (reserved)
(XEN)  0010 - 8d528000 (usable)
(XEN)  8d528000 - 8d52f000 (ACPI NVS)
(XEN)  8d52f000 - 8de44000 (reserved)
(XEN)  8de44000 - 8de4a000 (usable)
(XEN)  8de4a000 - 8e28b000 (reserved)
(XEN)  8e28b000 - 915dc000 (usable)
(XEN)  915dc000 - 91842000 (reserved)
(XEN)  91842000 - 91875000 (usable)
(XEN)  91875000 - 918d4000 (reserved)
(XEN)  918d4000 - 9193b000 (usable)
(XEN)  9193b000 - 919df000 (reserved)
(XEN)  919df000 - 91a13000 (usable)
(XEN)  91a13000 - 91a14000 (reserved)
(XEN)  91a14000 - 91a15000 (usable)
(XEN)  91a15000 - 91a17000 (reserved)
(XEN)  91a17000 - 91a18000 (usable)
(XEN)  91a18000 - 91a19000 (reserved)
(XEN)  91a19000 - 91a21000 (usable)
(XEN)  91a21000 - 91a22000 (reserved)
(XEN)  91a22000 - 91a2c000 (usable)
(XEN)  91a2c000 - 91a2d000 (reserved)
(XEN)  91a2d000 - 91a36000 (usable)
(XEN)  91a36000 - 91a41000 (reserved)
(XEN)  91a41000 - 91ac3000 (usable)
(XEN)  91ac3000 - 91b3f000 (reserved)
(XEN)  91b3f000 - 91b88000 (usable)
(XEN)  91b88000 - 91ee6000 (reserved)
(XEN)  91ee6000 - 91f2d000 (usable)
(XEN)  91f2d000 - 91fa3000 (reserved)
(XEN)  91fa3000 - 91fd6000 (usable)
(XEN)  91fd6000 

[Xen-devel] [distros-debian-snapshot test] 71633: regressions - trouble: blocked/broken/fail/pass

[Platform Team regression test user]

flight 71633 distros-debian-snapshot real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71633/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-i386-daily-netboot-pvgrub 9 debian-di-install fail REGR. vs. 
71604
 test-amd64-i386-amd64-daily-netboot-pygrub 9 debian-di-install fail REGR. vs. 
71604
 test-amd64-amd64-amd64-daily-netboot-pvgrub 9 debian-di-install fail REGR. vs. 
71604
 test-amd64-amd64-i386-daily-netboot-pygrub 9 debian-di-install fail REGR. vs. 
71604

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 
71604
 test-armhf-armhf-armhf-daily-netboot-pygrub 9 debian-di-install fail like 71604
 test-amd64-i386-i386-weekly-netinst-pygrub 9 debian-di-install fail like 71604
 test-amd64-amd64-i386-weekly-netinst-pygrub 9 debian-di-install fail like 71604
 test-amd64-i386-i386-current-netinst-pygrub 9 debian-di-install fail like 71604
 test-amd64-i386-amd64-weekly-netinst-pygrub 9 debian-di-install fail like 71604
 test-amd64-amd64-i386-current-netinst-pygrub 9 debian-di-install fail like 
71604
 test-amd64-i386-amd64-current-netinst-pygrub 9 debian-di-install fail like 
71604
 test-amd64-amd64-amd64-current-netinst-pygrub 9 debian-di-install fail like 
71604

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-armhf-daily-netboot-pygrub  1 build-check(1)  blocked n/a
 build-arm64-pvops 2 hosts-allocate   broken never pass
 build-arm64   2 hosts-allocate   broken never pass
 build-arm64   3 capture-logs broken never pass
 build-arm64-pvops 3 capture-logs broken never pass

baseline version:
 flight   71604

jobs:
 build-amd64  pass
 build-arm64  broken  
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-arm64-pvopsbroken  
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-daily-netboot-pvgrub  fail
 test-amd64-i386-i386-daily-netboot-pvgrubfail
 test-amd64-i386-amd64-daily-netboot-pygrub   fail
 test-arm64-arm64-armhf-daily-netboot-pygrub  blocked 
 test-armhf-armhf-armhf-daily-netboot-pygrub  fail
 test-amd64-amd64-i386-daily-netboot-pygrub   fail
 test-amd64-amd64-amd64-current-netinst-pygrubfail
 test-amd64-i386-amd64-current-netinst-pygrub fail
 test-amd64-amd64-i386-current-netinst-pygrub fail
 test-amd64-i386-i386-current-netinst-pygrub  fail
 test-amd64-amd64-amd64-weekly-netinst-pygrub fail
 test-amd64-i386-amd64-weekly-netinst-pygrub  fail
 test-amd64-amd64-i386-weekly-netinst-pygrub  fail
 test-amd64-i386-i386-weekly-netinst-pygrub   fail



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.


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

[Xen-devel] [PATCH] xen: selfballoon: remove unnecessary static in frontswap_selfshrink()

[Gustavo A. R. Silva]

Remove unnecessary static on local variables last_frontswap_pages and
tgt_frontswap_pages. Such variables are initialized before being used,
on every execution path throughout the function. The statics have no
benefit and, removing them reduce the code size.

This issue was detected using Coccinelle and the following semantic patch:

@bad exists@
position p;
identifier x;
type T;
@@

static T x@p;
...
x = <+...x...+>

@@
identifier x;
expression e;
type T;
position p != bad.p;
@@

-static
 T x@p;
 ... when != x
 when strict
?x = e;

You can see a significant difference in the code size after executing
the size command, before and after the code change:

before:
   textdata bss dec hex filename
   56333452 384946924fd drivers/xen/xen-selfballoon.o

after:
   textdata bss dec hex filename
   55763308 256914023b4 drivers/xen/xen-selfballoon.o

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/xen/xen-selfballoon.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/xen-selfballoon.c b/drivers/xen/xen-selfballoon.c
index 6662071..a67e955 100644
--- a/drivers/xen/xen-selfballoon.c
+++ b/drivers/xen/xen-selfballoon.c
@@ -151,8 +151,8 @@ static unsigned long frontswap_inertia_counter;
 static void frontswap_selfshrink(void)
 {
static unsigned long cur_frontswap_pages;
-   static unsigned long last_frontswap_pages;
-   static unsigned long tgt_frontswap_pages;
+   unsigned long last_frontswap_pages;
+   unsigned long tgt_frontswap_pages;
 
last_frontswap_pages = cur_frontswap_pages;
cur_frontswap_pages = frontswap_curr_pages();
-- 
2.5.0


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

Re: [Xen-devel] xen/arm: Software Step ARMv8 - PC stuck on instruction

[Julien Grall]

On 07/04/2017 01:30 PM, Florian Jakobsmeier wrote:

Hello all,


Hi Florian,


  asmlinkage void leave_hypervisor_tail(void)
  {
+/*This methode will be called after the 'guest_entry' macro in
/arch/arm64/entry.S set guest registers
+Check single_step_enabled flag in domain struct here and set
needed registers
+
+*/
+
+struct vcpu *v = current;
+
+if ( unlikely(v->domain->arch.monitor.singlestep_enabled ) )
+{
+
+WRITE_SYSREG(READ_SYSREG(MDCR_EL2)  | HDCR_TDE, MDCR_EL2);
+WRITE_SYSREG(READ_SYSREG(SPSR_EL2)  | 0x20, SPSR_EL2 );
+WRITE_SYSREG(READ_SYSREG(MDSCR_EL1) | 0x1, MDSCR_EL1);
+
+if (!(v->arch.single_step ))
+{
+gprintk(XENLOG_ERR, "Setting vcpu=%d for
domain=%d\n",v->vcpu_id,v->domain->domain_id);
+
+gprintk(XENLOG_ERR, "[Set_singlestep] MDSCR_EL1
0x%lx\n", READ_SYSREG(MDSCR_EL1));
+gprintk(XENLOG_ERR, "[Set_singlestep] SPSR_EL2 
0x%lx\n", READ_SYSREG(SPSR_EL2));
+gprintk(XENLOG_ERR, "[Set_singlestep] MDCR_EL2 
0x%lx\n", READ_SYSREG(MDCR_EL2));

+v->arch.single_step = 1;
+
+return;
+}else
+{
+//gprintk(XENLOG_ERR, "Register for vcpu=%d for
domain=%d already set\n",v->vcpu_id,v->domain->domain_id);
+}
+}


As mentioned, this function will set the needed registers. 
"monitor.singlestep_enabled" is the domain SS flag which is used to 
determine if the registers should be set. "arch.single_step" is the vcpu 
flag to check if the register were already set once (not really in use 
as for now). "HDCR_TDE" is the same value as "MDCR_EL2_TDE" would be, 
but this one is not implemented yet, thats why I'm using HDCR_TDE. 
"SPSR_EL2 | 0x20" sets the SS bit for EL2 (because our exception 
will be taken to the hypervisor). "MDSCR_EL1 | 0x1" to enable the SS bit.
Because I'm checking the domain in this function, every vcpu that will 
be used, will be set with the values above. By this I can assure that 
each vcpu will trigger these exceptions.


SPSR_EL2 is saved/restored on entry and exit of a trap to the hypervisor 
(see arch/arm/arm*/entry.S). So the value you wrote in the register is 
overridden afterwards.


If you want to set the SS bit, you need to do in the save registered 
cpsr. You can access using:


guest_cpu_user_regs()->cpsr |= 0x20;

Cheers,

--
Julien Grall

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

[Xen-devel] [xen-unstable test] 111368: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

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

version targeted for testing:
 xen  a7d802bca13489d303749177127089af48844f29
baseline version:
 xen  d468f4299cef469d882f4bed8530fca53ebf2ebd

Last test of basis   111352  2017-07-03 06:54:54 Z1 days
Testing same since   111368  2017-07-03 23:17:48 Z0 days1 attempts


People who touched revisions under test:
  Haozhong Zhang 
  Jan Beulich 

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm  pass
 build-armhf-xsm  pass 

Re: [Xen-devel] [PATCH 2/2] CODING_STYLE: Forbid nested block in the hypervisor code

[Julien Grall]

Hi,

On 07/04/2017 03:17 PM, Andrew Cooper wrote:

On 04/07/17 13:20, Jan Beulich wrote:

On 04.07.17 at 14:12,  wrote:

When removing if/for/while statements, the code should be reworked to
remove the { } and the extra indentation.

Yes.


This is improving code maintainability and code readability.

For the given example, yes. However, there are (rare) cases where
having such nested blocks actually improves readability, for example
in certain combinations with preprocessor conditionals. Hence I don't
think we should forbid them.


There are also a few specific cases where it is useful to use blocks
like that to introduce a new variable, where introducing it at function
level scope isn't appropriate.  (Alternatively, we could switch from C89
to C99, but that is a separate discussion).

I agree that we should discourage the use of blocks like this, but not
forbid them outright.


Thank you both for the feedback. I will rework the proposal to 
discourage contributor rather than forbid.


Cheers,

--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 111376: tolerable trouble: broken/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  d23afa6399a78ca7d0ed3294119632535828c9d8
baseline version:
 xen  864a269682025a64b6cb7c53fc65d9884ecc342e

Last test of basis   111372  2017-07-04 12:02:19 Z0 days
Testing same since   111376  2017-07-04 15:01:57 Z0 days1 attempts


People who touched revisions under test:
  Dongli Zhang 
  Julien Grall 
  Razvan Cojocaru 
  Wei Liu 
  Xiong Zhang 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=d23afa6399a78ca7d0ed3294119632535828c9d8
+ . ./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 xen-unstable-smoke 
d23afa6399a78ca7d0ed3294119632535828c9d8
+ branch=xen-unstable-smoke
+ revision=d23afa6399a78ca7d0ed3294119632535828c9d8
+ . ./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=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' xd23afa6399a78ca7d0ed3294119632535828c9d8 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : 

Re: [Xen-devel] [PATCH v5 10/12] arm/mem_access: Add long-descriptor based gpt

[Julien Grall]

Hi Sergej,

On 06/27/2017 12:52 PM, Sergej Proskurin wrote:

 Also, create a macro CHECK_BASE_SIZE which simply reduces the code
 size and simplifies readability.


No, it makes more confusing because you have the return within the 
macro. It is not that bad too have an helper checking the base and do


if ( check_base_size() )
  return -EINVAL;

[...]


+/* Make sure the base address does not exceed its configured size. */
+#define CHECK_BASE_SIZE(output_size, base)  \
+{   \
+paddr_t mask = GENMASK_ULL((TCR_EL1_IPS_48_BIT_VAL - 1), output_size);  \
+if ( output_size < TCR_EL1_IPS_48_BIT_VAL && (base & mask) )\
+return -EFAULT; \
+}


See my comment in the changelog about this macro.

[...]


+for ( ; ; level++ )
+{
+/*
+ * Add offset given by the GVA to the translation table base address.
+ * Shift the offset by 3 as it is 8-byte aligned.
+ */
+paddr |= offsets[gran][level] << 3;
+
+/* Access the guest's memory to read only one PTE. */
+ret = vgic_access_guest_memory(d, paddr, , sizeof(lpae_t), false);


It really doesn't make sense to call a function vgic_* in guest page 
table walk code. I wasn't expected that I needed to explicitly say that 
vgic_access_* should be moved in ARM generic code and be renamed.


[...]


+/*
+ * According to to ARM DDI 0487B.a J1-5927, we return an error if the found
+ * PTE is invalid or holds a reserved entry (PTE<1:0> == x0)) or if the PTE
+ * maps a memory block at level 3 (PTE<1:0> == 01).
+ */
+if ( !lpae_valid(pte) || ((level == 3) && !lpae_page(pte, level)) )


NIT: What you want to check here is either the entry is a superpage or a 
page. So the below check would be easier to parse:


if ( !lpae_is_superpage(pte, level) || !lpae_is_page(pte, level) )


+return -EFAULT;
+
+*ipa = pfn_to_paddr(pte.walk.base) | (gva & masks[gran][level]);
+
+/*
+ * Set permissions so that the caller can check the flags by herself. Note
+ * that stage 1 translations also inherit attributes from the tables
+ * (ARM DDI 0487B.a J1-5928).
+ */
+if ( !pte.pt.ro && !ro_table )
+*perms |= GV2M_WRITE;
+if ( !pte.pt.xn && !xn_table )
+*perms |= GV2M_EXEC;
+
+return 0;
+}
+
+#undef CHECK_BASE_SIZE
+
  int guest_walk_tables(const struct vcpu *v, vaddr_t gva,
paddr_t *ipa, unsigned int *perms)
  {



Cheers,

--
Julien Grall

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

Re: [Xen-devel] What is provided with the Xen Tools and why do I need them?

['Roger Pau Monné']

On Tue, Jul 04, 2017 at 09:45:19AM -0700, Nick Garnett wrote:
> 
> 
> -Original Message-
> From: Roger Pau Monné [mailto:roger@citrix.com] 
> Sent: Tuesday, July 04, 2017 09:40
> To: Nick Garnett 
> Cc: xen-devel@lists.xen.org
> Subject: Re: [Xen-devel] What is provided with the Xen Tools and why do I
> need them?
> 
> Hello,
> 
> Please avoid top-posting, it breaks the flow of the conversation.
> 
> On Tue, Jul 04, 2017 at 09:34:17AM -0700, Nick Garnett wrote:
> > Is "xl" the application that is installed following the "Xen ARM with 
> > Virtualization Extensions/CrossCompiling" page, "Build arm64 tools"
> section?
> 
> Yes, those are the tools I was referring to.
> 
> > I was able to install the "xen-tools" package with no issues, 
> > following the "xen-tools - a straightforward VM 
> > provisioning/installation tool" page 
> > ("https://blog.xenproject.org/2012/08/31/xen-tools-a-straightforward-v
> > m-prov
> > isioninginstallation-tool/").
> 
> OK, this is not the tools I was referring to. Sadly someone decided to
> create a completely different application that's used for provisioning vm
> images, and decided to name it xen-tools. This is not mandatory in order to
> run a Xen Dom0.
> 
> > Does that package provide the only "Xen Tools" that are necessary?
> 
> No.
> 
> Roger.
> 
> _
> 
> So, the "xen-tools" package does not provide all of the tools that are
> necessary.  It provides xl/xm, so what else is necessary?

I assume you are trying to cross-compile Xen for arm64, so you need to
build the tools as listed here:

https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/CrossCompiling#Build_arm64_tools

Roger.

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

Re: [Xen-devel] [PATCH] xen-blkfront: emit KOBJ_OFFLINE uevent when detaching device

[Roger Pau Monné]

On Tue, Jul 04, 2017 at 01:48:32PM +0200, Vincent Legout wrote:
> Devices are not unmounted inside a domU after a xl block-detach.
> 
> After xl block-detach, blkfront_closing() is called with state ==
> XenbusStateConnected, it detects that the device is still in use and
> only switches state to XenbusStateClosing. blkfront_closing() is called
> a second time but returns immediately because state ==
> XenbusStateClosing. Thus the device keeps being mounted inside the domU.
> 
> To fix this, emit a KOBJ_OFFLINE uevent even if the device has users.
> 
> With this patch, inside domU, udev has:
> 
> KERNEL[16994.526789] offline  /devices/vbd-51728/block/xvdb (block)
> KERNEL[16994.796197] remove   /devices/virtual/bdi/202:16 (bdi)
> KERNEL[16994.797167] remove   /devices/vbd-51728/block/xvdb (block)
> UDEV  [16994.798035] remove   /devices/virtual/bdi/202:16 (bdi)
> UDEV  [16994.809429] offline  /devices/vbd-51728/block/xvdb (block)
> UDEV  [16994.842365] remove   /devices/vbd-51728/block/xvdb (block)
> KERNEL[16995.461991] remove   /devices/vbd-51728 (xen)
> UDEV  [16995.462549] remove   /devices/vbd-51728 (xen)

I'm not an expect on udev, but aren't those messages duplicated? You
seem to get one message from udev and another one from the kernel.

> While without, it had:
> 
> KERNEL[30.862764] remove   /devices/vbd-51728 (xen)
> UDEV  [30.867838] remove   /devices/vbd-51728 (xen)
> 
> Signed-off-by: Pascal Bouchareine 
> Signed-off-by: Fatih Acar 
> Signed-off-by: Vincent Legout 
>
>  drivers/block/xen-blkfront.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
> index 39459631667c..da0b0444ee1f 100644
> --- a/drivers/block/xen-blkfront.c
> +++ b/drivers/block/xen-blkfront.c
> @@ -2185,8 +2185,10 @@ static void blkfront_closing(struct blkfront_info 
> *info)
>   mutex_lock(>bd_mutex);
>  
>   if (bdev->bd_openers) {
> - xenbus_dev_error(xbdev, -EBUSY,
> -  "Device in use; refusing to close");
> + dev_warn(disk_to_dev(info->gd),
> +  "detaching %s with pending users\n",
> +  xbdev->nodename);
> + kobject_uevent(_to_dev(info->gd)->kobj, KOBJ_OFFLINE);

What happens if you simply remove the xenbus_dev_error but don't add
the kobject_uevent?

I'm asking because I don't see any other block device calling
directly kobject_uevent, and I'm sure this should be pretty similar to
what virtio or USB do when a block device is hot-unplugged.

For example blk_unregister_queue already contains a call to trigger a
kobject_uevent.

Thanks, Roger.

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

Re: [Xen-devel] [PATCH v5 09/12] arm/mem_access: Add software guest-page-table walk

[Julien Grall]

Hi Sergej,

On 06/27/2017 12:52 PM, Sergej Proskurin wrote:

The function p2m_mem_access_check_and_get_page in mem_access.c
translates a gva to an ipa by means of the hardware functionality of the
ARM architecture. This is implemented in the function gva_to_ipa. If
mem_access is active, hardware-based gva to ipa translation might fail,
as gva_to_ipa uses the guest's translation tables, access to which might
be restricted by the active VTTBR. To address this issue, in this commit
we add a software-based guest-page-table walk, which will be used by the
function p2m_mem_access_check_and_get_page perform the gva to ipa
translation in software in one of the following commits.

Note: The introduced function guest_walk_tables assumes that the domain,
the gva of which is to be translated, is running on the currently active
vCPU. To walk the guest's page tables on a different vCPU, the following
registers would need to be loaded: TCR_EL1, TTBR0_EL1, TTBR1_EL1, and
SCTLR_EL1.

Signed-off-by: Sergej Proskurin 
Acked-by: Julien Grall 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v2: Rename p2m_gva_to_ipa to p2m_walk_gpt and move it to p2m.c.

 Move the functionality responsible for walking long-descriptor based
 translation tables out of the function p2m_walk_gpt. Also move out
 the long-descriptor based translation out of this commit.

 Change function parameters in order to return access access rights
 to a requested gva.

 Cosmetic fixes.

v3: Rename the introduced functions to guest_walk_(tables|sd|ld) and
 move the implementation to guest_copy.(c|h).

 Set permissions in guest_walk_tables also if the MMU is disabled.

 Change the function parameter of type "struct p2m_domain *" to
 "struct vcpu *" in the function guest_walk_tables.

v4: Change the function parameter of type "struct p2m_domain *" to
 "struct vcpu *" in the functions guest_walk_(sd|ld) as well.

v5: Merge two if-statements in guest_walk_tables to ease readability.

 Set perms to GV2M_READ as to avoid undefined permissions.


I would appreciate if you mention that you kept my tag even with the 
change made and asked whether I am happy with it...


In this case, you need a bit more rationale to explain why setting to 
GV2M_READ by default is fine... If it is just a random value, then say it.


Cheers.

--
Julien Grall

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

Re: [Xen-devel] What is provided with the Xen Tools and why do I need them?

[Wei Liu]

On Tue, Jul 04, 2017 at 09:34:17AM -0700, Nick Garnett wrote:
> Is "xl" the application that is installed following the "Xen ARM with
> Virtualization Extensions/CrossCompiling" page, "Build arm64 tools" section?
> 

I suppose so.

> I was able to install the "xen-tools" package with no issues, following the
> "xen-tools – a straightforward VM provisioning/installation tool" page
> ("https://blog.xenproject.org/2012/08/31/xen-tools-a-straightforward-vm-prov
> isioninginstallation-tool/").
> 
> Does that package provide the only "Xen Tools" that are necessary?

No. "xen-tools" (note the hyphen) is a third-party project to help you
provision VMs.

"Xen tools" should be read as "the userspace tools component of Xen
hypervsior project", which is part of the xen source code.

The confusion is a bit unfortunate.

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

Re: [Xen-devel] [PATCH v2 3/4] xen/mapcache: introduce xen_replace_cache_entry()

[Igor Druzhinin]

On 04/07/17 17:42, Paul Durrant wrote:
>> -Original Message-
>> From: Igor Druzhinin
>> Sent: 04 July 2017 17:34
>> To: Paul Durrant ; xen-de...@lists.xenproject.org;
>> qemu-de...@nongnu.org
>> Cc: sstabell...@kernel.org; Anthony Perard ;
>> pbonz...@redhat.com
>> Subject: Re: [PATCH v2 3/4] xen/mapcache: introduce
>> xen_replace_cache_entry()
>>
>> On 04/07/17 17:27, Paul Durrant wrote:
 -Original Message-
 From: Igor Druzhinin
 Sent: 04 July 2017 16:48
 To: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org
 Cc: Igor Druzhinin ; sstabell...@kernel.org;
 Anthony Perard ; Paul Durrant
 ; pbonz...@redhat.com
 Subject: [PATCH v2 3/4] xen/mapcache: introduce
 xen_replace_cache_entry()

 This new call is trying to update a requested map cache entry
 according to the changes in the physmap. The call is searching
 for the entry, unmaps it and maps again at the same place using
 a new guest address. If the mapping is dummy this call will
 make it real.

 This function makes use of a new xenforeignmemory_map2() call
 with an extended interface that was recently introduced in
 libxenforeignmemory [1].
>>>
>>> I don't understand how the compat layer works here. If
>> xenforeignmemory_map2() is not available then you can't control the
>> placement in virtual address space.
>>>
>>
>> If it's not 4.10 or newer xenforeignmemory_map2() doesn't exist and is
>> going to be defined as xenforeignmemory_map(). At the same time
>> XEN_COMPAT_PHYSMAP is defined and the entry replace function (which
>> relies on xenforeignmemory_map2 functionality) is never going to be called.
>>
>> If you mean that I should incorporate this into the description I can do it.
> 
> AFAICT XEN_COMPAT_PHYSMAP is not introduced until patch #4 though.
> 
> The problem really comes down to defining xenforeignmemory_map2() in terms of 
> xenforeignmemory_map(). It basically can't be safely done. Could you define 
> xenforeignmemory_map2() as abort() in the compat case instead? 
>

xen_replace_cache_entry() is not called in patch #3. Which means it's
safe to use a fallback version (xenforeignmemory_map) in
xen_remap_bucket here.

Igor

>   Paul
> 
>>
>> Igor
>>
>>>   Paul
>>>

 [1] https://www.mail-archive.com/xen-
>> de...@lists.xen.org/msg113007.html

 Signed-off-by: Igor Druzhinin 
 ---
  configure | 18 ++
  hw/i386/xen/xen-mapcache.c| 79
 ++-
  include/hw/xen/xen_common.h   |  7 
  include/sysemu/xen-mapcache.h | 11 +-
  4 files changed, 106 insertions(+), 9 deletions(-)

 diff --git a/configure b/configure
 index c571ad1..ad6156b 100755
 --- a/configure
 +++ b/configure
 @@ -2021,6 +2021,24 @@ EOF
  # Xen unstable
  elif
  cat > $TMPC <>>> +#undef XC_WANT_COMPAT_MAP_FOREIGN_API
 +#include 
 +int main(void) {
 +  xenforeignmemory_handle *xfmem;
 +
 +  xfmem = xenforeignmemory_open(0, 0);
 +  xenforeignmemory_map2(xfmem, 0, 0, 0, 0, 0, 0, 0);
 +
 +  return 0;
 +}
 +EOF
 +compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
 +  then
 +  xen_stable_libs="-lxendevicemodel $xen_stable_libs"
 +  xen_ctrl_version=41000
 +  xen=yes
 +elif
 +cat > $TMPC <>>>  #undef XC_WANT_COMPAT_DEVICEMODEL_API
  #define __XEN_TOOLS__
  #include 
 diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
 index cd4e746..a988be7 100644
 --- a/hw/i386/xen/xen-mapcache.c
 +++ b/hw/i386/xen/xen-mapcache.c
 @@ -151,6 +151,7 @@ void
>> xen_map_cache_init(phys_offset_to_gaddr_t f,
 void *opaque)
  }

  static void xen_remap_bucket(MapCacheEntry *entry,
 + void *vaddr,
   hwaddr size,
   hwaddr address_index,
   bool dummy)
 @@ -167,7 +168,9 @@ static void xen_remap_bucket(MapCacheEntry
 *entry,
  err = g_malloc0(nb_pfn * sizeof (int));

  if (entry->vaddr_base != NULL) {
 -ram_block_notify_remove(entry->vaddr_base, entry->size);
 +if (entry->vaddr_base != vaddr) {
 +ram_block_notify_remove(entry->vaddr_base, entry->size);
 +}
  if (munmap(entry->vaddr_base, entry->size) != 0) {
  perror("unmap fails");
  exit(-1);
 @@ -181,11 +184,11 @@ static void xen_remap_bucket(MapCacheEntry
 *entry,
  }

  if (!dummy) {
 -vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid,
 -  

Re: [Xen-devel] I was able to cross-compile the hypervisor on an amd64 host for the aarch64 target ... However, I can't build the Xen toolset

[Julien Grall]

Hello Nick,

Please avoid top-posting and keep mailing list CCed.

On 07/04/2017 05:42 PM, Nick Garnett wrote:

I tried installing the tools with an ARM64 chroot also and had a similar issue.  In that 
case, the package "crossbuild_essential_arm64" wouldn't install because it 
depended on a package that was not installable.


I don't use crossbuild within the chroot. My chroot contains ARM64 
binaries only and QEMU is used to run ARM64 binaries.


Which distributions are you targeting?

Cheers,

--
Julien Grall

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

Re: [Xen-devel] What is provided with the Xen Tools and why do I need them?

[Nick Garnett]

-Original Message-
From: Roger Pau Monné [mailto:roger@citrix.com] 
Sent: Tuesday, July 04, 2017 09:40
To: Nick Garnett 
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] What is provided with the Xen Tools and why do I
need them?

Hello,

Please avoid top-posting, it breaks the flow of the conversation.

On Tue, Jul 04, 2017 at 09:34:17AM -0700, Nick Garnett wrote:
> Is "xl" the application that is installed following the "Xen ARM with 
> Virtualization Extensions/CrossCompiling" page, "Build arm64 tools"
section?

Yes, those are the tools I was referring to.

> I was able to install the "xen-tools" package with no issues, 
> following the "xen-tools – a straightforward VM 
> provisioning/installation tool" page 
> ("https://blog.xenproject.org/2012/08/31/xen-tools-a-straightforward-v
> m-prov
> isioninginstallation-tool/").

OK, this is not the tools I was referring to. Sadly someone decided to
create a completely different application that's used for provisioning vm
images, and decided to name it xen-tools. This is not mandatory in order to
run a Xen Dom0.

> Does that package provide the only "Xen Tools" that are necessary?

No.

Roger.

_

So, the "xen-tools" package does not provide all of the tools that are
necessary.  It provides xl/xm, so what else is necessary?

OK, not top-posting.  Using a mail tool that puts replies at the top.



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

Re: [Xen-devel] [PATCH v2 3/4] xen/mapcache: introduce xen_replace_cache_entry()

[Paul Durrant]

> -Original Message-
> From: Igor Druzhinin
> Sent: 04 July 2017 17:34
> To: Paul Durrant ; xen-de...@lists.xenproject.org;
> qemu-de...@nongnu.org
> Cc: sstabell...@kernel.org; Anthony Perard ;
> pbonz...@redhat.com
> Subject: Re: [PATCH v2 3/4] xen/mapcache: introduce
> xen_replace_cache_entry()
> 
> On 04/07/17 17:27, Paul Durrant wrote:
> >> -Original Message-
> >> From: Igor Druzhinin
> >> Sent: 04 July 2017 16:48
> >> To: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org
> >> Cc: Igor Druzhinin ; sstabell...@kernel.org;
> >> Anthony Perard ; Paul Durrant
> >> ; pbonz...@redhat.com
> >> Subject: [PATCH v2 3/4] xen/mapcache: introduce
> >> xen_replace_cache_entry()
> >>
> >> This new call is trying to update a requested map cache entry
> >> according to the changes in the physmap. The call is searching
> >> for the entry, unmaps it and maps again at the same place using
> >> a new guest address. If the mapping is dummy this call will
> >> make it real.
> >>
> >> This function makes use of a new xenforeignmemory_map2() call
> >> with an extended interface that was recently introduced in
> >> libxenforeignmemory [1].
> >
> > I don't understand how the compat layer works here. If
> xenforeignmemory_map2() is not available then you can't control the
> placement in virtual address space.
> >
> 
> If it's not 4.10 or newer xenforeignmemory_map2() doesn't exist and is
> going to be defined as xenforeignmemory_map(). At the same time
> XEN_COMPAT_PHYSMAP is defined and the entry replace function (which
> relies on xenforeignmemory_map2 functionality) is never going to be called.
> 
> If you mean that I should incorporate this into the description I can do it.

AFAICT XEN_COMPAT_PHYSMAP is not introduced until patch #4 though.

The problem really comes down to defining xenforeignmemory_map2() in terms of 
xenforeignmemory_map(). It basically can't be safely done. Could you define 
xenforeignmemory_map2() as abort() in the compat case instead? 

  Paul

> 
> Igor
> 
> >   Paul
> >
> >>
> >> [1] https://www.mail-archive.com/xen-
> de...@lists.xen.org/msg113007.html
> >>
> >> Signed-off-by: Igor Druzhinin 
> >> ---
> >>  configure | 18 ++
> >>  hw/i386/xen/xen-mapcache.c| 79
> >> ++-
> >>  include/hw/xen/xen_common.h   |  7 
> >>  include/sysemu/xen-mapcache.h | 11 +-
> >>  4 files changed, 106 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/configure b/configure
> >> index c571ad1..ad6156b 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -2021,6 +2021,24 @@ EOF
> >>  # Xen unstable
> >>  elif
> >>  cat > $TMPC < >> +#undef XC_WANT_COMPAT_MAP_FOREIGN_API
> >> +#include 
> >> +int main(void) {
> >> +  xenforeignmemory_handle *xfmem;
> >> +
> >> +  xfmem = xenforeignmemory_open(0, 0);
> >> +  xenforeignmemory_map2(xfmem, 0, 0, 0, 0, 0, 0, 0);
> >> +
> >> +  return 0;
> >> +}
> >> +EOF
> >> +compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
> >> +  then
> >> +  xen_stable_libs="-lxendevicemodel $xen_stable_libs"
> >> +  xen_ctrl_version=41000
> >> +  xen=yes
> >> +elif
> >> +cat > $TMPC < >>  #undef XC_WANT_COMPAT_DEVICEMODEL_API
> >>  #define __XEN_TOOLS__
> >>  #include 
> >> diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
> >> index cd4e746..a988be7 100644
> >> --- a/hw/i386/xen/xen-mapcache.c
> >> +++ b/hw/i386/xen/xen-mapcache.c
> >> @@ -151,6 +151,7 @@ void
> xen_map_cache_init(phys_offset_to_gaddr_t f,
> >> void *opaque)
> >>  }
> >>
> >>  static void xen_remap_bucket(MapCacheEntry *entry,
> >> + void *vaddr,
> >>   hwaddr size,
> >>   hwaddr address_index,
> >>   bool dummy)
> >> @@ -167,7 +168,9 @@ static void xen_remap_bucket(MapCacheEntry
> >> *entry,
> >>  err = g_malloc0(nb_pfn * sizeof (int));
> >>
> >>  if (entry->vaddr_base != NULL) {
> >> -ram_block_notify_remove(entry->vaddr_base, entry->size);
> >> +if (entry->vaddr_base != vaddr) {
> >> +ram_block_notify_remove(entry->vaddr_base, entry->size);
> >> +}
> >>  if (munmap(entry->vaddr_base, entry->size) != 0) {
> >>  perror("unmap fails");
> >>  exit(-1);
> >> @@ -181,11 +184,11 @@ static void xen_remap_bucket(MapCacheEntry
> >> *entry,
> >>  }
> >>
> >>  if (!dummy) {
> >> -vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid,
> >> -   PROT_READ|PROT_WRITE,
> >> +vaddr_base = xenforeignmemory_map2(xen_fmem, xen_domid,
> >> vaddr,
> >> +   PROT_READ|PROT_WRITE, 0,
> >> 

Re: [Xen-devel] What is provided with the Xen Tools and why do I need them?

[Roger Pau Monné]

Hello,

Please avoid top-posting, it breaks the flow of the conversation.

On Tue, Jul 04, 2017 at 09:34:17AM -0700, Nick Garnett wrote:
> Is "xl" the application that is installed following the "Xen ARM with
> Virtualization Extensions/CrossCompiling" page, "Build arm64 tools" section?

Yes, those are the tools I was referring to.

> I was able to install the "xen-tools" package with no issues, following the
> "xen-tools – a straightforward VM provisioning/installation tool" page
> ("https://blog.xenproject.org/2012/08/31/xen-tools-a-straightforward-vm-prov
> isioninginstallation-tool/").

OK, this is not the tools I was referring to. Sadly someone decided to
create a completely different application that's used for provisioning
vm images, and decided to name it xen-tools. This is not mandatory in
order to run a Xen Dom0.

> Does that package provide the only "Xen Tools" that are necessary?

No.

Roger.

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

Re: [Xen-devel] What is provided with the Xen Tools and why do I need them?

[Nick Garnett]

Is "xl" the application that is installed following the "Xen ARM with
Virtualization Extensions/CrossCompiling" page, "Build arm64 tools" section?

I was able to install the "xen-tools" package with no issues, following the
"xen-tools – a straightforward VM provisioning/installation tool" page
("https://blog.xenproject.org/2012/08/31/xen-tools-a-straightforward-vm-prov
isioninginstallation-tool/").

Does that package provide the only "Xen Tools" that are necessary?

-Original Message-
From: Roger Pau Monné [mailto:roger@citrix.com] 
Sent: Tuesday, July 04, 2017 01:39
To: Nick Garnett 
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] What is provided with the Xen Tools and why do I
need them?

On Mon, Jul 03, 2017 at 11:44:33AM -0700, Nick Garnett wrote:
> There are many references to the "Xen Tools", but I can't find any 
> documentation that explains what the "Xen Tools" are.
>
> What is provided with the Xen Tools and why do I need them?

The Xen tools are used to create and manage virtual machines. See xl(1)[0]
for more information.

Roger.

[0] http://xenbits.xen.org/docs/unstable/man/xl.1.html



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

Re: [Xen-devel] What is provided with the Xen Tools and why do I need them?

[Nick Garnett]

Is "xl" the application that is installed following the "Xen ARM with
Virtualization Extensions/CrossCompiling" page, "Build arm64 tools" section?

I was able to install the "xen-tools" package with no issues, following the
"xen-tools – a straightforward VM provisioning/installation tool" page
("https://blog.xenproject.org/2012/08/31/xen-tools-a-straightforward-vm-prov
isioninginstallation-tool/").

Does that package provide the only "Xen Tools" that are necessary?

-Original Message-
From: Roger Pau Monné [mailto:roger@citrix.com] 
Sent: Tuesday, July 04, 2017 01:39
To: Nick Garnett 
Cc: xen-devel@lists.xen.org
Subject: Re: [Xen-devel] What is provided with the Xen Tools and why do I
need them?

On Mon, Jul 03, 2017 at 11:44:33AM -0700, Nick Garnett wrote:
> There are many references to the "Xen Tools", but I can't find any 
> documentation that explains what the "Xen Tools" are.
>
> What is provided with the Xen Tools and why do I need them?

The Xen tools are used to create and manage virtual machines. See xl(1)[0]
for more information.

Roger.

[0] http://xenbits.xen.org/docs/unstable/man/xl.1.html



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

[Xen-devel] time does not move forward in HVM guests

[Olaf Hering]

In my testing with sysbench in a HVM domU running a linux-4.4 based
pvops kernel on a xen-4.7 based dom0 the time does not move forward
properly:

There (URL below) is basically code like this:
  clock_gettime(CLOCK_MONOTONIC, a)
  do_work
  clock_gettime(CLOCK_MONOTONIC, b)
  diff_time(a,b)

All 'do_work' does is writing zeros to a block of memory.
clock_getres(CLOCK_MONOTONIC) indicates a resolution of 1ns.
If 'do_work' takes like 100ns or less: a==b. I think this is something
that should not happen. In case of vcpu overcommit this happens also
when 'do_work' takes around 800ns. At some point I have also seen cases
of time going backward. I can not reproduce this anymore, might have
been bugs in my code or the domU.cfg changed.

A workaround is booting the domU kernel with 'clocksource=tsc nohz=off 
highres=off'.

Why does this happen? Are the expectations too high?


Olaf


 https://github.com/olafhering/sysbench/compare/master...pv
 bash autogen.sh
 make -j
 bash mem.1K.on.sh


signature.asc
Description: PGP signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v2 3/4] xen/mapcache: introduce xen_replace_cache_entry()

[Igor Druzhinin]

On 04/07/17 17:27, Paul Durrant wrote:
>> -Original Message-
>> From: Igor Druzhinin
>> Sent: 04 July 2017 16:48
>> To: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org
>> Cc: Igor Druzhinin ; sstabell...@kernel.org;
>> Anthony Perard ; Paul Durrant
>> ; pbonz...@redhat.com
>> Subject: [PATCH v2 3/4] xen/mapcache: introduce
>> xen_replace_cache_entry()
>>
>> This new call is trying to update a requested map cache entry
>> according to the changes in the physmap. The call is searching
>> for the entry, unmaps it and maps again at the same place using
>> a new guest address. If the mapping is dummy this call will
>> make it real.
>>
>> This function makes use of a new xenforeignmemory_map2() call
>> with an extended interface that was recently introduced in
>> libxenforeignmemory [1].
> 
> I don't understand how the compat layer works here. If 
> xenforeignmemory_map2() is not available then you can't control the placement 
> in virtual address space.
> 

If it's not 4.10 or newer xenforeignmemory_map2() doesn't exist and is
going to be defined as xenforeignmemory_map(). At the same time
XEN_COMPAT_PHYSMAP is defined and the entry replace function (which
relies on xenforeignmemory_map2 functionality) is never going to be called.

If you mean that I should incorporate this into the description I can do it.

Igor

>   Paul
> 
>>
>> [1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg113007.html
>>
>> Signed-off-by: Igor Druzhinin 
>> ---
>>  configure | 18 ++
>>  hw/i386/xen/xen-mapcache.c| 79
>> ++-
>>  include/hw/xen/xen_common.h   |  7 
>>  include/sysemu/xen-mapcache.h | 11 +-
>>  4 files changed, 106 insertions(+), 9 deletions(-)
>>
>> diff --git a/configure b/configure
>> index c571ad1..ad6156b 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2021,6 +2021,24 @@ EOF
>>  # Xen unstable
>>  elif
>>  cat > $TMPC <> +#undef XC_WANT_COMPAT_MAP_FOREIGN_API
>> +#include 
>> +int main(void) {
>> +  xenforeignmemory_handle *xfmem;
>> +
>> +  xfmem = xenforeignmemory_open(0, 0);
>> +  xenforeignmemory_map2(xfmem, 0, 0, 0, 0, 0, 0, 0);
>> +
>> +  return 0;
>> +}
>> +EOF
>> +compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
>> +  then
>> +  xen_stable_libs="-lxendevicemodel $xen_stable_libs"
>> +  xen_ctrl_version=41000
>> +  xen=yes
>> +elif
>> +cat > $TMPC <>  #undef XC_WANT_COMPAT_DEVICEMODEL_API
>>  #define __XEN_TOOLS__
>>  #include 
>> diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
>> index cd4e746..a988be7 100644
>> --- a/hw/i386/xen/xen-mapcache.c
>> +++ b/hw/i386/xen/xen-mapcache.c
>> @@ -151,6 +151,7 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f,
>> void *opaque)
>>  }
>>
>>  static void xen_remap_bucket(MapCacheEntry *entry,
>> + void *vaddr,
>>   hwaddr size,
>>   hwaddr address_index,
>>   bool dummy)
>> @@ -167,7 +168,9 @@ static void xen_remap_bucket(MapCacheEntry
>> *entry,
>>  err = g_malloc0(nb_pfn * sizeof (int));
>>
>>  if (entry->vaddr_base != NULL) {
>> -ram_block_notify_remove(entry->vaddr_base, entry->size);
>> +if (entry->vaddr_base != vaddr) {
>> +ram_block_notify_remove(entry->vaddr_base, entry->size);
>> +}
>>  if (munmap(entry->vaddr_base, entry->size) != 0) {
>>  perror("unmap fails");
>>  exit(-1);
>> @@ -181,11 +184,11 @@ static void xen_remap_bucket(MapCacheEntry
>> *entry,
>>  }
>>
>>  if (!dummy) {
>> -vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid,
>> -   PROT_READ|PROT_WRITE,
>> +vaddr_base = xenforeignmemory_map2(xen_fmem, xen_domid,
>> vaddr,
>> +   PROT_READ|PROT_WRITE, 0,
>> nb_pfn, pfns, err);
>>  if (vaddr_base == NULL) {
>> -perror("xenforeignmemory_map");
>> +perror("xenforeignmemory_map2");
>>  exit(-1);
>>  }
>>  entry->flags &= ~(XEN_MAPCACHE_ENTRY_DUMMY);
>> @@ -194,7 +197,7 @@ static void xen_remap_bucket(MapCacheEntry
>> *entry,
>>   * We create dummy mappings where we are unable to create a foreign
>>   * mapping immediately due to certain circumstances (i.e. on resume
>> now)
>>   */
>> -vaddr_base = mmap(NULL, size, PROT_READ|PROT_WRITE,
>> +vaddr_base = mmap(vaddr, size, PROT_READ|PROT_WRITE,
>>MAP_ANON|MAP_SHARED, -1, 0);
>>  if (vaddr_base == NULL) {
>>  perror("mmap");
>> @@ -203,13 +206,16 @@ static void xen_remap_bucket(MapCacheEntry
>> *entry,
>>  entry->flags |= 

Re: [Xen-devel] [PATCH v2 3/4] xen/mapcache: introduce xen_replace_cache_entry()

[Paul Durrant]

> -Original Message-
> From: Igor Druzhinin
> Sent: 04 July 2017 16:48
> To: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org
> Cc: Igor Druzhinin ; sstabell...@kernel.org;
> Anthony Perard ; Paul Durrant
> ; pbonz...@redhat.com
> Subject: [PATCH v2 3/4] xen/mapcache: introduce
> xen_replace_cache_entry()
> 
> This new call is trying to update a requested map cache entry
> according to the changes in the physmap. The call is searching
> for the entry, unmaps it and maps again at the same place using
> a new guest address. If the mapping is dummy this call will
> make it real.
> 
> This function makes use of a new xenforeignmemory_map2() call
> with an extended interface that was recently introduced in
> libxenforeignmemory [1].

I don't understand how the compat layer works here. If xenforeignmemory_map2() 
is not available then you can't control the placement in virtual address space.

  Paul

> 
> [1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg113007.html
> 
> Signed-off-by: Igor Druzhinin 
> ---
>  configure | 18 ++
>  hw/i386/xen/xen-mapcache.c| 79
> ++-
>  include/hw/xen/xen_common.h   |  7 
>  include/sysemu/xen-mapcache.h | 11 +-
>  4 files changed, 106 insertions(+), 9 deletions(-)
> 
> diff --git a/configure b/configure
> index c571ad1..ad6156b 100755
> --- a/configure
> +++ b/configure
> @@ -2021,6 +2021,24 @@ EOF
>  # Xen unstable
>  elif
>  cat > $TMPC < +#undef XC_WANT_COMPAT_MAP_FOREIGN_API
> +#include 
> +int main(void) {
> +  xenforeignmemory_handle *xfmem;
> +
> +  xfmem = xenforeignmemory_open(0, 0);
> +  xenforeignmemory_map2(xfmem, 0, 0, 0, 0, 0, 0, 0);
> +
> +  return 0;
> +}
> +EOF
> +compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
> +  then
> +  xen_stable_libs="-lxendevicemodel $xen_stable_libs"
> +  xen_ctrl_version=41000
> +  xen=yes
> +elif
> +cat > $TMPC <  #undef XC_WANT_COMPAT_DEVICEMODEL_API
>  #define __XEN_TOOLS__
>  #include 
> diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
> index cd4e746..a988be7 100644
> --- a/hw/i386/xen/xen-mapcache.c
> +++ b/hw/i386/xen/xen-mapcache.c
> @@ -151,6 +151,7 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f,
> void *opaque)
>  }
> 
>  static void xen_remap_bucket(MapCacheEntry *entry,
> + void *vaddr,
>   hwaddr size,
>   hwaddr address_index,
>   bool dummy)
> @@ -167,7 +168,9 @@ static void xen_remap_bucket(MapCacheEntry
> *entry,
>  err = g_malloc0(nb_pfn * sizeof (int));
> 
>  if (entry->vaddr_base != NULL) {
> -ram_block_notify_remove(entry->vaddr_base, entry->size);
> +if (entry->vaddr_base != vaddr) {
> +ram_block_notify_remove(entry->vaddr_base, entry->size);
> +}
>  if (munmap(entry->vaddr_base, entry->size) != 0) {
>  perror("unmap fails");
>  exit(-1);
> @@ -181,11 +184,11 @@ static void xen_remap_bucket(MapCacheEntry
> *entry,
>  }
> 
>  if (!dummy) {
> -vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid,
> -   PROT_READ|PROT_WRITE,
> +vaddr_base = xenforeignmemory_map2(xen_fmem, xen_domid,
> vaddr,
> +   PROT_READ|PROT_WRITE, 0,
> nb_pfn, pfns, err);
>  if (vaddr_base == NULL) {
> -perror("xenforeignmemory_map");
> +perror("xenforeignmemory_map2");
>  exit(-1);
>  }
>  entry->flags &= ~(XEN_MAPCACHE_ENTRY_DUMMY);
> @@ -194,7 +197,7 @@ static void xen_remap_bucket(MapCacheEntry
> *entry,
>   * We create dummy mappings where we are unable to create a foreign
>   * mapping immediately due to certain circumstances (i.e. on resume
> now)
>   */
> -vaddr_base = mmap(NULL, size, PROT_READ|PROT_WRITE,
> +vaddr_base = mmap(vaddr, size, PROT_READ|PROT_WRITE,
>MAP_ANON|MAP_SHARED, -1, 0);
>  if (vaddr_base == NULL) {
>  perror("mmap");
> @@ -203,13 +206,16 @@ static void xen_remap_bucket(MapCacheEntry
> *entry,
>  entry->flags |= XEN_MAPCACHE_ENTRY_DUMMY;
>  }
> 
> +if (entry->vaddr_base == NULL || entry->vaddr_base != vaddr) {
> +ram_block_notify_add(vaddr_base, size);
> +}
> +
>  entry->vaddr_base = vaddr_base;
>  entry->paddr_index = address_index;
>  entry->size = size;
>  entry->valid_mapping = (unsigned long *) g_malloc0(sizeof(unsigned long)
> *
>  BITS_TO_LONGS(size >> XC_PAGE_SHIFT));
> 
> -ram_block_notify_add(entry->vaddr_base, entry->size);
>  bitmap_zero(entry->valid_mapping, nb_pfn);
> 

Re: [Xen-devel] [PATCH v5 08/12] arm/mem_access: Introduce GENMASK_ULL bit operation

[Julien Grall]

Hi Sergej,

On 06/27/2017 12:52 PM, Sergej Proskurin wrote:

The current implementation of GENMASK is capable of creating bitmasks of
32-bit values on AArch32 and 64-bit values on AArch64. As we need to
create masks for 64-bit values on AArch32 as well, in this commit we
introduce the GENMASK_ULL bit operation.

Signed-off-by: Sergej Proskurin  > ---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
  xen/include/asm-arm/config.h | 2 ++ >   xen/include/xen/bitops.h | 2 ++


This is common code and the relevant maintainers should have been CCed.

This is not the first time we are trying to introduce GENMASK_ULL. I 
would recommend you to read the following discussion:


https://patchwork.kernel.org/patch/9665869/

Cheers,


  2 files changed, 4 insertions(+)

diff --git a/xen/include/asm-arm/config.h b/xen/include/asm-arm/config.h
index 5b6f3c985d..7fa412f1b1 100644
--- a/xen/include/asm-arm/config.h
+++ b/xen/include/asm-arm/config.h
@@ -19,6 +19,8 @@
  #define BITS_PER_LONG (BYTES_PER_LONG << 3)
  #define POINTER_ALIGN BYTES_PER_LONG
  
+#define BITS_PER_LONG_LONG 64

+
  /* xen_ulong_t is always 64 bits */
  #define BITS_PER_XEN_ULONG 64
  
diff --git a/xen/include/xen/bitops.h b/xen/include/xen/bitops.h

index bd0883ab22..47170c9bfd 100644
--- a/xen/include/xen/bitops.h
+++ b/xen/include/xen/bitops.h
@@ -9,6 +9,8 @@
   */
  #define GENMASK(h, l) \
  (((~0UL) << (l)) & (~0UL >> (BITS_PER_LONG - 1 - (h
+#define GENMASK_ULL(h, l) \
+(((~0ULL) << (l)) & (~0ULL >> (BITS_PER_LONG_LONG - 1 - (h
  
  /*

   * ffs: find first bit set. This is defined the same way as



--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 07/12] arm/mem_access: Introduce BIT_ULL bit operation

[Julien Grall]

Hi Sergej,

On 06/27/2017 12:52 PM, Sergej Proskurin wrote:

We introduce the BIT_ULL macro to using values of unsigned long long as
to enable setting bits of 64-bit registers on AArch32.  In addition,
this commit adds a define holding the register width of 64 bit
double-word registers. This define simplifies using the associated
constants in the following commits.

Signed-off-by: Sergej Proskurin 


Reviewed-by: Julien Grall 

Cheers,


---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v4: We reused the previous commit with the msg "arm/mem_access: Add
 defines holding the width of 32/64bit regs" from v3, as we can reuse
 the already existing define BITS_PER_WORD.

v5: Introduce a new macro BIT_ULL instead of changing the type of the
 macro BIT.

 Remove the define BITS_PER_DOUBLE_WORD.
---
  xen/include/asm-arm/bitops.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/xen/include/asm-arm/bitops.h b/xen/include/asm-arm/bitops.h
index bda889841b..1cbfb9edb2 100644
--- a/xen/include/asm-arm/bitops.h
+++ b/xen/include/asm-arm/bitops.h
@@ -24,6 +24,7 @@
  #define BIT(nr) (1UL << (nr))
  #define BIT_MASK(nr)(1UL << ((nr) % BITS_PER_WORD))
  #define BIT_WORD(nr)((nr) / BITS_PER_WORD)
+#define BIT_ULL(nr) (1ULL << (nr))
  #define BITS_PER_BYTE   8
  
  #define ADDR (*(volatile int *) addr)




--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 05/12] arm/mem_access: Add short-descriptor pte typedefs and macros

[Julien Grall]

Hi Sergej,

On 06/27/2017 12:52 PM, Sergej Proskurin wrote:

The current implementation does not provide appropriate types for
short-descriptor translation table entries. As such, this commit adds new
types, which simplify managing the respective translation table entries.

Signed-off-by: Sergej Proskurin 


Acked-by: Julien Grall 

Cheers,


---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v3: Add more short-descriptor related pte typedefs that will be used by
 the following commits.

v4: Move short-descriptor pte typedefs out of page.h into short-desc.h.

 Change the type unsigned int to bool of every bitfield in
 short-descriptor related data-structures that holds only one bit.

 Change the typedef names from pte_sd_* to short_desc_*.

v5: Add {L1|L2}DESC_* defines to this commit.
---
  xen/include/asm-arm/short-desc.h | 130 +++
  1 file changed, 130 insertions(+)
  create mode 100644 xen/include/asm-arm/short-desc.h

diff --git a/xen/include/asm-arm/short-desc.h b/xen/include/asm-arm/short-desc.h
new file mode 100644
index 00..9652a103c4
--- /dev/null
+++ b/xen/include/asm-arm/short-desc.h
@@ -0,0 +1,130 @@
+#ifndef __ARM_SHORT_DESC_H__
+#define __ARM_SHORT_DESC_H__
+
+/*
+ * First level translation table descriptor types used by the AArch32
+ * short-descriptor translation table format.
+ */
+#define L1DESC_INVALID  (0)
+#define L1DESC_PAGE_TABLE   (1)
+#define L1DESC_SECTION  (2)
+#define L1DESC_SECTION_PXN  (3)
+
+/* Defines for section and supersection shifts. */
+#define L1DESC_SECTION_SHIFT(20)
+#define L1DESC_SUPERSECTION_SHIFT   (24)
+#define L1DESC_SUPERSECTION_EXT_BASE1_SHIFT (32)
+#define L1DESC_SUPERSECTION_EXT_BASE2_SHIFT (36)
+
+/* Second level translation table descriptor types. */
+#define L2DESC_INVALID  (0)
+
+/* Defines for small (4K) and large page (64K) shifts. */
+#define L2DESC_SMALL_PAGE_SHIFT (12)
+#define L2DESC_LARGE_PAGE_SHIFT (16)
+
+/*
+ * Comprises bits of the level 1 short-descriptor format representing
+ * a section.
+ */
+typedef struct __packed {
+bool pxn:1; /* Privileged Execute Never */
+bool sec:1; /* == 1 if section or supersection */
+bool b:1;   /* Bufferable */
+bool c:1;   /* Cacheable */
+bool xn:1;  /* Execute Never */
+unsigned int dom:4; /* Domain field */
+bool impl:1;/* Implementation defined */
+unsigned int ap:2;  /* AP[1:0] */
+unsigned int tex:3; /* TEX[2:0] */
+bool ro:1;  /* AP[2] */
+bool s:1;   /* Shareable */
+bool ng:1;  /* Non-global */
+bool supersec:1;/* Must be 0 for sections */
+bool ns:1;  /* Non-secure */
+unsigned int base:12;   /* Section base address */
+} short_desc_l1_sec_t;
+
+/*
+ * Comprises bits of the level 1 short-descriptor format representing
+ * a supersection.
+ */
+typedef struct __packed {
+bool pxn:1; /* Privileged Execute Never */
+bool sec:1; /* == 1 if section or supersection */
+bool b:1;   /* Bufferable */
+bool c:1;   /* Cacheable */
+bool xn:1;  /* Execute Never */
+unsigned int extbase2:4;/* Extended base address, PA[39:36] */
+bool impl:1;/* Implementation defined */
+unsigned int ap:2;  /* AP[1:0] */
+unsigned int tex:3; /* TEX[2:0] */
+bool ro:1;  /* AP[2] */
+bool s:1;   /* Shareable */
+bool ng:1;  /* Non-global */
+bool supersec:1;/* Must be 0 for sections */
+bool ns:1;  /* Non-secure */
+unsigned int extbase1:4;/* Extended base address, PA[35:32] */
+unsigned int base:8;/* Supersection base address */
+} short_desc_l1_supersec_t;
+
+/*
+ * Comprises bits of the level 2 short-descriptor format representing
+ * a small page.
+ */
+typedef struct __packed {
+bool xn:1;  /* Execute Never */
+bool page:1;/* ==1 if small page */
+bool b:1;   /* Bufferable */
+bool c:1;   /* Cacheable */
+unsigned int ap:2;  /* AP[1:0] */
+unsigned int tex:3; /* TEX[2:0] */
+bool ro:1;  /* AP[2] */
+bool s:1;   /* Shareable */
+bool ng:1;  /* Non-global */
+unsigned int base:20;   /* Small page base address */
+} short_desc_l2_page_t;
+
+/*
+ * Comprises bits of the level 2 short-descriptor format representing
+ * a large page.
+ */
+typedef struct 

Re: [Xen-devel] [PATCH v4 3/9] arm/mem_access: Add short-descriptor pte typedefs

[Julien Grall]

On 07/04/2017 05:22 PM, Julien Grall wrote:

Hi Sergekj,

On 06/20/2017 09:33 PM, Sergej Proskurin wrote:

The current implementation does not provide appropriate types for
short-descriptor translation table entries. As such, this commit adds new
types, which simplify managing the respective translation table entries.

Signed-off-by: Sergej Proskurin 


Acked-by: Julien Grall 


Hmmm, I commented on the wrong version. I will look at v5. Sorry for the 
noise.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 04/12] arm/lpae: Introduce lpae_page helper

[Julien Grall]

Hi Sergej,

On 06/27/2017 12:52 PM, Sergej Proskurin wrote:

This commit introduces a new helper that checks whether the target PTE
holds a page mapping or not. This helper will be used as part of the
following commits.

Signed-off-by: Sergej Proskurin 


Reviewed-by: Julien Grall 

Cheers,


---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
  xen/include/asm-arm/lpae.h | 5 +
  1 file changed, 5 insertions(+)

diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
index 2f7891ed0b..20565d2c8a 100644
--- a/xen/include/asm-arm/lpae.h
+++ b/xen/include/asm-arm/lpae.h
@@ -153,6 +153,11 @@ static inline bool lpae_is_superpage(lpae_t pte, unsigned 
int level)
  return (level < 3) && lpae_mapping(pte);
  }
  
+static inline bool lpae_page(lpae_t pte, unsigned int level)

+{
+return (level == 3) && lpae_valid(pte) && pte.walk.table;
+}
+
  /*
   * The ARMv8 architecture supports pages with different sizes (4K, 16K, and
   * 64K). To enable guest page table walks for various configurations, the



--
Julien Grall

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

Re: [Xen-devel] [PATCH v4 3/9] arm/mem_access: Add short-descriptor pte typedefs

[Julien Grall]

Hi Sergekj,

On 06/20/2017 09:33 PM, Sergej Proskurin wrote:

The current implementation does not provide appropriate types for
short-descriptor translation table entries. As such, this commit adds new
types, which simplify managing the respective translation table entries.

Signed-off-by: Sergej Proskurin 


Acked-by: Julien Grall 

Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v5 03/12] arm/mem_access: Add defines supporting PTs with varying page sizes

[Julien Grall]

Hi Sergej,

On 06/27/2017 12:52 PM, Sergej Proskurin wrote:

The ARMv8 architecture supports pages with different (4K, 16K, and 64K) sizes.
To enable guest page table walks for various configurations, this commit
extends the defines and helpers of the current implementation.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
v3: Eliminate redundant macro definitions by introducing generic macros.

v4: Replace existing macros with ones that generate static inline
 helpers as to ease the readability of the code.

 Move the introduced code into lpae.h

v5: Remove PAGE_SHIFT_* defines from lpae.h as we import them now from
 the header xen/lib.h.

 Remove *_guest_table_offset macros as to reduce the number of
 exported macros which are only used once. Instead, use the
 associated functionality directly within the
 GUEST_TABLE_OFFSET_HELPERS.

 Add comment in GUEST_TABLE_OFFSET_HELPERS stating that a page table
 with 64K page size granularity does not have a zeroeth lookup level.

 Add #undefs for GUEST_TABLE_OFFSET and GUEST_TABLE_OFFSET_HELPERS.

 Remove CONFIG_ARM_64 #defines.
---
  xen/include/asm-arm/lpae.h | 62 ++
  1 file changed, 62 insertions(+)

diff --git a/xen/include/asm-arm/lpae.h b/xen/include/asm-arm/lpae.h
index 6fbf7c606c..2f7891ed0b 100644
--- a/xen/include/asm-arm/lpae.h
+++ b/xen/include/asm-arm/lpae.h
@@ -3,6 +3,8 @@
  
  #ifndef __ASSEMBLY__
  
+#include 

+
  /*
   * WARNING!  Unlike the x86 pagetable code, where l1 is the lowest level and
   * l4 is the root of the trie, the ARM pagetables follow ARM's documentation:
@@ -151,6 +153,66 @@ static inline bool lpae_is_superpage(lpae_t pte, unsigned 
int level)
  return (level < 3) && lpae_mapping(pte);
  }
  
+/*

+ * The ARMv8 architecture supports pages with different sizes (4K, 16K, and
+ * 64K). To enable guest page table walks for various configurations, the
+ * following helpers enable walking the guest's translation table with varying
+ * page size granularities.
+ */
+
+#define LPAE_SHIFT_4K   (9)
+#define LPAE_SHIFT_16K  (11)
+#define LPAE_SHIFT_64K  (13)
+
+#define lpae_entries(gran)  (_AC(1,U) << LPAE_SHIFT_##gran)
+#define lpae_entry_mask(gran)   (lpae_entries(gran) - 1)
+
+#define third_shift(gran)   (PAGE_SHIFT_##gran)
+#define third_size(gran)((paddr_t)1 << third_shift(gran))
+
+#define second_shift(gran)  (third_shift(gran) + LPAE_SHIFT_##gran)
+#define second_size(gran)   ((paddr_t)1 << second_shift(gran))
+
+#define first_shift(gran)   (second_shift(gran) + LPAE_SHIFT_##gran)
+#define first_size(gran)((paddr_t)1 << first_shift(gran))
+
+/* Note that there is no zeroeth lookup level with a 64K granule size. */
+#define zeroeth_shift(gran) (first_shift(gran) + LPAE_SHIFT_##gran)
+#define zeroeth_size(gran)  ((paddr_t)1 << zeroeth_shift(gran))
+
+#define GUEST_TABLE_OFFSET(offs, gran)  ((paddr_t)(offs) & 
lpae_entry_mask(gran))
+#define GUEST_TABLE_OFFSET_HELPERS(gran)   
 \
+static inline vaddr_t third_guest_table_offset_##gran##K(vaddr_t gva)  
 \


Sorry I haven't spot it before. This is not going to work properly on 
32-bit if you use vaddr_t. Indeed, input for stage-2 page-table (i.e 
IPA) will be 40-bit. But vaddr_t is 32-bit. So you to use paddr_t here 
and in all the helpers below.



+{  
 \
+return GUEST_TABLE_OFFSET((gva >> third_shift(gran##K)), gran##K); 
 \
+}  
 \
+   
 \
+static inline vaddr_t second_guest_table_offset_##gran##K(vaddr_t gva) 
 \
+{  
 \
+return GUEST_TABLE_OFFSET((gva >> second_shift(gran##K)), gran##K);
 \
+}  
 \
+   
 \
+static inline vaddr_t first_guest_table_offset_##gran##K(vaddr_t gva)  
 \
+{  
 \
+return GUEST_TABLE_OFFSET(((paddr_t)gva >> first_shift(gran##K)), 
gran##K); \
+}  
 \
+   
 \
+static inline vaddr_t zeroeth_guest_table_offset_##gran##K(vaddr_t gva)
 \
+{ 

Re: [Xen-devel] [PATCH v2 2/4] xen/mapcache: add an ability to create dummy mappings

[Paul Durrant]

> -Original Message-
> From: Igor Druzhinin
> Sent: 04 July 2017 16:48
> To: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org
> Cc: Igor Druzhinin ; sstabell...@kernel.org;
> Anthony Perard ; Paul Durrant
> ; pbonz...@redhat.com
> Subject: [PATCH v2 2/4] xen/mapcache: add an ability to create dummy
> mappings
> 
> Dummys are simple anonymous mappings that are placed instead
> of regular foreign mappings in certain situations when we need
> to postpone the actual mapping but still have to give a
> memory region to QEMU to play with.
> 
> This is planned to be used for restore on Xen.
> 
> Signed-off-by: Igor Druzhinin 

Reviewed-by: Paul Durrant 

> ---
>  hw/i386/xen/xen-mapcache.c | 40
> 
>  1 file changed, 32 insertions(+), 8 deletions(-)
> 
> diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
> index e60156c..cd4e746 100644
> --- a/hw/i386/xen/xen-mapcache.c
> +++ b/hw/i386/xen/xen-mapcache.c
> @@ -53,6 +53,8 @@ typedef struct MapCacheEntry {
>  uint8_t *vaddr_base;
>  unsigned long *valid_mapping;
>  uint8_t lock;
> +#define XEN_MAPCACHE_ENTRY_DUMMY (1 << 0)
> +uint8_t flags;
>  hwaddr size;
>  struct MapCacheEntry *next;
>  } MapCacheEntry;
> @@ -150,7 +152,8 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f,
> void *opaque)
> 
>  static void xen_remap_bucket(MapCacheEntry *entry,
>   hwaddr size,
> - hwaddr address_index)
> + hwaddr address_index,
> + bool dummy)
>  {
>  uint8_t *vaddr_base;
>  xen_pfn_t *pfns;
> @@ -177,11 +180,27 @@ static void xen_remap_bucket(MapCacheEntry
> *entry,
>  pfns[i] = (address_index << (MCACHE_BUCKET_SHIFT-XC_PAGE_SHIFT))
> + i;
>  }
> 
> -vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid,
> PROT_READ|PROT_WRITE,
> -  nb_pfn, pfns, err);
> -if (vaddr_base == NULL) {
> -perror("xenforeignmemory_map");
> -exit(-1);
> +if (!dummy) {
> +vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid,
> +   PROT_READ|PROT_WRITE,
> +   nb_pfn, pfns, err);
> +if (vaddr_base == NULL) {
> +perror("xenforeignmemory_map");
> +exit(-1);
> +}
> +entry->flags &= ~(XEN_MAPCACHE_ENTRY_DUMMY);
> +} else {
> +/*
> + * We create dummy mappings where we are unable to create a foreign
> + * mapping immediately due to certain circumstances (i.e. on resume
> now)
> + */
> +vaddr_base = mmap(NULL, size, PROT_READ|PROT_WRITE,
> +  MAP_ANON|MAP_SHARED, -1, 0);
> +if (vaddr_base == NULL) {
> +perror("mmap");
> +exit(-1);
> +}
> +entry->flags |= XEN_MAPCACHE_ENTRY_DUMMY;
>  }
> 
>  entry->vaddr_base = vaddr_base;
> @@ -211,6 +230,7 @@ static uint8_t *xen_map_cache_unlocked(hwaddr
> phys_addr, hwaddr size,
>  hwaddr cache_size = size;
>  hwaddr test_bit_size;
>  bool translated = false;
> +bool dummy = false;
> 
>  tryagain:
>  address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
> @@ -262,14 +282,14 @@ tryagain:
>  if (!entry) {
>  entry = g_malloc0(sizeof (MapCacheEntry));
>  pentry->next = entry;
> -xen_remap_bucket(entry, cache_size, address_index);
> +xen_remap_bucket(entry, cache_size, address_index, dummy);
>  } else if (!entry->lock) {
>  if (!entry->vaddr_base || entry->paddr_index != address_index ||
>  entry->size != cache_size ||
>  !test_bits(address_offset >> XC_PAGE_SHIFT,
>  test_bit_size >> XC_PAGE_SHIFT,
>  entry->valid_mapping)) {
> -xen_remap_bucket(entry, cache_size, address_index);
> +xen_remap_bucket(entry, cache_size, address_index, dummy);
>  }
>  }
> 
> @@ -282,6 +302,10 @@ tryagain:
>  translated = true;
>  goto tryagain;
>  }
> +if (!dummy && runstate_check(RUN_STATE_INMIGRATE)) {
> +dummy = true;
> +goto tryagain;
> +}
>  trace_xen_map_cache_return(NULL);
>  return NULL;
>  }
> --
> 2.7.4


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

Re: [Xen-devel] [PATCH v2 1/4] xen: move physmap saving into a separate function

[Paul Durrant]

> -Original Message-
> From: Igor Druzhinin
> Sent: 04 July 2017 16:48
> To: xen-de...@lists.xenproject.org; qemu-de...@nongnu.org
> Cc: Igor Druzhinin ; sstabell...@kernel.org;
> Anthony Perard ; Paul Durrant
> ; pbonz...@redhat.com
> Subject: [PATCH v2 1/4] xen: move physmap saving into a separate function
> 
> Non-functional change.
> 
> Signed-off-by: Igor Druzhinin 

Reviewed-by: Paul Durrant 

> ---
>  hw/i386/xen/xen-hvm.c | 57 
> ---
>  1 file changed, 31 insertions(+), 26 deletions(-)
> 
> diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
> index cffa7e2..d259cf7 100644
> --- a/hw/i386/xen/xen-hvm.c
> +++ b/hw/i386/xen/xen-hvm.c
> @@ -305,6 +305,36 @@ static hwaddr xen_phys_offset_to_gaddr(hwaddr
> start_addr,
>  return start_addr;
>  }
> 
> +static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap)
> +{
> +char path[80], value[17];
> +
> +snprintf(path, sizeof(path),
> +"/local/domain/0/device-
> model/%d/physmap/%"PRIx64"/start_addr",
> +xen_domid, (uint64_t)physmap->phys_offset);
> +snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap-
> >start_addr);
> +if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
> +return -1;
> +}
> +snprintf(path, sizeof(path),
> +"/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
> +xen_domid, (uint64_t)physmap->phys_offset);
> +snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->size);
> +if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
> +return -1;
> +}
> +if (physmap->name) {
> +snprintf(path, sizeof(path),
> +"/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
> +xen_domid, (uint64_t)physmap->phys_offset);
> +if (!xs_write(state->xenstore, 0, path,
> +  physmap->name, strlen(physmap->name))) {
> +return -1;
> +}
> +}
> +return 0;
> +}
> +
>  static int xen_add_to_physmap(XenIOState *state,
>hwaddr start_addr,
>ram_addr_t size,
> @@ -316,7 +346,6 @@ static int xen_add_to_physmap(XenIOState *state,
>  XenPhysmap *physmap = NULL;
>  hwaddr pfn, start_gpfn;
>  hwaddr phys_offset = memory_region_get_ram_addr(mr);
> -char path[80], value[17];
>  const char *mr_name;
> 
>  if (get_physmapping(state, start_addr, size)) {
> @@ -368,31 +397,7 @@ go_physmap:
> start_addr >> TARGET_PAGE_BITS,
> (start_addr + size - 1) >> 
> TARGET_PAGE_BITS,
> XEN_DOMCTL_MEM_CACHEATTR_WB);
> -
> -snprintf(path, sizeof(path),
> -"/local/domain/0/device-
> model/%d/physmap/%"PRIx64"/start_addr",
> -xen_domid, (uint64_t)phys_offset);
> -snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)start_addr);
> -if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
> -return -1;
> -}
> -snprintf(path, sizeof(path),
> -"/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
> -xen_domid, (uint64_t)phys_offset);
> -snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)size);
> -if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
> -return -1;
> -}
> -if (mr_name) {
> -snprintf(path, sizeof(path),
> -"/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
> -xen_domid, (uint64_t)phys_offset);
> -if (!xs_write(state->xenstore, 0, path, mr_name, strlen(mr_name))) {
> -return -1;
> -}
> -}
> -
> -return 0;
> +return xen_save_physmap(state, physmap);
>  }
> 
>  static int xen_remove_from_physmap(XenIOState *state,
> --
> 2.7.4


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

Re: [Xen-devel] [PATCH v5 01/12] arm/mem_access: Add and cleanup (TCR_|TTBCR_)* defines

[Julien Grall]

Hi Sergej,

On 06/27/2017 12:52 PM, Sergej Proskurin wrote:

diff --git a/xen/include/asm-arm/processor.h b/xen/include/asm-arm/processor.h
index 855ded1b07..3dd439de33 100644
--- a/xen/include/asm-arm/processor.h
+++ b/xen/include/asm-arm/processor.h
@@ -94,6 +94,13 @@
  #define TTBCR_N_2KB  _AC(0x03,U)
  #define TTBCR_N_1KB  _AC(0x04,U)
  
+/*

+ * TTBCR_PD(0|1) can be applied only if LPAE is disabled, i.e., TTBCR.EAE==0
+ * (ARM DDI 0487B.a G6-5203 and ARM DDI 0406C.b B4-1722).
+ */
+#define TTBCR_PD0   (_AC(1,U)<<4)
+#define TTBCR_PD1   (_AC(1,U)<<5)
+
  /* SCTLR System Control Register. */
  /* HSCTLR is a subset of this. */
  #define SCTLR_TE(_AC(1,U)<<30)
@@ -154,7 +161,20 @@
  
  /* TCR: Stage 1 Translation Control */
  
-#define TCR_T0SZ(x) ((x)<<0)

+#define TCR_T0SZ_SHIFT  (0)
+#define TCR_T1SZ_SHIFT  (16)
+#define TCR_T0SZ(x) ((x)<

Cheers,

--
Julien Grall

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

[Xen-devel] [PATCH v2 3/4] xen/mapcache: introduce xen_replace_cache_entry()

[Igor Druzhinin]

This new call is trying to update a requested map cache entry
according to the changes in the physmap. The call is searching
for the entry, unmaps it and maps again at the same place using
a new guest address. If the mapping is dummy this call will
make it real.

This function makes use of a new xenforeignmemory_map2() call
with an extended interface that was recently introduced in
libxenforeignmemory [1].

[1] https://www.mail-archive.com/xen-devel@lists.xen.org/msg113007.html

Signed-off-by: Igor Druzhinin 
---
 configure | 18 ++
 hw/i386/xen/xen-mapcache.c| 79 ++-
 include/hw/xen/xen_common.h   |  7 
 include/sysemu/xen-mapcache.h | 11 +-
 4 files changed, 106 insertions(+), 9 deletions(-)

diff --git a/configure b/configure
index c571ad1..ad6156b 100755
--- a/configure
+++ b/configure
@@ -2021,6 +2021,24 @@ EOF
 # Xen unstable
 elif
 cat > $TMPC <
+int main(void) {
+  xenforeignmemory_handle *xfmem;
+
+  xfmem = xenforeignmemory_open(0, 0);
+  xenforeignmemory_map2(xfmem, 0, 0, 0, 0, 0, 0, 0);
+
+  return 0;
+}
+EOF
+compile_prog "" "$xen_libs -lxendevicemodel $xen_stable_libs"
+  then
+  xen_stable_libs="-lxendevicemodel $xen_stable_libs"
+  xen_ctrl_version=41000
+  xen=yes
+elif
+cat > $TMPC <
diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
index cd4e746..a988be7 100644
--- a/hw/i386/xen/xen-mapcache.c
+++ b/hw/i386/xen/xen-mapcache.c
@@ -151,6 +151,7 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f, void 
*opaque)
 }
 
 static void xen_remap_bucket(MapCacheEntry *entry,
+ void *vaddr,
  hwaddr size,
  hwaddr address_index,
  bool dummy)
@@ -167,7 +168,9 @@ static void xen_remap_bucket(MapCacheEntry *entry,
 err = g_malloc0(nb_pfn * sizeof (int));
 
 if (entry->vaddr_base != NULL) {
-ram_block_notify_remove(entry->vaddr_base, entry->size);
+if (entry->vaddr_base != vaddr) {
+ram_block_notify_remove(entry->vaddr_base, entry->size);
+}
 if (munmap(entry->vaddr_base, entry->size) != 0) {
 perror("unmap fails");
 exit(-1);
@@ -181,11 +184,11 @@ static void xen_remap_bucket(MapCacheEntry *entry,
 }
 
 if (!dummy) {
-vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid,
-   PROT_READ|PROT_WRITE,
+vaddr_base = xenforeignmemory_map2(xen_fmem, xen_domid, vaddr,
+   PROT_READ|PROT_WRITE, 0,
nb_pfn, pfns, err);
 if (vaddr_base == NULL) {
-perror("xenforeignmemory_map");
+perror("xenforeignmemory_map2");
 exit(-1);
 }
 entry->flags &= ~(XEN_MAPCACHE_ENTRY_DUMMY);
@@ -194,7 +197,7 @@ static void xen_remap_bucket(MapCacheEntry *entry,
  * We create dummy mappings where we are unable to create a foreign
  * mapping immediately due to certain circumstances (i.e. on resume 
now)
  */
-vaddr_base = mmap(NULL, size, PROT_READ|PROT_WRITE,
+vaddr_base = mmap(vaddr, size, PROT_READ|PROT_WRITE,
   MAP_ANON|MAP_SHARED, -1, 0);
 if (vaddr_base == NULL) {
 perror("mmap");
@@ -203,13 +206,16 @@ static void xen_remap_bucket(MapCacheEntry *entry,
 entry->flags |= XEN_MAPCACHE_ENTRY_DUMMY;
 }
 
+if (entry->vaddr_base == NULL || entry->vaddr_base != vaddr) {
+ram_block_notify_add(vaddr_base, size);
+}
+
 entry->vaddr_base = vaddr_base;
 entry->paddr_index = address_index;
 entry->size = size;
 entry->valid_mapping = (unsigned long *) g_malloc0(sizeof(unsigned long) *
 BITS_TO_LONGS(size >> XC_PAGE_SHIFT));
 
-ram_block_notify_add(entry->vaddr_base, entry->size);
 bitmap_zero(entry->valid_mapping, nb_pfn);
 for (i = 0; i < nb_pfn; i++) {
 if (!err[i]) {
@@ -282,14 +288,14 @@ tryagain:
 if (!entry) {
 entry = g_malloc0(sizeof (MapCacheEntry));
 pentry->next = entry;
-xen_remap_bucket(entry, cache_size, address_index, dummy);
+xen_remap_bucket(entry, NULL, cache_size, address_index, dummy);
 } else if (!entry->lock) {
 if (!entry->vaddr_base || entry->paddr_index != address_index ||
 entry->size != cache_size ||
 !test_bits(address_offset >> XC_PAGE_SHIFT,
 test_bit_size >> XC_PAGE_SHIFT,
 entry->valid_mapping)) {
-xen_remap_bucket(entry, cache_size, address_index, dummy);
+xen_remap_bucket(entry, NULL, cache_size, address_index, dummy);
 }
 }
 
@@ -486,3 +492,60 @@ void xen_invalidate_map_cache(void)
 
 mapcache_unlock();
 }
+
+static uint8_t 

[Xen-devel] [PATCH v2 0/4] xen: don't save/restore the physmap on VM save/restore

[Igor Druzhinin]

Saving/restoring the physmap to/from xenstore was introduced to
QEMU majorly in order to cover up the VRAM region restore issue.
The sequence of restore operations implies that we should know
the effective guest VRAM address *before* we have the VRAM region
restored (which happens later). Unfortunately, in Xen environment
VRAM memory does actually belong to a guest - not QEMU itself -
which means the position of this region is unknown beforehand and
can't be mapped into QEMU address space immediately.

Previously, recreating xenstore keys, holding the physmap, by the
toolstack helped to get this information in place at the right
moment ready to be consumed by QEMU to map the region properly.
But using xenstore for it has certain disadvantages: toolstack
needs to be aware of these keys and save/restore them accordingly;
accessing xenstore requires extra privileges which hinders QEMU
sandboxing.

The previous attempt to get rid of that was to remember all the
VRAM pointers during QEMU initialization phase and then update
them all at once when an actual foreign mapping is established.
Unfortunately, this approach worked only for VRAM and only for
a predefined set of devices - stdvga and cirrus. QXL and other
possible future devices using a moving emulated MMIO region
would be equally broken.

The new approach leverages xenforeignmemory_map2() call recently
introduced in libxenforeignmemory. It allows to create a dummy
anonymous mapping for QEMU during its initialization and change
it to a real one later during machine state restore.

---
Changed in v2:
* Patch 2: set dummy flag in a new flags field in struct MapCacheEntry
* Patch 3: change xen_remap_cache_entry name and signature
* Patch 3: gate ram_block_notify_* functions in xen_remap_bucket
* Patch 3: rewrite the logic of xen_replace_cache_entry_unlocked to
   reuse the existing entry instead of allocating a new one
* Patch 4: don't use xen_phys_offset_to_gaddr in non-compat mode

---
Igor Druzhinin (4):
  xen: move physmap saving into a separate function
  xen/mapcache: add an ability to create dummy mappings
  xen/mapcache: introduce xen_replace_cache_entry()
  xen: don't use xenstore to save/restore physmap anymore

 configure |  18 +++
 hw/i386/xen/xen-hvm.c | 105 ++---
 hw/i386/xen/xen-mapcache.c| 107 ++
 include/hw/xen/xen_common.h   |   8 
 include/sysemu/xen-mapcache.h |  11 -
 5 files changed, 201 insertions(+), 48 deletions(-)

-- 
2.7.4


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

[Xen-devel] [PATCH v2 4/4] xen: don't use xenstore to save/restore physmap anymore

[Igor Druzhinin]

If we have a system with xenforeignmemory_map2() implemented
we don't need to save/restore physmap on suspend/restore
anymore. In case we resume a VM without physmap - try to
recreate the physmap during memory region restore phase and
remap map cache entries accordingly. The old code is left
for compatibility reasons.

Signed-off-by: Igor Druzhinin 
---
 hw/i386/xen/xen-hvm.c   | 48 ++---
 include/hw/xen/xen_common.h |  1 +
 2 files changed, 38 insertions(+), 11 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index d259cf7..d24ca47 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -289,6 +289,7 @@ static XenPhysmap *get_physmapping(XenIOState *state,
 return NULL;
 }
 
+#ifdef XEN_COMPAT_PHYSMAP
 static hwaddr xen_phys_offset_to_gaddr(hwaddr start_addr,
ram_addr_t size, void 
*opaque)
 {
@@ -334,6 +335,12 @@ static int xen_save_physmap(XenIOState *state, XenPhysmap 
*physmap)
 }
 return 0;
 }
+#else
+static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap)
+{
+return 0;
+}
+#endif
 
 static int xen_add_to_physmap(XenIOState *state,
   hwaddr start_addr,
@@ -368,6 +375,26 @@ go_physmap:
 DPRINTF("mapping vram to %"HWADDR_PRIx" - %"HWADDR_PRIx"\n",
 start_addr, start_addr + size);
 
+mr_name = memory_region_name(mr);
+
+physmap = g_malloc(sizeof (XenPhysmap));
+
+physmap->start_addr = start_addr;
+physmap->size = size;
+physmap->name = mr_name;
+physmap->phys_offset = phys_offset;
+
+QLIST_INSERT_HEAD(>physmap, physmap, list);
+
+if (runstate_check(RUN_STATE_INMIGRATE)) {
+/* Now when we have a physmap entry we can replace a dummy mapping with
+ * a real one of guest foreign memory. */
+uint8_t *p = xen_replace_cache_entry(phys_offset, start_addr, size);
+assert(p && p == memory_region_get_ram_ptr(mr));
+
+return 0;
+}
+
 pfn = phys_offset >> TARGET_PAGE_BITS;
 start_gpfn = start_addr >> TARGET_PAGE_BITS;
 for (i = 0; i < size >> TARGET_PAGE_BITS; i++) {
@@ -382,17 +409,6 @@ go_physmap:
 }
 }
 
-mr_name = memory_region_name(mr);
-
-physmap = g_malloc(sizeof (XenPhysmap));
-
-physmap->start_addr = start_addr;
-physmap->size = size;
-physmap->name = mr_name;
-physmap->phys_offset = phys_offset;
-
-QLIST_INSERT_HEAD(>physmap, physmap, list);
-
 xc_domain_pin_memory_cacheattr(xen_xc, xen_domid,
start_addr >> TARGET_PAGE_BITS,
(start_addr + size - 1) >> TARGET_PAGE_BITS,
@@ -1158,6 +1174,7 @@ static void xen_exit_notifier(Notifier *n, void *data)
 xs_daemon_close(state->xenstore);
 }
 
+#ifdef XEN_COMPAT_PHYSMAP
 static void xen_read_physmap(XenIOState *state)
 {
 XenPhysmap *physmap = NULL;
@@ -1205,6 +1222,11 @@ static void xen_read_physmap(XenIOState *state)
 }
 free(entries);
 }
+#else
+static void xen_read_physmap(XenIOState *state)
+{
+}
+#endif
 
 static void xen_wakeup_notifier(Notifier *notifier, void *data)
 {
@@ -1331,7 +1353,11 @@ void xen_hvm_init(PCMachineState *pcms, MemoryRegion 
**ram_memory)
 state->bufioreq_local_port = rc;
 
 /* Init RAM management */
+#ifdef XEN_COMPAT_PHYSMAP
 xen_map_cache_init(xen_phys_offset_to_gaddr, state);
+#else
+xen_map_cache_init(NULL, state);
+#endif
 xen_ram_init(pcms, ram_size, ram_memory);
 
 qemu_add_vm_change_state_handler(xen_hvm_change_state_handler, state);
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 70a5cad..c04c5c9 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -80,6 +80,7 @@ extern xenforeignmemory_handle *xen_fmem;
 
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 41000
 
+#define XEN_COMPAT_PHYSMAP
 #define xenforeignmemory_map2(h, d, a, p, f, ps, ar, e) \
 xenforeignmemory_map(h, d, p, ps, ar, e)
 
-- 
2.7.4


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

[Xen-devel] [PATCH v2 1/4] xen: move physmap saving into a separate function

[Igor Druzhinin]

Non-functional change.

Signed-off-by: Igor Druzhinin 
---
 hw/i386/xen/xen-hvm.c | 57 ---
 1 file changed, 31 insertions(+), 26 deletions(-)

diff --git a/hw/i386/xen/xen-hvm.c b/hw/i386/xen/xen-hvm.c
index cffa7e2..d259cf7 100644
--- a/hw/i386/xen/xen-hvm.c
+++ b/hw/i386/xen/xen-hvm.c
@@ -305,6 +305,36 @@ static hwaddr xen_phys_offset_to_gaddr(hwaddr start_addr,
 return start_addr;
 }
 
+static int xen_save_physmap(XenIOState *state, XenPhysmap *physmap)
+{
+char path[80], value[17];
+
+snprintf(path, sizeof(path),
+"/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
+xen_domid, (uint64_t)physmap->phys_offset);
+snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->start_addr);
+if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+return -1;
+}
+snprintf(path, sizeof(path),
+"/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
+xen_domid, (uint64_t)physmap->phys_offset);
+snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)physmap->size);
+if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
+return -1;
+}
+if (physmap->name) {
+snprintf(path, sizeof(path),
+"/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
+xen_domid, (uint64_t)physmap->phys_offset);
+if (!xs_write(state->xenstore, 0, path,
+  physmap->name, strlen(physmap->name))) {
+return -1;
+}
+}
+return 0;
+}
+
 static int xen_add_to_physmap(XenIOState *state,
   hwaddr start_addr,
   ram_addr_t size,
@@ -316,7 +346,6 @@ static int xen_add_to_physmap(XenIOState *state,
 XenPhysmap *physmap = NULL;
 hwaddr pfn, start_gpfn;
 hwaddr phys_offset = memory_region_get_ram_addr(mr);
-char path[80], value[17];
 const char *mr_name;
 
 if (get_physmapping(state, start_addr, size)) {
@@ -368,31 +397,7 @@ go_physmap:
start_addr >> TARGET_PAGE_BITS,
(start_addr + size - 1) >> TARGET_PAGE_BITS,
XEN_DOMCTL_MEM_CACHEATTR_WB);
-
-snprintf(path, sizeof(path),
-"/local/domain/0/device-model/%d/physmap/%"PRIx64"/start_addr",
-xen_domid, (uint64_t)phys_offset);
-snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)start_addr);
-if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
-return -1;
-}
-snprintf(path, sizeof(path),
-"/local/domain/0/device-model/%d/physmap/%"PRIx64"/size",
-xen_domid, (uint64_t)phys_offset);
-snprintf(value, sizeof(value), "%"PRIx64, (uint64_t)size);
-if (!xs_write(state->xenstore, 0, path, value, strlen(value))) {
-return -1;
-}
-if (mr_name) {
-snprintf(path, sizeof(path),
-"/local/domain/0/device-model/%d/physmap/%"PRIx64"/name",
-xen_domid, (uint64_t)phys_offset);
-if (!xs_write(state->xenstore, 0, path, mr_name, strlen(mr_name))) {
-return -1;
-}
-}
-
-return 0;
+return xen_save_physmap(state, physmap);
 }
 
 static int xen_remove_from_physmap(XenIOState *state,
-- 
2.7.4


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

[Xen-devel] [PATCH v2 2/4] xen/mapcache: add an ability to create dummy mappings

[Igor Druzhinin]

Dummys are simple anonymous mappings that are placed instead
of regular foreign mappings in certain situations when we need
to postpone the actual mapping but still have to give a
memory region to QEMU to play with.

This is planned to be used for restore on Xen.

Signed-off-by: Igor Druzhinin 
---
 hw/i386/xen/xen-mapcache.c | 40 
 1 file changed, 32 insertions(+), 8 deletions(-)

diff --git a/hw/i386/xen/xen-mapcache.c b/hw/i386/xen/xen-mapcache.c
index e60156c..cd4e746 100644
--- a/hw/i386/xen/xen-mapcache.c
+++ b/hw/i386/xen/xen-mapcache.c
@@ -53,6 +53,8 @@ typedef struct MapCacheEntry {
 uint8_t *vaddr_base;
 unsigned long *valid_mapping;
 uint8_t lock;
+#define XEN_MAPCACHE_ENTRY_DUMMY (1 << 0)
+uint8_t flags;
 hwaddr size;
 struct MapCacheEntry *next;
 } MapCacheEntry;
@@ -150,7 +152,8 @@ void xen_map_cache_init(phys_offset_to_gaddr_t f, void 
*opaque)
 
 static void xen_remap_bucket(MapCacheEntry *entry,
  hwaddr size,
- hwaddr address_index)
+ hwaddr address_index,
+ bool dummy)
 {
 uint8_t *vaddr_base;
 xen_pfn_t *pfns;
@@ -177,11 +180,27 @@ static void xen_remap_bucket(MapCacheEntry *entry,
 pfns[i] = (address_index << (MCACHE_BUCKET_SHIFT-XC_PAGE_SHIFT)) + i;
 }
 
-vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid, 
PROT_READ|PROT_WRITE,
-  nb_pfn, pfns, err);
-if (vaddr_base == NULL) {
-perror("xenforeignmemory_map");
-exit(-1);
+if (!dummy) {
+vaddr_base = xenforeignmemory_map(xen_fmem, xen_domid,
+   PROT_READ|PROT_WRITE,
+   nb_pfn, pfns, err);
+if (vaddr_base == NULL) {
+perror("xenforeignmemory_map");
+exit(-1);
+}
+entry->flags &= ~(XEN_MAPCACHE_ENTRY_DUMMY);
+} else {
+/*
+ * We create dummy mappings where we are unable to create a foreign
+ * mapping immediately due to certain circumstances (i.e. on resume 
now)
+ */
+vaddr_base = mmap(NULL, size, PROT_READ|PROT_WRITE,
+  MAP_ANON|MAP_SHARED, -1, 0);
+if (vaddr_base == NULL) {
+perror("mmap");
+exit(-1);
+}
+entry->flags |= XEN_MAPCACHE_ENTRY_DUMMY;
 }
 
 entry->vaddr_base = vaddr_base;
@@ -211,6 +230,7 @@ static uint8_t *xen_map_cache_unlocked(hwaddr phys_addr, 
hwaddr size,
 hwaddr cache_size = size;
 hwaddr test_bit_size;
 bool translated = false;
+bool dummy = false;
 
 tryagain:
 address_index  = phys_addr >> MCACHE_BUCKET_SHIFT;
@@ -262,14 +282,14 @@ tryagain:
 if (!entry) {
 entry = g_malloc0(sizeof (MapCacheEntry));
 pentry->next = entry;
-xen_remap_bucket(entry, cache_size, address_index);
+xen_remap_bucket(entry, cache_size, address_index, dummy);
 } else if (!entry->lock) {
 if (!entry->vaddr_base || entry->paddr_index != address_index ||
 entry->size != cache_size ||
 !test_bits(address_offset >> XC_PAGE_SHIFT,
 test_bit_size >> XC_PAGE_SHIFT,
 entry->valid_mapping)) {
-xen_remap_bucket(entry, cache_size, address_index);
+xen_remap_bucket(entry, cache_size, address_index, dummy);
 }
 }
 
@@ -282,6 +302,10 @@ tryagain:
 translated = true;
 goto tryagain;
 }
+if (!dummy && runstate_check(RUN_STATE_INMIGRATE)) {
+dummy = true;
+goto tryagain;
+}
 trace_xen_map_cache_return(NULL);
 return NULL;
 }
-- 
2.7.4


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

Re: [Xen-devel] [PATCH 1/6] xen: Add support for hiding and unhiding pcie passthrough devices

[Jan Beulich]

>>> On 27.06.17 at 19:14,  wrote:

First of all, please Cc all maintainers of code you modify.

> xen: Add support for hiding and unhiding pcie passthrough devices

Please don't repeat the subject in the body of the mail.

> Add support for hiding and unhiding (by introducing two new hypercall
> subops) pci devices that trigger AER fatal errors while assigned to
> guests in passthrough mode. Hiding of the device is done by assigning
> it to dom_xen dummy domain.

Would you mind explaining why simply de-assigning the device
(with an existing operation) isn't suitable here? (This explanation
would presumably belong either in the description here or in the
cover letter.)

> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -393,9 +393,15 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>  {
>  case XEN_DOMCTL_createdomain:
>  case XEN_DOMCTL_test_assign_device:
> +case XEN_DOMCTL_test_hidden_device:
>  case XEN_DOMCTL_gdbsx_guestmemio:
>  d = NULL;
>  break;
> +case XEN_DOMCTL_hide_device:
> +case XEN_DOMCTL_unhide_device:
> +rcu_lock_domain(dom_xen);
> +d = dom_xen;
> +break;

I'm opposed to the introduction of new operations which ignore the
input domain ID. See my recent patch eliminating this for
XEN_DOMCTL_test_assign_device [1]. If these really are domain
independent operations, they ought to be sysctls.

> @@ -1333,19 +1334,31 @@ int iommu_remove_device(struct pci_dev *pdev)
>  return hd->platform_ops->remove_device(pdev->devfn, pci_to_dev(pdev));
>  }
>  
> +static bool device_assigned_to_domain(struct domain *d, u16 seg, u8 bus, u8 
> devfn)
> +{
> +bool rc = false;
> +
> +pcidevs_lock();
> +
> +if ( pci_get_pdev_by_domain(d, seg, bus, devfn) )
> +rc = true;
> +
> +pcidevs_unlock();
> +return rc;
> +}
> +
>  /*
>   * If the device isn't owned by the hardware domain, it means it already
>   * has been assigned to other domain, or it doesn't exist.
>   */
>  static int device_assigned(u16 seg, u8 bus, u8 devfn)
>  {
> -struct pci_dev *pdev;
> -
> -pcidevs_lock();
> -pdev = pci_get_pdev_by_domain(hardware_domain, seg, bus, devfn);
> -pcidevs_unlock();
> +return device_assigned_to_domain(hardware_domain, seg, bus, devfn) ? 0 : 
> -EBUSY;
> +}
>  
> -return pdev ? 0 : -EBUSY;
> +static int device_hidden(u16 seg, u8 bus, u8 devfn)
> +{
> +return device_assigned_to_domain(dom_xen, seg, bus, devfn) ? -EBUSY : 0;
>  }

At least this new function you add wants to return bool. I cannot
see how -EBUSY could be an appropriate return value for meaning
"yes".

> @@ -1354,6 +1367,22 @@ static int assign_device(struct domain *d, u16 seg, u8 
> bus, u8 devfn, u32 flag)
>  struct pci_dev *pdev;
>  int rc = 0;
>  
> +if ( device_hidden(seg, bus, devfn) )
> +return -EINVAL;
> +
> +if ( d == dom_xen )
> +{
> +pdev = pci_get_pdev(seg, bus, devfn);
> +if ( pdev )
> +{
> +list_move(>domain_list, _xen->arch.pdev_list);
> +pdev->domain = dom_xen;
> +return rc;
> +}
> +else
> +return -ENODEV;
> +}
> +
>  if ( !iommu_enabled || !hd->platform_ops )
>  return 0;

Your addition appears to be misplaced (would belong below the
checks seen above). Additionally you fail to acquire the pcidevs
lock. And the code would likely read better if you inverted the
inner if()'s condition and omitted the "else" and the braces.
Finally I'd prefer if you used d instead of dom_xen everywhere
inside the outer if().

> @@ -1679,7 +1743,86 @@ int iommu_do_pci_domctl(
> "deassign %04x:%02x:%02x.%u from dom%d failed (%d)\n",
> seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> d->domain_id, ret);
> +break;
> +
> +case XEN_DOMCTL_hide_device:
> +machine_sbdf = domctl->u.assign_device.u.pci.machine_sbdf;
> +ret = xsm_hide_device(XSM_HOOK, d, machine_sbdf);
> +if ( ret )
> +break;
> +
> +if ( unlikely(d->is_dying) )
> +{
> +ret = -EAGAIN;
> +break;
> +}
> +
> +seg = machine_sbdf >> 16;
> +bus = PCI_BUS(machine_sbdf);
> +devfn = PCI_DEVFN2(machine_sbdf);
> +flag = domctl->u.assign_device.flag;
> +
> +if ( device_hidden(seg, bus, devfn) )
> +{
> +ret = -EINVAL;
> +break;
> +}
> +
> +pcidevs_lock();
> +ret = assign_device(dom_xen, seg, bus, devfn, flag);
> +pcidevs_unlock();
> +if ( ret == -ERESTART )
> +ret = hypercall_create_continuation(__HYPERVISOR_domctl,
> +"h", u_domctl);
> +else if ( ret )
> +printk(XENLOG_G_ERR "XEN_DOMCTL_hide_device: "
> +   "hide %04x:%02x:%02x.%u failed (%d)\n",
> +

Re: [Xen-devel] [PATCH 1/7] xen/arm: SMMU: Implement the add_device callback in SMMU

[Julien Grall]

Hi Wei,

On 06/30/2017 04:15 AM, Wei Chen wrote:

This add_device callback function is taking care of adding a device
to SMMU and make sure it is fully prepare to be used by the SMMU
afterwards.

In previous code, we don't implement the add_device callback in
iommu_ops for ARM SMMU. We placed the work of add_device to
assign_device callback. The function assign_device should not care
about adding the device to an iommu_group. It might not even be
able to decide how to do that. In this patch, we move this work
back to add_device callback.

This add_device callback is only called while we are handling all
devices for constructing the Domain0.

Signed-off-by: Wei Chen 
---
  xen/drivers/passthrough/arm/smmu.c | 34 +++---
  1 file changed, 23 insertions(+), 11 deletions(-)

diff --git a/xen/drivers/passthrough/arm/smmu.c 
b/xen/drivers/passthrough/arm/smmu.c
index 74c09b0..2efa52d 100644
--- a/xen/drivers/passthrough/arm/smmu.c
+++ b/xen/drivers/passthrough/arm/smmu.c
@@ -2591,6 +2591,26 @@ static void arm_smmu_destroy_iommu_domain(struct 
iommu_domain *domain)
xfree(domain);
  }
  
+static int arm_smmu_xen_add_device(u8 devfn, struct device*dev)


Coding style: struct device *dev

Cheers,

--
Julien Grall

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

Re: [Xen-devel] I was able to cross-compile the hypervisor on an amd64 host for the aarch64 target ... However, I can't build the Xen toolset

[Julien Grall]

Hi,

On 07/04/2017 03:41 PM, Wei Liu wrote:

CC Julien and Stefano -- not sure if the wiki page should be updated


I don't cross-compile the tools usually but either build on the target 
or using an ARM chroot (setup with qemu-debootstrap).


Stefano seems to have updated the wiki page recently, maybe he is using it?



On Mon, Jul 03, 2017 at 11:41:37AM -0700, Nick Garnett wrote:

I was able to cross-compile the hypervisor on an amd64 host for the aarch64
target. However, I can't build the Xen toolset.

I am following the "Xen ARM with Virtualization Extensions/CrossCompiling"
page, "Build arm64 tools" section. When I execute:

"./configure --build=x86_64-unknown-linux-gnu --host=aarch64-linux-gnu", I
get the following errors:

checking for uuid_clear in -luuid... no
checking uuid.h usability... no
checking uuid.h presence... no
checking for uuid.h... no
configure: error: cannot find a valid uuid library
configure: error: ./configure failed for tools

I have installed uuid, uuid-dev uuid-runtime and uuidcdef, but continue to
get the same error. >>
If anyone has seen and resolved this issue, please provide details.

Regards, Nick Garnett

Zazzu Firmware Architect


Cheers,


--
Julien Grall

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

Re: [Xen-devel] RT-Xen on ARM

[Meng Xu]

On Tue, Jul 4, 2017 at 8:28 AM, Andrii Anisov  wrote:
>
>
> On 03.07.17 21:42, Meng Xu wrote:
>>
>> As far as I know, there is no known issue for ARM as long as that
>> version Xen runs on the ARM board.
>
>  That's good.
>>
>> I assume you have your own workloads to run, which are periodically
>> activated task.
>> The workloads in [1] are independent periodic CPU-intensive tasks: the
>> task does some computation for every period.
>> If your workloads are similar to the tasks, it should be ok.
>
> Actually now we have just a high-level use case without any specific 
> parameters defined.
> I.e. in an automotive system there should be a domain dedicated to 
> instrumental cluster beside IVI domain. IC domain should be RT.
> So we are just evaluating and experimenting with an existing functionality.
>
>> One thing in my mind that may affect your evaluations for your real
>> workload is what you want to achieve.
>>
>> The RTDS uses the EDF scheduling, under which the priorities of the
>> VCPUs (or VMs) are dynamically changed based on their (absolute)
>> deadlines. This provides better real-time performance for the
>> *overall* system.
>
> In case we would have a driver domain and IC domain would draw to pv display 
> baked by backend in a driver domain. Driver domain should be RT capable as 
> well.
> So it seems two domains should be RT beside non-RT IVI domain.
>
>> If you want to make one VM highest priority and let that VM preempt
>> other VMs whenever the highest priority VM is active, it's better to
>> use the RM or FP scheduling, instead of the EDF scheduling.
>
> So you are suggesting to introduce more RT schedulers with different 
> algorithms. Did I get you right?

The EDF scheduling cares about the overall system's RT performance. If
you want to guarantee the *soft* real-time performance of the IVI
domains and allow the IVI domain to delay the two RT domains in some
scheduling periods, the EDF scheduling is better than the RM
scheduling. Note that we need to reserve enough CPU resources to make
sure the delay from the IVI domain to the two RT domains won't cause
the deadline miss of the two RT domains.

The RM scheduling will guarantees a domain always has a higher
priority than another domain. If you want to eliminate the CPU delay
from the IVI domain to the other two RT domains, can tolerate some
deadline misses of the IVI domain, and want to consolidate the three
domains to *fewer* cores, the RM scheduling should be a better choice,
IMO.

Supporting the RM scheduling policy in the RTDS scheduler is not
difficult. Actually, the RTDS scheduler was designed to be able to
extend to other scheduling policies, such as RM scheduling. In the
RT-Xen project[1], it supports both RM and EDF scheduling policy. We
just choose to upstream the EDF first.

Currently, we are working on synchronizing the RT-Xen with the latest
Xen: we want to implement the RM scheduling policy in the latest Xen.
I'm also teaching/training a master student how to implement the
scheduling policies in the RTDS scheduler so that we can have more
contributors.

I personally am very interested in the realistic use case, especially
the automotive use cases, for the RTDS scheduler. If you have any use
case that we can help to test, please don't hesitate to ask.

[1] https://github.com/PennPanda/RT-Xen

Best,

Meng

---
Meng Xu
PhD Candidate in Computer and Information Science
University of Pennsylvania
http://www.cis.upenn.edu/~mengxu/

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

Re: [Xen-devel] [PATCH v1 5/6] vvmx: add per domain vmx msr policy

[Jan Beulich]

>>> On 26.06.17 at 12:44,  wrote:
> @@ -2085,7 +2097,7 @@ int nvmx_msr_read_intercept(unsigned int msr, u64 
> *msr_content)
>  {
>  struct vcpu *v = current;
>  struct domain *d = v->domain;
> -struct vmx_msr_policy *p = _max_vmx_msr_policy;
> +struct vmx_msr_policy *p = d->arch.vmx_msr;

I must have overlooked this in an earlier patch: This being the
read handler, you want to add const from the point on where
the variable gets being introduced. Apart from that
Reviewed-by: Jan Beulich 

Jan


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

Re: [Xen-devel] [PATCH v1 4/6] vvmx: add hvm_max_vmx_msr_policy

[Jan Beulich]

>>> On 26.06.17 at 12:44,  wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -244,6 +244,8 @@ static u32 adjust_vmx_controls(
>  return ctl;
>  }
>  
> +void calculate_hvm_max_policy(void);

As said for a prior patch, this once again needs to move to a header
which is also being included by the producer.

> --- a/xen/arch/x86/hvm/vmx/vvmx.c
> +++ b/xen/arch/x86/hvm/vmx/vvmx.c
> @@ -1941,6 +1941,8 @@ int nvmx_handle_invvpid(struct cpu_user_regs *regs)
>  return X86EMUL_OKAY;
>  }
>  
> +struct vmx_msr_policy __read_mostly hvm_max_vmx_msr_policy;

Wouldn't vvmx_max_msr_policy be unambiguous enough a name,
but shorter to type?

> @@ -1948,6 +1950,134 @@ int nvmx_handle_invvpid(struct cpu_user_regs *regs)
>  (((__emul_value(enable1, default1) & host_value) & (~0ul << 32)) | \
>  ((uint32_t)(__emul_value(enable1, default1) | host_value)))
>  
> +void __init calculate_hvm_max_policy(void)

This is not a suitable name for a VMX specific function. I should
have noticed and said this in patch 2 already, so please consider
it applicable there too.

> +{
> +struct vmx_msr_policy *p = _max_vmx_msr_policy;
> +uint64_t data, *msr;
> +u32 default1_bits;
> +
> +*p = raw_vmx_msr_policy;
> +
> +/* XXX: vmcs_revision_id for nested virt */

There was no such comment (presumably indicating something that
yet needs doing) in the old code - what's this about? Can't this be
implemented instead of such a comment be added?

> +/* MSR_IA32_VMX_VMCS_ENUM */
> +/* The max index of VVMCS encoding is 0x1f. */
> +data = 0x1f << 1;
> +msr = >msr[MSR_IA32_VMX_VMCS_ENUM - MSR_IA32_VMX_BASIC];
> +*msr = data;
> +
> +/* MSR_IA32_VMX_CR0_FIXED0 */
> +/* PG, PE bits must be 1 in VMX operation */
> +data = X86_CR0_PE | X86_CR0_PG;
> +msr = >msr[MSR_IA32_VMX_CR0_FIXED0 - MSR_IA32_VMX_BASIC];
> +*msr = data;
> +
> +/* MSR_IA32_VMX_CR0_FIXED1 */
> +/* allow 0-settings for all bits */
> +data = 0x;
> +msr = >msr[MSR_IA32_VMX_CR0_FIXED1 - MSR_IA32_VMX_BASIC];
> +*msr = data;
> +
> +/* MSR_IA32_VMX_CR4_FIXED0 */
> +/* VMXE bit must be 1 in VMX operation */
> +data = X86_CR4_VMXE;
> +msr = >msr[MSR_IA32_VMX_CR4_FIXED0 - MSR_IA32_VMX_BASIC];
> +*msr = data;

I don't see a need for using "data" as an intermediate variable in any
of the three cases above.

> +/* MSR_IA32_VMX_CR4_FIXED1 */
> +/* Treated dynamically */
> +
> +/* MSR_IA32_VMX_MISC */
> +/* Do not support CR3-target feature now */
> +msr = >msr[MSR_IA32_VMX_MISC - MSR_IA32_VMX_BASIC];
> +*msr = *msr & ~VMX_MISC_CR3_TARGET;

&=

> +/* MSR_IA32_VMX_EPT_VPID_CAP */
> +data = nept_get_ept_vpid_cap();
> +msr = >msr[MSR_IA32_VMX_EPT_VPID_CAP - MSR_IA32_VMX_BASIC];
> +*msr = data;

No need to use "data" again.

> +/* MSR_IA32_VMX_VMFUNC is N/A */
> +p->available &= ~0x2;

Please use an expression again here.

Jan


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

[Xen-devel] DESIGN v2: CPUID part 3

[Andrew Cooper]

Presented herewith is the a plan for the final part of CPUID work, which
primarily covers better Xen/Toolstack interaction for configuring the guests
CPUID policy.

A PDF version of this document is available from:

http://xenbits.xen.org/people/andrewcoop/cpuid-part-3-rev2.pdf

Changes from v1:
 * Clarification of the interaction of emulated features
 * More information about the difference between max and default featuresets.

~Andrew

-8<-
% CPUID Handling (part 3)
% Revision 2

# Current state

At early boot, Xen enumerates the features it can see, takes into account
errata checks and command line arguments, and stores this information in the
`boot_cpu_data.x86_capability[]` bitmap.  This gets adjusted as APs boot up,
and is sanitised to disable all dependent leaf features.

At mid/late boot (before dom0 is constructed), Xen performs the necessary
calculations for guest cpuid handling.  Data are contained within the `struct
cpuid_policy` object, which is a representation of the architectural CPUID
information as specified by the Intel and AMD manuals.

There are a few global `cpuid_policy` objects.  First is the **raw_policy**
which is filled in from native `CPUID` instructions.  This represents what the
hardware is capable of, in its current firmware/microcode configuration.

The next global object is **host_policy**, which is derived from the
**raw_policy** and `boot_cpu_data.x86_capability[]`. It represents the
features which Xen knows about and is using.  The **host_policy** is
necessarily a subset of **raw_policy**.

The **pv_max_policy** and **hvm_max_policy** are derived from the
**host_policy**, and represent the upper bounds available to guests.
Generally speaking, the guest policies are less featurefull than the
**host_policy** because there are features which Xen doesn't or cannot safely
provide to guests.  However, they are not subsets.  There are some features
(the HYPERVISOR bit for all guests, and X2APIC mode for HVM guests) which are
emulated in the absence of real hardware support.

The toolstack may query for the **{raw,host,pv,hvm}\_featureset** information
using _XEN\_SYSCTL\_get\_cpu\_featureset_.  This is bitmap form of the feature
leaves only.

When a new domain is created, the appropriate **{pv,hvm}\_max_policy** is
duplicated as a starting point, and can be subsequently mutated indirectly by
some hypercalls
(_XEN\_DOMCTL\_{set\_address\_size,disable\_migrate,settscinfo}_) or directly
by _XEN\_DOMCTL\_set\_cpuid_.


# Issues with the existing hypercalls

_XEN\_DOMCTL\_set\_cpuid_ doesn't have a return value which the domain builder
pays attention to.  This is because, before CPUID part 2, there were no
failure conditions, as Xen would accept all toolstack-provided data, and
attempt to audit it at the time it was requested by the guest.  To simplify
the part 2 work, this behaviour was maintained, although Xen was altered to
audit the data at hypercall time, typically zeroing out areas which failed the
audit.

There is no mechanism for the toolstack to query the CPUID configuration for a
specific domain.  Originally, the domain builder constructed a guests CPUID
policy from first principles, using native `CPUID` instructions in the control
domain.  This functioned to an extent, but was subject to masking problems,
and is fundamentally incompatible with HVM control domains or the use of
_CPUID Faulting_ in newer Intel processors.

CPUID phase 1 introduced the featureset information, which provided an
architecturally sound mechanism for the toolstack to identify which features
are usable for guests.  However, the rest of the CPUID policy is still
generated from native `CPUID` instructions.

The `cpuid_policy` is per-domain information.  Most CPUID data is identical
across all CPUs.  Some data are dynamic, based on other control settings
(APIC, OSXSAVE, OSPKE, OSLWP), and Xen substitutes these appropriately when
the information is requested..  Other areas however are topology information,
including thread/core/socket layout, cache and TLB hierarchy.  These data are
inherited from whichever physical CPU the domain builder happened to be
running on when it was making calculations.  As a result, it is inappropriate
for the guest under construction, and usually entirely bogus when considered
alongside other data.


# Other problems

There is no easy provision for features at different code maturity levels,
both in the hypervisor, and in the toolstack.

Some CPUID features have top-level command line options on the Xen command
line, but most do not.  On some hardware, some features can be hidden
indirectly by altering the `cpuid_mask_*` parameters.  This is a problem for
developing new features (which want to be off-by-default but able to be opted
in to), debugging, where it can sometimes be very useful to hide features and
see if a problem reoccurs, and occasionally in security circumstances, where
disabling a feature outright is an easy stop-gap solution.

From the toolstack 

Re: [Xen-devel] [PATCH 1/1] gitignore: add tools/misc/xen-diag to .gitignore

[Wei Liu]

On Tue, Jul 04, 2017 at 10:35:28PM +0800, Dongli Zhang wrote:
> Signed-off-by: Dongli Zhang 

Acked-by: Wei Liu 

This section of the list isn't ordered alphabetically so it isn't really
your fault. But I wouldn't want to make things worse, so I would move
this line below tools/misc/xen-detect while committing.

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

[Xen-devel] Xen Community Call 21/06/17 meeting minutes

[Julien Grall]

Hi all,

Sorry, I forgot to write the list of attendees. I only wrote down the 
company name. Feel free to forward the e-mail to any people interested.


During the previous community call, we discussed about potential 
embedded/automative boards. Stefano Stabellini brought up 3 names:


- Renases R-Car
- NXP IMX.8
- Qualcomm Snapdragon 820

He requested feedback from the attendees.

* Renesas R-Car *

There are a page on Xen wiki how on to use Xen on the Salvator-X:

https://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/Salvator-X

EPAM is looking at supporting the IPMMU-VMSA in Xen:

https://lists.xen.org/archives/html/xen-devel/2017-05/msg00959.html

The support of the IOMMU require to unshare the page tables between the 
processor and IOMMU because the descriptors are incompatibles.


It was mentioned there are missing patches in Xen to support the serial 
console. I am wasn't able to find which one. Can someone give a pointer 
to any missing patches for the R-Car?


* IMX.8 *

Dornerworks is working on a support for Xen. Work is been done in 
private at the moment.


Issue with the current SMMU drivers has been discussed, such as 
StreamIDs shared between multiple devices.


Most of the devices can be passthrough-ed but graphics cards at the moment.

* Snapdragon 820 *

No one on the call used it. Feedbacks are requested from the community.

Cheers,

--
Julien Grall

--
Julien Grall

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

Re: [Xen-devel] I was able to cross-compile the hypervisor on an amd64 host for the aarch64 target ... However, I can't build the Xen toolset

[Wei Liu]

CC Julien and Stefano -- not sure if the wiki page should be updated

On Mon, Jul 03, 2017 at 11:41:37AM -0700, Nick Garnett wrote:
> I was able to cross-compile the hypervisor on an amd64 host for the aarch64
> target. However, I can't build the Xen toolset. 
> 
> I am following the "Xen ARM with Virtualization Extensions/CrossCompiling"
> page, "Build arm64 tools" section. When I execute:
> 
> "./configure --build=x86_64-unknown-linux-gnu --host=aarch64-linux-gnu", I
> get the following errors:
> 
> checking for uuid_clear in -luuid... no
> checking uuid.h usability... no
> checking uuid.h presence... no
> checking for uuid.h... no
> configure: error: cannot find a valid uuid library
> configure: error: ./configure failed for tools
> 
> I have installed uuid, uuid-dev uuid-runtime and uuidcdef, but continue to
> get the same error.
> 
> If anyone has seen and resolved this issue, please provide details.
> 
> Regards, Nick Garnett
> 
> Zazzu Firmware Architect
> 
> 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

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

[Xen-devel] [PATCH 1/1] gitignore: add tools/misc/xen-diag to .gitignore

[Dongli Zhang]

Signed-off-by: Dongli Zhang 
---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 068f430..e1009e0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -211,6 +211,7 @@ tools/misc/xenperf
 tools/misc/xenpm
 tools/misc/xen-hvmctx
 tools/misc/xenlockprof
+tools/misc/xen-diag
 tools/misc/lowmemd
 tools/misc/xencov
 tools/pkg-config/*
-- 
2.7.4


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

Re: [Xen-devel] [PATCH v2 2/2] tools: utility to dump guest grant table info

[Dongli Zhang]

Hi Wei,

I will send the patch based on staging.

Dongli Zhang

On 07/04/2017 10:10 PM, Wei Liu wrote:
> I pushed your two patches and discovered you also need to patch
> .gitignore. Could you please send a patch for that? thanks
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
> 

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

Re: [Xen-devel] [PATCH v1 3/6] vmx: refactor vmx_init_vmcs_config()

[Jan Beulich]

>>> On 26.06.17 at 12:44,  wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -227,7 +227,8 @@ static u32 adjust_vmx_controls(
>  {
>  u32 vmx_msr_low, vmx_msr_high, ctl = ctl_min | ctl_opt;
>  
> -rdmsr(msr, vmx_msr_low, vmx_msr_high);
> +vmx_msr_low = raw_vmx_msr_policy.msr[msr - MSR_IA32_VMX_BASIC];
> +vmx_msr_high = raw_vmx_msr_policy.msr[msr - MSR_IA32_VMX_BASIC] >> 32;

Please consider adding a helper macro or inline function for the
raw_vmx_msr_policy.msr[msr - MSR_IA32_VMX_BASIC] sub-expression
(which likely is going to be usable elsewhere too, e.g. in patch 2).

> @@ -632,8 +628,8 @@ int vmx_cpu_up(void)
>   * the requred CRO fixed bits in VMX operation. 
>   */
>  cr0 = read_cr0();
> -rdmsrl(MSR_IA32_VMX_CR0_FIXED0, vmx_cr0_fixed0);
> -rdmsrl(MSR_IA32_VMX_CR0_FIXED1, vmx_cr0_fixed1);
> +vmx_cr0_fixed0 = raw_vmx_msr_policy.cr0_fixed_0.raw;
> +vmx_cr0_fixed1 = raw_vmx_msr_policy.cr0_fixed_1.raw;

Ah, here comes the change I did ask for. Judging from the title I
wasn't able to guess that, and I really don't mind in which of the
patches it happens.

Jan


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

Re: [Xen-devel] [PATCH 2/2] CODING_STYLE: Forbid nested block in the hypervisor code

[Andrew Cooper]

On 04/07/17 13:20, Jan Beulich wrote:
 On 04.07.17 at 14:12,  wrote:
>> When removing if/for/while statements, the code should be reworked to
>> remove the { } and the extra indentation.
> Yes.
>
>> This is improving code maintainability and code readability.
> For the given example, yes. However, there are (rare) cases where
> having such nested blocks actually improves readability, for example
> in certain combinations with preprocessor conditionals. Hence I don't
> think we should forbid them.

There are also a few specific cases where it is useful to use blocks
like that to introduce a new variable, where introducing it at function
level scope isn't appropriate.  (Alternatively, we could switch from C89
to C99, but that is a separate discussion).

I agree that we should discourage the use of blocks like this, but not
forbid them outright.

~Andrew

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

Re: [Xen-devel] [PATCH v1 2/6] vmx: add raw_vmx_msr_policy

[Jan Beulich]

>>> On 26.06.17 at 12:44,  wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -144,6 +144,8 @@ static void __init vmx_display_features(void)
>  printk(" - none\n");
>  }
>  
> +struct vmx_msr_policy __read_mostly raw_vmx_msr_policy;

Does this really need to be non-static? I don't see a use outside of
this file in the patch here at least.

> @@ -152,6 +154,74 @@ bool vmx_msr_available(struct vmx_msr_policy *p, 
> uint32_t msr)
>  return p->available & (1u << (msr - MSR_IA32_VMX_BASIC));
>  }
>  
> +int calculate_raw_policy(bool bsp)
> +{
> +struct vmx_msr_policy policy;
> +struct vmx_msr_policy *p = 
> +int msr;

unsigned int

> +/* Raw policy is filled only on boot CPU */
> +if ( bsp )
> +p = _vmx_msr_policy;
> +else
> +memset(, 0, sizeof(policy));
> +
> +p->available = 0x7ff;

(1u << (MSR_IA32_VMX_VMCS_ENUM + 1 - MSR_IA32_VMX_BASIC)) - 1

> +for ( msr = MSR_IA32_VMX_BASIC; msr <= MSR_IA32_VMX_VMCS_ENUM; msr++ )
> +rdmsrl(msr, p->msr[msr - MSR_IA32_VMX_BASIC]);
> +
> +if ( p->basic.default1_zero )
> +{
> +p->available |= 0x1e000;

Same here and further down - please calculate the values from
available constants. Maybe you want to have a helper macro or
inline function.

> +/* Check that secondary CPUs have exactly the same bits in VMX MSRs */
> +if ( !bsp && memcmp(p, _vmx_msr_policy, sizeof(*p)) != 0 )
> +{
> +for ( msr = MSR_IA32_VMX_BASIC; msr <= MSR_IA32_VMX_VMFUNC; msr++ )
> +{
> +if ( p->msr[msr - MSR_IA32_VMX_BASIC] !=
> + raw_vmx_msr_policy.msr[msr - MSR_IA32_VMX_BASIC] )
> +{
> +printk("VMX msr %#x: saw 0x%016"PRIx64" expected 
> 0x%016"PRIx64
> +"\n", msr, p->msr[msr - MSR_IA32_VMX_BASIC],

Please keep the newline on the same line as the rest of the format
string. It being slightly longer then really wanted is okay for format
strings.

> @@ -611,6 +624,9 @@ int vmx_cpu_up(void)
>  
>  BUG_ON(!(read_cr4() & X86_CR4_VMXE));
>  
> +if ( (rc = calculate_raw_policy(false)) != 0 )
> +return rc;
> +
>  /* 
>   * Ensure the current processor operating mode meets 
>   * the requred CRO fixed bits in VMX operation. 

Following here are reads of MSR_IA32_VMX_CR0_FIXED{0,1} which
you should be able to drop now, instead using the raw policy you've
just checked matches this CPU.

Btw., is it intentional that the function is being invoked for the BSP a
second time here (after start_vmx() did so already), with the flag
now being passed with the wrong value?

> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -2432,6 +2432,8 @@ static void pi_notification_interrupt(struct 
> cpu_user_regs *regs)
>  raise_softirq(VCPU_KICK_SOFTIRQ);
>  }
>  
> +int calculate_raw_policy(bool bsp);

Declarations need to go in a header included by both producer and
consumer, so that someone changing only one of definition and
declaration will be forced to also change the other side.

Jan


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

Re: [Xen-devel] [PATCH 1/2] CODING_STYLE: removing trailing whitespaces

[Wei Liu]

On Tue, Jul 04, 2017 at 01:12:13PM +0100, Julien Grall wrote:
> Signed-off-by: Julien Grall 

Applied this patch.

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

Re: [Xen-devel] [PATCH v2 2/2] tools: utility to dump guest grant table info

[Wei Liu]

I pushed your two patches and discovered you also need to patch
.gitignore. Could you please send a patch for that? thanks

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

[Xen-devel] [xen-unstable-smoke test] 111372: tolerable trouble: broken/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  864a269682025a64b6cb7c53fc65d9884ecc342e
baseline version:
 xen  6a0b420a7a086af21dbcf15172f24ad1af12a1f2

Last test of basis   111371  2017-07-04 09:23:04 Z0 days
Testing same since   111372  2017-07-04 12:02:19 Z0 days1 attempts


People who touched revisions under test:
  Thomas Sanders 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=864a269682025a64b6cb7c53fc65d9884ecc342e
+ . ./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 xen-unstable-smoke 
864a269682025a64b6cb7c53fc65d9884ecc342e
+ branch=xen-unstable-smoke
+ revision=864a269682025a64b6cb7c53fc65d9884ecc342e
+ . ./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=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' x864a269682025a64b6cb7c53fc65d9884ecc342e = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ 

Re: [Xen-devel] [PATCH v1 1/6] vmx: add struct vmx_msr_policy

[Jan Beulich]

>>> On 26.06.17 at 12:44,  wrote:
> --- a/xen/arch/x86/hvm/vmx/vmcs.c
> +++ b/xen/arch/x86/hvm/vmx/vmcs.c
> @@ -144,6 +144,14 @@ static void __init vmx_display_features(void)
>  printk(" - none\n");
>  }
>  
> +bool vmx_msr_available(struct vmx_msr_policy *p, uint32_t msr)

const

> --- a/xen/include/asm-x86/hvm/vmx/vmcs.h
> +++ b/xen/include/asm-x86/hvm/vmx/vmcs.h
> @@ -562,6 +562,350 @@ void vmx_domain_flush_pml_buffers(struct domain *d);
>  
>  void vmx_domain_update_eptp(struct domain *d);
>  
> +union vmx_pin_based_exec_control_bits {
> +uint32_t raw;
> +struct {
> +bool ext_intr_exiting:1;
> +uint32_t :2;  /* 1:2 reserved */
> +bool  nmi_exiting:1;
> +uint32_t :1;  /* 4 reserved */
> +bool virtual_nmis:1;
> +boolpreempt_timer:1;
> +bool posted_interrupt:1;
> +uint32_t :24; /* 8:31 reserved */

This mixture of bool and uint32_t worries me - I don't think the
resulting layout is well defined. Yes, you put suitable
BUILD_BUG_ON()s in place to catch possible issues, but anyway.

> +struct vmx_msr_policy
> +{
> +/*
> + * Bitmap of readable MSRs, starting from MSR_IA32_VMX_BASIC,
> + * derived from contents of MSRs in this structure.
> + */
> +uint32_t available;
> +
> +union {
> +uint64_t msr[MSR_IA32_VMX_VMFUNC - MSR_IA32_VMX_BASIC + 1];

Considering the recurring use of MSR_IA32_VMX_VMFUNC,
wouldn't it be worthwhile to have a "last" #define? You'd then
clearly want to add a BUILD_BUG_ON() to vmx_msr_available()
making sure the delta doesn't grow beyond 32.

> +struct {
> +/* MSR 0x480 */

Please also give the msr-index.h name in the comment, for grep-s
to match here. In fact I'm unconvinced the hex index is of much use.

> +union {
> +uint64_t raw;
> +struct {
> +uint32_t vmcs_revision_id:31;
> +bool :1;  /* 31 always zero */

Name it mbz then?

> +/* MSR 0x486 */
> +union {
> +uint64_t raw;
> +struct {
> +uint32_t allowed_0;
> +uint32_t :32;
> +};
> +} cr0_fixed_0;

I can't find any indication that this and the following MSRs have an
undefined upper half. The VMCS fields they correspond to are native
width, so I think the type here should be unsigned long.

Yet then the question arises whether breaking these up into bit
fields wouldn't be useful too. Of if that's no useful, is there really
a point in having both a "raw" and a properly named field?

> +/* MSR 0x48A */
> +union {
> +uint64_t raw;
> +struct {
> +uint32_t  :1;  /* 0 reserved */
> +uint32_t vmcs_encoding_max_idx:9;
> +uint64_t  :54; /* 10:63 reserved */

This pairing of uint32_t and uint64_t looks even more worrying to
me than the bool/uint32_t one further up. I'm actually surprised
this doesn't cause the respective BUILD_BUG_ON() to trigger.

> +/* MSR 0x491 */
> +union {
> +uint64_t raw;
> +struct {
> +bool eptp_switching:1;
> +};

Any reason the other 63 bits don't have a placeholder here, just like
you do everywhere else?

Jan


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

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111255 
REGR. vs. 110441

Tests which are failing intermittently (not blocking):
 test-amd64-i386-freebsd10-amd64 17 guest-localmigrate/x10 fail in 111255 pass 
in 111365
 test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail in 111344 
pass in 111365
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail pass in 111255
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail pass in 111255
 test-armhf-armhf-examine  5 xen-installfail pass in 111344

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-libvirt-xsm  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl   1 build-check(1)   blocked  n/a
 test-arm64-arm64-examine  1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-credit2   1 build-check(1)   blocked  n/a
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop   fail blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop   fail blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 18 guest-start/win.repeat fail in 111255 
blocked in 110441
 test-amd64-amd64-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111255 
like 110441
 test-amd64-i386-xl-qemuu-win7-amd64 18 guest-start/win.repeat fail in 111344 
blocked in 110441
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail in 111344 
like 110441
 test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt 14 saverestore-support-checkfail  like 110441
 test-armhf-armhf-libvirt-raw 13 saverestore-support-checkfail  like 110441
 test-amd64-amd64-xl-qemut-ws16-amd64 10 windows-installfail never pass
 test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-installfail never pass
 test-amd64-i386-libvirt  13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-arndale  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  14 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-vhd 12 migrate-support-checkfail   never pass
 test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore   fail never pass
 test-amd64-i386-xl-qemut-ws16-amd64 13 guest-saverestore   fail never pass
 build-arm64-pvops 6 kernel-build fail   never pass
 test-armhf-armhf-xl-multivcpu 13 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 14 saverestore-support-checkfail  never pass
 test-armhf-armhf-libvirt-xsm 13 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 13 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 14 saverestore-support-checkfail never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 14 saverestore-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  13 saverestore-support-checkfail   never pass
 test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemuu-win10-i386 10 windows-installfail never pass
 test-amd64-i386-xl-qemut-win10-i386 10 windows-install fail never pass
 test-amd64-amd64-xl-qemut-win10-i386 10 windows-installfail never pass

version targeted for testing:
 linux985c6fe6e0357c79642bc506f15932983571ce93
baseline 

Re: [Xen-devel] Question about "xen: Revert commits da72ff5bfcb0 and 72a9b186292d"

[Jean-Louis Dupond]

Op 2017-07-04 14:51, schreef Juergen Gross:

On 04/07/17 14:44, Jean-Louis Dupond wrote:

Hi Juergen,

We run Xen as dom0 with Windows domU's.

Now with older 4.9.x kernels, we had BSOD's when we booted a domU with
old Xen drivers in it.
With the newest kernel (4.9.34), this seems to be resolved.

I was wondering what caused this. And that patch triggered my 
attention :)


No, I don't think this patch can be the reason.

Which was the latest dom0 kernel causing failure? Or could it be you
upgraded the hypervisor or Xen tools at the same time and the kernel
version just doesn't matter?


Juergen


We switched from 3.18 -> 4.9 (using CentOS VIRT), and started to see the 
issue.

If we just upgrade the kernel to latest 4.9, it works fine again.

So something broke it, but its fixed now ...
Was just wondering what caused it exactly :)

Jean-Louis

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

[Xen-devel] [PATCH] arm/p2m: Cleanup access to the host's p2m

[Sergej Proskurin]

This commit substitutes the direct access of the host's p2m
(>arch.p2m) for the macro "p2m_get_hostp2m". This macro simplifies
readability and also the differentiation between the host's p2m and
alternative p2m's, i.e., as part of the altp2m subsystem that will be
submitted in the future.

Signed-off-by: Sergej Proskurin 
---
Razvan Cojocaru 
Tamas K Lengyel 
Stefano Stabellini 
Julien Grall 
---
v1:
This commit has been already acknowledged in the altp2m patch
series, however not yet applied to mainline. I have removed the
Acked-by: Julien Grall  to resubmit this patch
individually.
---
 xen/arch/arm/mem_access.c |  2 +-
 xen/arch/arm/p2m.c| 28 ++--
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/xen/arch/arm/mem_access.c b/xen/arch/arm/mem_access.c
index bcf49f5c15..e0888bbad2 100644
--- a/xen/arch/arm/mem_access.c
+++ b/xen/arch/arm/mem_access.c
@@ -107,7 +107,7 @@ p2m_mem_access_check_and_get_page(vaddr_t gva, unsigned 
long flag,
 xenmem_access_t xma;
 p2m_type_t t;
 struct page_info *page = NULL;
-struct p2m_domain *p2m = >domain->arch.p2m;
+struct p2m_domain *p2m = p2m_get_hostp2m(v->domain);
 
 rc = gva_to_ipa(gva, , flag);
 if ( rc < 0 )
diff --git a/xen/arch/arm/p2m.c b/xen/arch/arm/p2m.c
index 9b7a580a87..7b2aac4c90 100644
--- a/xen/arch/arm/p2m.c
+++ b/xen/arch/arm/p2m.c
@@ -73,7 +73,7 @@ void p2m_write_unlock(struct p2m_domain *p2m)
 
 void p2m_dump_info(struct domain *d)
 {
-struct p2m_domain *p2m = >arch.p2m;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
 p2m_read_lock(p2m);
 printk("p2m mappings for domain %d (vmid %d):\n",
@@ -93,7 +93,7 @@ void memory_type_changed(struct domain *d)
 
 void dump_p2m_lookup(struct domain *d, paddr_t addr)
 {
-struct p2m_domain *p2m = >arch.p2m;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
 printk("dom%d IPA 0x%"PRIpaddr"\n", d->domain_id, addr);
 
@@ -111,7 +111,7 @@ void p2m_save_state(struct vcpu *p)
 
 void p2m_restore_state(struct vcpu *n)
 {
-struct p2m_domain *p2m = >domain->arch.p2m;
+struct p2m_domain *p2m = p2m_get_hostp2m(n->domain);
 uint8_t *last_vcpu_ran;
 
 if ( is_idle_vcpu(n) )
@@ -377,7 +377,7 @@ out:
 mfn_t p2m_lookup(struct domain *d, gfn_t gfn, p2m_type_t *t)
 {
 mfn_t ret;
-struct p2m_domain *p2m = >arch.p2m;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
 p2m_read_lock(p2m);
 ret = p2m_get_entry(p2m, gfn, t, NULL, NULL);
@@ -1032,7 +1032,7 @@ static inline int p2m_insert_mapping(struct domain *d,
  mfn_t mfn,
  p2m_type_t t)
 {
-struct p2m_domain *p2m = >arch.p2m;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
 int rc;
 
 p2m_write_lock(p2m);
@@ -1047,7 +1047,7 @@ static inline int p2m_remove_mapping(struct domain *d,
  unsigned long nr,
  mfn_t mfn)
 {
-struct p2m_domain *p2m = >arch.p2m;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
 int rc;
 
 p2m_write_lock(p2m);
@@ -1129,7 +1129,7 @@ int guest_physmap_remove_page(struct domain *d, gfn_t 
gfn, mfn_t mfn,
 
 static int p2m_alloc_table(struct domain *d)
 {
-struct p2m_domain *p2m = >arch.p2m;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
 struct page_info *page;
 unsigned int i;
 
@@ -1180,7 +1180,7 @@ static void p2m_vmid_allocator_init(void)
 
 static int p2m_alloc_vmid(struct domain *d)
 {
-struct p2m_domain *p2m = >arch.p2m;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
 int rc, nr;
 
@@ -1210,7 +1210,7 @@ out:
 
 static void p2m_free_vmid(struct domain *d)
 {
-struct p2m_domain *p2m = >arch.p2m;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
 spin_lock(_alloc_lock);
 if ( p2m->vmid != INVALID_VMID )
 clear_bit(p2m->vmid, vmid_mask);
@@ -1220,7 +1220,7 @@ static void p2m_free_vmid(struct domain *d)
 
 void p2m_teardown(struct domain *d)
 {
-struct p2m_domain *p2m = >arch.p2m;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
 struct page_info *pg;
 
 while ( (pg = page_list_remove_head(>pages)) )
@@ -1238,7 +1238,7 @@ void p2m_teardown(struct domain *d)
 
 int p2m_init(struct domain *d)
 {
-struct p2m_domain *p2m = >arch.p2m;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
 int rc = 0;
 unsigned int cpu;
 
@@ -1291,7 +1291,7 @@ int p2m_init(struct domain *d)
  */
 int relinquish_p2m_mapping(struct domain *d)
 {
-struct p2m_domain *p2m = >arch.p2m;
+struct p2m_domain *p2m = p2m_get_hostp2m(d);
 unsigned long count = 0;
 p2m_type_t t;
 int rc = 0;
@@ -1351,7 +1351,7 @@ int relinquish_p2m_mapping(struct domain *d)
 
 int p2m_cache_flush(struct domain *d, gfn_t start, unsigned long nr)
 {
-struct p2m_domain 

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
110515

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

version targeted for testing:
 linux6f7da290413ba713f0cdd9ff1a2a9bb129ef4f6c
baseline version:
 linux1439ccf73d9c07654fdd5b4969fd53c2feb8684d

Last test of basis   110515  2017-06-17 06:48:56 Z   17 days
Failing since110536  2017-06-17 23:48:13 Z   16 days   17 attempts
Testing same since   111363  2017-07-03 13:21:27 Z0 days1 attempts


304 people touched revisions under test,
not listing them all

jobs:
 build-amd64-xsm  pass
 build-arm64-xsm 

Re: [Xen-devel] Question about "xen: Revert commits da72ff5bfcb0 and 72a9b186292d"

[Juergen Gross]

On 04/07/17 14:44, Jean-Louis Dupond wrote:
> Hi Juergen,
> 
> We run Xen as dom0 with Windows domU's.
> 
> Now with older 4.9.x kernels, we had BSOD's when we booted a domU with
> old Xen drivers in it.
> With the newest kernel (4.9.34), this seems to be resolved.
> 
> I was wondering what caused this. And that patch triggered my attention :)

No, I don't think this patch can be the reason.

Which was the latest dom0 kernel causing failure? Or could it be you
upgraded the hypervisor or Xen tools at the same time and the kernel
version just doesn't matter?


Juergen

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

Re: [Xen-devel] Question about "xen: Revert commits da72ff5bfcb0 and 72a9b186292d"

[Jean-Louis Dupond]

Hi Juergen,

We run Xen as dom0 with Windows domU's.

Now with older 4.9.x kernels, we had BSOD's when we booted a domU with 
old Xen drivers in it.

With the newest kernel (4.9.34), this seems to be resolved.

I was wondering what caused this. And that patch triggered my attention 
:)


Thanks
Jean-Louis

Op 2017-07-04 14:40, schreef Juergen Gross:

On 04/07/17 13:54, Jean-Louis Dupond wrote:

Hi All,

We had some issues with BSOD's on Windows at startup when using some 
old

Xen drivers inside Windows.
Now when we upgrade to the most recent 4.9.x kernel. The issue seems 
to

be resolved.

Could it be that the following commit fixes the issue:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=84d582d236dc1f9085e741affc72e9ba061a67c2

?

As far as I can see it only breaks Xen < 4.0. But could it be it also
breaks Windows VM's with old Xen drivers?


Umm, I don't get it.

Are you using Windows or Linux? Above commit is for the Linux kernel
running as HVM domain. It shouldn't be able to modify behavior of a
Windows guest at all.


Juergen


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

Re: [Xen-devel] Question about "xen: Revert commits da72ff5bfcb0 and 72a9b186292d"

[Juergen Gross]

On 04/07/17 13:54, Jean-Louis Dupond wrote:
> Hi All,
> 
> We had some issues with BSOD's on Windows at startup when using some old
> Xen drivers inside Windows.
> Now when we upgrade to the most recent 4.9.x kernel. The issue seems to
> be resolved.
> 
> Could it be that the following commit fixes the issue:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=84d582d236dc1f9085e741affc72e9ba061a67c2
> 
> ?
> 
> As far as I can see it only breaks Xen < 4.0. But could it be it also
> breaks Windows VM's with old Xen drivers?

Umm, I don't get it.

Are you using Windows or Linux? Above commit is for the Linux kernel
running as HVM domain. It shouldn't be able to modify behavior of a
Windows guest at all.


Juergen

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

[Xen-devel] xen/arm: Software Step ARMv8 - PC stuck on instruction

[Florian Jakobsmeier]

Hello all,

I'm trying to implement a single step functionality for XEN on ARMv8 using
"Software Step Exceptions". My problem with this is, that after taking the
exception the PC will stay on the same instruction.

By adding a "singlestep_enabled" flag in the "struct arch_domain" (based on
the single step mechanism for x86), I'm able to set the needed registers
(namely MDSCR_EL1.SS , SPSR_EL2.SS, MDCR_EL2.TDE ) for each vcpu that is
used by a given domain (referenced by its domain_id).
Within the "arch/arm/traps.c:leave_hypervisor_tail()" function, which is
called when exiting the hypervisor (according to /arch/arm/arm64/entry.S),
I am checking the singlestep_enabled flag and set the registers (by this i
can assure that each register is set on every vm entry). Also I'm checking
that the registers are set for the correct domain and vcpu (by examining
current->domain)

In comparison with the ARM ArchManual State machine(ARM DDI 0487B.a: Page
1957) an instruction that should be single-stepped, will be executed when
"ERET setting PSTATE.SS to 1".
For this to happen, specific conditions should be met. Table D2-22 on page
1959 defines which Table sets this condition (in my case :{MDSCR_EL1.SS=1,
Lock=False, NS=1, TDE=1} ).

Because I'm routing the exception from EL1 to EL2 (because of their naming
convention "From EL = EL2" and "Target EL=EL1, according to Page 1959) with
KDE=1, PSTATE.D=1 (monitored by printing MDSCR_EL1 and cpu_user_regs.cpsr)
the system should copy SPSR_EL2.SS to PSTATE.SS when executing ERET.

The state machine dictates, that when PSTATE.SS=1 the system should be in
the "Active-not-pending" state and after this should execute the
single-stepped instruction, which should increase the PC.
But because my PC stays constant, the state in which the system is, should
be the Active-Pending state.

By printing the PC value within the Exception handler
(xen/arch/arm/traps.c:do_trap_guest_sync()) I can see the exceptions will
be generated (otherwise there would be no prints) and the PC stays on the
same value, which results in a not working VM.

Following is the code, that is use to setup single stepping:

--- original_xen/xen/xen/arch/arm/traps.c2017-07-04 13:58:09.526280389
> +0200
> +++ xen/xen/arch/arm/traps.c2017-07-04 13:48:48.146066332 +0200
> @@ -1247,6 +1247,7 @@
>
>  asmlinkage void do_trap_guest_sync(struct cpu_user_regs *regs)
>  {
>  const union hsr hsr = { .bits = regs->hsr };
>
>  enter_hypervisor_head(regs);
>
>  switch (hsr.ec) {
>  case HSR_EC_WFI_WFE:
>  /*
> @@ -2917,6 +2931,7 @@
>  #endif
> +case HSR_EC_SOFTSTEP_LOWER_EL:
> +do_trap_software_step(regs);
> +break;
>  default:
>  gprintk(XENLOG_WARNING,
>  "Unknown Guest Trap. HSR=0x%x EC=0x%x IL=%x
> Syndrome=0x%"PRIx32"\n",
>
> Extended the Switch case in trap_guest_sync_handler to support singlestep
on ARMv8. Defined "HSR_EC_SOFTSTEP_LOWER_EL"=0x32 in
/xen/include/asm/processor.h



>
> +asmlinkage void do_trap_software_step(struct cpu_user_regs *regs)
> +{
> +/*inform dom0*/
> +//PC to next instruction
> +gprintk(XENLOG_ERR, "SPSR_EL2 = 0x%lx  Regs.SPSR = 0x%x\n",
> READ_SYSREG(SPSR_EL2) ,regs->cpsr);
> +}
> +
>
Handler method that will be called when a software step exception is
catched by the hypervisor (currently just prints various information). This
is also the function, which allows me to check whether or not the PC was
increased.


>  asmlinkage void leave_hypervisor_tail(void)
>  {
> +/*This methode will be called after the 'guest_entry' macro in
> /arch/arm64/entry.S set guest registers
> +Check single_step_enabled flag in domain struct here and set needed
> registers
> +
> +*/
> +
> +struct vcpu *v = current;
> +
> +if ( unlikely(v->domain->arch.monitor.singlestep_enabled ) )
> +{
> +
> +WRITE_SYSREG(READ_SYSREG(MDCR_EL2)  | HDCR_TDE, MDCR_EL2);
> +WRITE_SYSREG(READ_SYSREG(SPSR_EL2)  | 0x20, SPSR_EL2 );
> +WRITE_SYSREG(READ_SYSREG(MDSCR_EL1) | 0x1, MDSCR_EL1);
> +
> +if (!(v->arch.single_step ))
> +{
> +gprintk(XENLOG_ERR, "Setting vcpu=%d for
> domain=%d\n",v->vcpu_id,v->domain->domain_id);
> +
> +gprintk(XENLOG_ERR, "[Set_singlestep] MDSCR_EL1 0x%lx\n",
> READ_SYSREG(MDSCR_EL1));
> +gprintk(XENLOG_ERR, "[Set_singlestep] SPSR_EL2  0x%lx\n",
> READ_SYSREG(SPSR_EL2));
> +gprintk(XENLOG_ERR, "[Set_singlestep] MDCR_EL2  0x%lx\n",
> READ_SYSREG(MDCR_EL2));
> +v->arch.single_step = 1;
> +
> +return;
> +}else
> +{
> +//gprintk(XENLOG_ERR, "Register for vcpu=%d for domain=%d
> already set\n",v->vcpu_id,v->domain->domain_id);
> +}
> +}
>

As mentioned, this function will set the needed registers.
"monitor.singlestep_enabled" is the domain SS flag which is used to
determine if the registers should be set. "arch.single_step" is the vcpu
flag to check 

Re: [Xen-devel] RT-Xen on ARM

[Andrii Anisov]

On 03.07.17 21:42, Meng Xu wrote:

As far as I know, there is no known issue for ARM as long as that
version Xen runs on the ARM board.

 That's good.

I assume you have your own workloads to run, which are periodically
activated task.
The workloads in [1] are independent periodic CPU-intensive tasks: the
task does some computation for every period.
If your workloads are similar to the tasks, it should be ok.
Actually now we have just a high-level use case without any specific 
parameters defined.
I.e. in an automotive system there should be a domain dedicated to 
instrumental cluster beside IVI domain. IC domain should be RT.

So we are just evaluating and experimenting with an existing functionality.


One thing in my mind that may affect your evaluations for your real
workload is what you want to achieve.

The RTDS uses the EDF scheduling, under which the priorities of the
VCPUs (or VMs) are dynamically changed based on their (absolute)
deadlines. This provides better real-time performance for the
*overall* system.
In case we would have a driver domain and IC domain would draw to pv 
display baked by backend in a driver domain. Driver domain should be RT 
capable as well.

So it seems two domains should be RT beside non-RT IVI domain.


If you want to make one VM highest priority and let that VM preempt
other VMs whenever the highest priority VM is active, it's better to
use the RM or FP scheduling, instead of the EDF scheduling.
So you are suggesting to introduce more RT schedulers with different 
algorithms. Did I get you right?



Once the scheduling policy is determined, you will need to configure
the VCPUs' parameters based on the systems' workload.
This requires the workload's timing parameters for the CARTS tool to
compute the VCPUs' parameters.

Thank you for suggestions.

--

*Andrii Anisov*



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

Re: [Xen-devel] [PATCH 2/2] CODING_STYLE: Forbid nested block in the hypervisor code

[Jan Beulich]

>>> On 04.07.17 at 14:12,  wrote:
> When removing if/for/while statements, the code should be reworked to
> remove the { } and the extra indentation.

Yes.

> This is improving code maintainability and code readability.

For the given example, yes. However, there are (rare) cases where
having such nested blocks actually improves readability, for example
in certain combinations with preprocessor conditionals. Hence I don't
think we should forbid them.

Jan


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

[Xen-devel] [PATCH RFC] x86emul: add read-modify-write hook

[Jan Beulich]

In order to correctly emulate read-modify-write insns, especially
LOCKed ones, we should not issue reads and writes separately. Use a
new hook to combine both, and don't uniformly read the memory
destination anymore. Instead, DstMem opcodes without Mov now need to
have done so in their respective case blocks.

For now, make use of the hook optional for callers; eventually this
should become mandatory.

Note that operand-size-wise the test harness'es rmw() function had been
added only what has been observed to be necessary.

Signed-off-by: Jan Beulich 
---
This mainly is in preparation for Andrew's "Improvements to
in-hypervisor emulation" session on the meeting in Budapest. Note that
this is unlikely to apply as is, as I have it sitting on top of various
other pending patches, but it should be good enough for discussing the
approach.

TBD: not dealing with cmpxchg/cmpxchg{8,16}b yet - need to either alter that
 hook's behavior or add x86_rmw_cmpxchg (but the latter would require
 another input to ->rmw())

--- a/tools/tests/x86_emulator/test_x86_emulator.c
+++ b/tools/tests/x86_emulator/test_x86_emulator.c
@@ -311,6 +311,139 @@ static int write(
 return X86EMUL_OKAY;
 }
 
+static int rmw(
+enum x86_rmw_op op,
+enum x86_segment seg,
+unsigned long offset,
+void *p_data,
+unsigned int bytes,
+uint32_t *eflags,
+struct x86_emulate_ctxt *ctxt)
+{
+union {
+uint8_t  u8;
+uint16_t u16;
+uint32_t u32;
+uint64_t u64;
+} *ptr = (void *)offset, *data = p_data;
+
+if ( verbose )
+printf("** %s(%d, %u, %p,, %u,,)\n", __func__, op, seg, ptr, bytes);
+
+if ( !is_x86_user_segment(seg) )
+return X86EMUL_UNHANDLEABLE;
+switch ( op )
+{
+bool cf;
+
+#ifdef __x86_64__
+# define asm64 asm
+# define popfl(n) "pop %q" #n
+#else
+# define asm64(...) return X86EMUL_UNHANDLEABLE
+# define popfl(n) "pop %" #n
+#endif
+
+#define BINOP(insn) \
+case x86_rmw_##insn: \
+if ( bytes != 4 ) \
+return printf("[%d:%u]", op, bytes), X86EMUL_UNHANDLEABLE; \
+asm ( #insn "l %2,%0; pushf; " popfl(1) \
+  : "+m" (ptr->u32), "=rm" (*eflags) \
+  : "r" (data->u32) ); \
+break
+BINOP(add);
+BINOP(and);
+BINOP(or);
+BINOP(sub);
+BINOP(xor);
+#undef BINOP
+
+#define BINOPC(insn) \
+case x86_rmw_##insn: \
+if ( bytes != 4 ) \
+return printf("[%d:%u]", op, bytes), X86EMUL_UNHANDLEABLE; \
+cf = *eflags & X86_EFLAGS_CF; \
+asm ( "shr $1,%3; " #insn "l %2,%0; pushf; " popfl(1) \
+  : "+m" (ptr->u32), "=rm" (*eflags) \
+  : "r" (data->u32), "q" (cf) ); \
+break
+BINOPC(adc);
+BINOPC(sbb);
+#undef BINOPC
+
+#define UNOP(insn) \
+case x86_rmw_##insn: \
+if ( bytes != 4 ) \
+return X86EMUL_UNHANDLEABLE; \
+asm ( #insn "l %0; pushf; " popfl(1) \
+  : "+m" (ptr->u32), "=rm" (*eflags) ); \
+break
+UNOP(dec);
+UNOP(inc);
+UNOP(neg);
+#undef UNOP
+
+#define BTOP(op) \
+case x86_rmw_bt##op: \
+switch ( bytes ) \
+{ \
+case 4: \
+if ( data->u32 >= 32 ) \
+return X86EMUL_UNHANDLEABLE; \
+asm ( "bt" #op "l %2,%0; setc %1" \
+  : "+m" (ptr->u32), "=qm" (cf) \
+  : "r" (data->u32) ); \
+break; \
+case 8: \
+if ( data->u64 >= 64 ) \
+return X86EMUL_UNHANDLEABLE; \
+asm64 ( "bt" #op "q %2,%0; setc %1" \
+: "+m" (ptr->u64), "=qm" (cf) \
+: "r" (data->u64) ); \
+break; \
+default: \
+return X86EMUL_UNHANDLEABLE; \
+} \
+if ( cf ) \
+*eflags |= X86_EFLAGS_CF; \
+else \
+*eflags &= ~X86_EFLAGS_CF; \
+break
+BTOP(c);
+BTOP(r);
+BTOP(s);
+#undef BTOP
+
+case x86_rmw_not:
+if ( bytes != 4 )
+return X86EMUL_UNHANDLEABLE;
+asm ( "notl %0; pushf; pop %1" : "+m" (ptr->u32) );
+break;
+
+case x86_rmw_xadd:
+if ( bytes != 2 )
+return X86EMUL_UNHANDLEABLE;
+asm ( "xaddw %1,%0; pushf; " popfl(2)
+  : "+m" (ptr->u16), "+r" (data->u16), "=rm" (*eflags) );
+break;
+
+case x86_rmw_xchg:
+if ( bytes != 4 )
+return X86EMUL_UNHANDLEABLE;
+asm ( "xchgl %1,%0" : "+m" (ptr->u32), "+r" (data->u32) );
+break;
+
+default:
+return X86EMUL_UNHANDLEABLE;
+
+#undef asm64
+#undef popfl
+}
+
+return X86EMUL_OKAY;
+}
+
 static int cmpxchg(
 enum x86_segment seg,
 unsigned long offset,
@@ -410,6 +543,7 @@ int main(int argc, char **argv)
 if ( !stack_exec )
 printf("Warning: Stack could not be made executable (%d).\n", errno);
 
+ rmw_restart:
 printf("%-40s", "Testing addl 

[Xen-devel] [PATCH 1/2] CODING_STYLE: removing trailing whitespaces

[Julien Grall]

Signed-off-by: Julien Grall 
---
 CODING_STYLE | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/CODING_STYLE b/CODING_STYLE
index 4c3b53a754..6cc5b774cf 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -4,11 +4,11 @@ Coding Style for the Xen Hypervisor
 The Xen coding style described below is the coding style used by the
 Xen hypervisor itself (xen/*) as well as various associated low-level
 libraries (e.g. tools/libxc/*).
-
+
 An exception is made for files which are imported from an external
 source. In these cases the prevailing coding style of the upstream
 source is generally used (commonly the Linux coding style).
-
+
 Other parts of the code base may use other coding styles, sometimes
 explicitly (e.g. tools/libxl/CODING_STYLE) but often implicitly (Linux
 coding style is fairly common). In general you should copy the style
-- 
2.11.0


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

[Xen-devel] [PATCH 2/2] CODING_STYLE: Forbid nested block in the hypervisor code

[Julien Grall]

When removing if/for/while statements, the code should be reworked to
remove the { } and the extra indentation. This is improving code
maintainability and code readability.

Signed-off-by: Julien Grall 

---
This patch was triggered whilst reviewing a patch [1] on ARM that
remove the if statement but keep the braces around. I personally
dislike such changes as it make the code less and readable maintenable
in the future. Stefano asked to send a patch against CODING_STYLE to
apply the rule to all the hypervisor code.

I am not entirely sure about the name of those type of block and the
wording. I would appreciate any advice here.

[1] https://lists.xen.org/archives/html/xen-devel/2017-07/msg00060.html
---
 CODING_STYLE | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/CODING_STYLE b/CODING_STYLE
index 6cc5b774cf..d1575a7068 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -88,6 +88,21 @@ Braces should be omitted for blocks with a single statement. 
e.g.,
 if ( condition )
 single_statement();
 
+Nested blocks
+-
+
+Nested blocks should be avoided e.g:
+
+int a;
+{
+int b;
+/* Do stuff */
+}
+/* Do stuff */
+
+More importantly, if a patch requires to remove an if/while/for statements, the
+code should be reworked rather than introducing a nested block.
+
 Comments
 
 
-- 
2.11.0


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

[Xen-devel] Question about "xen: Revert commits da72ff5bfcb0 and 72a9b186292d"

[Jean-Louis Dupond]

Hi All,

We had some issues with BSOD's on Windows at startup when using some old 
Xen drivers inside Windows.
Now when we upgrade to the most recent 4.9.x kernel. The issue seems to 
be resolved.


Could it be that the following commit fixes the issue:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=84d582d236dc1f9085e741affc72e9ba061a67c2
?

As far as I can see it only breaks Xen < 4.0. But could it be it also 
breaks Windows VM's with old Xen drivers?


Thanks
Jean-Louis

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

[Xen-devel] [ovmf baseline-only test] 71632: tolerable FAIL

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 71632 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71632/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-i386-libvirt5 libvirt-buildfail   like 71630
 build-amd64-libvirt   5 libvirt-buildfail   like 71630

version targeted for testing:
 ovmf 1e6add9e476696461526163bde843570cfdffb39
baseline version:
 ovmf fb5a64de3a8be8482c3173f85cddda5ae204fe40

Last test of basis71630  2017-07-04 03:49:09 Z0 days
Testing same since71632  2017-07-04 06:16:49 Z0 days1 attempts


People who touched revisions under test:
  Chris Ruffin 

jobs:
 build-amd64-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  fail
 build-i386-libvirt   fail
 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 1e6add9e476696461526163bde843570cfdffb39
Author: Chris Ruffin 
Date:   Thu Jun 22 14:59:49 2017 -0400

BaseTools: suppress usage instructions with rebuild options

When using edksetup.bat Rebuild, the script outputs usage instructions
to the console, when no usage error is encountered.  Update the usage
instructions and suppress these usage instructions when using the
Rebuild, ForceRebuild options.

Change-Id: Ica98e19f3d5198df2519106e4c55314c255e04ac
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chris Ruffin 
Reviewed-by: Yonghong Zhu 

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

[Xen-devel] [PATCH] xen-blkfront: emit KOBJ_OFFLINE uevent when detaching device

[Vincent Legout]

Devices are not unmounted inside a domU after a xl block-detach.

After xl block-detach, blkfront_closing() is called with state ==
XenbusStateConnected, it detects that the device is still in use and
only switches state to XenbusStateClosing. blkfront_closing() is called
a second time but returns immediately because state ==
XenbusStateClosing. Thus the device keeps being mounted inside the domU.

To fix this, emit a KOBJ_OFFLINE uevent even if the device has users.

With this patch, inside domU, udev has:

KERNEL[16994.526789] offline  /devices/vbd-51728/block/xvdb (block)
KERNEL[16994.796197] remove   /devices/virtual/bdi/202:16 (bdi)
KERNEL[16994.797167] remove   /devices/vbd-51728/block/xvdb (block)
UDEV  [16994.798035] remove   /devices/virtual/bdi/202:16 (bdi)
UDEV  [16994.809429] offline  /devices/vbd-51728/block/xvdb (block)
UDEV  [16994.842365] remove   /devices/vbd-51728/block/xvdb (block)
KERNEL[16995.461991] remove   /devices/vbd-51728 (xen)
UDEV  [16995.462549] remove   /devices/vbd-51728 (xen)

While without, it had:

KERNEL[30.862764] remove   /devices/vbd-51728 (xen)
UDEV  [30.867838] remove   /devices/vbd-51728 (xen)

Signed-off-by: Pascal Bouchareine 
Signed-off-by: Fatih Acar 
Signed-off-by: Vincent Legout 
---
 drivers/block/xen-blkfront.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c
index 39459631667c..da0b0444ee1f 100644
--- a/drivers/block/xen-blkfront.c
+++ b/drivers/block/xen-blkfront.c
@@ -2185,8 +2185,10 @@ static void blkfront_closing(struct blkfront_info *info)
mutex_lock(>bd_mutex);
 
if (bdev->bd_openers) {
-   xenbus_dev_error(xbdev, -EBUSY,
-"Device in use; refusing to close");
+   dev_warn(disk_to_dev(info->gd),
+"detaching %s with pending users\n",
+xbdev->nodename);
+   kobject_uevent(_to_dev(info->gd)->kobj, KOBJ_OFFLINE);
xenbus_switch_state(xbdev, XenbusStateClosing);
} else {
xlvbd_release_gendisk(info);
-- 
2.13.2


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

Re: [Xen-devel] [PATCH v2 4/4] vsmc: psci: remove 64 bit mode check

[Julien Grall]

Hi,

On 07/03/2017 06:29 PM, Stefano Stabellini wrote:

On Sun, 2 Jul 2017, Julien Grall wrote:

Hi,

On 06/30/2017 10:19 PM, Stefano Stabellini wrote:

On Thu, 22 Jun 2017, Volodymyr Babchuk wrote:

PSCI handling code had helper routine that checked calling convention.
It does not needed anymore, because:

   - Generic handler checks that 64 bit calls can be made only by
 64 bit guests.

   - SMCCC requires that 64-bit handler should support both 32 and 64 bit
 calls even if they originate from 64 bit caller.

This patch removes that extra check.

Signed-off-by: Volodymyr Babchuk 
---
   xen/arch/arm/vsmc.c | 13 +
   1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/xen/arch/arm/vsmc.c b/xen/arch/arm/vsmc.c
index 5f10fd1..1983e0e 100644
--- a/xen/arch/arm/vsmc.c
+++ b/xen/arch/arm/vsmc.c
@@ -98,12 +98,6 @@ static bool handle_arch(struct cpu_user_regs *regs)
   return false;
   }
   -/* helper function for checking arm mode 32/64 bit */
-static inline int psci_mode_check(struct domain *d, register_t fid)
-{
-return !( is_64bit_domain(d)^( (fid & PSCI_0_2_64BIT) >> 30 ) );
-}
-
   /* PSCI 2.0 interface */
   static bool handle_ssc(struct cpu_user_regs *regs)
   {
@@ -125,8 +119,7 @@ static bool handle_ssc(struct cpu_user_regs *regs)
   return true;
   case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_MIGRATE_INFO_UP_CPU):
   perfc_incr(vpsci_migrate_info_up_cpu);
-if ( psci_mode_check(current->domain, fid) )
-set_user_reg(regs, 0, do_psci_0_2_migrate_info_up_cpu());
+set_user_reg(regs, 0, do_psci_0_2_migrate_info_up_cpu());
   return true;
   case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_SYSTEM_OFF):
   perfc_incr(vpsci_system_off);
@@ -140,7 +133,6 @@ static bool handle_ssc(struct cpu_user_regs *regs)
   return true;
   case ARM_SMCCC_FUNC_NUM(PSCI_0_2_FN_CPU_ON):
   perfc_incr(vpsci_cpu_on);
-if ( psci_mode_check(current->domain, fid) )


I would prefer if the `return true' was within the { } block. But anyway
it's just a code style issue, so:


Well, I think we should keep the coding style consistent within arch/arm. If
we have the return true within {} in other place. Then this should be done
here.

In general, { } should only be used to en-globe everything in a case or for
if/else/while/for with more than a line. All the other kind of { } should be
avoided. I particularly dislike any code doing

code

{
variable definition;

code
}

code

Unless you have a strong reason to do it (avoiding reworking the code is not
one), I will nack any code resulting to that.


Right, care to submit a patch for CODING_STYLE? I noticed there are no
entries on this topic.


I can write down a patch assuming the other hypervisor maintainers are 
happy with it.


Cheers,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v2 1/2] tools/libxl/libxl_pci.c: Extract sysfs_dev_get_class from libxl__grant_vga_iomem_permission

[Wei Liu]

On Tue, Jul 04, 2017 at 12:30:58PM +0100, Roger Pau Monné wrote:
> On Tue, Jul 04, 2017 at 12:07:30PM +0100, Wei Liu wrote:
> > On Mon, Jul 03, 2017 at 03:25:52AM +0800, Xiong Zhang wrote:
> > > No functional change. Just extract this function for next patch and avoid
> > > code repetition.
> > > 
> > > Signed-off-by: Xiong Zhang 
> > 
> > Acked-by: Wei Liu 
> > 
> > Note to self: maybe add some blank lines while committing.
> 
> Not that I intend this patch to fix this, but poking ad sysfs nodes
> should be done in libxl_linux.c.

Indeed. Patches welcome...

> 
> Roger.

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

Re: [Xen-devel] [PATCH] xl console: Add interactive option

[Wei Liu]

On Mon, Jul 03, 2017 at 08:34:22AM +0200, Felix Schmoll wrote:
> Added an interactive option to the 'xl console'-command that
> forwards the input stream of the console to the underlying pty.
> 
> Made corresponding changes to libxl, xl and xenconsole.
> 
> Signed-off-by: Felix Schmoll 
> ---
>  tools/console/client/main.c |  4 
>  tools/libxl/libxl.h |  5 +++--
>  tools/libxl/libxl_console.c | 19 ++-
>  tools/xl/xl_console.c   | 11 +++
>  tools/xl/xl_vmcontrol.c |  2 +-
>  5 files changed, 29 insertions(+), 12 deletions(-)
> 
> diff --git a/tools/console/client/main.c b/tools/console/client/main.c
> index 99f034..a3c4b00835 100644
> --- a/tools/console/client/main.c
> +++ b/tools/console/client/main.c
> @@ -334,6 +334,7 @@ int main(int argc, char **argv)
>   { "num", 1, 0, 'n' },
>   { "help",0, 0, 'h' },
>   { "start-notify-fd", 1, 0, 's' },
> + { "pipe", 0, 0, 'p' },
>   { 0 },
>  
>   };
> @@ -370,6 +371,9 @@ int main(int argc, char **argv)
>   case 's':
>   start_notify_fd = atoi(optarg);
>   break;
> +case 'p':
> +interactive = 1;
> +break;

Indentation is wrong.

And I believe some more changes are needed. Currently interactive also
changes the terminal attributes via tcsetattr. Since now STDIN isn't
really a tty, we need to skip that.

I think you need to introduce a new flag, not reusing interactive.

>   default:
>   fprintf(stderr, "Invalid argument\n");
>   fprintf(stderr, "Try `%s --help' for more 
> information.\n", 
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index cf8687aa7e..a55f9b1cc7 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -1499,7 +1499,8 @@ int libxl_vncviewer_exec(libxl_ctx *ctx, uint32_t 
> domid, int autopass);
>   * the caller that it has connected to the guest console.
>   */
>  int libxl_console_exec(libxl_ctx *ctx, uint32_t domid, int cons_num,
> -   libxl_console_type type, int notify_fd);
> +   libxl_console_type type, int notify_fd,
> +   int interactive);

If we're to change libxl API, we need to provide compatibility
implementation for older version of this API. See the surrounding code.

And I think using "pipe" is better.

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

Re: [Xen-devel] [PATCH v2 1/2] tools/libxl/libxl_pci.c: Extract sysfs_dev_get_class from libxl__grant_vga_iomem_permission

[Roger Pau Monné]

On Tue, Jul 04, 2017 at 12:07:30PM +0100, Wei Liu wrote:
> On Mon, Jul 03, 2017 at 03:25:52AM +0800, Xiong Zhang wrote:
> > No functional change. Just extract this function for next patch and avoid
> > code repetition.
> > 
> > Signed-off-by: Xiong Zhang 
> 
> Acked-by: Wei Liu 
> 
> Note to self: maybe add some blank lines while committing.

Not that I intend this patch to fix this, but poking ad sysfs nodes
should be done in libxl_linux.c.

Roger.

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

[Xen-devel] [xen-unstable-smoke test] 111371: tolerable trouble: broken/pass - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-arm64-arm64-xl-xsm   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt 13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  14 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  6a0b420a7a086af21dbcf15172f24ad1af12a1f2
baseline version:
 xen  a7d802bca13489d303749177127089af48844f29

Last test of basis   111364  2017-07-03 16:02:36 Z0 days
Testing same since   111371  2017-07-04 09:23:04 Z0 days1 attempts


People who touched revisions under test:
  Haozhong Zhang 

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



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

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

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

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


Pushing revision :

+ branch=xen-unstable-smoke
+ revision=6a0b420a7a086af21dbcf15172f24ad1af12a1f2
+ . ./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 xen-unstable-smoke 
6a0b420a7a086af21dbcf15172f24ad1af12a1f2
+ branch=xen-unstable-smoke
+ revision=6a0b420a7a086af21dbcf15172f24ad1af12a1f2
+ . ./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=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.9-testing
+ '[' x6a0b420a7a086af21dbcf15172f24ad1af12a1f2 = 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/xtf.git
++ : osst...@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.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/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osst...@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : 

Re: [Xen-devel] [PATCH v2 1/2] tools/libxl/libxl_pci.c: Extract sysfs_dev_get_class from libxl__grant_vga_iomem_permission

[Wei Liu]

On Mon, Jul 03, 2017 at 03:25:52AM +0800, Xiong Zhang wrote:
> No functional change. Just extract this function for next patch and avoid
> code repetition.
> 
> Signed-off-by: Xiong Zhang 

Acked-by: Wei Liu 

Note to self: maybe add some blank lines while committing.

> ---
> Changes in v2:
> -Add No functional change in commit message
> -Use 'goto out' style error handling
> ---
>  tools/libxl/libxl_pci.c | 47 +--
>  1 file changed, 29 insertions(+), 18 deletions(-)
> 
> diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
> index b14df16..d109930 100644
> --- a/tools/libxl/libxl_pci.c
> +++ b/tools/libxl/libxl_pci.c
> @@ -531,6 +531,34 @@ static uint16_t sysfs_dev_get_device(libxl__gc *gc, 
> libxl_device_pci *pcidev)
>  return pci_device_device;
>  }
>  
> +static int sysfs_dev_get_class(libxl__gc *gc, libxl_device_pci *pcidev,
> +   unsigned long *class)
> +{
> +char *pci_device_class_path = GCSPRINTF(SYSFS_PCI_DEV"/"PCI_BDF"/class",
> + pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
> +int read_items, ret = 0;
> +
> +FILE *f = fopen(pci_device_class_path, "r");
> +if (!f) {
> +LOGE(ERROR,
> + "pci device "PCI_BDF" does not have class attribute",
> + pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
> +ret = ERROR_FAIL;
> +goto out;
> +}

Here.

> +read_items = fscanf(f, "0x%lx\n", class);

Here.

> +fclose(f);

Here.

> +if (read_items != 1) {
> +LOGE(ERROR,
> + "cannot read class of pci device "PCI_BDF,
> + pcidev->domain, pcidev->bus, pcidev->dev, pcidev->func);
> +ret = ERROR_FAIL;
> +}
> +
> +out:
> +return ret;
> +}
> +

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