date:20160329

>>> On 25.03.16 at 19:47,  wrote:
> On Thu, Mar 17, 2016 at 10:14:22AM -0600, Jan Beulich wrote:
> 
> Something is off with your patch. This is 5/4 :-)

Well, yes - this got added later on top of the previously sent series,
to make the dependency obvious.

>> Instead of addressing these fields via the base of the stack (which
>> uniformly requires 4-byte displacements), address them from the end
>> (which for everything other than guest_cpu_user_regs requires just
>> 1-byte ones). This yields a code size reduction somewhere between 8k
>> and 12k in my builds.
> 
> Also you made the macro a bit different - the %r is removed.
> 
> Particular reason? 

This is an integral part of the change, so the macro can derive
e.g. both %eax and %rax from the passed argument

Jan


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

Re: [Xen-devel] [PATCH v7 00/22] Prepare UEFI and ACPI tables for Dom0 on ARM64

>>> On 25.03.16 at 14:48,  wrote:
> These patches are Part 4 (and last part) of the previous patch set I
> sent which adds ACPI support for arm64 on Xen[1]. Split them as an
> individual set for convenient reviewing.
> 
> These patches create UEFI and ACPI tables which are mapped to Dom0's
> space and add other preparations for Dom0 to use ACPI. Then at last
> enable ACPI support on ARM64.

Looks like this series is ready to go in up to patch 20. Julien, you
had a number of comments on v6, and I didn't follow the
discussion too closely - could you (just informally, no need to send
out further individual acks if you didn't mean to send such anyway)
confirm that all the issues you had raised have got taken care of?

Thanks, Jan

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

Re: [Xen-devel] [PATCH 1/2] IOMMU/MMU: Adjust top level functions for VT-d Device-TLB flush error.

>>> On 28.03.16 at 05:33,  wrote:
> On March 18, 2016 1:15am,  wrote:
>> >>> On 17.03.16 at 07:54,  wrote:
>> > --- a/xen/common/grant_table.c
>> > +++ b/xen/common/grant_table.c
>> > @@ -932,8 +932,9 @@ __gnttab_map_grant_ref(
>> >  {
>> >  nr_gets++;
>> >  (void)get_page(pg, rd);
>> > -if ( !(op->flags & GNTMAP_readonly) )
>> > -get_page_type(pg, PGT_writable_page);
>> > +if ( !(op->flags & GNTMAP_readonly) &&
>> > + !get_page_type(pg, PGT_writable_page) )
>> > +goto could_not_pin;
>> 
>> This needs explanation, as it doesn't look related to what your actual goal 
>> is: If
>> an error was possible here, I think this would be a security issue. However, 
>> as
>> also kind of documented by the explicitly ignored return value from 
>> get_page(),
>> it is my understanding there here we only obtain an _extra_ reference.
>> 
> 
> For this point, I inferred from:
> map_vcpu_info()
> {
> ...
> if ( !get_page_type(page, PGT_writable_page) )
> {
> put_page(page);
> return -EINVAL;
> }
> ...
> }
> , then for get_page_type(), I think the return value:
>  0 -- error, 
>  1-- right.
> 
> So if get_page_type() is failed, we should goto could_not_pin.

Did you read my reply at all? The explanation I'm expecting here is
why error checking is all of the sudden needed _at all_.

> btw, there is another issue in the call path:
> iommu_{,un}map_page() -- __get_page_type() -- get_page_type()---
> 
> 
> I tried to return iommu_{,un}map_page() error code in __get_page_type(), is 
> it right?

If the operation got fully rolled back - yes. Whether fully rolling back
is feasible there though is - see the respective discussion - an open
question.

>> > --- a/xen/drivers/passthrough/x86/iommu.c
>> > +++ b/xen/drivers/passthrough/x86/iommu.c
>> > @@ -104,7 +104,11 @@ int arch_iommu_populate_page_table(struct
>> domain *d)
>> >  this_cpu(iommu_dont_flush_iotlb) = 0;
>> >
>> >  if ( !rc )
>> > -iommu_iotlb_flush_all(d);
>> > +{
>> > +rc = iommu_iotlb_flush_all(d);
>> > +if ( rc )
>> > +iommu_teardown(d);
>> > +}
>> >  else if ( rc != -ERESTART )
>> >  iommu_teardown(d);
>> 
>> Why can't you just use the existing call to iommu_teardown(), by simply 
> deleting
>> the "else"?
>> 
> 
> Just check it, could I modify it as below:
> --- a/xen/drivers/passthrough/x86/iommu.c
> +++ b/xen/drivers/passthrough/x86/iommu.c
> @@ -105,7 +105,8 @@ int arch_iommu_populate_page_table(struct domain *d)
> 
>  if ( !rc )
>  iommu_iotlb_flush_all(d);
> -else if ( rc != -ERESTART )
> +
> +if ( rc != -ERESTART )
>  iommu_teardown(d);

Clearly not - not only are you losing the return value of
iommu_iotlb_flush_all() now, you would then also call
iommu_teardown() in the "success" case. My comment was
related to code structure, yet you seem to have taken it
literally.

Jan


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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64  3 host-install(3) broken in 87395 REGR. vs. 66399
 build-amd64-rumpuserxen   6 xen-build fail REGR. vs. 66399
 build-i386-rumpuserxen6 xen-build fail REGR. vs. 66399

Tests which are failing intermittently (not blocking):
 test-armhf-armhf-xl-xsm  16 guest-start.2  fail in 87117 pass in 86830
 test-armhf-armhf-xl   15 guest-start/debian.repeat fail in 87204 pass in 87582
 test-armhf-armhf-libvirt-qcow2  6 xen-boot fail in 87204 pass in 87765
 test-armhf-armhf-xl-rtds 11 guest-startfail in 87204 pass in 87765
 test-armhf-armhf-xl-cubietruck 11 guest-start  fail in 87204 pass in 87765
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
in 87295 pass in 87765
 test-amd64-amd64-xl-qemuu-win7-amd64 15 guest-localmigrate/x10 fail in 87295 
pass in 87765
 test-armhf-armhf-xl-multivcpu 15 guest-start/debian.repeat fail in 87395 pass 
in 87204
 test-armhf-armhf-xl-credit2  16 guest-start.2  fail in 87395 pass in 87295
 test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail in 87692 pass in 
87395
 test-amd64-amd64-xl-qemut-debianhvm-amd64 13 guest-localmigrate fail in 87692 
pass in 87765
 test-armhf-armhf-xl-xsm  11 guest-startfail in 87692 pass in 87765
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat   fail pass in 87117
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 
87204
 test-armhf-armhf-xl-cubietruck 15 guest-start/debian.repeat fail pass in 87295
 test-armhf-armhf-xl-multivcpu 11 guest-startfail pass in 87395
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 
87582
 test-armhf-armhf-xl  11 guest-start fail pass in 87692
 test-armhf-armhf-xl-credit2  11 guest-start fail pass in 87692

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop  fail like 66399
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 66399
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 66399
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeatfail   like 66399
 test-armhf-armhf-xl-vhd   9 debian-di-installfail   like 66399
 test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 66399

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)blocked in 87395 n/a
 build-amd64-rumpuserxen   1 build-check(1)blocked in 87395 n/a
 test-amd64-amd64-xl-pvh-intel  1 build-check(1)   blocked in 87395 n/a
 test-amd64-amd64-xl-pvh-amd   1 build-check(1)blocked in 87395 n/a
 test-amd64-amd64-xl   1 build-check(1)blocked in 87395 n/a
 test-amd64-i386-qemut-rhel6hvm-intel  1 build-check(1)blocked in 87395 n/a
 test-amd64-amd64-libvirt  1 build-check(1)blocked in 87395 n/a
 test-amd64-i386-xl1 build-check(1)blocked in 87395 n/a
 test-amd64-amd64-xl-multivcpu  1 build-check(1)   blocked in 87395 n/a
 test-amd64-amd64-pygrub   1 build-check(1)blocked in 87395 n/a
 test-amd64-amd64-amd64-pvgrub  1 build-check(1)   blocked in 87395 n/a
 test-amd64-amd64-xl-credit2   1 build-check(1)blocked in 87395 n/a
 test-amd64-i386-libvirt   1 build-check(1)blocked in 87395 n/a
 test-amd64-amd64-libvirt-xsm  1 build-check(1)blocked in 87395 n/a
 test-amd64-amd64-i386-pvgrub  1 build-check(1)blocked in 87395 n/a
 test-amd64-i386-pair  1 build-check(1)blocked in 87395 n/a
 test-amd64-amd64-xl-qcow2 1 build-check(1)blocked in 87395 n/a
 test-amd64-amd64-pair 1 build-check(1)blocked in 87395 n/a
 test-amd64-amd64-libvirt-pair  1 build-check(1)   blocked in 87395 n/a
 test-amd64-i386-qemut-rhel6hvm-amd  1 build-check(1)  blocked in 87395 n/a
 test-amd64-amd64-xl-rtds  1 build-check(1)blocked in 87395 n/a
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked in 
87395 n/a
 test-amd64-i386-libvirt-pair  1 build-check(1)blocked in 87395 n/a
 test-amd64-amd64-qemuu-nested-amd  1 build-check(1)   blocked in 87395 n/a
 test-amd64-i386-qemuu-rhel6hvm-amd  1 build-check(1)  blocked in 87395 n/a
 test-amd64-amd64-qemuu-nested-intel  1 build-check(1) blocked in 87395 n/a
 test-amd64-amd64-xl-qemut-debianhvm-amd64 1 build-check(1) blocked in 87395 n/a
 test-amd64-i386-freebsd10-amd64  1 build-check(1) blocked in 87395 n/a
 test-amd64-i386-xl-qemut-win7-amd64  1 build-check(1) blocked

Re: [Xen-devel] [PATCH 2/2] IOMMU/MMU: Adjust low level functions for VT-d Device-TLB flush error.

>>> On 25.03.16 at 10:27,  wrote:
> On March 18, 2016 6:20pm,  wrote:
>> >>> On 17.03.16 at 07:54,  wrote:
>> > --- a/xen/drivers/passthrough/iommu.c
>> > +++ b/xen/drivers/passthrough/iommu.c
>> > @@ -182,7 +182,11 @@ void __hwdom_init iommu_hwdom_init(struct
>> domain *d)
>> >   ((page->u.inuse.type_info & PGT_type_mask)
>> >== PGT_writable_page) )
>> >  mapping |= IOMMUF_writable;
>> > -hd->platform_ops->map_page(d, gfn, mfn, mapping);
>> > +if ( hd->platform_ops->map_page(d, gfn, mfn, mapping) )
>> > +printk(XENLOG_G_ERR
>> > +   "IOMMU: Map page gfn: 0x%lx(mfn: 0x%lx)
>> failed.\n",
>> > +   gfn, mfn);
>> > +
>> 
>> Printing one message here is certainly necessary, but what if the failure 
> repeats
>> for very many pages? 
> 
> Yes, to me, it is ok, but I am open to your suggestion.
> 
>> Also %#lx instead of 0x%lx please, and a blank before the
>> opening parenthesis.
>> 
> OK, just check it:
> 
> ..
> "IOMMU: Map page gfn: %#lx (mfn: %#lx) failed.\n"
> ..
> 
> Right?

Almost: Generally no full stop in log messages please. And I think
the word "page" is redundant here. As rule of thumb: Log
messages should give as much as possible useful information (which
includes the requirement for distinct ones to be distinguishable in
resulting logs) with as little as possible verbosity.

>> > @@ -554,11 +555,24 @@ static void iommu_flush_all(void)
>> >  iommu = drhd->iommu;
>> >  iommu_flush_context_global(iommu, 0);
>> >  flush_dev_iotlb = find_ats_dev_drhd(iommu) ? 1 : 0;
>> > -iommu_flush_iotlb_global(iommu, 0, flush_dev_iotlb);
>> > +rc = iommu_flush_iotlb_global(iommu, 0, flush_dev_iotlb);
>> > +
>> > +if ( rc > 0 )
>> > +{
>> > +iommu_flush_write_buffer(iommu);
>> 
>> Why is this needed all of the sudden?
> 
> As there may be multiple IOMMUs. .e.g, there are 2 IOMMUs in my machine, and 
> I can find the following log message:
> """
> (XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB.
> (XEN) Intel VT-d iommu 1 supported page sizes: 4kB, 2MB, 1GB.
> """
> __iiuc__, iommu_flush_write_buffer() is per IOMMU, so It should be called to 
> flush every IOMMU.

For one what you say suggests that right now this is being done
for some (one?) IOMMU(s), which I don't see being the case. And
then what you say _still_ doesn't say _why_ this is now needed all
of the sudden. If, in the course of doing your re-work here, you
find pre-existing issues with the code, please split the necessary
fixes out of your re-work and submit them separately with proper
explanations in their commit messages.

>> > +rc = 0;
>> > +}
>> > +else if ( rc < 0 )
>> > +{
>> > +printk(XENLOG_G_ERR "IOMMU: IOMMU flush all failed.\n");
>> > +break;
>> > +}
>> 
>> Is a log message really advisable here?
>> 
> 
> To me, It looks tricky too. I was struggling to make decision. For scheme B, 
> I would try to do as below:
> 
> if ( iommu_flush_all() )
> printk("... nnn ...");
> 
> but there are 4 function calls, if so, to me, it looks redundant.
> 
> Or, could I ignore the print out for iommu_flush_all() failed?

Directing the question back is not helpful: You should know better
than me why you had added a log message there in the first place.
And it is this "why" which is to judge about whether it should stay
there, move elsewhere, or get dropped altogether.

>> > @@ -622,7 +640,7 @@ static void dma_pte_clear_one(struct domain
>> *domain, u64 addr)
>> >  if ( pg_maddr == 0 )
>> >  {
>> >  spin_unlock(&hd->arch.mapping_lock);
>> > -return;
>> > +return -ENOMEM;
>> >  }
>> 
>> addr_to_dma_page_maddr() gets called with "alloc" being false, so there can't
>> be any memory allocation failure here. There simply is nothing to do in this
>> case.
>> 
> 
> I copy it from iommu_map_page().
> 
> Good, then the error of iommu_unmap_page() looks only from flush (the crash 
> is at least obvious), then error handling can be lighter weight--
> We may return an error, but don't roll back the failed operation.
> Right?

I don't think so, and I can only re-iterate: There can't be any error
here, so there's no error code to forward up the call tree. IOW the
"pg_maddr == 0" case simply means "nothing to do" here.

>> > -void me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map)
>> > +int me_wifi_quirk(struct domain *domain, u8 bus, u8 devfn, int map)
>> >  {
>> >  u32 id;
>> > +int rc = 0;
>> >
>> >  id = pci_conf_read32(0, 0, 0, 0, 0);
>> >  if ( IS_CTG(id) )
>> >  {
>> >  /* quit if ME does not exist */
>> >  if ( pci_conf_read32(0, 0, 3, 0, 0) == 0x )
>> > -return;
>> > +return -ENOENT;
>> 
>> Is this really an error? IOW, do all systems which satisfy IS_CTG() have 
>> such a
>>

Re: [Xen-devel] [PATCH v8 01/17] Xen: ACPI: Hide UART used by Xen

2016-03-29 Thread Shannon Zhao



On 2016/3/26 1:15, Bjorn Helgaas wrote:
> On Fri, Mar 25, 2016 at 04:05:49PM +0800, Shannon Zhao wrote:
>> > From: Shannon Zhao 
>> > 
>> > ACPI 6.0 introduces a new table STAO to list the devices which are used
>> > by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
>> > UART is used by Xen. So here it hides UART from Dom0.
>> > 
>> > CC: "Rafael J. Wysocki"  (supporter:ACPI)
>> > CC: Len Brown  (supporter:ACPI)
>> > CC: linux-a...@vger.kernel.org (open list:ACPI)
>> > Signed-off-by: Shannon Zhao 
>> > ---
>> >  drivers/acpi/scan.c | 68 
>> > +
>> >  1 file changed, 68 insertions(+)
>> > 
>> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
>> > index 5f28cf7..5420cc5 100644
>> > --- a/drivers/acpi/scan.c
>> > +++ b/drivers/acpi/scan.c
>> > @@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
>> >  DEFINE_MUTEX(acpi_device_lock);
>> >  LIST_HEAD(acpi_wakeup_device_list);
>> >  static DEFINE_MUTEX(acpi_hp_context_lock);
>> > +static u64 spcr_uart_addr;
>> >  
>> >  struct acpi_dep_data {
>> >struct list_head node;
>> > @@ -1453,6 +1454,41 @@ static int acpi_add_single_object(struct 
>> > acpi_device **child,
>> >return 0;
>> >  }
>> >  
>> > +static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
>> > +  void *context)
>> > +{
>> > +  struct resource *res = context;
>> > +
>> > +  if (acpi_dev_resource_memory(ares, res))
>> > +  return AE_CTRL_TERMINATE;
>> > +
>> > +  return AE_OK;
>> > +}
>> > +
>> > +static bool acpi_device_should_be_hidden(acpi_handle handle)
>> > +{
>> > +  acpi_status status;
>> > +  struct resource res;
>> > +
>> > +  /* Check if it should ignore the UART device */
>> > +  if (spcr_uart_addr != 0) {
>> > +  if (!acpi_has_method(handle, METHOD_NAME__CRS))
>> > +  return false;
>> > +
>> > +  status = acpi_walk_resources(handle, METHOD_NAME__CRS,
>> > +   acpi_get_resource_memory, &res);
>> > +  if (ACPI_FAILURE(status))
>> > +  return false;
>> > +
>> > +  if (res.start == spcr_uart_addr) {
>> > +  printk(KERN_INFO PREFIX "The UART device in SPCR table 
>> > will be hidden\n");
> Can we at least print out the ACPI device path and address here for
> debugging purposes?  IMHO, kernel messages that contain only static
> text are always dubious.  There's almost always a useful address, IRQ,
> return value, etc., that could be included.
> 
Ok, I'll add the device address in the message and update this patch.

Thanks,
-- 
Shannon


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

[Xen-devel] [PATCH v9 01/17] Xen: ACPI: Hide UART used by Xen

2016-03-29 Thread Shannon Zhao

From: Shannon Zhao 

ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.

CC: "Rafael J. Wysocki"  (supporter:ACPI)
CC: Len Brown  (supporter:ACPI)
CC: linux-a...@vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao 
---
v9: add the UART device address in printed message
---
 drivers/acpi/scan.c | 69 +
 1 file changed, 69 insertions(+)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..29f26fc 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
 DEFINE_MUTEX(acpi_device_lock);
 LIST_HEAD(acpi_wakeup_device_list);
 static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
 
 struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,42 @@ static int acpi_add_single_object(struct acpi_device 
**child,
return 0;
 }
 
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+   void *context)
+{
+   struct resource *res = context;
+
+   if (acpi_dev_resource_memory(ares, res))
+   return AE_CTRL_TERMINATE;
+
+   return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+   acpi_status status;
+   struct resource res;
+
+   /* Check if it should ignore the UART device */
+   if (spcr_uart_addr != 0) {
+   if (!acpi_has_method(handle, METHOD_NAME__CRS))
+   return false;
+
+   status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+acpi_get_resource_memory, &res);
+   if (ACPI_FAILURE(status))
+   return false;
+
+   if (res.start == spcr_uart_addr) {
+   printk(KERN_INFO PREFIX "The UART device @%pa in SPCR 
table will be hidden\n",
+  &res.start);
+   return true;
+   }
+   }
+
+   return false;
+}
+
 static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
 {
@@ -1466,6 +1503,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, 
int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+   if (acpi_device_should_be_hidden(handle))
+   return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1956,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
 }
 
+static void __init acpi_get_spcr_uart_addr(void)
+{
+   acpi_status status;
+   struct acpi_table_spcr *spcr_ptr;
+
+   status = acpi_get_table(ACPI_SIG_SPCR, 0,
+   (struct acpi_table_header **)&spcr_ptr);
+   if (ACPI_SUCCESS(status))
+   spcr_uart_addr = spcr_ptr->serial_port.address;
+   else
+   printk(KERN_WARNING PREFIX "STAO table present, but SPCR is 
missing\n");
+}
+
 int __init acpi_scan_init(void)
 {
int result;
+   acpi_status status;
+   struct acpi_table_stao *stao_ptr;
 
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1989,20 @@ int __init acpi_scan_init(void)
 
acpi_scan_add_handler(&generic_device_handler);
 
+   /*
+* If there is STAO table, check whether it needs to ignore the UART
+* device in SPCR table.
+*/
+   status = acpi_get_table(ACPI_SIG_STAO, 0,
+   (struct acpi_table_header **)&stao_ptr);
+   if (ACPI_SUCCESS(status)) {
+   if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+   printk(KERN_INFO PREFIX "STAO Name List not yet 
supported.");
+
+   if (stao_ptr->ignore_uart)
+   acpi_get_spcr_uart_addr();
+   }
+
mutex_lock(&acpi_scan_lock);
/*
 * Enumerate devices in the ACPI namespace.
-- 
2.0.4



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

[Xen-devel] [RESEND PATCH v9 01/17] Xen: ACPI: Hide UART used by Xen

2016-03-29 Thread Shannon Zhao

From: Shannon Zhao 

ACPI 6.0 introduces a new table STAO to list the devices which are used
by Xen and can't be used by Dom0. On Xen virtual platforms, the physical
UART is used by Xen. So here it hides UART from Dom0.

CC: "Rafael J. Wysocki"  (supporter:ACPI)
CC: Len Brown  (supporter:ACPI)
CC: linux-a...@vger.kernel.org (open list:ACPI)
Signed-off-by: Shannon Zhao 
---
v9: add the UART device address in printed message
---
 drivers/acpi/scan.c | 69 +
 1 file changed, 69 insertions(+)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..29f26fc 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -45,6 +45,7 @@ static LIST_HEAD(acpi_scan_handlers_list);
 DEFINE_MUTEX(acpi_device_lock);
 LIST_HEAD(acpi_wakeup_device_list);
 static DEFINE_MUTEX(acpi_hp_context_lock);
+static u64 spcr_uart_addr;
 
 struct acpi_dep_data {
struct list_head node;
@@ -1453,6 +1454,42 @@ static int acpi_add_single_object(struct acpi_device 
**child,
return 0;
 }
 
+static acpi_status acpi_get_resource_memory(struct acpi_resource *ares,
+   void *context)
+{
+   struct resource *res = context;
+
+   if (acpi_dev_resource_memory(ares, res))
+   return AE_CTRL_TERMINATE;
+
+   return AE_OK;
+}
+
+static bool acpi_device_should_be_hidden(acpi_handle handle)
+{
+   acpi_status status;
+   struct resource res;
+
+   /* Check if it should ignore the UART device */
+   if (spcr_uart_addr != 0) {
+   if (!acpi_has_method(handle, METHOD_NAME__CRS))
+   return false;
+
+   status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+acpi_get_resource_memory, &res);
+   if (ACPI_FAILURE(status))
+   return false;
+
+   if (res.start == spcr_uart_addr) {
+   printk(KERN_INFO PREFIX "The UART device @%pa in SPCR 
table will be hidden\n",
+  &res.start);
+   return true;
+   }
+   }
+
+   return false;
+}
+
 static int acpi_bus_type_and_status(acpi_handle handle, int *type,
unsigned long long *sta)
 {
@@ -1466,6 +1503,9 @@ static int acpi_bus_type_and_status(acpi_handle handle, 
int *type,
switch (acpi_type) {
case ACPI_TYPE_ANY: /* for ACPI_ROOT_OBJECT */
case ACPI_TYPE_DEVICE:
+   if (acpi_device_should_be_hidden(handle))
+   return -ENODEV;
+
*type = ACPI_BUS_TYPE_DEVICE;
status = acpi_bus_get_status_handle(handle, sta);
if (ACPI_FAILURE(status))
@@ -1916,9 +1956,24 @@ static int acpi_bus_scan_fixed(void)
return result < 0 ? result : 0;
 }
 
+static void __init acpi_get_spcr_uart_addr(void)
+{
+   acpi_status status;
+   struct acpi_table_spcr *spcr_ptr;
+
+   status = acpi_get_table(ACPI_SIG_SPCR, 0,
+   (struct acpi_table_header **)&spcr_ptr);
+   if (ACPI_SUCCESS(status))
+   spcr_uart_addr = spcr_ptr->serial_port.address;
+   else
+   printk(KERN_WARNING PREFIX "STAO table present, but SPCR is 
missing\n");
+}
+
 int __init acpi_scan_init(void)
 {
int result;
+   acpi_status status;
+   struct acpi_table_stao *stao_ptr;
 
acpi_pci_root_init();
acpi_pci_link_init();
@@ -1934,6 +1989,20 @@ int __init acpi_scan_init(void)
 
acpi_scan_add_handler(&generic_device_handler);
 
+   /*
+* If there is STAO table, check whether it needs to ignore the UART
+* device in SPCR table.
+*/
+   status = acpi_get_table(ACPI_SIG_STAO, 0,
+   (struct acpi_table_header **)&stao_ptr);
+   if (ACPI_SUCCESS(status)) {
+   if (stao_ptr->header.length > sizeof(struct acpi_table_stao))
+   printk(KERN_INFO PREFIX "STAO Name List not yet 
supported.");
+
+   if (stao_ptr->ignore_uart)
+   acpi_get_spcr_uart_addr();
+   }
+
mutex_lock(&acpi_scan_lock);
/*
 * Enumerate devices in the ACPI namespace.
-- 
2.0.4



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

[Xen-devel] xen run on minnowboard

2016-03-29 Thread aicha hamza

hello
i'm trynig to run xen on minnowboard max .. well , there is no
documentation about this .. so i was thinking to install ubuntu on my
minnowboard and then install xen just like i worked on my host but i failed
.. i get an error during the installation of ubuntu ..so i decide to
install xen from the source but i don't know how exactly
what should i have on my sd card to get xen running on my board
do i need a bootloader , zimage , xen , dtbs and a file system !!
can you give me a little help.. i'll appreciate it


Regards



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

Re: [Xen-devel] [PATCH] x86/hvm/viridian: save APIC assist vector

>>> On 24.03.16 at 18:19,  wrote:
> @@ -293,10 +292,11 @@ void viridian_start_apic_assist(struct vcpu *v, int 
> vector)
>   * wrong and the VM will most likely hang so force a crash now
>   * to make the problem clear.
>   */
> -if ( v->arch.hvm_vcpu.viridian.apic_assist.vector >= 0 )
> +if ( v->arch.hvm_vcpu.viridian.apic_assist.vector != 0 )
>  domain_crash(v->domain);
>  
> -v->arch.hvm_vcpu.viridian.apic_assist.vector = vector;
> +/* Increment the value so that zero is always invalid. */
> +v->arch.hvm_vcpu.viridian.apic_assist.vector = vector + 1;

From an APIC perspective, aren't vectors below 0x10 invalid
anyway? I.e. can't zero serve the "none" indication just as much
as -1 did without this new biasing? Or otherwise I'd still expect ...

> @@ -829,13 +830,21 @@ static int viridian_load_vcpu_ctxt(struct domain *d, 
> hvm_domain_context_t *h)
>  return -EINVAL;
>  }
>  
> -if ( hvm_load_entry(VIRIDIAN_VCPU, h, &ctxt) != 0 )
> +if ( hvm_load_entry_zeroextend(VIRIDIAN_VCPU, h, &ctxt) != 0 )
>  return -EINVAL;
>  
> -v->arch.hvm_vcpu.viridian.apic_assist.msr.raw = ctxt.apic_assist;
> +v->arch.hvm_vcpu.viridian.apic_assist.msr.raw = ctxt.apic_assist_msr;
>  if ( v->arch.hvm_vcpu.viridian.apic_assist.msr.fields.enabled )
>  initialize_apic_assist(v);
>  
> +/*
> + * Guests that were saved on a host that did not use APIC assist
> + * will clearly never have a pending assist, so reading the zero
> + * value for apic_assist_vector from the zero extended save record
> + * will always be correct.
> + */
> +v->arch.hvm_vcpu.viridian.apic_assist.vector = ctxt.apic_assist_vector;

... the bias to get accounted for here, instead of quite a bit of
other code getting adjusted, and the meaning of the "vector"
field getting slightly mis-used.

Jan


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

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

2016-03-29 Thread Haozhong Zhang

On 03/17/16 22:21, Haozhong Zhang wrote:
> On 03/17/16 14:00, Ian Jackson wrote:
> > Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM 
> > support for Xen"):
> > > QEMU keeps mappings of guest memory because (1) that mapping is
> > > created by itself, and/or (2) certain device emulation needs to access
> > > the guest memory. But for vNVDIMM, I'm going to move the creation of
> > > its mappings out of qemu to toolstack and vNVDIMM in QEMU does not
> > > access vNVDIMM pages mapped to guest, so it's not necessary to let
> > > qemu keeps vNVDIMM mappings.
> > 
> > I'm confused by this.
> > 
> > Suppose a guest uses an emulated device (or backend) provided by qemu,
> > to do DMA to an vNVDIMM.  Then qemu will need to map the real NVDIMM
> > pages into its own address space, so that it can write to the memory
> > (ie, do the virtual DMA).
> > 
> > That virtual DMA might well involve a direct mapping in the kernel
> > underlying qemu: ie, qemu might use O_DIRECT to have its kernel write
> > directly to the NVDIMM, and with luck the actual device backing the
> > virtual device will be able to DMA to the NVDIMM.
> > 
> > All of this seems to me to mean that qemu needs to be able to map
> > its guest's parts of NVDIMMs
> > 
> > There are probably other example: memory inspection systems used by
> > virus scanners etc.; debuggers used to inspect a guest from outside;
> > etc.
> > 
> > I haven't even got started on save/restore...
> > 
> 
> Oops, so many cases I missed. Thanks Ian for pointing out all these!
> Now I need to reconsider how to manage guest permissions for NVDIMM pages.
> 

I still cannot find a neat approach to manage guest permissions for
nvdimm pages. A possible one is to use a per-domain bitmap to track
permissions: each bit corresponding to an nvdimm page. The bitmap can
save lots of spaces and even be stored in the normal ram, but
operating it for a large nvdimm range, especially for a contiguous
one, is slower than rangeset.

BTW, if I take the other way to map nvdimm pages to guest
(http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01972.html)
| 2. Or, given the same inputs, we may combine above two steps into a new
|dom0 system call that (1) gets the SPA ranges, (2) calls xen
|hypercall to map SPA ranges
and treat nvdimm as normal ram, then xen will not need to use rangeset
or above bitmap to track guest permissions for nvdimm? But looking at
how qemu currently populates guest memory via XENMEM_populate_physmap
, and other hypercalls like XENMEM_[in|de]crease_reservation, it looks
like that mapping a _dedicated_ piece of host ram to guest is not
allowed out of the hypervisor (and not allowed even in dom0 kernel)?
Is it for security concerns, e.g. avoiding a malfunctioned dom0 leaking
guest memory?

Thanks,
Haozhong

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

Re: [Xen-devel] [RFC PATCH 2/2] build: convert crash_debug to Kconfig

>>> On 25.03.16 at 22:02,  wrote:
> On 3/25/16 2:49 PM, Konrad Rzeszutek Wilk wrote:
>> On Thu, Mar 24, 2016 at 11:48:19AM -0500, Doug Goldstein wrote:
>>> --- a/xen/Kconfig.debug
>>> +++ b/xen/Kconfig.debug
>>> @@ -4,3 +4,14 @@ menuconfig DEBUG
>>> ---help---
>>>   If you want to debug Xen say Y and select any additional debugging
>>>   support options.
>>> +
>>> +if DEBUG
>> 
>> Perhaps if !defined then atuomatically enable it? Looking at Config.mk
>> it seems you could do crash_debug without debug=y?
> 
> debug=y unfortunately is more than just a "meta" option that selects
> verbose=y and frame_pointer=y. It also turns off NDEBUG so that debug
> messages appear. I'm not sure how that should be mapped in the context
> of this patch. Should the messages be enabled when DEBUG is enabled or
> should there be another option?

Let's not make this too fine grained, at least for now. I.e. enabling
DEBUG should mean exactly what "debug=y" so far meant.

Jan


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

Re: [Xen-devel] 4.4: INFO: rcu_sched self-detected stall on CPU

2016-03-29 Thread Steven Haigh

On 26/03/2016 8:07 AM, Steven Haigh wrote:
> On 26/03/2016 3:20 AM, Boris Ostrovsky wrote:
>> On 03/25/2016 12:04 PM, Steven Haigh wrote:
>>> It may not actually be the full logs. Once the system gets really upset,
>>> you can't run anything - as such, grabbing anything from dmesg is not
>>> possible.
>>>
>>> The logs provided above is all that gets spat out to the syslog server.
>>>
>>> I'll try tinkering with a few things to see if I can get more output -
>>> but right now, that's all I've been able to achieve. So far, my only
>>> ideas are to remove the 'quiet' options from the kernel command line -
>>> but I'm not sure how much that would help.
>>>
>>> Suggestions gladly accepted on this front.
>>
>> You probably want to run connected to guest serial console ("
>> serial='pty' " in guest config file and something like 'loglevel=7
>> console=tty0 console=ttyS0,38400n8' on guest kernel commandline). And
>> start the guest with 'xl create -c ' or connect later with 'xl
>> console '.
> 
> Ok thanks, I've booted the DomU with:
> 
> $ cat /proc/cmdline
> root=UUID=63ade949-ee67-4afb-8fe7-ecd96faa15e2 ro enforcemodulesig=1
> selinux=0 fsck.repair=yes loglevel=7 console=tty0 console=ttyS0,38400n8
> 
> I've left a screen session attached to the console (via xl console) and
> I'll see if that turns anything up. As this seems to be rather
> unpredictable when it happens, it may take a day or two to get anything.
> I just hope its more than the syslog output :)

Interestingly enough, this just happened again - but on a different
virtual machine. I'm starting to wonder if this may have something to do
with the uptime of the machine - as the system that this seems to happen
to is always different.

Destroying it and monitoring it again has so far come up blank.

I've thrown the latest lot of kernel messages here:
http://paste.fedoraproject.org/346802/59241532

Interestingly, around the same time, /var/log/messages on the remote
syslog server shows:
Mar 29 17:00:01 zeus systemd: Created slice user-0.slice.
Mar 29 17:00:01 zeus systemd: Starting user-0.slice.
Mar 29 17:00:01 zeus systemd: Started Session 1567 of user root.
Mar 29 17:00:01 zeus systemd: Starting Session 1567 of user root.
Mar 29 17:00:01 zeus systemd: Removed slice user-0.slice.
Mar 29 17:00:01 zeus systemd: Stopping user-0.slice.
Mar 29 17:01:01 zeus systemd: Created slice user-0.slice.
Mar 29 17:01:01 zeus systemd: Starting user-0.slice.
Mar 29 17:01:01 zeus systemd: Started Session 1568 of user root.
Mar 29 17:01:01 zeus systemd: Starting Session 1568 of user root.
Mar 29 17:08:34 zeus ntpdate[18569]: adjust time server 203.56.246.94
offset -0.002247 sec
Mar 29 17:08:34 zeus systemd: Removed slice user-0.slice.
Mar 29 17:08:34 zeus systemd: Stopping user-0.slice.
Mar 29 17:10:01 zeus systemd: Created slice user-0.slice.
Mar 29 17:10:01 zeus systemd: Starting user-0.slice.
Mar 29 17:10:01 zeus systemd: Started Session 1569 of user root.
Mar 29 17:10:01 zeus systemd: Starting Session 1569 of user root.
Mar 29 17:10:01 zeus systemd: Removed slice user-0.slice.
Mar 29 17:10:01 zeus systemd: Stopping user-0.slice.
Mar 29 17:20:01 zeus systemd: Created slice user-0.slice.
Mar 29 17:20:01 zeus systemd: Starting user-0.slice.
Mar 29 17:20:01 zeus systemd: Started Session 1570 of user root.
Mar 29 17:20:01 zeus systemd: Starting Session 1570 of user root.
Mar 29 17:20:01 zeus systemd: Removed slice user-0.slice.
Mar 29 17:20:01 zeus systemd: Stopping user-0.slice.
Mar 29 17:30:55 zeus systemd: systemd-logind.service watchdog timeout
(limit 1min)!
Mar 29 17:32:25 zeus systemd: systemd-logind.service stop-sigabrt timed
out. Terminating.
Mar 29 17:33:56 zeus systemd: systemd-logind.service stop-sigterm timed
out. Killing.
Mar 29 17:35:26 zeus systemd: systemd-logind.service still around after
SIGKILL. Ignoring.
Mar 29 17:36:56 zeus systemd: systemd-logind.service stop-final-sigterm
timed out. Killing.
Mar 29 17:38:26 zeus systemd: systemd-logind.service still around after
final SIGKILL. Entering failed mode.
Mar 29 17:38:26 zeus systemd: Unit systemd-logind.service entered failed
state.
Mar 29 17:38:26 zeus systemd: systemd-logind.service failed.

-- 
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897

signature.asc
Description: OpenPGP digital signature
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH v4 07/26] xen/x86: Calculate maximum host and guest featuresets

>>> On 23.03.16 at 17:36,  wrote:
> All of this information will be used by the toolstack to make informed
> levelling decisions for VMs, and by Xen to sanity check toolstack-provided
> information.

Not only am I still missing a sentence or two here on the two HVM
feature sets (namely why only one gets exposed), I'm also now
realizing that your intention of not exposing both in the public
interface is in contradiction with patch 6, which does expose both
of them, even if only in textual (comment) form. I.e. I think the
public header should then also get a note added that these
annotations are not part of the public interface.

Jan

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

Re: [Xen-devel] [PATCH] x86/hvm/viridian: save APIC assist vector

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 29 March 2016 09:42
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [PATCH] x86/hvm/viridian: save APIC assist vector
> 
> >>> On 24.03.16 at 18:19,  wrote:
> > @@ -293,10 +292,11 @@ void viridian_start_apic_assist(struct vcpu *v, int
> vector)
> >   * wrong and the VM will most likely hang so force a crash now
> >   * to make the problem clear.
> >   */
> > -if ( v->arch.hvm_vcpu.viridian.apic_assist.vector >= 0 )
> > +if ( v->arch.hvm_vcpu.viridian.apic_assist.vector != 0 )
> >  domain_crash(v->domain);
> >
> > -v->arch.hvm_vcpu.viridian.apic_assist.vector = vector;
> > +/* Increment the value so that zero is always invalid. */
> > +v->arch.hvm_vcpu.viridian.apic_assist.vector = vector + 1;
> 
> From an APIC perspective, aren't vectors below 0x10 invalid
> anyway? I.e. can't zero serve the "none" indication just as much
> as -1 did without this new biasing? Or otherwise I'd still expect ...
> 

I can do that, if you're happy with it. If I'm going to do it this way though I 
will also put in an explicit check to make sure APIC assist is not used for 
vectors < 0x16.

  Paul

> > @@ -829,13 +830,21 @@ static int viridian_load_vcpu_ctxt(struct domain
> *d, hvm_domain_context_t *h)
> >  return -EINVAL;
> >  }
> >
> > -if ( hvm_load_entry(VIRIDIAN_VCPU, h, &ctxt) != 0 )
> > +if ( hvm_load_entry_zeroextend(VIRIDIAN_VCPU, h, &ctxt) != 0 )
> >  return -EINVAL;
> >
> > -v->arch.hvm_vcpu.viridian.apic_assist.msr.raw = ctxt.apic_assist;
> > +v->arch.hvm_vcpu.viridian.apic_assist.msr.raw = ctxt.apic_assist_msr;
> >  if ( v->arch.hvm_vcpu.viridian.apic_assist.msr.fields.enabled )
> >  initialize_apic_assist(v);
> >
> > +/*
> > + * Guests that were saved on a host that did not use APIC assist
> > + * will clearly never have a pending assist, so reading the zero
> > + * value for apic_assist_vector from the zero extended save record
> > + * will always be correct.
> > + */
> > +v->arch.hvm_vcpu.viridian.apic_assist.vector = ctxt.apic_assist_vector;
> 
> ... the bias to get accounted for here, instead of quite a bit of
> other code getting adjusted, and the meaning of the "vector"
> field getting slightly mis-used.
> 
> Jan


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

Re: [Xen-devel] [PATCH] x86/hvm/viridian: save APIC assist vector

> -Original Message-
> From: Andrew Cooper [mailto:andrew.coop...@citrix.com]
> Sent: 24 March 2016 17:58
> To: Paul Durrant; xen-de...@lists.xenproject.org
> Cc: Jan Beulich
> Subject: Re: [Xen-devel] [PATCH] x86/hvm/viridian: save APIC assist vector
> 
> On 24/03/16 17:19, Paul Durrant wrote:
> > @@ -293,10 +292,11 @@ void viridian_start_apic_assist(struct vcpu *v, int
> vector)
> >   * wrong and the VM will most likely hang so force a crash now
> >   * to make the problem clear.
> >   */
> > -if ( v->arch.hvm_vcpu.viridian.apic_assist.vector >= 0 )
> > +if ( v->arch.hvm_vcpu.viridian.apic_assist.vector != 0 )
> >  domain_crash(v->domain);
> >
> > -v->arch.hvm_vcpu.viridian.apic_assist.vector = vector;
> > +/* Increment the value so that zero is always invalid. */
> > +v->arch.hvm_vcpu.viridian.apic_assist.vector = vector + 1;
> 
> Can you add a comment to viridan_cpu that a variable named vector
> actually holds "vector + 1" ?
> 
> It can also be changed to an unsigned value.
> 
> >  *va |= 1u;
> >  }
> >
> > diff --git a/xen/include/public/arch-x86/hvm/save.h
> b/xen/include/public/arch-x86/hvm/save.h
> > index fbd1c6a..fc8e8f9 100644
> > --- a/xen/include/public/arch-x86/hvm/save.h
> > +++ b/xen/include/public/arch-x86/hvm/save.h
> > @@ -588,7 +588,8 @@ struct hvm_viridian_domain_context {
> >  DECLARE_HVM_SAVE_TYPE(VIRIDIAN_DOMAIN, 15, struct
> hvm_viridian_domain_context);
> >
> >  struct hvm_viridian_vcpu_context {
> > -uint64_t apic_assist;
> > +uint64_t apic_assist_msr;
> > +uint16_t apic_assist_vector;
> 
> An explicit uint16_t[3] _pad; please.
> 

Given that I'm going to drop the biasing technique, I'll drop this to a uint8_t 
and add appropriate padding as requested.

  Paul

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

Re: [Xen-devel] [PATCH] x86/hvm/viridian: save APIC assist vector

> -Original Message-
> From: Paul Durrant
> Sent: 29 March 2016 09:57
> To: 'Jan Beulich'
> Cc: xen-de...@lists.xenproject.org
> Subject: RE: [PATCH] x86/hvm/viridian: save APIC assist vector
> 
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 29 March 2016 09:42
> > To: Paul Durrant
> > Cc: xen-de...@lists.xenproject.org
> > Subject: Re: [PATCH] x86/hvm/viridian: save APIC assist vector
> >
> > >>> On 24.03.16 at 18:19,  wrote:
> > > @@ -293,10 +292,11 @@ void viridian_start_apic_assist(struct vcpu *v,
> int
> > vector)
> > >   * wrong and the VM will most likely hang so force a crash now
> > >   * to make the problem clear.
> > >   */
> > > -if ( v->arch.hvm_vcpu.viridian.apic_assist.vector >= 0 )
> > > +if ( v->arch.hvm_vcpu.viridian.apic_assist.vector != 0 )
> > >  domain_crash(v->domain);
> > >
> > > -v->arch.hvm_vcpu.viridian.apic_assist.vector = vector;
> > > +/* Increment the value so that zero is always invalid. */
> > > +v->arch.hvm_vcpu.viridian.apic_assist.vector = vector + 1;
> >
> > From an APIC perspective, aren't vectors below 0x10 invalid
> > anyway? I.e. can't zero serve the "none" indication just as much
> > as -1 did without this new biasing? Or otherwise I'd still expect ...
> >
> 
> I can do that, if you're happy with it. If I'm going to do it this way though 
> I will
> also put in an explicit check to make sure APIC assist is not used for 
> vectors <
> 0x16.

Obviously I meant 0x10 there ;-)

  Paul

> 
>   Paul
> 
> > > @@ -829,13 +830,21 @@ static int viridian_load_vcpu_ctxt(struct domain
> > *d, hvm_domain_context_t *h)
> > >  return -EINVAL;
> > >  }
> > >
> > > -if ( hvm_load_entry(VIRIDIAN_VCPU, h, &ctxt) != 0 )
> > > +if ( hvm_load_entry_zeroextend(VIRIDIAN_VCPU, h, &ctxt) != 0 )
> > >  return -EINVAL;
> > >
> > > -v->arch.hvm_vcpu.viridian.apic_assist.msr.raw = ctxt.apic_assist;
> > > +v->arch.hvm_vcpu.viridian.apic_assist.msr.raw = ctxt.apic_assist_msr;
> > >  if ( v->arch.hvm_vcpu.viridian.apic_assist.msr.fields.enabled )
> > >  initialize_apic_assist(v);
> > >
> > > +/*
> > > + * Guests that were saved on a host that did not use APIC assist
> > > + * will clearly never have a pending assist, so reading the zero
> > > + * value for apic_assist_vector from the zero extended save record
> > > + * will always be correct.
> > > + */
> > > +v->arch.hvm_vcpu.viridian.apic_assist.vector =
> ctxt.apic_assist_vector;
> >
> > ... the bias to get accounted for here, instead of quite a bit of
> > other code getting adjusted, and the meaning of the "vector"
> > field getting slightly mis-used.
> >
> > Jan


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

Re: [Xen-devel] [PATCH] x86/hvm/viridian: save APIC assist vector

>>> On 29.03.16 at 10:57,  wrote:
>>  -Original Message-
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: 29 March 2016 09:42
>> To: Paul Durrant
>> Cc: xen-de...@lists.xenproject.org 
>> Subject: Re: [PATCH] x86/hvm/viridian: save APIC assist vector
>> 
>> >>> On 24.03.16 at 18:19,  wrote:
>> > @@ -293,10 +292,11 @@ void viridian_start_apic_assist(struct vcpu *v, int
>> vector)
>> >   * wrong and the VM will most likely hang so force a crash now
>> >   * to make the problem clear.
>> >   */
>> > -if ( v->arch.hvm_vcpu.viridian.apic_assist.vector >= 0 )
>> > +if ( v->arch.hvm_vcpu.viridian.apic_assist.vector != 0 )
>> >  domain_crash(v->domain);
>> >
>> > -v->arch.hvm_vcpu.viridian.apic_assist.vector = vector;
>> > +/* Increment the value so that zero is always invalid. */
>> > +v->arch.hvm_vcpu.viridian.apic_assist.vector = vector + 1;
>> 
>> From an APIC perspective, aren't vectors below 0x10 invalid
>> anyway? I.e. can't zero serve the "none" indication just as much
>> as -1 did without this new biasing? Or otherwise I'd still expect ...
>> 
> 
> I can do that, if you're happy with it. If I'm going to do it this way 
> though I will also put in an explicit check to make sure APIC assist is not 
> used for vectors < 0x16.

As long as you mean 0x10 or 16, yes (at once allowing the fields to
be uint8_t, as would be customary for vectors). I had actually half
written a comment to that effect on the original patch, until I
realized that the only harm caused by using a bogus low vector
would be to the guest itself.

Jan


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

Re: [Xen-devel] [PATCH 3/7] oxenstored: refactor request processing

2016-03-29 Thread Jonathan Davies

On Thu, Mar 24, 2016 at 07:57:30PM -0400, Boris Ostrovsky wrote:
> On 03/24/2016 06:49 PM, Andrew Cooper wrote:
> >On 24/03/2016 22:22, Boris Ostrovsky wrote:
> >>On 03/17/2016 01:51 PM, Jonathan Davies wrote:
> >>>Encapsulate the request in a record that is passed from do_input to
> >>>process_packet and input_handle_error.
> >>>
> >>>This will be helpful when keeping track of the requests made as part
> >>>of a
> >>>transaction.
> >>>
> >>>Signed-off-by: Jonathan Davies 
> >>>Reviewed-by: Andrew Cooper 
> >>>Reviewed-by: Jon Ludlam 
> >>>Reviewed-by: Euan Harris 
> >>>---
> >>>   tools/ocaml/xenstored/process.ml |   15 ++-
> >>>   1 file changed, 10 insertions(+), 5 deletions(-)
> >>>
> >>>diff --git a/tools/ocaml/xenstored/process.ml
> >>>b/tools/ocaml/xenstored/process.ml
> >>>index 7a73669..c92bec7 100644
> >>>--- a/tools/ocaml/xenstored/process.ml
> >>>+++ b/tools/ocaml/xenstored/process.ml
> >>>@@ -344,11 +344,11 @@ let function_of_type ty =
> >>>   | Xenbus.Xb.Op.Invalid   -> reply_ack do_error
> >>>   | _  -> reply_ack do_error
> >>>   -let input_handle_error ~cons ~doms ~fct ~ty ~con ~t ~rid ~data =
> >>>+let input_handle_error ~cons ~doms ~fct ~con ~t ~req =
> >>>   let reply_error e =
> >>>   Packet.Error e in
> >>>   try
> >>>-fct con t doms cons data
> >>>+fct con t doms cons req.Packet.data
> >>>   with
> >>>   | Define.Invalid_path  -> reply_error "EINVAL"
> >>>   | Define.Already_exist -> reply_error "EEXIST"
> >>>@@ -370,7 +370,10 @@ let input_handle_error ~cons ~doms ~fct ~ty ~con
> >>>~t ~rid ~data =
> >>>   (**
> >>>* Nothrow guarantee.
> >>>*)
> >>>-let process_packet ~store ~cons ~doms ~con ~tid ~rid ~ty ~data =
> >>>+let process_packet ~store ~cons ~doms ~con ~req =
> >>>+let ty = req.Packet.ty in
> >>>+let tid = req.Packet.tid in
> >>>+let rid = req.Packet.rid in
> >>>   try
> >>>   let fct = function_of_type ty in
> >>>   let t =
> >>>@@ -379,7 +382,7 @@ let process_packet ~store ~cons ~doms ~con ~tid
> >>>~rid ~ty ~data =
> >>>   else
> >>>   Connection.get_transaction con tid
> >>>   in
> >>>-let response = input_handle_error ~cons ~doms ~fct ~ty ~con
> >>>~t ~rid ~data in
> >>>+let response = input_handle_error ~cons ~doms ~fct ~con ~t
> >>>~req in
> >>> (* Put the response on the wire *)
> >>>   send_response ty con t rid response
> >>>@@ -412,11 +415,13 @@ let do_input store cons doms con =
> >>>   if newpacket then (
> >>>   let packet = Connection.pop_in con in
> >>>   let tid, rid, ty, data = Xenbus.Xb.Packet.unpack packet in
> >>>+let req = {Packet.tid; Packet.rid; Packet.ty; Packet.data} in
> >>>+
> >>I think this change breaks the build with older ocaml versions:
> >>
> >>root@haswell> ocamlopt -v
> >>The OCaml native-code compiler, version 4.00.1
> >>Standard library directory: /usr/lib64/ocaml
> >>root@haswell> ocamlopt -g -ccopt "" -dtypes -I
> >>/root/tmp/xen/tools/ocaml/xenstored/../libs/xb -I
> >>/root/tmp/xen/tools/ocaml/xenstored/../libs/mmap -I
> >>/root/tmp/xen/tools/ocaml/xenstored/../libs/xc -I
> >>/root/tmp/xen/tools/ocaml/xenstored/../libs/eventchn -cc gcc -w F
> >>-warn-error F -c -o process.cmx process.ml
> >>root@haswell>
> >>
> >>
> >>root@ovs104> ocamlopt -v
> >>The Objective Caml native-code compiler, version 3.11.2
> >>Standard library directory: /usr/lib64/ocaml
> >>root@ovs104> ocamlopt -g -ccopt "" -dtypes -I
> >>/root/tmp/xen/tools/ocaml/xenstored/../libs/xb -I
> >>/root/tmp/xen/tools/ocaml/xenstored/../libs/mmap -I
> >>/root/tmp/xen/tools/ocaml/xenstored/../libs/xc -I
> >>/root/tmp/xen/tools/ocaml/xenstored/../libs/eventchn -cc gcc -w F
> >>-warn-error F -c -o process.cmx process.ml
> >>File "process.ml", line 487, characters 23-24:
> >>Error: Syntax error
> >>root@ovs104>
> >>
> >>I don't know much about ocaml (OK, I know *nothing* about ocaml) so I
> >>can't say what exactly might be wrong.
> >Could you perhaps try this instead?
> >
> >let req = {tid = Packet.tid; rid = Packet.rid; ty = Packet.ty; data =
> >Packet.data} in
> >
> >It is most likely that the older version of Ocaml can't infer the order
> >of fields.
> >
> >~Andrew
> 
> 
> No, it now gives me "Error: Unbound record field label tid"
> 
> -boris

Andrew's guess was close, but the wrong way around -- please could you try the
following with the older compiler?

let req = {Packet.tid=tid; Packet.rid=rid; Packet.ty=ty; Packet.data=data} in

I was using a syntactic feature of OCaml called 'field punning' which is
generally considered good practice and makes for more readable code. It looks
like this feature was introduced in OCaml 3.12.0 (dating from 2010), which is
consistent with Boris' findings.

What's the policy here -- is there a defined version of the OCaml compiler which
tools/ocaml needs to be able to compile with

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

>>> On 29.03.16 at 10:47,  wrote:
> On 03/17/16 22:21, Haozhong Zhang wrote:
>> On 03/17/16 14:00, Ian Jackson wrote:
>> > Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM 
>> > support for Xen"):
>> > > QEMU keeps mappings of guest memory because (1) that mapping is
>> > > created by itself, and/or (2) certain device emulation needs to access
>> > > the guest memory. But for vNVDIMM, I'm going to move the creation of
>> > > its mappings out of qemu to toolstack and vNVDIMM in QEMU does not
>> > > access vNVDIMM pages mapped to guest, so it's not necessary to let
>> > > qemu keeps vNVDIMM mappings.
>> > 
>> > I'm confused by this.
>> > 
>> > Suppose a guest uses an emulated device (or backend) provided by qemu,
>> > to do DMA to an vNVDIMM.  Then qemu will need to map the real NVDIMM
>> > pages into its own address space, so that it can write to the memory
>> > (ie, do the virtual DMA).
>> > 
>> > That virtual DMA might well involve a direct mapping in the kernel
>> > underlying qemu: ie, qemu might use O_DIRECT to have its kernel write
>> > directly to the NVDIMM, and with luck the actual device backing the
>> > virtual device will be able to DMA to the NVDIMM.
>> > 
>> > All of this seems to me to mean that qemu needs to be able to map
>> > its guest's parts of NVDIMMs
>> > 
>> > There are probably other example: memory inspection systems used by
>> > virus scanners etc.; debuggers used to inspect a guest from outside;
>> > etc.
>> > 
>> > I haven't even got started on save/restore...
>> > 
>> 
>> Oops, so many cases I missed. Thanks Ian for pointing out all these!
>> Now I need to reconsider how to manage guest permissions for NVDIMM pages.
>> 
> 
> I still cannot find a neat approach to manage guest permissions for
> nvdimm pages. A possible one is to use a per-domain bitmap to track
> permissions: each bit corresponding to an nvdimm page. The bitmap can
> save lots of spaces and even be stored in the normal ram, but
> operating it for a large nvdimm range, especially for a contiguous
> one, is slower than rangeset.

I don't follow: What would a single bit in that bitmap mean? Any
guest may access the page? That surely wouldn't be what we
need.

> BTW, if I take the other way to map nvdimm pages to guest
> (http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01972.html)
> | 2. Or, given the same inputs, we may combine above two steps into a new
> |dom0 system call that (1) gets the SPA ranges, (2) calls xen
> |hypercall to map SPA ranges
> and treat nvdimm as normal ram, then xen will not need to use rangeset
> or above bitmap to track guest permissions for nvdimm? But looking at
> how qemu currently populates guest memory via XENMEM_populate_physmap
> , and other hypercalls like XENMEM_[in|de]crease_reservation, it looks
> like that mapping a _dedicated_ piece of host ram to guest is not
> allowed out of the hypervisor (and not allowed even in dom0 kernel)?
> Is it for security concerns, e.g. avoiding a malfunctioned dom0 leaking
> guest memory?

Well, it's simply because RAM is a resource managed through
allocation/freeing, instead of via reserving chunks for special
purposes.

Jan


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

Re: [Xen-devel] [PATCH v5 05/28] xsplice: Design document

>>> On 24.03.16 at 21:00,  wrote:
> +struct xen_sysctl_xsplice_list {  
> +uint32_t version;   /* OUT: Hypervisor stamps value.
> +   If varies between calls, we 
> are  
> +   getting stale data. */  
> +uint32_t idx;   /* IN: Index into hypervisor 
> array.
> +   Should be between [0, nr). */

This is now actively wrong, when comparing with the implementation
in the next patch, namely

if ( list->idx > i++ )
continue;

E.g. on some subsequent invocation you might have idx=55 and
nr=32, making you populate array slots [0,31] with data for payloads
[55,86]. Why don't you just say "Index into hypervisor list"?

Jan


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

[Xen-devel] [PATCH v2] x86/hvm/viridian: save APIC assist vector

If any vcpu has a pending APIC assist when the domain is suspended
then the vector needs to be saved. If this is not done then it's
possible for the vector to remain pending in the vlapic ISR
indefinitely after resume.

This patch adds code to save the APIC assist vector value in the
viridian vcpu save record. This means that the record is now zero-
extended on load and, because this implies a loaded value of
zero means nothing is pending (for backwards compatibility with
hosts not implementing APIC assist), the rest of the viridian APIC
assist code is adjusted to treat a zero value in this way. A
check has therefore been added to viridian_start_apic_assist() to
prevent the enlightenment being used for vectors < 0x10 (which
are illegal for an APIC).

Signed-off-by: Paul Durrant 
Cc: Jan Beulich 
---

v2:
 - don't use biasing
 - add missing padding to save record
---
 xen/arch/x86/hvm/viridian.c| 23 ++-
 xen/arch/x86/hvm/vlapic.c  |  2 +-
 xen/include/public/arch-x86/hvm/save.h |  4 +++-
 3 files changed, 18 insertions(+), 11 deletions(-)

diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index 410320c..dceed2c 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -252,7 +252,6 @@ static void initialize_apic_assist(struct vcpu *v)
 if ( viridian_feature_mask(v->domain) & HVMPV_apic_assist )
 {
 v->arch.hvm_vcpu.viridian.apic_assist.va = va;
-v->arch.hvm_vcpu.viridian.apic_assist.vector = -1;
 return;
 }
 
@@ -288,12 +287,15 @@ void viridian_start_apic_assist(struct vcpu *v, int 
vector)
 if ( !va )
 return;
 
+if ( vector < 0x10 )
+return;
+
 /*
  * If there is already an assist pending then something has gone
  * wrong and the VM will most likely hang so force a crash now
  * to make the problem clear.
  */
-if ( v->arch.hvm_vcpu.viridian.apic_assist.vector >= 0 )
+if ( v->arch.hvm_vcpu.viridian.apic_assist.vector )
 domain_crash(v->domain);
 
 v->arch.hvm_vcpu.viridian.apic_assist.vector = vector;
@@ -306,13 +308,13 @@ int viridian_complete_apic_assist(struct vcpu *v)
 int vector;
 
 if ( !va )
-return -1;
+return 0;
 
 if ( *va & 1u )
-return -1; /* Interrupt not yet processed by the guest. */
+return 0; /* Interrupt not yet processed by the guest. */
 
 vector = v->arch.hvm_vcpu.viridian.apic_assist.vector;
-v->arch.hvm_vcpu.viridian.apic_assist.vector = -1;
+v->arch.hvm_vcpu.viridian.apic_assist.vector = 0;
 
 return vector;
 }
@@ -325,7 +327,7 @@ void viridian_abort_apic_assist(struct vcpu *v)
 return;
 
 *va &= ~1u;
-v->arch.hvm_vcpu.viridian.apic_assist.vector = -1;
+v->arch.hvm_vcpu.viridian.apic_assist.vector = 0;
 }
 
 static void update_reference_tsc(struct domain *d, bool_t initialize)
@@ -806,7 +808,8 @@ static int viridian_save_vcpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 for_each_vcpu( d, v ) {
 struct hvm_viridian_vcpu_context ctxt;
 
-ctxt.apic_assist = v->arch.hvm_vcpu.viridian.apic_assist.msr.raw;
+ctxt.apic_assist_msr = v->arch.hvm_vcpu.viridian.apic_assist.msr.raw;
+ctxt.apic_assist_vector = v->arch.hvm_vcpu.viridian.apic_assist.vector;
 
 if ( hvm_save_entry(VIRIDIAN_VCPU, v->vcpu_id, h, &ctxt) != 0 )
 return 1;
@@ -829,13 +832,15 @@ static int viridian_load_vcpu_ctxt(struct domain *d, 
hvm_domain_context_t *h)
 return -EINVAL;
 }
 
-if ( hvm_load_entry(VIRIDIAN_VCPU, h, &ctxt) != 0 )
+if ( hvm_load_entry_zeroextend(VIRIDIAN_VCPU, h, &ctxt) != 0 )
 return -EINVAL;
 
-v->arch.hvm_vcpu.viridian.apic_assist.msr.raw = ctxt.apic_assist;
+v->arch.hvm_vcpu.viridian.apic_assist.msr.raw = ctxt.apic_assist_msr;
 if ( v->arch.hvm_vcpu.viridian.apic_assist.msr.fields.enabled )
 initialize_apic_assist(v);
 
+v->arch.hvm_vcpu.viridian.apic_assist.vector = ctxt.apic_assist_vector;
+
 return 0;
 }
 
diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c
index f36eff7..e2f4450 100644
--- a/xen/arch/x86/hvm/vlapic.c
+++ b/xen/arch/x86/hvm/vlapic.c
@@ -1189,7 +1189,7 @@ int vlapic_has_pending_irq(struct vcpu *v)
  * comparing with the IRR.
  */
 vector = viridian_complete_apic_assist(v);
-if ( vector != -1 )
+if ( vector )
 vlapic_clear_vector(vector, &vlapic->regs->data[APIC_ISR]);
 
 isr = vlapic_find_highest_isr(vlapic);
diff --git a/xen/include/public/arch-x86/hvm/save.h 
b/xen/include/public/arch-x86/hvm/save.h
index fbd1c6a..8d73b51 100644
--- a/xen/include/public/arch-x86/hvm/save.h
+++ b/xen/include/public/arch-x86/hvm/save.h
@@ -588,7 +588,9 @@ struct hvm_viridian_domain_context {
 DECLARE_HVM_SAVE_TYPE(VIRIDIAN_DOMAIN, 15, struct hvm_viridian_domain_context);
 
 struct hvm_viridian_vcpu_context {
-uint64_t apic_assist;
+uint64_t apic_assist_msr;
+uint8_t

Re: [Xen-devel] [PATCH 3/3] libxl: add new pvusb backend "qusb" provided by qemu

On Fri, Mar 25, 2016 at 6:09 AM, Juergen Gross  wrote:
> On 24/03/16 21:07, Wei Liu wrote:
>> On Fri, Mar 18, 2016 at 09:24:26AM +0100, Juergen Gross wrote:
>>> On 17/03/16 17:55, George Dunlap wrote:
 On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross  wrote:
> Add a new pvusb backend type "qusb" which is provided by qemu. It can
> be selected either by specifying the type directly in the configuration
> or it is selected automatically by libxl in case there is no "usbback"
> driver loaded.
>
> Signed-off-by: Juergen Gross 

 Oh, last thing -- shouldn't we have a way for libxl to tell whether
 qemu can provide a qusb backend before we offer to start it up?
>>>
>>> How? Is this possible for qdisk? Or for an emulated frame buffer?
>>>
>>
>> I don't think it is  possible at the moment. But I think you might be
>> able to do it either via qmp command or parsing qemu help string. The
>> latter functionality is implemented in Ian's device model deprivilege
>> patch series IIRC -- but it is not yet merged either.
>
> Won't help for qusb, as there is no qemu parameter or help text related
> to the backend. It would be possible to add a qmp command to print the
> supported backend types, of course.

Well as I understand it, for qemu-upstream we can't assume what
version of qemu we'll end up getting: we need to be compatible with
recent releases of qemu which don't provide qusb.  Which I'm pretty
sure means failing gracefully (i.e., giving a sensible warning
message) if someone tries to add qusb when their qemu binary doesn't
support it.

If you can tell from the qemu failure that qusb is at fault, that's OK
I think; but if not, I think you'll have to add some way to query
whether qusb is supported by the qemu binary before starting it.

 -George

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

Re: [Xen-devel] [PATCH v7 00/11] grub-xen: support booting huge pv-domains

On 03/03/16 10:38, Juergen Gross wrote:
> The Xen hypervisor supports starting a dom0 with large memory (up to
> the TB range) by not including the initrd and p2m list in the initial
> kernel mapping. Especially the p2m list can grow larger than the
> available virtual space in the initial mapping.
> 
> The started kernel is indicating the support of each feature via
> elf notes.
> 
> This series enables grub-xen to do the same as the hypervisor.
> 
> Tested with:
> - 32 bit domU (kernel not supporting unmapped initrd)
> - 32 bit domU (kernel supporting unmapped initrd)
> - 1 GB 64 bit domU (kernel supporting unmapped initrd, not p2m)
> - 1 GB 64 bit domU (kernel supporting unmapped initrd and p2m)
> - 900GB 64 bit domU (kernel supporting unmapped initrd and p2m)

There has been no reaction for these patches for nearly 4 weeks now.
Neither has there been any response regarding my request to include
it in 2.02.

I'd really appreciate some kind of comment.


Juergen

> 
> Changes in V7:
> - patch 9: set initrd size once instead of in if and else clause as requested
>   by Daniel Kiper
> - patch 10: add GRUB_PACKED attribute to structure, drop alignments in 
> assembly
>   files as requested by Daniel Kiper
> 
> Changes in V6:
> - patch 9: rename grub_xen_alloc_final() as requested by Daniel Kiper
> 
> Changes in V5:
> - patch 2: set grub_errno to GRUB_ERR_NONE to avoid false error reports as
>   requested by Daniel Kiper
> - patch 9: let call grub_xen_alloc_final() all subfunctions unconditionally
>   and let them decide whether they need to do anything as suggested by
>   Daniel Kiper
> 
> Changes in V4:
> - split patch 1 into two patches as requested by Daniel Kiper
> - patch 9 (was 8): rename grub_xen_alloc_end() as requested by Daniel Kiper
> - patch 10 (was 9): align variables in assembly sources,
>   use separate structure define as requested by Daniel Kiper
> 
> Changes in V3:
> - added new patch 1 (free memory in case of error) as requested by
>   Daniel Kiper
> - added new patch 2 (avoid global variables) as requested by Daniel Kiper
> - added new patch 3 (use constants for elf notes) as requested by Daniel Kiper
> - added new patch 4 (sync with new Xen headers) in order to use constants
>   in assembly code
> - modified patch 9 (was patch 5) to use constants instead of numbers as
>   requested by Daniel Kiper
> 
> Changes in V2:
> - rebased patch 5 to current master
> 
> Juergen Gross (11):
>   xen: make xen loader callable multiple times
>   xen: avoid memleaks on error
>   xen: reduce number of global variables in xen loader
>   xen: add elfnote.h to avoid using numbers instead of constants
>   xen: synchronize xen header
>   xen: factor out p2m list allocation into separate function
>   xen: factor out allocation of special pages into separate function
>   xen: factor out allocation of page tables into separate function
>   xen: add capability to load initrd outside of initial mapping
>   xen: modify page table construction
>   xen: add capability to load p2m list outside of kernel mapping
> 
>  grub-core/lib/i386/xen/relocator.S   |  87 ++--
>  grub-core/lib/x86_64/xen/relocator.S | 134 +++---
>  grub-core/lib/xen/relocator.c|  28 +-
>  grub-core/loader/i386/xen.c  | 778 
> +++
>  grub-core/loader/i386/xen_fileXX.c   |  45 +-
>  include/grub/i386/memory.h   |   7 +
>  include/grub/xen/relocator.h |   6 +-
>  include/grub/xen_file.h  |   3 +
>  include/xen/arch-x86/xen-x86_32.h|  22 +-
>  include/xen/arch-x86/xen-x86_64.h|   8 +-
>  include/xen/elfnote.h| 281 +
>  include/xen/xen.h| 125 --
>  12 files changed, 1076 insertions(+), 448 deletions(-)
>  create mode 100644 include/xen/elfnote.h
> 


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

Re: [Xen-devel] [PATCH v2] x86/hvm/viridian: save APIC assist vector

>>> On 29.03.16 at 11:30,  wrote:
> If any vcpu has a pending APIC assist when the domain is suspended
> then the vector needs to be saved. If this is not done then it's
> possible for the vector to remain pending in the vlapic ISR
> indefinitely after resume.
> 
> This patch adds code to save the APIC assist vector value in the
> viridian vcpu save record. This means that the record is now zero-
> extended on load and, because this implies a loaded value of
> zero means nothing is pending (for backwards compatibility with
> hosts not implementing APIC assist), the rest of the viridian APIC
> assist code is adjusted to treat a zero value in this way. A
> check has therefore been added to viridian_start_apic_assist() to
> prevent the enlightenment being used for vectors < 0x10 (which
> are illegal for an APIC).
> 
> Signed-off-by: Paul Durrant 

Reviewed-by: Jan Beulich 

Are you then also looking into the domain page leaks which seem
likely to stem from the earlier APIC assist change?

Jan


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

Re: [Xen-devel] [PATCH v3] xen/arm64: check XSM Magic and Signature from the second unknown module.

>>> On 29.03.16 at 05:26,  wrote:
> +static bool __init check_xsm_signature(const void *fdt, int node,
> +   const char *name,
> +   u32 address_cells, u32 size_cells)
> +{
> +#ifdef CONFIG_FLASK
> +u32 xen_magic = XSM_MAGIC, target_len = 8;
> +const struct fdt_property *prop;
> +unsigned char buff[16];
> +paddr_t start, size;
> +const __be32 *cell;
> +int len;
> +
> +prop = fdt_get_property(fdt, node, "reg", &len);
> +if ( !prop || len < dt_cells_to_size(address_cells + size_cells))

At the very least you'll need to adjust style: There's a missing
blank before the closing parenthesis here, and more of this kind
of issue follow later.

Jan


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

Re: [Xen-devel] [PATCH v2] x86/hvm/viridian: save APIC assist vector

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 29 March 2016 10:53
> To: Paul Durrant
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [PATCH v2] x86/hvm/viridian: save APIC assist vector
> 
> >>> On 29.03.16 at 11:30,  wrote:
> > If any vcpu has a pending APIC assist when the domain is suspended
> > then the vector needs to be saved. If this is not done then it's
> > possible for the vector to remain pending in the vlapic ISR
> > indefinitely after resume.
> >
> > This patch adds code to save the APIC assist vector value in the
> > viridian vcpu save record. This means that the record is now zero-
> > extended on load and, because this implies a loaded value of
> > zero means nothing is pending (for backwards compatibility with
> > hosts not implementing APIC assist), the rest of the viridian APIC
> > assist code is adjusted to treat a zero value in this way. A
> > check has therefore been added to viridian_start_apic_assist() to
> > prevent the enlightenment being used for vectors < 0x10 (which
> > are illegal for an APIC).
> >
> > Signed-off-by: Paul Durrant 
> 
> Reviewed-by: Jan Beulich 
> 
> Are you then also looking into the domain page leaks which seem
> likely to stem from the earlier APIC assist change?
> 

Yes, I'm going to look at them. Not sure why the vcpu shutdown code is not 
releasing things.

  Paul

> Jan


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

[Xen-devel] [PATCH] Xen on ARM and ARM64: update MAINTAINERS info

2016-03-29 Thread Stefano Stabellini

Not my full time job anymore, but still maintaining it.

Signed-off-by: Stefano Stabellini 

diff --git a/MAINTAINERS b/MAINTAINERS
index 32bafda..049aa1d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12193,16 +12193,16 @@ F:include/xen/
 F: include/uapi/xen/
 
 XEN HYPERVISOR ARM
-M: Stefano Stabellini 
+M: Stefano Stabellini 
 L: xen-de...@lists.xenproject.org (moderated for non-subscribers)
-S: Supported
+S: Maintained
 F: arch/arm/xen/
 F: arch/arm/include/asm/xen/
 
 XEN HYPERVISOR ARM64
-M: Stefano Stabellini 
+M: Stefano Stabellini 
 L: xen-de...@lists.xenproject.org (moderated for non-subscribers)
-S: Supported
+S: Maintained
 F: arch/arm64/xen/
 F: arch/arm64/include/asm/xen/
 

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

[Xen-devel] [PATCH] Xen: update MAINTAINERS info

2016-03-29 Thread Stefano Stabellini

Add Anthony Perard as Xen co-maintainer.
Update my email address.

Signed-off-by: Stefano Stabellini 
Acked-by: Anthony Perard 

diff --git a/MAINTAINERS b/MAINTAINERS
index afbe845..66abde8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -278,7 +278,8 @@ Guest CPU Cores (Xen):
 --
 
 X86
-M: Stefano Stabellini 
+M: Stefano Stabellini 
+M: Anthony Perard 
 L: xen-de...@lists.xensource.com
 S: Supported
 F: xen-*

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

Re: [Xen-devel] [PATCH v7 00/11] grub-xen: support booting huge pv-domains

2016-03-29 Thread Daniel Kiper

On Tue, Mar 29, 2016 at 11:52:52AM +0200, Juergen Gross wrote:
> On 03/03/16 10:38, Juergen Gross wrote:
> > The Xen hypervisor supports starting a dom0 with large memory (up to
> > the TB range) by not including the initrd and p2m list in the initial
> > kernel mapping. Especially the p2m list can grow larger than the
> > available virtual space in the initial mapping.
> >
> > The started kernel is indicating the support of each feature via
> > elf notes.
> >
> > This series enables grub-xen to do the same as the hypervisor.
> >
> > Tested with:
> > - 32 bit domU (kernel not supporting unmapped initrd)
> > - 32 bit domU (kernel supporting unmapped initrd)
> > - 1 GB 64 bit domU (kernel supporting unmapped initrd, not p2m)
> > - 1 GB 64 bit domU (kernel supporting unmapped initrd and p2m)
> > - 900GB 64 bit domU (kernel supporting unmapped initrd and p2m)
>
> There has been no reaction for these patches for nearly 4 weeks now.
> Neither has there been any response regarding my request to include
> it in 2.02.

It looks that it will be taken into 2.02. Please check this email:
http://lists.gnu.org/archive/html/grub-devel/2016-03/msg00281.html

Daniel

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

Re: [Xen-devel] crash on boot with 4.6.1 on fedora 24

>>> On 28.03.16 at 19:00,  wrote:
> I get a crash on boot with my Fedora xen-4.6.1-3.fc24 packages. This seems 
> to be related to how it is compiled because the same code compiled under 
> Fedora 23 works. The boot logs are attached. The address mentioned in the 
> crash has the code
> 0x82d08023d3c3 :
>  je 0x82d08023e90a 
> but I have compared it with the Fedora 23 version of create_bounce_frame 
> and as far as I can see the code is the same, so I am a bit stuck on how 
> to debug this further.

Well, it doesn't look like your problem is with create_bounce_frame(),
but instead this

(XEN) d0v0: unhandled page fault (ec=)
(XEN) Pagetable walk from 81d6b665:
(XEN)  L4[0x1ff] = 3a088067 2088
(XEN)  L3[0x1fe] = 3a087067 2087
(XEN)  L2[0x00e] = 3a096067 2096 
(XEN)  L1[0x16b] = 001039d6b067 1d6b

is pointing at an issue with paging of Dom0. The walk shown doesn't,
to me, indicate any reason why a page fault would have got raised
in the first place (not even a missing TLB flush could account for
that, since any fault condition would result in a hardware re-walk).
Some of the data in the registers and on the stack suggest there
are page table manipulations going on in Dom0 around the time of
the crash, so you may want to check where exactly Dom0 was when
that crash occurred.

And then the question of course is: If the crash occurs reliably
with the F24 built binary (but not the F23 one), perhaps you need
to go and compare more than just the one function?

Jan

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

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

2016-03-29 Thread Haozhong Zhang

On 03/29/16 03:11, Jan Beulich wrote:
> >>> On 29.03.16 at 10:47,  wrote:
> > On 03/17/16 22:21, Haozhong Zhang wrote:
> >> On 03/17/16 14:00, Ian Jackson wrote:
> >> > Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM 
> >> > support for Xen"):
> >> > > QEMU keeps mappings of guest memory because (1) that mapping is
> >> > > created by itself, and/or (2) certain device emulation needs to access
> >> > > the guest memory. But for vNVDIMM, I'm going to move the creation of
> >> > > its mappings out of qemu to toolstack and vNVDIMM in QEMU does not
> >> > > access vNVDIMM pages mapped to guest, so it's not necessary to let
> >> > > qemu keeps vNVDIMM mappings.
> >> > 
> >> > I'm confused by this.
> >> > 
> >> > Suppose a guest uses an emulated device (or backend) provided by qemu,
> >> > to do DMA to an vNVDIMM.  Then qemu will need to map the real NVDIMM
> >> > pages into its own address space, so that it can write to the memory
> >> > (ie, do the virtual DMA).
> >> > 
> >> > That virtual DMA might well involve a direct mapping in the kernel
> >> > underlying qemu: ie, qemu might use O_DIRECT to have its kernel write
> >> > directly to the NVDIMM, and with luck the actual device backing the
> >> > virtual device will be able to DMA to the NVDIMM.
> >> > 
> >> > All of this seems to me to mean that qemu needs to be able to map
> >> > its guest's parts of NVDIMMs
> >> > 
> >> > There are probably other example: memory inspection systems used by
> >> > virus scanners etc.; debuggers used to inspect a guest from outside;
> >> > etc.
> >> > 
> >> > I haven't even got started on save/restore...
> >> > 
> >> 
> >> Oops, so many cases I missed. Thanks Ian for pointing out all these!
> >> Now I need to reconsider how to manage guest permissions for NVDIMM pages.
> >> 
> > 
> > I still cannot find a neat approach to manage guest permissions for
> > nvdimm pages. A possible one is to use a per-domain bitmap to track
> > permissions: each bit corresponding to an nvdimm page. The bitmap can
> > save lots of spaces and even be stored in the normal ram, but
> > operating it for a large nvdimm range, especially for a contiguous
> > one, is slower than rangeset.
> 
> I don't follow: What would a single bit in that bitmap mean? Any
> guest may access the page? That surely wouldn't be what we
> need.
>

For a host having a N pages of nvdimm, each domain will have a N bits
bitmap. If the m'th bit of a domain's bitmap is set, then that domain
has the permission to access the m'th host nvdimm page.

> > BTW, if I take the other way to map nvdimm pages to guest
> > (http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01972.html)
> > | 2. Or, given the same inputs, we may combine above two steps into a new
> > |dom0 system call that (1) gets the SPA ranges, (2) calls xen
> > |hypercall to map SPA ranges
> > and treat nvdimm as normal ram, then xen will not need to use rangeset
> > or above bitmap to track guest permissions for nvdimm? But looking at
> > how qemu currently populates guest memory via XENMEM_populate_physmap
> > , and other hypercalls like XENMEM_[in|de]crease_reservation, it looks
> > like that mapping a _dedicated_ piece of host ram to guest is not
> > allowed out of the hypervisor (and not allowed even in dom0 kernel)?
> > Is it for security concerns, e.g. avoiding a malfunctioned dom0 leaking
> > guest memory?
> 
> Well, it's simply because RAM is a resource managed through
> allocation/freeing, instead of via reserving chunks for special
> purposes.
> 

So that means xen can always ensure the ram assigned to a guest is
what the guest is permitted to access, so no data structures like
iomem_caps is needed for ram. If I have to introduce a hypercall that
maps the dedicated host ram/nvdimm to guest, then the explicit
permission management is still needed, regardless of who (dom0 kernel,
qemu or toolstack) will use it. Right?

Haozhong

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

[Xen-devel] [PATCH] update MAINTAINERS info

2016-03-29 Thread Stefano Stabellini

Update my email address.
Remove myself from STUB DOMAINS, MINI-OS and TOOLSTACK, where I haven't
been active recently.

Signed-off-by: Stefano Stabellini 

diff --git a/MAINTAINERS b/MAINTAINERS
index 52cc538..519c703 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -125,7 +125,7 @@ F:  xen/common/sched_arinc653.c
 F: tools/libxc/xc_arinc653.c
 
 ARM (W/ VIRTUALISATION EXTENSIONS) ARCHITECTURE
-M: Stefano Stabellini 
+M: Stefano Stabellini 
 M: Julien Grall 
 S: Supported
 L: xen-devel@lists.xen.org
@@ -145,7 +145,7 @@ S:  Supported
 F: xen/common/cpupool.c
 
 DEVICE TREE
-M: Stefano Stabellini 
+M: Stefano Stabellini 
 M: Julien Grall 
 S: Supported
 F: xen/common/libfdt/
@@ -233,7 +233,6 @@ S:  Supported
 F: xen/arch/x86/cpu/mcheck/
 
 MINI-OS
-M: Stefano Stabellini 
 M: Samuel Thibault 
 S: Supported
 L: minios-de...@lists.xenproject.org
@@ -267,7 +266,7 @@ S:  Supported
 T: git git://xenbits.xen.org/qemu-xen-traditional.git
 
 QEMU UPSTREAM
-M: Stefano Stabellini 
+M: Stefano Stabellini 
 S: Supported
 T: git git://xenbits.xen.org/qemu-xen.git
 
@@ -302,7 +301,6 @@ S:  Supported
 T: git git://xenbits.xen.org/seabios.git
 
 STUB DOMAINS
-M: Stefano Stabellini 
 M: Samuel Thibault 
 S: Supported
 F: config/Stubdom.mk.in
@@ -311,7 +309,6 @@ F:  stubdom/
 
 TOOLSTACK
 M: Ian Jackson 
-M: Stefano Stabellini 
 M: Wei Liu 
 S: Supported
 F: autogen.sh

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

Re: [Xen-devel] [PATCH v2] x86/hvm/viridian: save APIC assist vector

> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xen.org] On Behalf Of
> Paul Durrant
> Sent: 29 March 2016 10:58
> To: Jan Beulich
> Cc: xen-de...@lists.xenproject.org
> Subject: Re: [Xen-devel] [PATCH v2] x86/hvm/viridian: save APIC assist
> vector
> 
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 29 March 2016 10:53
> > To: Paul Durrant
> > Cc: xen-de...@lists.xenproject.org
> > Subject: Re: [PATCH v2] x86/hvm/viridian: save APIC assist vector
> >
> > >>> On 29.03.16 at 11:30,  wrote:
> > > If any vcpu has a pending APIC assist when the domain is suspended
> > > then the vector needs to be saved. If this is not done then it's
> > > possible for the vector to remain pending in the vlapic ISR
> > > indefinitely after resume.
> > >
> > > This patch adds code to save the APIC assist vector value in the
> > > viridian vcpu save record. This means that the record is now zero-
> > > extended on load and, because this implies a loaded value of
> > > zero means nothing is pending (for backwards compatibility with
> > > hosts not implementing APIC assist), the rest of the viridian APIC
> > > assist code is adjusted to treat a zero value in this way. A
> > > check has therefore been added to viridian_start_apic_assist() to
> > > prevent the enlightenment being used for vectors < 0x10 (which
> > > are illegal for an APIC).
> > >
> > > Signed-off-by: Paul Durrant 
> >
> > Reviewed-by: Jan Beulich 
> >
> > Are you then also looking into the domain page leaks which seem
> > likely to stem from the earlier APIC assist change?
> >
> 
> Yes, I'm going to look at them. Not sure why the vcpu shutdown code is not
> releasing things.
> 

Ah. It appears to doesn't get called when the domain is shut down, that's why. 
I guess the viridian_vcpu_deinit() call needs relocating then.

  Paul

>   Paul
> 
> > Jan
> 
> 
> ___
> 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

Re: [Xen-devel] [PATCH v7 01/22] arm/acpi: Estimate memory required for acpi/efi tables


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

[...]


+static int estimate_acpi_efi_size(struct domain *d, struct kernel_info *kinfo)
+{
+size_t efi_size, acpi_size, madt_size;
+u64 addr;
+struct acpi_table_rsdp *rsdp_tbl;
+struct acpi_table_header *table;
+
+efi_size = estimate_efi_size(kinfo->mem.nr_banks);
+
+acpi_size = ROUNDUP(sizeof(struct acpi_table_fadt), 8);
+acpi_size += ROUNDUP(sizeof(struct acpi_table_stao), 8);
+
+madt_size = sizeof(struct acpi_table_madt)
++ sizeof(struct acpi_madt_generic_interrupt) * d->max_vcpus
++ sizeof(struct acpi_madt_generic_distributor);
+if ( d->arch.vgic.version == GIC_V3 )
+madt_size += sizeof(struct acpi_madt_generic_redistributor)
+ * d->arch.vgic.nr_regions;
+acpi_size += ROUNDUP(madt_size, 8);
+
+addr = acpi_os_get_root_pointer();
+if ( !addr )
+{
+printk("Unable to get acpi root pointer\n");
+return -EINVAL;
+}
+
+rsdp_tbl = acpi_os_map_memory(addr, sizeof(struct acpi_table_rsdp));
+if ( !rsdp_tbl )
+{
+printk("Unable to map RSDP table\n");
+return -EINVAL;
+}
+
+table = acpi_os_map_memory(rsdp_tbl->xsdt_physical_address,
+   sizeof(struct acpi_table_header));
+if ( !table )


rsdp_tbl will be left mapped if Xen fails to map the XSDT.

As you don't use rsdp_tbl later, I would move 
acpi_os_unmap_memory(rsdp_tlb,...) here.


With this change:

Acked-by: Julien Grall 



+{
+printk("Unable to map XSDT table\n");
+return -EINVAL;
+}
+
+/* Add place for STAO table in XSDT table */
+acpi_size += ROUNDUP(table->length + sizeof(u64), 8);
+acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
+acpi_os_unmap_memory(rsdp_tbl, sizeof(struct acpi_table_rsdp));
+
+acpi_size += ROUNDUP(sizeof(struct acpi_table_rsdp), 8);
+d->arch.efi_acpi_len = PAGE_ALIGN(ROUNDUP(efi_size, 8)
+  + ROUNDUP(acpi_size, 8));
+
+return 0;
+}


Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 0/7] Enhance PAT init to fix Xorg crashes

2016-03-29 Thread Ingo Molnar


* Toshi Kani  wrote:

> A Xorg failure on qemu32 was reported as a regression [1] caused by
> 'commit 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is disabled")'.
> This patch-set fixes the regression.
> 
> Negative effects of this regression were two failures [2] in Xorg on
> QEMU with QEMU CPU model "qemu32" (-cpu qemu32), which were triggered
> by the fact that its virtual CPU does not support MTRR.
>  #1. copy_process() failed in the check in reserve_pfn_range()
>  #2. error path in copy_process() then hit WARN_ON_ONCE in
>  untrack_pfn().
> 
> These negative effects are caused by two separate bugs, but they can be
> addressed in separate patches.  This patch-set addresses the root cause,
> a long-standing PAT initialization issue.
> 
> Please see the changelog in patch 4/7 for the details of the issue.
> 
> - Patch 1-2 make necessary enhancement to PAT for the fix without
>   breaking Xen.
> - Patch 3 is cleanup.
> - Patch 4 fixes the regression.
> - Patch 5 fixes an MTRR issue related with PAT init.
> - Patch 6 removes PAT init code from Xen.
> - Patch 7 adds PAT init to documentation.
> 
> [1]: https://lkml.org/lkml/2016/3/3/828
> [2]: https://lkml.org/lkml/2016/3/4/775

The changelogs are much improved, I've applied these patches to tip:x86/mm,
thanks Toshi!

> I'd appreciate if someone can test this patch-set on Xen to verify that
> there is no change in "x86/PAT: Configuration [0-7] .." message in dmesg.

So I don't have a Xen setup, but hopefully such testing will happen once these 
changes show up in linux-next, tomorrow or so.

Thanks,

Ingo

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

Re: [Xen-devel] [PATCH 3/3] libxl: add new pvusb backend "qusb" provided by qemu

On 29/03/16 11:45, George Dunlap wrote:
> On Fri, Mar 25, 2016 at 6:09 AM, Juergen Gross  wrote:
>> On 24/03/16 21:07, Wei Liu wrote:
>>> On Fri, Mar 18, 2016 at 09:24:26AM +0100, Juergen Gross wrote:
 On 17/03/16 17:55, George Dunlap wrote:
> On Thu, Mar 10, 2016 at 3:00 PM, Juergen Gross  wrote:
>> Add a new pvusb backend type "qusb" which is provided by qemu. It can
>> be selected either by specifying the type directly in the configuration
>> or it is selected automatically by libxl in case there is no "usbback"
>> driver loaded.
>>
>> Signed-off-by: Juergen Gross 
>
> Oh, last thing -- shouldn't we have a way for libxl to tell whether
> qemu can provide a qusb backend before we offer to start it up?

 How? Is this possible for qdisk? Or for an emulated frame buffer?

>>>
>>> I don't think it is  possible at the moment. But I think you might be
>>> able to do it either via qmp command or parsing qemu help string. The
>>> latter functionality is implemented in Ian's device model deprivilege
>>> patch series IIRC -- but it is not yet merged either.
>>
>> Won't help for qusb, as there is no qemu parameter or help text related
>> to the backend. It would be possible to add a qmp command to print the
>> supported backend types, of course.
> 
> Well as I understand it, for qemu-upstream we can't assume what
> version of qemu we'll end up getting: we need to be compatible with
> recent releases of qemu which don't provide qusb.  Which I'm pretty
> sure means failing gracefully (i.e., giving a sensible warning
> message) if someone tries to add qusb when their qemu binary doesn't
> support it.
> 
> If you can tell from the qemu failure that qusb is at fault, that's OK
> I think; but if not, I think you'll have to add some way to query
> whether qusb is supported by the qemu binary before starting it.

So we would want a qemu command line option (e.g. -xen-help) printing
the supported pv backends. I think this should be easy to setup.


Juergen


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

Re: [Xen-devel] [PATCH] spinlock: improve spin_is_locked() for recursive locks

On Thu, Mar 24, 2016 at 4:19 PM, Jan Beulich  wrote:
 On 24.03.16 at 16:55,  wrote:
>> On 24/03/16 11:30, Jan Beulich wrote:
>>> Recursive locks know their current owner, and since we use the function
>>> solely to determine whether a particular lock is being held by the
>>> current CPU (which so far has been an imprecise check), make actually
>>> check the owner for recusrively acquired locks.
>>
>> What's the expected behaviour of _spin_is_locked() if the lock is held
>> by another CPU?
>>
>> Before it may return true if it is held by another CPU, now it will
>> always return false in this case.
>
> Correct - hence the reference to this only being used for a limited
> set of cases (read: ASSERT()s and alike).

A bunch of the mm locks add "_by_me" at the end of the function.  Did
spin_is_locked() used to have that as well?

In any case I suppose "spin_is_locked_by_someone()" is really pretty
useless information.

 -George

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

[Xen-devel] [PATCH v2] x86/HVM: fix forwarding of internally cached requests

Forwarding entire batches to the device model when an individual
iteration of them got rejected by internal device emulation handlers
with X86EMUL_UNHANDLEABLE is wrong: The device model would then handle
all iterations, without the internal handler getting to see any past
the one it returned failure for. This causes misbehavior in at least
the MSI-X and VGA code, which want to see all such requests for
internal tracking/caching purposes. But note that this does not apply
to buffered I/O requests.

This in turn means that the condition in hvm_process_io_intercept() of
when to crash the domain was wrong: Since X86EMUL_UNHANDLEABLE can
validly be returned by the individual device handlers, we mustn't
blindly crash the domain if such occurs on other than the initial
iteration. Instead we need to distinguish hvm_copy_*_guest_phys()
failures from device specific ones, and then the former need to always
be fatal to the domain (i.e. also on the first iteration), since
otherwise we again would end up forwarding a request to qemu which the
internal handler didn't get to see.

The adjustment should be okay even for stdvga's MMIO handling:
- if it is not caching then the accept function would have failed so we
  won't get into hvm_process_io_intercept(),
- if it issued the buffered ioreq then we only get to the p->count
  reduction if hvm_send_ioreq() actually encountered an error (in which
  we don't care about the request getting split up).

Also commit 4faffc41d ("x86/hvm: limit reps to avoid the need to handle
retry") went too far in removing code from hvm_process_io_intercept():
When there were successfully handled iterations, the function should
continue to return success with a clipped repeat count.

Signed-off-by: Jan Beulich 
Cc: Chang Jianzhong 
---
v2: Make hvm_process_io_intercept() always return a valid X86EMUL_*
code by moving the domain_crash() invocations up. Add a stdvga
related paragraph to the commit message.
---
I assume this also addresses the issue which
http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg03189.html 
attempted to deal with in a not really acceptable way.

--- a/xen/arch/x86/hvm/emulate.c
+++ b/xen/arch/x86/hvm/emulate.c
@@ -95,7 +95,7 @@ static const struct hvm_io_handler null_
 };
 
 static int hvmemul_do_io(
-bool_t is_mmio, paddr_t addr, unsigned long reps, unsigned int size,
+bool_t is_mmio, paddr_t addr, unsigned long *reps, unsigned int size,
 uint8_t dir, bool_t df, bool_t data_is_addr, uintptr_t data)
 {
 struct vcpu *curr = current;
@@ -104,7 +104,7 @@ static int hvmemul_do_io(
 .type = is_mmio ? IOREQ_TYPE_COPY : IOREQ_TYPE_PIO,
 .addr = addr,
 .size = size,
-.count = reps,
+.count = *reps,
 .dir = dir,
 .df = df,
 .data = data,
@@ -136,7 +136,7 @@ static int hvmemul_do_io(
 if ( (p.type != is_mmio ? IOREQ_TYPE_COPY : IOREQ_TYPE_PIO) ||
  (p.addr != addr) ||
  (p.size != size) ||
- (p.count != reps) ||
+ (p.count != *reps) ||
  (p.dir != dir) ||
  (p.df != df) ||
  (p.data_is_ptr != data_is_addr) )
@@ -214,7 +214,7 @@ static int hvmemul_do_io_buffer(
 
 BUG_ON(buffer == NULL);
 
-rc = hvmemul_do_io(is_mmio, addr, *reps, size, dir, df, 0,
+rc = hvmemul_do_io(is_mmio, addr, reps, size, dir, df, 0,
(uintptr_t)buffer);
 if ( rc == X86EMUL_UNHANDLEABLE && dir == IOREQ_READ )
 memset(buffer, 0xff, size);
@@ -305,13 +305,13 @@ static int hvmemul_do_io_addr(
 count = 1;
 }
 
-rc = hvmemul_do_io(is_mmio, addr, count, size, dir, df, 1,
+rc = hvmemul_do_io(is_mmio, addr, &count, size, dir, df, 1,
ram_gpa);
+
 if ( rc == X86EMUL_OKAY )
-{
 v->arch.hvm_vcpu.hvm_io.mmio_retry = (count < *reps);
-*reps = count;
-}
+
+*reps = count;
 
  out:
 while ( nr_pages )
--- a/xen/arch/x86/hvm/intercept.c
+++ b/xen/arch/x86/hvm/intercept.c
@@ -148,8 +148,8 @@ int hvm_process_io_intercept(const struc
 ASSERT_UNREACHABLE();
 /* fall through */
 default:
-rc = X86EMUL_UNHANDLEABLE;
-break;
+domain_crash(current->domain);
+return X86EMUL_UNHANDLEABLE;
 }
 if ( rc != X86EMUL_OKAY )
 break;
@@ -178,8 +178,8 @@ int hvm_process_io_intercept(const struc
 ASSERT_UNREACHABLE();
 /* fall through */
 default:
-rc = X86EMUL_UNHANDLEABLE;
-break;
+domain_crash(current->domain);
+return X86EMUL_UNHANDLEABLE;
 }
 if ( rc != X86EMUL_OKAY )
 break;
@@ -196,8 +196,20 @@ int hvm_process_io_intercept(const struc
 }
 }
 
-

Re: [Xen-devel] [PATCH v2] x86/HVM: fix forwarding of internally cached requests

> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 29 March 2016 11:40
> To: xen-devel
> Cc: Andrew Cooper; Paul Durrant; Chang Jianzhong; Keir (Xen.org)
> Subject: [PATCH v2] x86/HVM: fix forwarding of internally cached requests
> 
> Forwarding entire batches to the device model when an individual
> iteration of them got rejected by internal device emulation handlers
> with X86EMUL_UNHANDLEABLE is wrong: The device model would then
> handle
> all iterations, without the internal handler getting to see any past
> the one it returned failure for. This causes misbehavior in at least
> the MSI-X and VGA code, which want to see all such requests for
> internal tracking/caching purposes. But note that this does not apply
> to buffered I/O requests.
> 
> This in turn means that the condition in hvm_process_io_intercept() of
> when to crash the domain was wrong: Since X86EMUL_UNHANDLEABLE can
> validly be returned by the individual device handlers, we mustn't
> blindly crash the domain if such occurs on other than the initial
> iteration. Instead we need to distinguish hvm_copy_*_guest_phys()
> failures from device specific ones, and then the former need to always
> be fatal to the domain (i.e. also on the first iteration), since
> otherwise we again would end up forwarding a request to qemu which the
> internal handler didn't get to see.
> 
> The adjustment should be okay even for stdvga's MMIO handling:
> - if it is not caching then the accept function would have failed so we
>   won't get into hvm_process_io_intercept(),
> - if it issued the buffered ioreq then we only get to the p->count
>   reduction if hvm_send_ioreq() actually encountered an error (in which
>   we don't care about the request getting split up).
> 
> Also commit 4faffc41d ("x86/hvm: limit reps to avoid the need to handle
> retry") went too far in removing code from hvm_process_io_intercept():
> When there were successfully handled iterations, the function should
> continue to return success with a clipped repeat count.
> 
> Signed-off-by: Jan Beulich 

Reviewed-by: Paul Durrant 

> Cc: Chang Jianzhong 
> ---
> v2: Make hvm_process_io_intercept() always return a valid X86EMUL_*
> code by moving the domain_crash() invocations up. Add a stdvga
> related paragraph to the commit message.
> ---
> I assume this also addresses the issue which
> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg03189.html
> attempted to deal with in a not really acceptable way.
> 
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -95,7 +95,7 @@ static const struct hvm_io_handler null_
>  };
> 
>  static int hvmemul_do_io(
> -bool_t is_mmio, paddr_t addr, unsigned long reps, unsigned int size,
> +bool_t is_mmio, paddr_t addr, unsigned long *reps, unsigned int size,
>  uint8_t dir, bool_t df, bool_t data_is_addr, uintptr_t data)
>  {
>  struct vcpu *curr = current;
> @@ -104,7 +104,7 @@ static int hvmemul_do_io(
>  .type = is_mmio ? IOREQ_TYPE_COPY : IOREQ_TYPE_PIO,
>  .addr = addr,
>  .size = size,
> -.count = reps,
> +.count = *reps,
>  .dir = dir,
>  .df = df,
>  .data = data,
> @@ -136,7 +136,7 @@ static int hvmemul_do_io(
>  if ( (p.type != is_mmio ? IOREQ_TYPE_COPY : IOREQ_TYPE_PIO) ||
>   (p.addr != addr) ||
>   (p.size != size) ||
> - (p.count != reps) ||
> + (p.count != *reps) ||
>   (p.dir != dir) ||
>   (p.df != df) ||
>   (p.data_is_ptr != data_is_addr) )
> @@ -214,7 +214,7 @@ static int hvmemul_do_io_buffer(
> 
>  BUG_ON(buffer == NULL);
> 
> -rc = hvmemul_do_io(is_mmio, addr, *reps, size, dir, df, 0,
> +rc = hvmemul_do_io(is_mmio, addr, reps, size, dir, df, 0,
> (uintptr_t)buffer);
>  if ( rc == X86EMUL_UNHANDLEABLE && dir == IOREQ_READ )
>  memset(buffer, 0xff, size);
> @@ -305,13 +305,13 @@ static int hvmemul_do_io_addr(
>  count = 1;
>  }
> 
> -rc = hvmemul_do_io(is_mmio, addr, count, size, dir, df, 1,
> +rc = hvmemul_do_io(is_mmio, addr, &count, size, dir, df, 1,
> ram_gpa);
> +
>  if ( rc == X86EMUL_OKAY )
> -{
>  v->arch.hvm_vcpu.hvm_io.mmio_retry = (count < *reps);
> -*reps = count;
> -}
> +
> +*reps = count;
> 
>   out:
>  while ( nr_pages )
> --- a/xen/arch/x86/hvm/intercept.c
> +++ b/xen/arch/x86/hvm/intercept.c
> @@ -148,8 +148,8 @@ int hvm_process_io_intercept(const struc
>  ASSERT_UNREACHABLE();
>  /* fall through */
>  default:
> -rc = X86EMUL_UNHANDLEABLE;
> -break;
> +domain_crash(current->domain);
> +return X86EMUL_UNHANDLEABLE;
>  }
>  if ( rc != X86EMUL_OKAY )
>  break;
> @@ -178

Re: [Xen-devel] [PATCH] spinlock: improve spin_is_locked() for recursive locks

>>> On 29.03.16 at 12:36,  wrote:
> On Thu, Mar 24, 2016 at 4:19 PM, Jan Beulich  wrote:
> On 24.03.16 at 16:55,  wrote:
>>> On 24/03/16 11:30, Jan Beulich wrote:
 Recursive locks know their current owner, and since we use the function
 solely to determine whether a particular lock is being held by the
 current CPU (which so far has been an imprecise check), make actually
 check the owner for recusrively acquired locks.
>>>
>>> What's the expected behaviour of _spin_is_locked() if the lock is held
>>> by another CPU?
>>>
>>> Before it may return true if it is held by another CPU, now it will
>>> always return false in this case.
>>
>> Correct - hence the reference to this only being used for a limited
>> set of cases (read: ASSERT()s and alike).
> 
> A bunch of the mm locks add "_by_me" at the end of the function.  Did
> spin_is_locked() used to have that as well?

I don't think it did. And I think the only other readily visible use
case of spin_is_locked() (testing whether a spin lock could be
acquired without delay) is bogus anyway, as it would better be
performed by doing a try-lock.

> In any case I suppose "spin_is_locked_by_someone()" is really pretty
> useless information.

Indeed, hence I didn't want to alter the functions' names.

Jan


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

Re: [Xen-devel] [PATCH v7 02/22] arm/acpi: Add a helper function to get the acpi table offset


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

These tables are aligned with 64bit.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 
---
v7: add commnets to explain what thsi function does
---
  xen/arch/arm/acpi/lib.c| 20 
  xen/include/asm-arm/acpi.h |  2 ++
  2 files changed, 22 insertions(+)

diff --git a/xen/arch/arm/acpi/lib.c b/xen/arch/arm/acpi/lib.c
index db5c4d8..cee2454 100644
--- a/xen/arch/arm/acpi/lib.c
+++ b/xen/arch/arm/acpi/lib.c
@@ -60,3 +60,23 @@ bool_t __init acpi_psci_hvc_present(void)
  {
  return acpi_gbl_FADT.arm_boot_flags & ACPI_FADT_PSCI_USE_HVC;
  }
+
+/*
+ * This function is used to get the offset of some new created ACPI or EFI 
table
+ * in the allocated memory region. Currently the tables should be created in 
the
+ * order of enum EFI_MEM_RES.
+ */


The function could be called after the table is created and still return 
the correct value. I would clearly write in the description when this 
function can be called or not. Something along those lines:


"This function returns the offset of a given ACPI/EFI table in the 
allocated memory region.


Currently, the tables should be created in the same order as their 
associated 'index' in the enum EFI_MEM_RES. This means the function 
won't return the correct offset until all the tables before a given 
'index' are created.".


Also, the description of an external function is usually done in the header.

Regards,

--
Julien Grall

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

Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM support for Xen

>>> On 29.03.16 at 12:10,  wrote:
> On 03/29/16 03:11, Jan Beulich wrote:
>> >>> On 29.03.16 at 10:47,  wrote:
>> > On 03/17/16 22:21, Haozhong Zhang wrote:
>> >> On 03/17/16 14:00, Ian Jackson wrote:
>> >> > Haozhong Zhang writes ("Re: [Xen-devel] [RFC Design Doc] Add vNVDIMM 
> support for Xen"):
>> >> > > QEMU keeps mappings of guest memory because (1) that mapping is
>> >> > > created by itself, and/or (2) certain device emulation needs to access
>> >> > > the guest memory. But for vNVDIMM, I'm going to move the creation of
>> >> > > its mappings out of qemu to toolstack and vNVDIMM in QEMU does not
>> >> > > access vNVDIMM pages mapped to guest, so it's not necessary to let
>> >> > > qemu keeps vNVDIMM mappings.
>> >> > 
>> >> > I'm confused by this.
>> >> > 
>> >> > Suppose a guest uses an emulated device (or backend) provided by qemu,
>> >> > to do DMA to an vNVDIMM.  Then qemu will need to map the real NVDIMM
>> >> > pages into its own address space, so that it can write to the memory
>> >> > (ie, do the virtual DMA).
>> >> > 
>> >> > That virtual DMA might well involve a direct mapping in the kernel
>> >> > underlying qemu: ie, qemu might use O_DIRECT to have its kernel write
>> >> > directly to the NVDIMM, and with luck the actual device backing the
>> >> > virtual device will be able to DMA to the NVDIMM.
>> >> > 
>> >> > All of this seems to me to mean that qemu needs to be able to map
>> >> > its guest's parts of NVDIMMs
>> >> > 
>> >> > There are probably other example: memory inspection systems used by
>> >> > virus scanners etc.; debuggers used to inspect a guest from outside;
>> >> > etc.
>> >> > 
>> >> > I haven't even got started on save/restore...
>> >> > 
>> >> 
>> >> Oops, so many cases I missed. Thanks Ian for pointing out all these!
>> >> Now I need to reconsider how to manage guest permissions for NVDIMM pages.
>> >> 
>> > 
>> > I still cannot find a neat approach to manage guest permissions for
>> > nvdimm pages. A possible one is to use a per-domain bitmap to track
>> > permissions: each bit corresponding to an nvdimm page. The bitmap can
>> > save lots of spaces and even be stored in the normal ram, but
>> > operating it for a large nvdimm range, especially for a contiguous
>> > one, is slower than rangeset.
>> 
>> I don't follow: What would a single bit in that bitmap mean? Any
>> guest may access the page? That surely wouldn't be what we
>> need.
>>
> 
> For a host having a N pages of nvdimm, each domain will have a N bits
> bitmap. If the m'th bit of a domain's bitmap is set, then that domain
> has the permission to access the m'th host nvdimm page.

Which will be more overhead as soon as there are enough such
domains in a system.

>> > BTW, if I take the other way to map nvdimm pages to guest
>> > (http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg01972.html)
>> > | 2. Or, given the same inputs, we may combine above two steps into a new
>> > |dom0 system call that (1) gets the SPA ranges, (2) calls xen
>> > |hypercall to map SPA ranges
>> > and treat nvdimm as normal ram, then xen will not need to use rangeset
>> > or above bitmap to track guest permissions for nvdimm? But looking at
>> > how qemu currently populates guest memory via XENMEM_populate_physmap
>> > , and other hypercalls like XENMEM_[in|de]crease_reservation, it looks
>> > like that mapping a _dedicated_ piece of host ram to guest is not
>> > allowed out of the hypervisor (and not allowed even in dom0 kernel)?
>> > Is it for security concerns, e.g. avoiding a malfunctioned dom0 leaking
>> > guest memory?
>> 
>> Well, it's simply because RAM is a resource managed through
>> allocation/freeing, instead of via reserving chunks for special
>> purposes.
>> 
> 
> So that means xen can always ensure the ram assigned to a guest is
> what the guest is permitted to access, so no data structures like
> iomem_caps is needed for ram. If I have to introduce a hypercall that
> maps the dedicated host ram/nvdimm to guest, then the explicit
> permission management is still needed, regardless of who (dom0 kernel,
> qemu or toolstack) will use it. Right?

Yes (if you really mean to go that route).

Jan

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

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

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-freebsd10-i386 10 guest-start fail REGR. vs. 86454
 test-amd64-i386-qemuu-rhel6hvm-intel  9 redhat-installfail REGR. vs. 86454
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 86454
 test-amd64-i386-freebsd10-amd64 10 guest-startfail REGR. vs. 86454
 test-amd64-i386-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
86454
 test-amd64-i386-qemuu-rhel6hvm-amd  9 redhat-install  fail REGR. vs. 86454
 test-amd64-i386-xl-qemuu-ovmf-amd64  9 debian-hvm-install fail REGR. vs. 86454
 test-amd64-amd64-qemuu-nested-intel  9 debian-hvm-install fail REGR. vs. 86454
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail 
REGR. vs. 86454
 test-amd64-amd64-qemuu-nested-amd  9 debian-hvm-install   fail REGR. vs. 86454
 test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 86454
 test-amd64-amd64-xl-qemuu-debianhvm-amd64 9 debian-hvm-install fail REGR. vs. 
86454
 test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. 
vs. 86454
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 86454

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-raw   16 guest-localmigrate/x10 fail in 87591 pass in 87801
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 
87428
 test-armhf-armhf-xl-xsm  15 guest-start/debian.repeat   fail pass in 87591
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 
87710
 test-armhf-armhf-libvirt-qcow2  9 debian-di-install fail pass in 87710
 test-armhf-armhf-xl-vhd  14 guest-start/debian.repeat   fail pass in 87710

Regressions which are regarded as allowable (not blocking):
 test-armhf-armhf-xl-rtds 15 guest-start/debian.repeat fail in 87710 blocked in 
86454
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86454
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 86454
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 86454

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 87710 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 87710 never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail in 87710 never 
pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestore   fail in 87710 never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt 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-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-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-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-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 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-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-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 qemuub68a80139e37e806f004237e55311ebc42151434
baseline version:
 qemuud1f8764099022bc11

[Xen-devel] [PATCH] x86/hvm/viridian: fix APIC assist page leak

Commit a6f2cdb6 "keep APIC assist page mapped..." introduced a page
leak because it relied on viridian_vcpu_deinit() always being called
to release the page mapping. This does not happen in the case a normal
domain shutdown.

This patch fixes the problem by introducing a new function,
viridian_domain_deinit(), which will iterate through the vCPUs and
release any page mappings still present.

Signed-off-by: Paul Durrant 
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 
---
 xen/arch/x86/hvm/hvm.c |  2 ++
 xen/arch/x86/hvm/viridian.c| 16 
 xen/include/asm-x86/hvm/viridian.h |  1 +
 3 files changed, 19 insertions(+)

diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 80d59ff..611470e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -1726,6 +1726,8 @@ void hvm_domain_relinquish_resources(struct domain *d)
 if ( hvm_funcs.nhvm_domain_relinquish_resources )
 hvm_funcs.nhvm_domain_relinquish_resources(d);
 
+viridian_domain_deinit(d);
+
 hvm_destroy_all_ioreq_servers(d);
 
 msixtbl_pt_cleanup(d);
diff --git a/xen/arch/x86/hvm/viridian.c b/xen/arch/x86/hvm/viridian.c
index dceed2c..5c76c1a 100644
--- a/xen/arch/x86/hvm/viridian.c
+++ b/xen/arch/x86/hvm/viridian.c
@@ -251,6 +251,14 @@ static void initialize_apic_assist(struct vcpu *v)
 
 if ( viridian_feature_mask(v->domain) & HVMPV_apic_assist )
 {
+/*
+ * If we overwrite an existing address here then something has
+ * gone wrong and a domain page will leak. Instead crash the
+ * domain to make the problem obvious.
+ */
+if ( v->arch.hvm_vcpu.viridian.apic_assist.va )
+domain_crash(d);
+
 v->arch.hvm_vcpu.viridian.apic_assist.va = va;
 return;
 }
@@ -608,6 +616,14 @@ void viridian_vcpu_deinit(struct vcpu *v)
 teardown_apic_assist(v);
 }
 
+void viridian_domain_deinit(struct domain *d)
+{
+struct vcpu *v;
+
+for_each_vcpu ( d, v )
+teardown_apic_assist(v);
+}
+
 static DEFINE_PER_CPU(cpumask_t, ipi_cpumask);
 
 int viridian_hypercall(struct cpu_user_regs *regs)
diff --git a/xen/include/asm-x86/hvm/viridian.h 
b/xen/include/asm-x86/hvm/viridian.h
index 7f281b2..bdbccd5 100644
--- a/xen/include/asm-x86/hvm/viridian.h
+++ b/xen/include/asm-x86/hvm/viridian.h
@@ -122,6 +122,7 @@ void viridian_time_ref_count_freeze(struct domain *d);
 void viridian_time_ref_count_thaw(struct domain *d);
 
 void viridian_vcpu_deinit(struct vcpu *v);
+void viridian_domain_deinit(struct domain *d);
 
 void viridian_start_apic_assist(struct vcpu *v, int vector);
 int viridian_complete_apic_assist(struct vcpu *v);
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v8 for Xen 4.7 1/4] xen: enable per-VCPU parameter for RTDS

2016-03-29 Thread Dario Faggioli

On Fri, 2016-03-25 at 13:07 -0500, Chong Li wrote:
> Ok. I've already fixed all problems pointed out by George and Jan.
> 
> Dario and Meng, do you have any other comments on this patch?
> 
Hey,

Sorry for the delay... busy, and then public holidays... I'll look at
this series later today.

Regards,
Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D 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 v3] xen/arm64: check XSM Magic and Signature from the second unknown module.

2016-03-29 Thread Fu Wei

Hi Jan

On 29 March 2016 at 17:56, Jan Beulich  wrote:
 On 29.03.16 at 05:26,  wrote:
>> +static bool __init check_xsm_signature(const void *fdt, int node,
>> +   const char *name,
>> +   u32 address_cells, u32 size_cells)
>> +{
>> +#ifdef CONFIG_FLASK
>> +u32 xen_magic = XSM_MAGIC, target_len = 8;
>> +const struct fdt_property *prop;
>> +unsigned char buff[16];
>> +paddr_t start, size;
>> +const __be32 *cell;
>> +int len;
>> +
>> +prop = fdt_get_property(fdt, node, "reg", &len);
>> +if ( !prop || len < dt_cells_to_size(address_cells + size_cells))
>
> At the very least you'll need to adjust style: There's a missing
> blank before the closing parenthesis here, and more of this kind
> of issue follow later.

Ah, sorry,  will fix it. Thanks ! ;-)

>
> Jan
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021

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

Re: [Xen-devel] xl: improve return codes for more xl comands

On Fri, Mar 25, 2016 at 1:53 PM, Paulina Szubarczyk
 wrote:
> Hi,
>
> This regards bite-size task for Outreachy program [0].
>
> I followed the patches prepared by Harmandeep [1] where functions in
> xl_cmdimpl.c have the pattern:
>
> "*main_foo() is treated somewhat as a regular main(), it is changed to
> return EXIT_SUCCESS or EXIT_FAILURE.
>
> *Functions that are not main_foo(), are changed to do 'return 0' or
> 'return 1', and then 0/1 is taken care in the main_foo() functions
> that calls them. "
>
> The changes regard scheduling functions.
>
> But in the preliminary patches [2] there is a notion to change not
> main_foo()
> to return EXIT_SUCCESS or EXIT_FAILURE, like in [3].
>
> Should not-main functions related to
> - mem-set
> - cd-insert
> - pci-*
> return 0/1 or should EXIT_SUCCESS/EXIT_FAILURE be kept?
>
> There is also a patch that change exit code from numeric values or ERROR_*
> codes to be either EXIT_SUCCESS or EXIT_FAILURE for migrate related
> functions [4].
>
> Could that be applied to those functions too?

Yes, it looks like Harmandeep's series had more scrutiny and more
careful thought, so please follow the pattern she set. :-)

 -George

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

Re: [Xen-devel] [PATCH] x86/hvm/viridian: fix APIC assist page leak

>>> On 29.03.16 at 12:47,  wrote:
> Commit a6f2cdb6 "keep APIC assist page mapped..." introduced a page
> leak because it relied on viridian_vcpu_deinit() always being called
> to release the page mapping. This does not happen in the case a normal
> domain shutdown.
> 
> This patch fixes the problem by introducing a new function,
> viridian_domain_deinit(), which will iterate through the vCPUs and
> release any page mappings still present.
> 
> Signed-off-by: Paul Durrant 

Reviewed-by: Jan Beulich 


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

Re: [Xen-devel] [PATCH] blktap2: Invalid logic detecting unaligned buffers in vhd_write_block

On Fri, Mar 25, 2016 at 4:34 PM, Ross Philipson
 wrote:
> On 03/25/2016 12:11 PM, Wei Liu wrote:
>> On Thu, Mar 17, 2016 at 06:10:59PM -0400, Ross Philipson wrote:
>>> It seems the logic is meant to detect sector unaligned buffers for block
>>> writes. The NOTing of the logic instead masks off any unaligned bits and
>>> also would cause the function to always fail. It seems the function is not
>>> used in any of the tools so that is probably why the problem is not seen.
>>> In the vhd_read_block function it is correct.
>>>
>>> Signed-off-by: Ross Philipson 
>>
>> This seems to fall under tools umbrella. I've look at blktap2 code,
>> the reasoning is convincing to me so:
>>
>>   Acked-by: Wei Liu 
>>
>> But I've never used blktap2 and we don't normally test it so I would
>> also wait a bit longer to see if anybody objects to this change.
>>
>> OOI if no code was using this, how did you discover this problem?
>
> We have an old fork of blktap2 from way back when. I was working to extract 
> our
> changes and turn them into patches so we could rebase on upstream blktap2.
> Someone long ago found that - I have no idea how but it was a valid fix so I
> upstreamed it.
>
> There are a number of other ones that were found that are still in upstream
> blktap2 - I plan to send them too.

Ross,

Instead of cross-porting fixes from XenServer's blktap3 to the
bitrotting blktap2, would you consider taking up my work on replacing
blktap2 with building blktap3 as an external project?

The basic shape of things that need to happen for that are:

1. Allow qemu to provide emulated devices for disks which use hotplug
scripts (just checked in last week)

2. Do the tweaks necessary to allow blktap3 to be built as an
independent project (outside the XenServer build system)

3. Switch libxl to use the already-in-tree block-tap script (which
calls tapctl) rather than linking against the blktap library.

4. Add a blktap target to raisin.

#1 is done and was just checked in last week.  #2 shouldn't be a
terribly large amount of work.  For #3, I've posted patches already,
and I can probably do a quick rebase for you to pick up if you wanted.
#4 shouldn't be too hard once you have an out-of-tree build working; I
can help with that as well.

If we then add tests for upstream blktap to osstest, then we'll catch
any breakages, and automatically get updates; and we can delete the
bitrotting blktap2 out of the tree.

What do you think?

 -George

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

Re: [Xen-devel] [PATCH 2/2] tools: detect appropriate debug optimization level

On Mon, Mar 28, 2016 at 4:01 PM, Doug Goldstein  wrote:
> On 3/16/16 2:14 PM, Doug Goldstein wrote:
>> On 3/8/16 10:50 AM, Wei Liu wrote:
>>> On Tue, Mar 08, 2016 at 10:34:42AM -0600, Doug Goldstein wrote:
 On 3/8/16 9:38 AM, Wei Liu wrote:
> On Mon, Mar 07, 2016 at 08:23:40PM -0600, Doug Goldstein wrote:
>> The build should not use -O0 as that results in miscompilations. There
>
> This needs some (concrete) references. Is that a known issue in gcc? If
> so can you reference the bug number?

 So its not really a bug in GCC but just the complete lack of
 optimizations in play. inlines aren't inlined. dead code elimination
 isn't run so things are much bigger. structures aren't padded the same way.

>>>
>>> Urgh...
>>>
 This came about from reading reports on the -devel and -user's ML that
 were solved by building Xen with debug=n. I was also striving to reduce
 the duplication of CFLAGS that are passed on the command line of builds.

>>>
>>> I agree this is a good idea.
>>>
>
>> have been a few instances on the ML where users were told to switch
>> from -O0 to -O1 or -O2 or to set debug=n and their issue went away. The
>> preferred route should be to use -Og if its available, otherwise use
>> -O1 which is the default. This change undoes the change from -O1 to -O0
>
> gcc manual says -O0 is the default.

 I wasn't clear about where the 'the default' came from. That's the
 default in the Xen tree (see: config/StdGNU.mk for example but every
 platform has -O1 set).

>>>
>>> OK. I thought you're talking about something in the manual.
>>>
>
> Not that I disagree with this patch in general, but the commit message
> seems a bit misleading.

 I can rewrite it. I'd also be willing to change the patch to prefer -Og
 if its available and use -O0 if its not.

>>>
>>> No need to do it now because ...
>>>
>
>> in 1166ecf781b1016eaa61f8d5ba4fb1fde9d599b6.
>>
>
> And I have no idea why -O1 confuses the debugger so I've CC'ed Euan for
> more input.

 -O1 can optimize things out when you look at them with gdb but -Og is
 suppose to do the right thing.

>>>
>>> .. I don't know much about gcc so I would like to wait for Ian to give
>>> some input.
>>>
>>> Wei.
>>>
>
>> Signed-off-by: Doug Goldstein 
>> ---
>> CC: Ian Jackson 
>> CC: Stefano Stabellini 
>> CC: Wei Liu 
>> ---
>>  tools/Rules.mk | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/Rules.mk b/tools/Rules.mk
>> index 9ef0b47..ae6b01f 100644
>> --- a/tools/Rules.mk
>> +++ b/tools/Rules.mk
>> @@ -137,7 +137,8 @@ SHLIB_libxenvchan  = $(SHDEPS_libxenvchan) 
>> -Wl,-rpath-link=$(XEN_LIBVCHAN)
>>
>>  ifeq ($(debug),y)
>>  # Disable optimizations and enable debugging information for macros
>> -CFLAGS += -O0 -g3
>> +$(call cc-option-add,CFLAGS,CC,-Og)
>> +CFLAGS += -g3
>>  # But allow an override to -O0 in case Python enforces 
>> -D_FORTIFY_SOURCE=.
>>  PY_CFLAGS += $(PY_NOOPT_CFLAGS)
>>  endif
>> --
>> 2.4.10
>>


 --
 Doug Goldstein

>>>
>>>
>>>
>>
>> ping?
>>
>>
>
> ping the ping?

So just reading through the history -- I'm a bit confused why, if -Og
is supposed to "do the right thing", why you didn't add that in this
patch?

In any case, having debug=y *functioning* should take priority over
having gdb working, so I'm inclined to say that we should take a patch
like this.

 -George

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

[Xen-devel] Xen Security Advisory 172 (CVE-2016-3158, CVE-2016-3159) - broken AMD FPU FIP/FDP/FOP leak workaround

2016-03-29 Thread Xen . org security team

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 Xen Security Advisory CVE-2016-3158,CVE-2016-3159 / XSA-172
  version 3

  broken AMD FPU FIP/FDP/FOP leak workaround

UPDATES IN VERSION 3


Public release.

ISSUE DESCRIPTION
=

There is a workaround in Xen to deal with the fact that AMD CPUs don't
load the x86 registers FIP (and possibly FCS), FDP (and possibly FDS),
and FOP from memory (via XRSTOR or FXRSTOR) when there is no pending
unmasked exception.  (See XSA-52.)

However, this workaround does not cover all possible input cases.
This is because writes to the hardware FSW.ES bit, which the current
workaround is based on, are ignored; instead, the CPU calculates
FSW.ES from the pending exception and exception mask bits.  Xen
therefore needs to do the same.

Note that part of said workaround was the subject of XSA-52.

This can leak register contents from one guest to another.  The
registers in question are the FPU instruction and data pointers and
opcode.

IMPACT
==

A malicious domain is able to obtain address space usage and timing
information, about another domain, at a fairly low rate.

The leaked address information might be used to help defeat address
space randomisation in order to enable another attack.  The leaked
address and timing information forms a low-bandwidth covert channel
which might be used to gain information about the operation of a
target guest.

The affected FPU facility would not normally be used by cryptographic
operations, as it does not provide cryptographically-relevant SIMD
functions.

It appears to us very unlikely that the leak might directly compromise
sensitive information such as cryptographic keys, although (without
knowledge of the guest software) this cannot be ruled out.  (This is
notwithstanding the contrary statement in `Impact' in XSA-52.)

VULNERABLE SYSTEMS
==

Xen versions 4.0 and onwards are vulnerable.  Any kind of guest can
exploit the vulnerability.

The vulnerability is exposed only on AMD x86 systems.  Intel and ARM
systems do not expose this vulnerability.

Both PV and HVM guests are affected.

MITIGATION
==

The vulnerability can be avoided if the guest kernel is controlled by
the host rather than guest administrator, provided that further steps
are taken to prevent the guest administrator from loading code into
the kernel (e.g. by disabling loadable modules etc) or from using
other mechanisms which allow them to run code at kernel privilege.

On Xen versions 4.3 and earlier, turning off XSAVE support via the
"no-xsave" hypervisor command line option will avoid the vulnerability.

On Xen versions 4.4 and onwards there is no other known mitigation.

CREDITS
===

This issue was discovered by Jan Beulich from SUSE.

RESOLUTION
==

Applying the appropriate attached patch resolves this issue.

xsa172.patch   xen-unstable, Xen 4.6.x, Xen 4.5.x, Xen 4.4.x
xsa172-4.3.patch   Xen 4.3.x

$ sha256sum xsa172*
f18282fcb794b8772bc3af51d56860050071bd62a5a909b8f2fc2018e2958154  xsa172.patch
6aac179620afcdbdab041163239019bc35b0e243f3bd16673caaec7d5a4d97ec  
xsa172-4.3.patch
$

NOTE REGARDING CVE
==

CVE-2016-3158 is for the code change which is required for all
versions (but which is sufficient only on Xen 4.3.x, and insufficient
on later versions).  Ie for the second hunk in xsa172.patch (the only
hunk in xsa172-4.3.patch), which patches the function xrstor.

CVE-2016-3159 is for the code change which is applicable for later
versions only, but which must always be combined with the code change
for CVE-2016-3158.  Ie for the first hunk in xsa172.patch, which
patches the function fpu_fxrstor.

DEPLOYMENT DURING EMBARGO
=

Deployment of the PATCH or the TRUSTED KERNEL MITIGATION (or others
which are substantially similar) is permitted during the embargo, even
on public-facing systems with untrusted guest users and
administrators.

However deployment of the "no-xsave" MITIGATION is NOT permitted
(except where all the affected systems and VMs are administered and
used only by organisations which are members of the Xen Project
Security Issues Predisclosure List).  Specifically, deployment on
public cloud systems is NOT permitted.

This is because such a host configuration change would be guest-visible
which could lead to the rediscovery of the vulnerability.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible

[Xen-devel] patch ping

REST maintainers,

may I please ask for acks or otherwise on
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg03193.html
(v2 of patch 2: 
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg02804.html)
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03135.html
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03179.html
http://lists.xenproject.org/archives/html/xen-devel/2016-03/msg03180.html

Thanks, Jan


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

Re: [Xen-devel] [PATCH 3/7] oxenstored: refactor request processing

2016-03-29 Thread Boris Ostrovsky


On 03/29/2016 05:08 AM, Jonathan Davies wrote:

On Thu, Mar 24, 2016 at 07:57:30PM -0400, Boris Ostrovsky wrote:

On 03/24/2016 06:49 PM, Andrew Cooper wrote:

On 24/03/2016 22:22, Boris Ostrovsky wrote:

On 03/17/2016 01:51 PM, Jonathan Davies wrote:

Encapsulate the request in a record that is passed from do_input to
process_packet and input_handle_error.

This will be helpful when keeping track of the requests made as part
of a
transaction.

Signed-off-by: Jonathan Davies 
Reviewed-by: Andrew Cooper 
Reviewed-by: Jon Ludlam 
Reviewed-by: Euan Harris 
---
   tools/ocaml/xenstored/process.ml |   15 ++-
   1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/tools/ocaml/xenstored/process.ml
b/tools/ocaml/xenstored/process.ml
index 7a73669..c92bec7 100644
--- a/tools/ocaml/xenstored/process.ml
+++ b/tools/ocaml/xenstored/process.ml
@@ -344,11 +344,11 @@ let function_of_type ty =
   | Xenbus.Xb.Op.Invalid   -> reply_ack do_error
   | _  -> reply_ack do_error
   -let input_handle_error ~cons ~doms ~fct ~ty ~con ~t ~rid ~data =
+let input_handle_error ~cons ~doms ~fct ~con ~t ~req =
   let reply_error e =
   Packet.Error e in
   try
-fct con t doms cons data
+fct con t doms cons req.Packet.data
   with
   | Define.Invalid_path  -> reply_error "EINVAL"
   | Define.Already_exist -> reply_error "EEXIST"
@@ -370,7 +370,10 @@ let input_handle_error ~cons ~doms ~fct ~ty ~con
~t ~rid ~data =
   (**
* Nothrow guarantee.
*)
-let process_packet ~store ~cons ~doms ~con ~tid ~rid ~ty ~data =
+let process_packet ~store ~cons ~doms ~con ~req =
+let ty = req.Packet.ty in
+let tid = req.Packet.tid in
+let rid = req.Packet.rid in
   try
   let fct = function_of_type ty in
   let t =
@@ -379,7 +382,7 @@ let process_packet ~store ~cons ~doms ~con ~tid
~rid ~ty ~data =
   else
   Connection.get_transaction con tid
   in
-let response = input_handle_error ~cons ~doms ~fct ~ty ~con
~t ~rid ~data in
+let response = input_handle_error ~cons ~doms ~fct ~con ~t
~req in
 (* Put the response on the wire *)
   send_response ty con t rid response
@@ -412,11 +415,13 @@ let do_input store cons doms con =
   if newpacket then (
   let packet = Connection.pop_in con in
   let tid, rid, ty, data = Xenbus.Xb.Packet.unpack packet in
+let req = {Packet.tid; Packet.rid; Packet.ty; Packet.data} in
+

I think this change breaks the build with older ocaml versions:

root@haswell> ocamlopt -v
The OCaml native-code compiler, version 4.00.1
Standard library directory: /usr/lib64/ocaml
root@haswell> ocamlopt -g -ccopt "" -dtypes -I
/root/tmp/xen/tools/ocaml/xenstored/../libs/xb -I
/root/tmp/xen/tools/ocaml/xenstored/../libs/mmap -I
/root/tmp/xen/tools/ocaml/xenstored/../libs/xc -I
/root/tmp/xen/tools/ocaml/xenstored/../libs/eventchn -cc gcc -w F
-warn-error F -c -o process.cmx process.ml
root@haswell>


root@ovs104> ocamlopt -v
The Objective Caml native-code compiler, version 3.11.2
Standard library directory: /usr/lib64/ocaml
root@ovs104> ocamlopt -g -ccopt "" -dtypes -I
/root/tmp/xen/tools/ocaml/xenstored/../libs/xb -I
/root/tmp/xen/tools/ocaml/xenstored/../libs/mmap -I
/root/tmp/xen/tools/ocaml/xenstored/../libs/xc -I
/root/tmp/xen/tools/ocaml/xenstored/../libs/eventchn -cc gcc -w F
-warn-error F -c -o process.cmx process.ml
File "process.ml", line 487, characters 23-24:
Error: Syntax error
root@ovs104>

I don't know much about ocaml (OK, I know *nothing* about ocaml) so I
can't say what exactly might be wrong.

Could you perhaps try this instead?

let req = {tid = Packet.tid; rid = Packet.rid; ty = Packet.ty; data =
Packet.data} in

It is most likely that the older version of Ocaml can't infer the order
of fields.

~Andrew


No, it now gives me "Error: Unbound record field label tid"

-boris

Andrew's guess was close, but the wrong way around -- please could you try the
following with the older compiler?

let req = {Packet.tid=tid; Packet.rid=rid; Packet.ty=ty; Packet.data=data} in

I was using a syntactic feature of OCaml called 'field punning' which is
generally considered good practice and makes for more readable code. It looks
like this feature was introduced in OCaml 3.12.0 (dating from 2010), which is
consistent with Boris' findings.


Yes, this fixes it, thanks.


What's the policy here -- is there a defined version of the OCaml compiler which
tools/ocaml needs to be able to compile with?


Not to answer this question directly but more as an FYI --- this version 
of ocaml is found on Oracle Linux 6.2, which AFAIK is actively supported.


-boris


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

Re: [Xen-devel] [PATCH v7 04/22] arm/gic: Add a new callback for creating MADT table for Dom0


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

Add a new member in gic_hw_operations which is used to create MADT table
for Dom0.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v7 09/22] arm/p2m: Add helper functions to map memory regions


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

From: Parth Dixit 

Create a helper function for mapping with cached attributes and
read-write range.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v7 10/22] arm/acpi: Map all other tables for Dom0


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

Map all other ACPI tables into Dom0 using 1:1 mappings.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v3 0/7] Enhance PAT init to fix Xorg crashes

2016-03-29 Thread Toshi Kani

On Tue, 2016-03-29 at 12:34 +0200, Ingo Molnar wrote:
> * Toshi Kani  wrote:
> 
> > A Xorg failure on qemu32 was reported as a regression [1] caused by
> > 'commit 9cd25aac1f44 ("x86/mm/pat: Emulate PAT when it is disabled")'.
> > This patch-set fixes the regression.
> > 
> > Negative effects of this regression were two failures [2] in Xorg on
> > QEMU with QEMU CPU model "qemu32" (-cpu qemu32), which were triggered
> > by the fact that its virtual CPU does not support MTRR.
> >  #1. copy_process() failed in the check in reserve_pfn_range()
> >  #2. error path in copy_process() then hit WARN_ON_ONCE in
> >  untrack_pfn().
> > 
> > These negative effects are caused by two separate bugs, but they can be
> > addressed in separate patches.  This patch-set addresses the root
> > cause, a long-standing PAT initialization issue.
> > 
> > Please see the changelog in patch 4/7 for the details of the issue.
> > 
> > - Patch 1-2 make necessary enhancement to PAT for the fix without
> >   breaking Xen.
> > - Patch 3 is cleanup.
> > - Patch 4 fixes the regression.
> > - Patch 5 fixes an MTRR issue related with PAT init.
> > - Patch 6 removes PAT init code from Xen.
> > - Patch 7 adds PAT init to documentation.
> > 
> > [1]: https://lkml.org/lkml/2016/3/3/828
> > [2]: https://lkml.org/lkml/2016/3/4/775
> 
> The changelogs are much improved, I've applied these patches to
> tip:x86/mm, thanks Toshi!

Great! Thanks for all valuable comments!

> > I'd appreciate if someone can test this patch-set on Xen to verify that
> > there is no change in "x86/PAT: Configuration [0-7] .." message in
> > dmesg.
> 
> So I don't have a Xen setup, but hopefully such testing will happen once
> these changes show up in linux-next, tomorrow or so.

I will address if any issue is found in testing.

-Toshi

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

Re: [Xen-devel] XSA-155: _apparently_ missing blktap1 fix (up to 4.5)

>>> On 04.03.16 at 09:21,  wrote:
> In the course of backporting other XSA fixes to very old trees I had
> noticed that the XSA-155 had shrunk to just the change to
> xen/include/public/io/ring.h at some point, which didn't seem right.
> Clearly up to 4.5 the situation of blktap1 is the same as that of
> blktap2, i.e. one would think it also needs to be fixed. However, in
> the course of doing so I stumbled across the code blindly using
> req->id as an array index (which similarly is the case for blktap2).
> That alone would be another security issue, if only the first change
> really addressed one. But it didn't: The rings we're talking about
> here are those interfacing with the kernel module, and it's only the
> kernel module which interfaces with the guest ring.
> 
> Bottom line: No fix is needed to blktap1, and the change to blktap2
> didn't really fix anything either. It merely made things slightly slower
> due to the extra copy operation. (I haven't fully understood the
> purpose of block-log.c yet, but I can't see how it would manage to
> bypass the kernel module and interface directly with the frontend
> in the guest, the more that tdlog_open() sets up its ring using
> shm_open(), implying host local operation. Hence that part of the
> change, which has no blktap1 equivalent, should not be needed
> either.)
> 
> Therefore, Ian, I'd like to request that the blktap2 change not be
> backported to any of the stable trees - only the libvchan one
> should make it there (and the prereq to the blktap2 one, adding
> RING_COPY_REQUEST(), then isn't needed either). Since that
> blktap2 change isn't entirely benign, I think we should even
> consider reverting it from master.

Since, in the course of verifying 4.5.3, you must have agreed to
the analysis above - what about the revert proposal on master
then?

Jan


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

[Xen-devel] [PATCH v2 5/6] x86/time: refactor read_platform_stime()

To fetch the last read from the clocksource which was used to
calculate system_time. In the case of clocksource=tsc we will
use it to set tsc_timestamp.

Signed-off-by: Joao Martins 
Reviewed-by: Andrew Cooper 
---
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

Changes since v1:
 - Add missing spaces between brackets
 - Move plt_stamp_counter to read_platform_stime()
 - Add signature change in time_calibration_std_rendezvous()
---
 xen/arch/x86/time.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 9cadfcb..123aa42 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -568,16 +568,19 @@ static void plt_overflow(void *unused)
 set_timer(&plt_overflow_timer, NOW() + plt_overflow_period);
 }
 
-static s_time_t read_platform_stime(void)
+static s_time_t read_platform_stime(u64 *stamp)
 {
-u64 count;
+u64 plt_stamp_counter, count;
 s_time_t stime;
 
 ASSERT(!local_irq_is_enabled());
 
 spin_lock(&platform_timer_lock);
-count = plt_stamp64 + ((plt_src.read_counter() - plt_stamp) & plt_mask);
+plt_stamp_counter = plt_src.read_counter();
+count = plt_stamp64 + ((plt_stamp_counter - plt_stamp) & plt_mask);
 stime = __read_platform_stime(count);
+if ( stamp )
+*stamp = plt_stamp_counter;
 spin_unlock(&platform_timer_lock);
 
 return stime;
@@ -727,7 +730,7 @@ void cstate_restore_tsc(void)
 if ( boot_cpu_has(X86_FEATURE_NONSTOP_TSC) )
 return;
 
-write_tsc(stime2tsc(read_platform_stime()));
+write_tsc(stime2tsc(read_platform_stime(NULL)));
 }
 
 /***
@@ -1046,7 +1049,7 @@ int cpu_frequency_change(u64 freq)
 
 local_irq_disable();
 /* Platform time /first/, as we may be delayed by platform_timer_lock. */
-t->stime_master_stamp = read_platform_stime();
+t->stime_master_stamp = read_platform_stime(NULL);
 /* TSC-extrapolated time may be bogus after frequency change. */
 /*t->stime_local_stamp = get_s_time();*/
 t->stime_local_stamp = t->stime_master_stamp;
@@ -1364,7 +1367,7 @@ static void time_calibration_tsc_rendezvous(void *_r)
 
 if ( r->master_stime == 0 )
 {
-r->master_stime = read_platform_stime();
+r->master_stime = read_platform_stime(NULL);
 r->master_tsc_stamp = rdtsc();
 }
 atomic_inc(&r->semaphore);
@@ -1409,7 +1412,7 @@ static void time_calibration_std_rendezvous(void *_r)
 {
 while ( atomic_read(&r->semaphore) != (total_cpus - 1) )
 cpu_relax();
-r->master_stime = read_platform_stime();
+r->master_stime = read_platform_stime(NULL);
 mb(); /* write r->master_stime /then/ signal */
 atomic_inc(&r->semaphore);
 }
@@ -1456,7 +1459,7 @@ void init_percpu_time(void)
 
 local_irq_save(flags);
 t->local_tsc_stamp = rdtsc();
-now = read_platform_stime();
+now = read_platform_stime(NULL);
 local_irq_restore(flags);
 
 t->stime_master_stamp = now;
-- 
2.1.4


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

[Xen-devel] [PATCH v2 4/6] x86/time: streamline platform time init on plt_init()

And use to initialize platform time solely for clocksource=tsc,
as opposed to initializing platform overflow timer, which would
only fire in ~180 years (on 2.2 Ghz Broadwell processor).

Signed-off-by: Joao Martins 
Reviewed-by: Andrew Cooper 
---
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

Changes since v1:
 - Remove initialisation to 0.
 - Remove assignment and return mix.
 - Fix the style on plt_overflow_period calculation.

Changes since RFC:
 - Move clocksource_is_tsc variable to this patch.
 - s/10/SECONDS(1)
---
 xen/arch/x86/time.c | 44 
 1 file changed, 36 insertions(+), 8 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 2602dda..9cadfcb 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -434,6 +434,7 @@ uint64_t ns_to_acpi_pm_tick(uint64_t ns)
 /
  * PLATFORM TIMER 4: TSC
  */
+static bool_t clocksource_is_tsc;
 static u64 tsc_freq;
 static unsigned long tsc_max_warp;
 static void tsc_check_reliability(void);
@@ -466,6 +467,8 @@ static int __init init_tsctimer(struct platform_timesource 
*pts)
 }
 
 pts->frequency = tsc_freq;
+clocksource_is_tsc = tsc_reliable;
+
 return tsc_reliable;
 }
 
@@ -516,17 +519,31 @@ static s_time_t __read_platform_stime(u64 platform_time)
 return (stime_platform_stamp + scale_delta(diff, &plt_scale));
 }
 
+static void __plt_init(void)
+{
+u64 count;
+
+ASSERT(spin_is_locked(&platform_timer_lock));
+count = plt_src.read_counter();
+plt_stamp64 += (count - plt_stamp) & plt_mask;
+plt_stamp = count;
+}
+
+static void plt_init(void)
+{
+spin_lock_irq(&platform_timer_lock);
+__plt_init();
+spin_unlock_irq(&platform_timer_lock);
+}
+
 static void plt_overflow(void *unused)
 {
 int i;
-u64 count;
 s_time_t now, plt_now, plt_wrap;
 
 spin_lock_irq(&platform_timer_lock);
 
-count = plt_src.read_counter();
-plt_stamp64 += (count - plt_stamp) & plt_mask;
-plt_stamp = count;
+__plt_init();
 
 now = NOW();
 plt_wrap = __read_platform_stime(plt_stamp64);
@@ -621,11 +638,22 @@ static int __init try_platform_timer(struct 
platform_timesource *pts)
 
 set_time_scale(&plt_scale, pts->frequency);
 
-plt_overflow_period = scale_delta(
-1ull << (pts->counter_bits - 1), &plt_scale);
-init_timer(&plt_overflow_timer, plt_overflow, NULL, 0);
 plt_src = *pts;
-plt_overflow(NULL);
+
+if ( clocksource_is_tsc )
+{
+plt_init();
+}
+else
+{
+plt_overflow_period = scale_delta(
+1ull << (pts->counter_bits - 1), &plt_scale);
+init_timer(&plt_overflow_timer, plt_overflow, NULL, 0);
+plt_overflow(NULL);
+
+printk("Platform timer overflow period is %lu secs\n",
+   plt_overflow_period/SECONDS(1));
+}
 
 platform_timer_stamp = plt_stamp64;
 stime_platform_stamp = NOW();
-- 
2.1.4


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

[Xen-devel] [PATCH v2 1/6] public/xen.h: add flags field to vcpu_time_info

This field has two possible flags (as of latest pvclock ABI
shared with KVM).

flags: bits in this field indicate extended capabilities
coordinated between the guest and the hypervisor.  Specifically
on KVM, availability of specific flags has to be checked in
0x4001 cpuid leaf. On Xen, we don't have that but we can
still check some of the flags after registering the time info
page since a force_update_vcpu_system_time is performed.

Current flags are:

 flag bit   | cpuid bit| meaning
-
|  | time measures taken across
 0  |  24  | multiple cpus are guaranteed to
|  | be monotonic
-
|  | guest vcpu has been paused by
 1  | N/A  | the host
|  |
-

Signed-off-by: Joao Martins 
---
Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 

Changes since v1:
 - flags and pad are both uint8_t.
 - fix indentation with the other fields in the struct.
---
 xen/include/public/xen.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 64ba7ab..b263fe3 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -614,10 +614,14 @@ struct vcpu_time_info {
  */
 uint32_t tsc_to_system_mul;
 int8_t   tsc_shift;
-int8_t   pad1[3];
+uint8_t  flags;
+uint8_t  pad1[2];
 }; /* 32 bytes */
 typedef struct vcpu_time_info vcpu_time_info_t;
 
+#define PVCLOCK_TSC_STABLE_BIT (1 << 0)
+#define PVCLOCK_GUEST_STOPPED  (1 << 1)
+
 struct vcpu_info {
 /*
  * 'evtchn_upcall_pending' is written non-zero by Xen to indicate
-- 
2.1.4


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

[Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource

Introduce support for using TSC as platform time which is the highest
resolution time and most performant to get (~20 nsecs).  Though there
are also several problems associated with its usage, and there isn't a
complete (and architecturally defined) guarantee that all machines
will provide reliable and monotonic TSC across all CPUs, on different
sockets and different P/C states.  I believe Intel to be the only that
can guarantee that. For this reason it's only set when adminstrator
changes "clocksource" boot option to "tsc". Initializing TSC
clocksource requires all CPUs to have the tsc reliability checks
performed. init_xen_time is called before all CPUs are up, and so we
start with HPET at boot time, and switch later to TSC. The switch then
happens on verify_tsc_reliability initcall that is invoked when all
CPUs are up. When attempting to initializing TSC we also check for
time warps and appropriate CPU features i.e.  TSC_RELIABLE,
CONSTANT_TSC and NONSTOP_TSC. And in case none of these conditions are
met, we keep the clocksource that was previously initialized on
init_xen_time.

It is also worth noting that with clocksource=tsc there isn't any
need to synchronise with another clocksource, and I could verify that
great portion the time skew was eliminated and seeing much less time
warps happening. With HPET I used to observe ~500 warps in the period
of 1h of around 27 us, and with TSC down to 50 warps in the same
period having each warp < 100 ns. The warps still exist though but
are only related to cross CPU calibration (being how much it takes to
rendezvous with master), in which a later patch in this series aims to
solve.

Signed-off-by: Joao Martins 
---
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

Changes since v1:
 - s/printk/printk(XENLOG_INFO
 - Remove extra space on inner brackets
 - Add missing space around brackets
 - Defer clocksource TSC initialization when all CPUs are up.

Changes since RFC:
 - Spelling fixes in the commit message.
 - Remove unused clocksource_is_tsc variable and introduce it instead
 on the patch that uses it.
 - Move plt_tsc from second to last in the available clocksources.
---
 xen/arch/x86/time.c | 97 +++--
 1 file changed, 95 insertions(+), 2 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index ed4ed24..2602dda 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -432,6 +432,63 @@ uint64_t ns_to_acpi_pm_tick(uint64_t ns)
 }
 
 /
+ * PLATFORM TIMER 4: TSC
+ */
+static u64 tsc_freq;
+static unsigned long tsc_max_warp;
+static void tsc_check_reliability(void);
+
+static int __init init_tsctimer(struct platform_timesource *pts)
+{
+bool_t tsc_reliable = 0;
+
+tsc_check_reliability();
+
+if ( tsc_max_warp > 0 )
+{
+tsc_reliable = 0;
+printk(XENLOG_INFO "TSC: didn't passed warp test\n");
+}
+else if ( boot_cpu_has(X86_FEATURE_TSC_RELIABLE) ||
+  (boot_cpu_has(X86_FEATURE_CONSTANT_TSC) &&
+   boot_cpu_has(X86_FEATURE_NONSTOP_TSC)) )
+{
+tsc_reliable = 1;
+}
+else if ( boot_cpu_has(X86_FEATURE_CONSTANT_TSC) )
+{
+tsc_reliable = (max_cstate <= 2);
+
+if ( tsc_reliable )
+printk(XENLOG_INFO "TSC: no deep Cstates, deemed reliable\n");
+else
+printk(XENLOG_INFO "TSC: deep Cstates possible, so not 
reliable\n");
+}
+
+pts->frequency = tsc_freq;
+return tsc_reliable;
+}
+
+static u64 read_tsc(void)
+{
+return rdtsc();
+}
+
+static void resume_tsctimer(struct platform_timesource *pts)
+{
+}
+
+static struct platform_timesource __initdata plt_tsc =
+{
+.id = "tsc",
+.name = "TSC",
+.read_counter = read_tsc,
+.counter_bits = 64,
+.init = init_tsctimer,
+.resume = resume_tsctimer,
+};
+
+/
  * GENERIC PLATFORM TIMER INFRASTRUCTURE
  */
 
@@ -533,6 +590,21 @@ static void resume_platform_timer(void)
 plt_stamp = plt_src.read_counter();
 }
 
+static void __init reset_platform_timer(void)
+{
+/* Deactivate any timers running */
+kill_timer(&plt_overflow_timer);
+kill_timer(&calibration_timer);
+
+/* Reset counters and stamps */
+spin_lock_irq(&platform_timer_lock);
+plt_stamp = 0;
+plt_stamp64 = 0;
+platform_timer_stamp = 0;
+stime_platform_stamp = 0;
+spin_unlock_irq(&platform_timer_lock);
+}
+
 static int __init try_platform_timer(struct platform_timesource *pts)
 {
 int rc = -1;
@@ -541,6 +613,10 @@ static int __init try_platform_timer(struct 
platform_timesource *pts)
 if ( rc <= 0 )
 return rc;
 
+/* We have a platform timesource already so reset it */
+if ( plt_src.counter_bits != 0 )
+reset_platform_timer();
+
 plt_mask = (u64)~0ull >> (64 - pts->counter_bits);
 
 set_time_scale(&plt_scale, pts->frequency);
@@ -566,7 +642,9

[Xen-devel] [PATCH v2 0/6] x86/time: PVCLOCK_TSC_STABLE_BIT support

Hey,

This series is the v2 of pvclock TSC series (v1 presented here [0]).

PVCLOCK_TSC_STABLE_BIT is the flag telling the guest that the
vcpu_time_info (pvti) are monotonic as seen by any CPU, a feature
which is currently not supported. As it is (i.e. bindly setting the
flag), we can observe that this property isn't there: a process using
vdso clock_gettime/gettimeofday will observe a significant amount of
warps (i.e. time going backwards) and it's due to 1) time calibration
skew in xen rendezvous algorithm 2) clocksource not in sync with TSC.
These warps are seen more frequently on PV guests (potentially because
vcpu time infos are only updated when guest is in kernel mode, and
perhaps lack of tsc_offset?), and in rare ocasions on HVM guests. It
is worth noting that with guests VCPUs pinned, only PV guests see
these warps. But on HVM guests specifically: such warps only occur
when one of guest VCPUs is pinned to CPU0. This series aims to propose
a solution to that and it's divided as following:

U * Patch 1: Adds the missing flag field to vcpu_time_info.
N * Patch 2: Small refactor around init_platform_time to reuse
initialization code when switching to TSC.
U * Patch 3: Adds a new clocksource based on TSC
R,R* Patch 4, 5: Adjustments for patch 5
U * Patch 5: Implements the PVCLOCK_TSC_STABLE_BIT

[ R := Reviewed-by ;; U := Updated ;; N := New ]

PVCLOCK_TSC_STABLE_BIT is set only when using clocksource=tsc and CPU
hotplug is not meant to be perfomed, and remains optional unless specified
by the admin. nocpuhotplug is the option telling that no cpu hotplug is
to be perfomed which overrides system default behaviour when initializing
TSC i.e. testing max_vcpus and number of present cpus.

The test was running time-warp-test, that constantly calls
clock_gettime/gettimeofday on every CPU. It measures a delta with the
previous returned value and mark a warp if it's negative. I measured
it during periods of 1h and 6h and check how many warps and their
values (alongside the amount of time skew). Measurements/Changelog are
included in individual patches.

Note that most of the testing has been done with Linux 4.4 in which
these warps/skew could be easily observed as vdso would use each vCPU
pvti. Though Linux >= 4.5 changes this behaviour and use only the
vCPU0 pvti though still requiring PVCLOCK_TSC_STABLE_BIT flag
support.

Thanks!
Joao

[0]
http://bugs.xenproject.org/xen/mid/%3c1458231136-13457-1-git-send-email-joao.m.mart...@oracle.com%3E

Joao Martins (6):
public/xen.h: add flags field to vcpu_time_info
x86/time: refactor init_platform_time()
x86/time: implement tsc as clocksource
x86/time: streamline platform time init on plt_init()
x86/time: refactor read_platform_stime()
x86/time: implement PVCLOCK_TSC_STABLE_BIT

xen/arch/x86/time.c | 236 +--
xen/include/public/xen.h | 6 +-
2 files changed, 212 insertions(+), 30 deletions(-)

--
2.1.4

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

[Xen-devel] [PATCH v2 6/6] x86/time: implement PVCLOCK_TSC_STABLE_BIT

When using TSC as clocksource we will solely rely on TSC for updating
vcpu time infos (pvti). Right now, each vCPU takes the tsc_timestamp
at different instants meaning every EPOCH + delta.  This delta is
variable depending on the time the CPU calibrates with CPU 0 (master),
and will likely be different and variable across vCPUS. This means
that each VCPU pvti won't account to its calibration error which could
lead to time going backwards, and allowing a situation where time read
on VCPU B immediately after A being smaller. While this doesn't happen
a lot, I was able to observe (for clocksource=tsc) around 50 times in
an hour having warps of < 100 ns.

This patch proposes relying on host TSC synchronization and
passthrough to the guest, when running on a TSC-safe platform. On
time_calibration we retrieve the platform time in ns and the counter
read by the clocksource that was used to compute system time. We
introduce a new rendezous function which doesn't require
synchronization between master and slave CPUS and just reads
calibration_rendezvous struct and writes it down the stime and stamp
to the cpu_calibration struct to be used later on. We can guarantee that
on a platform with a constant and reliable TSC, that the time read on
vcpu B right after A is bigger independently of the CPU calibration
error. Since pvclock time infos are monotonic as seen by any vCPU set
PVCLOCK_TSC_STABLE_BIT, which then enables usage of VDSO on Linux.
IIUC, this is similar to how it's implemented on KVM.

Note that PVCLOCK_TSC_STABLE_BIT is set only when CPU hotplug isn't
meant to be performed on the host, which will either be when max vcpus
and num_present_cpu are the same or if "nocpuhotplug" command line
parameter is used. This is because a newly hotplugged CPU may not
satisfy the condition of having all TSCs synchronized.

Signed-off-by: Joao Martins 
---
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

Perhaps "cpuhotplugsafe" would be a better name, since potentially
hardware could guarantee TSCs are synchronized on hotplug?

Changes since v1:
 - Change approach to follow Andrew's guideline to
 skip std_rendezvous. And doing so by introducing a nop_rendezvous
 - Change commit message reflecting the change above.
 - Use TSC_STABLE_BIT only if cpu hotplug isn't possible.
 - Add command line option to override it if no cpu hotplug is
 intended.
---
 xen/arch/x86/time.c | 43 +++
 1 file changed, 43 insertions(+)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 123aa42..1dcd4af 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -43,6 +43,10 @@
 static char __initdata opt_clocksource[10];
 string_param("clocksource", opt_clocksource);
 
+/* opt_nocpuhotplug: Set if CPU hotplug isn't meant to be used */
+static bool_t __initdata opt_nocpuhotplug;
+boolean_param("nocpuhotplug", opt_nocpuhotplug);
+
 unsigned long __read_mostly cpu_khz;  /* CPU clock frequency in kHz. */
 DEFINE_SPINLOCK(rtc_lock);
 unsigned long pit0_ticks;
@@ -435,6 +439,7 @@ uint64_t ns_to_acpi_pm_tick(uint64_t ns)
  * PLATFORM TIMER 4: TSC
  */
 static bool_t clocksource_is_tsc;
+static bool_t use_tsc_stable_bit;
 static u64 tsc_freq;
 static unsigned long tsc_max_warp;
 static void tsc_check_reliability(void);
@@ -468,6 +473,11 @@ static int __init init_tsctimer(struct platform_timesource 
*pts)
 
 pts->frequency = tsc_freq;
 clocksource_is_tsc = tsc_reliable;
+use_tsc_stable_bit = clocksource_is_tsc &&
+((nr_cpu_ids == num_present_cpus()) || opt_nocpuhotplug);
+
+if ( clocksource_is_tsc && !use_tsc_stable_bit )
+printk(XENLOG_INFO "TSC: CPU Hotplug intended, not setting stable 
bit\n");
 
 return tsc_reliable;
 }
@@ -950,6 +960,8 @@ static void __update_vcpu_system_time(struct vcpu *v, int 
force)
 
 _u.tsc_timestamp = tsc_stamp;
 _u.system_time   = t->stime_local_stamp;
+if ( use_tsc_stable_bit )
+_u.flags|= PVCLOCK_TSC_STABLE_BIT;
 
 if ( is_hvm_domain(d) )
 _u.tsc_timestamp += v->arch.hvm_vcpu.cache_tsc_offset;
@@ -1431,6 +1443,22 @@ static void time_calibration_std_rendezvous(void *_r)
 raise_softirq(TIME_CALIBRATE_SOFTIRQ);
 }
 
+/*
+ * Rendezvous function used when clocksource is TSC and
+ * no CPU hotplug will be performed.
+ */
+static void time_calibration_nop_rendezvous(void *_r)
+{
+struct cpu_calibration *c = &this_cpu(cpu_calibration);
+struct calibration_rendezvous *r = _r;
+
+c->local_tsc_stamp = r->master_tsc_stamp;
+c->stime_local_stamp = get_s_time();
+c->stime_master_stamp = r->master_stime;
+
+raise_softirq(TIME_CALIBRATE_SOFTIRQ);
+}
+
 static void (*time_calibration_rendezvous_fn)(void *) =
 time_calibration_std_rendezvous;
 
@@ -1440,6 +1468,13 @@ static void time_calibration(void *unused)
 .semaphore = ATOMIC_INIT(0)
 };
 
+if ( use_tsc_stable_bit )
+{
+local_irq_disable();
+r.master_stime = read_platform_stime(&r.master_tsc_st

[Xen-devel] [PATCH v2 2/6] x86/time: refactor init_platform_time()

And accomodate platform time source initialization in
try_platform_time(). This is a preparatory patch for deferring
TSC clocksource initialization to the stage where all CPUS are
up (verify_tsc_reliability init call).

Signed-off-by: Joao Martins 
---
Cc: Keir Fraser 
Cc: Jan Beulich 
Cc: Andrew Cooper 

New in v2.
---
 xen/arch/x86/time.c | 41 ++---
 1 file changed, 26 insertions(+), 15 deletions(-)

diff --git a/xen/arch/x86/time.c b/xen/arch/x86/time.c
index 687e39b..ed4ed24 100644
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -533,6 +533,30 @@ static void resume_platform_timer(void)
 plt_stamp = plt_src.read_counter();
 }
 
+static int __init try_platform_timer(struct platform_timesource *pts)
+{
+int rc = -1;
+
+rc = pts->init(pts);
+if ( rc <= 0 )
+return rc;
+
+plt_mask = (u64)~0ull >> (64 - pts->counter_bits);
+
+set_time_scale(&plt_scale, pts->frequency);
+
+plt_overflow_period = scale_delta(
+1ull << (pts->counter_bits - 1), &plt_scale);
+init_timer(&plt_overflow_timer, plt_overflow, NULL, 0);
+plt_src = *pts;
+plt_overflow(NULL);
+
+platform_timer_stamp = plt_stamp64;
+stime_platform_stamp = NOW();
+
+return rc;
+}
+
 static void __init init_platform_timer(void)
 {
 static struct platform_timesource * __initdata plt_timers[] = {
@@ -549,7 +573,7 @@ static void __init init_platform_timer(void)
 pts = plt_timers[i];
 if ( !strcmp(opt_clocksource, pts->id) )
 {
-rc = pts->init(pts);
+rc = try_platform_timer(pts);
 break;
 }
 }
@@ -565,26 +589,13 @@ static void __init init_platform_timer(void)
 for ( i = 0; i < ARRAY_SIZE(plt_timers); i++ )
 {
 pts = plt_timers[i];
-if ( (rc = pts->init(pts)) > 0 )
+if ( (rc = try_platform_timer(pts)) > 0 )
 break;
 }
 }
 
 BUG_ON(rc <= 0);
 
-plt_mask = (u64)~0ull >> (64 - pts->counter_bits);
-
-set_time_scale(&plt_scale, pts->frequency);
-
-plt_overflow_period = scale_delta(
-1ull << (pts->counter_bits-1), &plt_scale);
-init_timer(&plt_overflow_timer, plt_overflow, NULL, 0);
-plt_src = *pts;
-plt_overflow(NULL);
-
-platform_timer_stamp = plt_stamp64;
-stime_platform_stamp = NOW();
-
 printk("Platform timer is %s %s\n",
freq_string(pts->frequency), pts->name);
 }
-- 
2.1.4


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

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 25/03/16 08:54, Juergen Gross wrote:
> On 24/03/16 12:38, George Dunlap wrote:
>> On Thu, Mar 24, 2016 at 11:23 AM, Andrew Cooper
>>  wrote:
>>> On 24/03/16 10:58, Juergen Gross wrote:
 I've searched a little bit in git history in order to understand why
 xen-detect has been invented and/or has all the options which clearly
 are meant to be used in scripts.

 The last large modification was done in 2009 and I think Konrad is to
 blame here. ;-)

 It was meant to be used in early boot sequence to autoload the needed
 modules (frontends/backends) in case of running on top of Xen. I believe
 this usage isn't needed any longer as the dom0 case is handled
 differently and the needed frontends are loaded automatically on demand.

 So this means we can drop all the options of xen-detect, as they serve
 no purpose today.

 Next question is whether the remaining functionality warrants keeping
 xen-detect, and how the information it is presenting can be obtained.

 If we want to keep it, I can think of following solutions:
 - new kernel ABI (as suggested, David doesn't like it)
 - follow the route it is taking today, information is unreliable
 - parsing of the boot messages (e.g. via an init script into a file)
   and printing that information (would work, but is a little bit hacky)

 Thoughts?
>>>
>>> I don't recommend keeping xen-detect.  It is unreliable, and we will
>>> always be playing catchup.
>>>
>>> Parsing? that's not a little hacky...  The ABI is definitely a better
>>> solution.
>>>
>>> As for the ABI,
>>>
>>> [root@fusebot ~]# find /sys/hypervisor/
>>> /sys/hypervisor/
>>> /sys/hypervisor/type
>>> /sys/hypervisor/uuid
>>> /sys/hypervisor/compilation
>>> /sys/hypervisor/compilation/compiled_by
>>> /sys/hypervisor/compilation/compile_date
>>> /sys/hypervisor/compilation/compiler
>>> /sys/hypervisor/properties
>>> /sys/hypervisor/properties/pagesize
>>> /sys/hypervisor/properties/changeset
>>> /sys/hypervisor/properties/virtual_start
>>> /sys/hypervisor/properties/features
>>> /sys/hypervisor/properties/capabilities
>>> /sys/hypervisor/version
>>> /sys/hypervisor/version/extra
>>> /sys/hypervisor/version/major
>>> /sys/hypervisor/version/minor
>>>
>>> A /sys/hypervisor/guest_type property would fit nicely alongside uuid,
>>> and is applicable to all hypervisors, not just Xen.
>>
>> FWIW this sounds reasonable to me.
> 
> Another sum up:
> 
> - common sense seems to be the current way xen-detect is trying to
>   guess the guest type is unreliable and should be dropped (Jan
>   would like to keep it, but I guess he just wants the information
>   to be available - is this correct, Jan?)
> - the command line options of xen-detect are not necessary any more
> - the information which guest type we are should be obtainable from
>   inside the guest, the consumer of this information should be humans
>   only
> - the OS already knows in which mode it is running, so it should be the
>   kernel to present that information (David disagrees here: he isn't
>   convinced this information is it worth to add another kernel
>   interface)
> 
> As there is no real hurry to have this topic settled I'd suggest we just
> discuss it at the Hackathon (all involved in the discussion so far but
> George will be there). What do you think?

I just signed up, so I'll be there too. :-)

So if we decide not to add a /sys/hypervisor/guest_type node, I guess
we'll probably be deleting this anyway.  The next question is, if we
*do* add such a node, will we replace xen-detect with a program that
simply reports the value of this node?  Or are we planning on deleting
it either way?

If we're planning on deleting it either way, I'd be in favor of deleting
it now, so that it can be gone from 4.7.

 -George

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

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 29/03/16 15:54, George Dunlap wrote:
> On 25/03/16 08:54, Juergen Gross wrote:
>> On 24/03/16 12:38, George Dunlap wrote:
>>> On Thu, Mar 24, 2016 at 11:23 AM, Andrew Cooper
>>>  wrote:
 On 24/03/16 10:58, Juergen Gross wrote:
> I've searched a little bit in git history in order to understand why
> xen-detect has been invented and/or has all the options which clearly
> are meant to be used in scripts.
>
> The last large modification was done in 2009 and I think Konrad is to
> blame here. ;-)
>
> It was meant to be used in early boot sequence to autoload the needed
> modules (frontends/backends) in case of running on top of Xen. I believe
> this usage isn't needed any longer as the dom0 case is handled
> differently and the needed frontends are loaded automatically on demand.
>
> So this means we can drop all the options of xen-detect, as they serve
> no purpose today.
>
> Next question is whether the remaining functionality warrants keeping
> xen-detect, and how the information it is presenting can be obtained.
>
> If we want to keep it, I can think of following solutions:
> - new kernel ABI (as suggested, David doesn't like it)
> - follow the route it is taking today, information is unreliable
> - parsing of the boot messages (e.g. via an init script into a file)
>   and printing that information (would work, but is a little bit hacky)
>
> Thoughts?

 I don't recommend keeping xen-detect.  It is unreliable, and we will
 always be playing catchup.

 Parsing? that's not a little hacky...  The ABI is definitely a better
 solution.

 As for the ABI,

 [root@fusebot ~]# find /sys/hypervisor/
 /sys/hypervisor/
 /sys/hypervisor/type
 /sys/hypervisor/uuid
 /sys/hypervisor/compilation
 /sys/hypervisor/compilation/compiled_by
 /sys/hypervisor/compilation/compile_date
 /sys/hypervisor/compilation/compiler
 /sys/hypervisor/properties
 /sys/hypervisor/properties/pagesize
 /sys/hypervisor/properties/changeset
 /sys/hypervisor/properties/virtual_start
 /sys/hypervisor/properties/features
 /sys/hypervisor/properties/capabilities
 /sys/hypervisor/version
 /sys/hypervisor/version/extra
 /sys/hypervisor/version/major
 /sys/hypervisor/version/minor

 A /sys/hypervisor/guest_type property would fit nicely alongside uuid,
 and is applicable to all hypervisors, not just Xen.
>>>
>>> FWIW this sounds reasonable to me.
>>
>> Another sum up:
>>
>> - common sense seems to be the current way xen-detect is trying to
>>   guess the guest type is unreliable and should be dropped (Jan
>>   would like to keep it, but I guess he just wants the information
>>   to be available - is this correct, Jan?)
>> - the command line options of xen-detect are not necessary any more
>> - the information which guest type we are should be obtainable from
>>   inside the guest, the consumer of this information should be humans
>>   only
>> - the OS already knows in which mode it is running, so it should be the
>>   kernel to present that information (David disagrees here: he isn't
>>   convinced this information is it worth to add another kernel
>>   interface)
>>
>> As there is no real hurry to have this topic settled I'd suggest we just
>> discuss it at the Hackathon (all involved in the discussion so far but
>> George will be there). What do you think?
> 
> I just signed up, so I'll be there too. :-)
> 
> So if we decide not to add a /sys/hypervisor/guest_type node, I guess
> we'll probably be deleting this anyway.  The next question is, if we
> *do* add such a node, will we replace xen-detect with a program that
> simply reports the value of this node?  Or are we planning on deleting
> it either way?

+1 for deleting it. Installing a program which is just doing a "cat" of
a file is nonsense IMO.

> 
> If we're planning on deleting it either way, I'd be in favor of deleting
> it now, so that it can be gone from 4.7.

+1


Juergen


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

Re: [Xen-devel] [PATCH] tools: fix xen-detect to correctly identify domU type

On 29/03/16 15:00, Juergen Gross wrote:
> On 29/03/16 15:54, George Dunlap wrote:
>> On 25/03/16 08:54, Juergen Gross wrote:
>>> On 24/03/16 12:38, George Dunlap wrote:
 On Thu, Mar 24, 2016 at 11:23 AM, Andrew Cooper
  wrote:
> On 24/03/16 10:58, Juergen Gross wrote:
>> I've searched a little bit in git history in order to understand why
>> xen-detect has been invented and/or has all the options which clearly
>> are meant to be used in scripts.
>>
>> The last large modification was done in 2009 and I think Konrad is to
>> blame here. ;-)
>>
>> It was meant to be used in early boot sequence to autoload the needed
>> modules (frontends/backends) in case of running on top of Xen. I believe
>> this usage isn't needed any longer as the dom0 case is handled
>> differently and the needed frontends are loaded automatically on demand.
>>
>> So this means we can drop all the options of xen-detect, as they serve
>> no purpose today.
>>
>> Next question is whether the remaining functionality warrants keeping
>> xen-detect, and how the information it is presenting can be obtained.
>>
>> If we want to keep it, I can think of following solutions:
>> - new kernel ABI (as suggested, David doesn't like it)
>> - follow the route it is taking today, information is unreliable
>> - parsing of the boot messages (e.g. via an init script into a file)
>>   and printing that information (would work, but is a little bit hacky)
>>
>> Thoughts?
>
> I don't recommend keeping xen-detect.  It is unreliable, and we will
> always be playing catchup.
>
> Parsing? that's not a little hacky...  The ABI is definitely a better
> solution.
>
> As for the ABI,
>
> [root@fusebot ~]# find /sys/hypervisor/
> /sys/hypervisor/
> /sys/hypervisor/type
> /sys/hypervisor/uuid
> /sys/hypervisor/compilation
> /sys/hypervisor/compilation/compiled_by
> /sys/hypervisor/compilation/compile_date
> /sys/hypervisor/compilation/compiler
> /sys/hypervisor/properties
> /sys/hypervisor/properties/pagesize
> /sys/hypervisor/properties/changeset
> /sys/hypervisor/properties/virtual_start
> /sys/hypervisor/properties/features
> /sys/hypervisor/properties/capabilities
> /sys/hypervisor/version
> /sys/hypervisor/version/extra
> /sys/hypervisor/version/major
> /sys/hypervisor/version/minor
>
> A /sys/hypervisor/guest_type property would fit nicely alongside uuid,
> and is applicable to all hypervisors, not just Xen.

 FWIW this sounds reasonable to me.
>>>
>>> Another sum up:
>>>
>>> - common sense seems to be the current way xen-detect is trying to
>>>   guess the guest type is unreliable and should be dropped (Jan
>>>   would like to keep it, but I guess he just wants the information
>>>   to be available - is this correct, Jan?)
>>> - the command line options of xen-detect are not necessary any more
>>> - the information which guest type we are should be obtainable from
>>>   inside the guest, the consumer of this information should be humans
>>>   only
>>> - the OS already knows in which mode it is running, so it should be the
>>>   kernel to present that information (David disagrees here: he isn't
>>>   convinced this information is it worth to add another kernel
>>>   interface)
>>>
>>> As there is no real hurry to have this topic settled I'd suggest we just
>>> discuss it at the Hackathon (all involved in the discussion so far but
>>> George will be there). What do you think?
>>
>> I just signed up, so I'll be there too. :-)
>>
>> So if we decide not to add a /sys/hypervisor/guest_type node, I guess
>> we'll probably be deleting this anyway.  The next question is, if we
>> *do* add such a node, will we replace xen-detect with a program that
>> simply reports the value of this node?  Or are we planning on deleting
>> it either way?
> 
> +1 for deleting it. Installing a program which is just doing a "cat" of
> a file is nonsense IMO.

Well running "xen-detect" is certainly a lot better interface than "cat
/sys/hypervisor/guest_type".  An argument could also be made that
maintaining the existing interface is worthwhile -- all the scripts that
currently run xen-detect would continue to operate as they always had
been, rather than breaking and needing to be re-written.

Unfortunately it's a bit hard to know how valuable this would actually be.

 -George

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

Re: [Xen-devel] 4.4: INFO: rcu_sched self-detected stall on CPU

2016-03-29 Thread Boris Ostrovsky


On 03/29/2016 04:56 AM, Steven Haigh wrote:


Interestingly enough, this just happened again - but on a different
virtual machine. I'm starting to wonder if this may have something to do
with the uptime of the machine - as the system that this seems to happen
to is always different.

Destroying it and monitoring it again has so far come up blank.

I've thrown the latest lot of kernel messages here:
 http://paste.fedoraproject.org/346802/59241532


Would be good to see full console log. The one that you posted starts 
with an error so I wonder what was before that.


Have you tried this on bare metal, BTW? And you said this is only 
observed on 4.4, not 4.5, right?




Interestingly, around the same time, /var/log/messages on the remote
syslog server shows:
Mar 29 17:00:01 zeus systemd: Created slice user-0.slice.
Mar 29 17:00:01 zeus systemd: Starting user-0.slice.
Mar 29 17:00:01 zeus systemd: Started Session 1567 of user root.
Mar 29 17:00:01 zeus systemd: Starting Session 1567 of user root.
Mar 29 17:00:01 zeus systemd: Removed slice user-0.slice.
Mar 29 17:00:01 zeus systemd: Stopping user-0.slice.
Mar 29 17:01:01 zeus systemd: Created slice user-0.slice.
Mar 29 17:01:01 zeus systemd: Starting user-0.slice.
Mar 29 17:01:01 zeus systemd: Started Session 1568 of user root.
Mar 29 17:01:01 zeus systemd: Starting Session 1568 of user root.
Mar 29 17:08:34 zeus ntpdate[18569]: adjust time server 203.56.246.94
offset -0.002247 sec
Mar 29 17:08:34 zeus systemd: Removed slice user-0.slice.
Mar 29 17:08:34 zeus systemd: Stopping user-0.slice.
Mar 29 17:10:01 zeus systemd: Created slice user-0.slice.
Mar 29 17:10:01 zeus systemd: Starting user-0.slice.
Mar 29 17:10:01 zeus systemd: Started Session 1569 of user root.
Mar 29 17:10:01 zeus systemd: Starting Session 1569 of user root.
Mar 29 17:10:01 zeus systemd: Removed slice user-0.slice.
Mar 29 17:10:01 zeus systemd: Stopping user-0.slice.
Mar 29 17:20:01 zeus systemd: Created slice user-0.slice.
Mar 29 17:20:01 zeus systemd: Starting user-0.slice.
Mar 29 17:20:01 zeus systemd: Started Session 1570 of user root.
Mar 29 17:20:01 zeus systemd: Starting Session 1570 of user root.
Mar 29 17:20:01 zeus systemd: Removed slice user-0.slice.
Mar 29 17:20:01 zeus systemd: Stopping user-0.slice.
Mar 29 17:30:55 zeus systemd: systemd-logind.service watchdog timeout
(limit 1min)!
Mar 29 17:32:25 zeus systemd: systemd-logind.service stop-sigabrt timed
out. Terminating.
Mar 29 17:33:56 zeus systemd: systemd-logind.service stop-sigterm timed
out. Killing.
Mar 29 17:35:26 zeus systemd: systemd-logind.service still around after
SIGKILL. Ignoring.
Mar 29 17:36:56 zeus systemd: systemd-logind.service stop-final-sigterm
timed out. Killing.
Mar 29 17:38:26 zeus systemd: systemd-logind.service still around after
final SIGKILL. Entering failed mode.
Mar 29 17:38:26 zeus systemd: Unit systemd-logind.service entered failed
state.
Mar 29 17:38:26 zeus systemd: systemd-logind.service failed.



These may be result of your system not feeling well, which is not 
surprising.


-boris

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

Re: [Xen-devel] [PATCH v8 3/3] VT-d: Fix vt-d Device-TLB flush timeout issue

2016-03-29 Thread Konrad Rzeszutek Wilk

On Tue, Mar 29, 2016 at 01:32:02AM +, Xu, Quan wrote:
> On March 28, 2016 10:11pm, Konrad Rzeszutek Wilk  
> wrote:
> > >
> > > > > +list_del(&pdev->domain_list);
> > > > > +pdev->domain = NULL;
> > > > > +pci_hide_existing_device(pdev);
> > > > > +break;
> > > > > +}
> > > > > +}
> > > > > +
> > > > > +pcidevs_unlock();
> > > > > +
> > > > > +if ( !is_hardware_domain(d) )
> > > > > +domain_crash(d);
> > > >
> > > > The description said something about 'just throw out a warning' (if
> > > > the domain owning it is a hardware domain). That seems to be missing?
> > > >
> > > >
> > >
> > > The warning is in the call path, in queue_invalidate_wait():
> > >   """Queue invalidate wait descriptor timed out."""
> > 
> > Aah, right.
> > >
> > > Then, does it make sense?
> > 
> > Yes. I would recommend you modify the commit description so that clueless
> > folks like me can see it. You could modify the commit description to say:
> > 
> > "just throw out a warning (done in queue_invalidate_wait)."
> > 
> > 
> 
> Then, based on Dario/your suggestion, the changelog could be:
> """
> VT-d: Fix vt-d Device-TLB flush timeout issue
> 
> If Device-TLB flush timed out, we would hide the target ATS device and crash 
> the domain owning this ATS device.
> If impacted domain is hardware domain, just throw out a warning (done in 
> queue_invalidate_wait).
> 
> By hiding the device, we make sure it can't be assigned to any domain any 
> longer.
> """

s/to any domain any longer./to any domain any longer (see device_assigned)./


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

Re: [Xen-devel] [PATCH v2 3/3] libxl: add domain config parameter to force start of qemu

2016-03-29 Thread Konrad Rzeszutek Wilk

On Tue, Mar 29, 2016 at 06:44:32AM +0200, Juergen Gross wrote:
> On 28/03/16 16:50, Konrad Rzeszutek Wilk wrote:
> > On Tue, Mar 22, 2016 at 08:29:23AM +0100, Juergen Gross wrote:
> >> Today the device model (qemu) is started for a pv domain only in case
> >> a device requiring qemu is specified in the domain configuration
> >> (qdisk, vfb, channel). If there is no such device the device model
> >> isn't started and hence it is possible to add such a device to the
> >> domain later.
> >>
> >> Add a domain configuration parameter to specify the device model is
> >> to be started in any case. This will enable adding devices with a
> >> qemu based backend later.
> > 
> > .. s/devices/PV devices/
> > 
> > As surely PV guests can't use emulated devices. Or could they? That
> > would be quite interesting in a not kind of fun way.
> 
> Would require some work.
> 
> > 
> >>
> >> While the optimal solution would be to start the device model
> >> automatically when needed this would require some major rework of
> >> libxl at multiple places.
> > 
> > But you are not using this now (late start of QEMU), so why this patch?
> 
> This was the reason for the patch: start the device model early in order
> to have it running in case it would be needed later.


OK. However I am missing something here. My understanding is that the
QEMU Xen PV USB backend is not in the code-base. So why do this if QEMU
won't even support this?

Would it make more sense to wait until QEMU has this support, then
have this patch, or work on making libxl be able to start QEMU later
(during the time QEMU gains the XEn PV USB backend)?

> 
> Juergen

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

Re: [Xen-devel] [PATCH v2 2/3] libxl: add new pvusb backend "qusb" provided by qemu

On 29/03/16 16:24, Konrad Rzeszutek Wilk wrote:
 +static int usbback_is_loaded(libxl__gc *gc)
 +{
 +int r;
 +struct stat st;
 +
 +r = lstat(SYSFS_USBBACK_DRIVER, &st);
 +
 +if (r == 0)
 +return 1;
 +if (r < 0 && errno == ENOENT)
 +return 0;
>>>
>>> I believe the CODING STYLE in libxl asks for you to use { } for these
>>> ones.
>>
>> No, it doesn't:
>>
>> Quote from tools/libxl/CODING_STYLE:
>>
>> 5. Block structure
>>
>> Every indented statement is braced apart from blocks that contain just
>> one statement.
> 
> You are right. I am so used to 'if (..) else'!
>>
>>>
 +LOGE(ERROR, "Accessing %s", SYSFS_USBBACK_DRIVER);
>>>
>>> Why is this an error?
>>
>> What else? We can't determine whether the driver is loaded or not.
>> ENOENT is tested above, so it must be something weird.
> 
> Or it could be EPERM.

Which is weird in this case. :-)

>>
>>>
 +return -1;
> 
> Which results in the code assuming (the caller of this function)
> it is an kernel driver. Is that OK? Or should we bail out completly?

Have a look in V4 of the patches. :-)


Juergen

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

Re: [Xen-devel] [PATCH v2 3/3] libxl: add domain config parameter to force start of qemu

On 29/03/16 16:27, Konrad Rzeszutek Wilk wrote:
> On Tue, Mar 29, 2016 at 06:44:32AM +0200, Juergen Gross wrote:
>> On 28/03/16 16:50, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Mar 22, 2016 at 08:29:23AM +0100, Juergen Gross wrote:
 Today the device model (qemu) is started for a pv domain only in case
 a device requiring qemu is specified in the domain configuration
 (qdisk, vfb, channel). If there is no such device the device model
 isn't started and hence it is possible to add such a device to the
 domain later.

 Add a domain configuration parameter to specify the device model is
 to be started in any case. This will enable adding devices with a
 qemu based backend later.
>>>
>>> .. s/devices/PV devices/
>>>
>>> As surely PV guests can't use emulated devices. Or could they? That
>>> would be quite interesting in a not kind of fun way.
>>
>> Would require some work.
>>
>>>

 While the optimal solution would be to start the device model
 automatically when needed this would require some major rework of
 libxl at multiple places.
>>>
>>> But you are not using this now (late start of QEMU), so why this patch?
>>
>> This was the reason for the patch: start the device model early in order
>> to have it running in case it would be needed later.
> 
> 
> OK. However I am missing something here. My understanding is that the
> QEMU Xen PV USB backend is not in the code-base. So why do this if QEMU
> won't even support this?
> 
> Would it make more sense to wait until QEMU has this support, then
> have this patch, or work on making libxl be able to start QEMU later
> (during the time QEMU gains the XEn PV USB backend)?

The qemu patches are sent already. I hope they are being accepted
rather soon.

I'm planning to add support for starting qemu as needed when 4.7 is
out.


Juergen

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

Re: [Xen-devel] [PATCH v2 2/3] libxl: add new pvusb backend "qusb" provided by qemu

2016-03-29 Thread Konrad Rzeszutek Wilk

> >> +static int usbback_is_loaded(libxl__gc *gc)
> >> +{
> >> +int r;
> >> +struct stat st;
> >> +
> >> +r = lstat(SYSFS_USBBACK_DRIVER, &st);
> >> +
> >> +if (r == 0)
> >> +return 1;
> >> +if (r < 0 && errno == ENOENT)
> >> +return 0;
> > 
> > I believe the CODING STYLE in libxl asks for you to use { } for these
> > ones.
> 
> No, it doesn't:
> 
> Quote from tools/libxl/CODING_STYLE:
> 
> 5. Block structure
> 
> Every indented statement is braced apart from blocks that contain just
> one statement.

You are right. I am so used to 'if (..) else'!
> 
> > 
> >> +LOGE(ERROR, "Accessing %s", SYSFS_USBBACK_DRIVER);
> > 
> > Why is this an error?
> 
> What else? We can't determine whether the driver is loaded or not.
> ENOENT is tested above, so it must be something weird.

Or it could be EPERM.
> 
> > 
> >> +return -1;

Which results in the code assuming (the caller of this function)
it is an kernel driver. Is that OK? Or should we bail out completly?

> >> +}
> >> +
> > 
> > Otherwise looks OK to me.
> 
> Thanks,
> 
> Juergen
> 

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

Re: [Xen-devel] [PATCH v8 3/3] VT-d: Fix vt-d Device-TLB flush timeout issue

2016-03-29 Thread Xu, Quan

On March 29, 2016 10:21pm, Konrad Rzeszutek Wilk  wrote:
> On Tue, Mar 29, 2016 at 01:32:02AM +, Xu, Quan wrote:
> > On March 28, 2016 10:11pm, Konrad Rzeszutek Wilk
>  wrote:
> > > >
> > > > > > +list_del(&pdev->domain_list);
> > > > > > +pdev->domain = NULL;
> > > > > > +pci_hide_existing_device(pdev);
> > > > > > +break;
> > > > > > +}
> > > > > > +}
> > > > > > +
> > > > > > +pcidevs_unlock();
> > > > > > +
> > > > > > +if ( !is_hardware_domain(d) )
> > > > > > +domain_crash(d);
> > > > >
> > > > > The description said something about 'just throw out a warning'
> > > > > (if the domain owning it is a hardware domain). That seems to be
> missing?
> > > > >
> > > > >
> > > >
> > > > The warning is in the call path, in queue_invalidate_wait():
> > > >   """Queue invalidate wait descriptor timed out."""
> > >
> > > Aah, right.
> > > >
> > > > Then, does it make sense?
> > >
> > > Yes. I would recommend you modify the commit description so that
> > > clueless folks like me can see it. You could modify the commit 
> > > description to
> say:
> > >
> > > "just throw out a warning (done in queue_invalidate_wait)."
> > >
> > >
> >
> > Then, based on Dario/your suggestion, the changelog could be:
> > """
> > VT-d: Fix vt-d Device-TLB flush timeout issue
> >
> > If Device-TLB flush timed out, we would hide the target ATS device and crash
> the domain owning this ATS device.
> > If impacted domain is hardware domain, just throw out a warning (done in
> queue_invalidate_wait).
> >
> > By hiding the device, we make sure it can't be assigned to any domain any
> longer.
> > """
> 
> s/to any domain any longer./to any domain any longer (see device_assigned)./
> 
Got it, thanks.

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

Re: [Xen-devel] [PATCH V6 1/2] x86/xsaves: calculate the comp_offsets base on xcomp_bv

>>> On 24.03.16 at 09:29,  wrote:
>  static void *get_xsave_addr(struct xsave_struct *xsave,
> -unsigned int xfeature_idx)
> +const uint16_t *comp_offsets,
> +unsigned int xfeature_idx)
>  {
>  if ( !((1ul << xfeature_idx) & xsave->xsave_hdr.xstate_bv) )
>  return NULL;

While not a problem in this patch, I think this being at least
questionable now becomes more obvious: With XSAVEC and
XSAVES this field may have clear bits just because the
component was in init state. Yet I don't think this should be
fixed here - instead the consumer(s) should better deal with
NULL coming back here (i.e. expand_xsave_states() should
probably memset() the area in an "else" to the if() leading to
memcpy(), whereas compress_xsave_states() is fine as is).

That's a 3rd patch, though.

> +return (void *)xsave + (xsave_area_compressed(xsave) ?
> +comp_offsets[xfeature_idx] :
> +xstate_offsets[xfeature_idx]);

This function doesn't ever get called when
!xsave_area_compressed(xsave), so I don't really see why this
conditional expression ever got added. Yet another follow-up
patch I would say.

The patch here looks okay to me now.

Jan

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

[Xen-devel] unsub

2016-03-29 Thread 贺超


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

Re: [Xen-devel] [PATCH v3 0/7] Enhance PAT init to fix Xorg crashes

2016-03-29 Thread Boris Ostrovsky


On 03/29/2016 10:19 AM, Toshi Kani wrote:

On Tue, 2016-03-29 at 12:34 +0200, Ingo Molnar wrote:


I'd appreciate if someone can test this patch-set on Xen to verify that
there is no change in "x86/PAT: Configuration [0-7] .." message in
dmesg.

So I don't have a Xen setup, but hopefully such testing will happen once
these changes show up in linux-next, tomorrow or so.

I will address if any issue is found in testing.


I ran a subset of out nightly test. Nobody died.

So this all looks good. (It actually may have also fixed another bug 
that was reported recently by Olaf, copied here)


-boris

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

Re: [Xen-devel] [PATCH v7 12/22] arm/acpi: Prepare EFI memory descriptor for Dom0


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

Create EFI memory descriptors to tell Dom0 the RAM region information,
ACPI table regions and EFI tables reserved regions.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 

Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v7 11/22] arm/acpi: Prepare EFI system table for Dom0


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

Prepare EFI system table for Dom0 to describe the information of UEFI.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

[Xen-devel] [xen-unstable-smoke test] 87883: regressions - FAIL

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64   5 xen-build fail REGR. vs. 87376

Tests which did not succeed, but are not blocking:
 build-amd64-libvirt   1 build-check(1)   blocked  n/a
 test-amd64-amd64-libvirt  1 build-check(1)   blocked  n/a
 test-amd64-amd64-xl-qemuu-debianhvm-i386  1 build-check(1) blocked n/a
 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  a43f1e9b9d44eda4dd0338904ab422b4542bd031
baseline version:
 xen  04119085f5a2a135e5161535b8821e1aa0d7db8a

Last test of basis87376  2016-03-25 23:21:00 Z3 days
Testing same since87883  2016-03-29 13:02:02 Z0 days1 attempts


People who touched revisions under test:
  Anthony PERARD 
  Jan Beulich 
  Paul Durrant 
  Shannon Zhao 
  Stefano Stabellini 

jobs:
 build-amd64  fail
 build-armhf  pass
 build-amd64-libvirt  blocked 
 test-armhf-armhf-xl  pass
 test-amd64-amd64-xl-qemuu-debianhvm-i386 blocked 
 test-amd64-amd64-libvirt blocked 



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

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

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

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


Not pushing.


commit a43f1e9b9d44eda4dd0338904ab422b4542bd031
Author: Shannon Zhao 
Date:   Tue Mar 29 14:26:57 2016 +0200

hvm/params: add a new delivery type for event-channel in 
HVM_PARAM_CALLBACK_IRQ

This new delivery type which is for ARM shares the same value with
HVM_PARAM_CALLBACK_TYPE_VECTOR which is for x86.

val[15:8] is flag: val[7:0] is a PPI.
To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and
bit 9 stands the interrupt polarity is active low(1) or high(0).

Signed-off-by: Shannon Zhao 
Acked-by: Jan Beulich 

commit b93687291574ee64b8244e15455a71d663787962
Author: Paul Durrant 
Date:   Tue Mar 29 14:26:33 2016 +0200

x86/hvm/viridian: fix APIC assist page leak

Commit a6f2cdb6 "keep APIC assist page mapped..." introduced a page
leak because it relied on viridian_vcpu_deinit() always being called
to release the page mapping. This does not happen in the case a normal
domain shutdown.

This patch fixes the problem by introducing a new function,
viridian_domain_deinit(), which will iterate through the vCPUs and
release any page mappings still present.

Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 

commit 78c5f59ebd79117321a988c200048b5d94aa5df6
Author: Paul Durrant 
Date:   Tue Mar 29 14:26:03 2016 +0200

x86/hvm/viridian: save APIC assist vector

If any vcpu has a pending APIC assist when the domain is suspended
then the vector needs to be saved. If this is not done then it's
possible for the vector to remain pending in the vlapic ISR
indefinitely after resume.

This patch adds code to save the APIC assist vector value in the
viridian vcpu save record. This means that the record is now zero-
extended on load and, because this implies a loaded value of
zero means nothing is pending (for backwards compatibility with
hosts not implementing APIC assist), the rest of the viridian APIC
assist code is adjusted to treat a zero value in this way. A
check has therefore been added to viridian_start_apic_assist() to
prevent the enlightenment being used for vectors < 0x10 (which
are illegal for an APIC).

Signed-off-by: Paul Durrant 
Reviewed-by: Jan Beulich 

commit 966a420c010355bd7c28f8a75e31e713715f6afa
Author: Stefano Stabellini 
Date:   Tue Mar 29 14:25:43 2016 +0200

Anthony Perard to co-maintain qemu

I nominate Anthony Perard as qemu-xen co-maintainer. He has been doing a
lot of QEMU work over the years and in fact he is the original author of
the Xen enablement code in upstream QEMU.

As qemu-xen co-maintainer, he coul

Re: [Xen-devel] [PATCH v3 0/7] Enhance PAT init to fix Xorg crashes

2016-03-29 Thread Toshi Kani

On Tue, 2016-03-29 at 10:46 -0400, Boris Ostrovsky wrote:
> On 03/29/2016 10:19 AM, Toshi Kani wrote:
> > On Tue, 2016-03-29 at 12:34 +0200, Ingo Molnar wrote:
> > 
> > > > I'd appreciate if someone can test this patch-set on Xen to verify
> > > > that there is no change in "x86/PAT: Configuration [0-7] .."
> > > > message in dmesg.
> > > So I don't have a Xen setup, but hopefully such testing will happen
> > > once these changes show up in linux-next, tomorrow or so.
> > I will address if any issue is found in testing.
> 
> I ran a subset of out nightly test. Nobody died.
> 
> So this all looks good. (It actually may have also fixed another bug 
> that was reported recently by Olaf, copied here)

Cool! Thanks Boris!
-Toshi

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

Re: [Xen-devel] [PATCH V6 2/2] x86/xsaves: fix overwriting between non-lazy/lazy xsaves

>>> On 24.03.16 at 09:29,  wrote:
> The offset at which components xsaved by xsave[sc] are not fixed.
> So when when a save with v->fpu_dirtied set is followed by one
> with v->fpu_dirtied clear, non-lazy xsave[sc] may overwriting data
> written by the lazy one.
> 
> The solution is when using_xsave_compact is enabled and taking xcr0_accum into
> consideration, if guest has ever used XSTATE_LAZY & ~XSTATE_FP_SSE
> (XSTATE_FP_SSE will be excluded beacause xsave will write XSTATE_FP_SSE
> part in legacy region of xsave area which is fixed, saving XSTATE_FS_SSE
> will not cause overwriting problem), vcpu_xsave_mask will return XSTATE_ALL.
> Otherwise vcpu_xsave_mask will return XSTATE_NONLAZY.
> 
> This may cause overhead save on lazy states which will cause performance
> impact. After doing some performance tests on xsavec and xsaveopt
> (suggested by jan), the results show xsaveopt performs better than xsavec.
> So hypervisor will not use xsavec anymore.
> 
> xsaves will be used until supervised state is instroduced in hypervisor.

"xsaves will not be used ... introduced ..." I suppose?

> @@ -223,13 +223,15 @@ void compress_xsave_states(struct vcpu *v, const void 
> *src, unsigned int size)
>  u64 xstate_bv = ((const struct xsave_struct *)src)->xsave_hdr.xstate_bv;
>  u64 valid;
>  
> -if ( !cpu_has_xsaves && !cpu_has_xsavec )
> +ASSERT(!xsave_area_compressed(src));
> +
> +if ( !(v->arch.xcr0_accum & XSTATE_XSAVES_ONLY) &&
> + !xsave_area_compressed(src) )

Considering the ASSERT(), what's this second half of the conditional
good for?

> @@ -368,19 +371,29 @@ void xrstor(struct vcpu *v, uint64_t mask)
>  switch ( __builtin_expect(ptr->fpu_sse.x[FPU_WORD_SIZE_OFFSET], 8) )
>  {
>  BUILD_BUG_ON(sizeof(faults) != 4); /* Clang doesn't support %z 
> in asm. */
> -#define XRSTOR(pfx) \
> -alternative_io("1: .byte " pfx "0x0f,0xae,0x2f\n" \
> +#define _xrstor(xrstor_ins) \
> +asm volatile ( "1: .byte "xrstor_ins"\n" \

Blanks around xrstor_ins please. Also please consider naming the
macro parameter just "insn".

> "3:\n" \
> "   .section .fixup,\"ax\"\n" \
> "2: incl %[faults]\n" \
> "   jmp 3b\n" \
> "   .previous\n" \
> -   _ASM_EXTABLE(1b, 2b), \
> -   ".byte " pfx "0x0f,0xc7,0x1f\n", \
> -   X86_FEATURE_XSAVES, \
> -   ASM_OUTPUT2([mem] "+m" (*ptr), [faults] "+g" 
> (faults)), \
> -   [lmask] "a" (lmask), [hmask] "d" (hmask), \
> -   [ptr] "D" (ptr))
> +   _ASM_EXTABLE(1b, 2b) \
> +   : [mem] "+m" (*ptr), [faults] "+g" (faults) \
> +   : [lmask] "a" (lmask), [hmask] "d" (hmask), \
> + [ptr] "D" (ptr) )
> +
> +#define XRSTOR(pfx) \
> +if ( v->arch.xcr0_accum & XSTATE_XSAVES_ONLY ) \
> +{ \
> +if ( unlikely(!(ptr->xsave_hdr.xcomp_bv \
> +& XSTATE_COMPACTION_ENABLED)) ) \
> +ptr->xsave_hdr.xcomp_bv |= ptr->xsave_hdr.xstate_bv \
> +   | XSTATE_COMPACTION_ENABLED; \

In both cases above the operator in a split line belongs on the
previous one.

> +_xrstor(pfx "0x0f,0xc7,0x1f"); /* xrstors */ \

Indentation.

Jan


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

Re: [Xen-devel] [PATCH v7 13/22] arm/acpi: Map the new created EFI and ACPI tables to Dom0


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

Map the UEFI and ACPI tables which we created to non-RAM space in Dom0.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 


With the suggestion below:

Acked-by: Julien Grall 


---
v7: flush the cache
---
  xen/arch/arm/domain_build.c | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
index 954e0e3..70c8421 100644
--- a/xen/arch/arm/domain_build.c
+++ b/xen/arch/arm/domain_build.c
@@ -1723,6 +1723,25 @@ static int prepare_acpi(struct domain *d, struct 
kernel_info *kinfo)
  acpi_create_efi_system_table(d, tbl_add);
  acpi_create_efi_mmap_table(d, &kinfo->mem, tbl_add);

+/* Map the EFI and ACPI tables to Dom0 */
+rc = map_regions_rw_cache(d,
+  paddr_to_pfn(d->arch.efi_acpi_gpa),
+  PFN_UP(d->arch.efi_acpi_len),
+  
paddr_to_pfn(virt_to_maddr(d->arch.efi_acpi_table)));
+if ( rc != 0 )
+{
+printk(XENLOG_ERR "Unable to map EFI/ACPI table 0x%"PRIx64
+   " - 0x%"PRIx64" in domain %d\n",
+   d->arch.efi_acpi_gpa & PAGE_MASK,
+   PAGE_ALIGN(d->arch.efi_acpi_gpa + d->arch.efi_acpi_len) - 1,
+   d->domain_id);
+return rc;
+}
+
+/* Flush cache of this region in case Dom0 gets wrong data. */


NIT: I think it would be clearer if you say:

"Flush the cache for this region, otherwise DOM0 may read wrong data 
when the cache is disabled."



+clean_and_invalidate_dcache_va_range(d->arch.efi_acpi_table,
+ d->arch.efi_acpi_len);
+
  return 0;
  }
  #else



Regards,

--
Julien Grall

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

[Xen-devel] [xen-unstable test] 87820: regressions - FAIL

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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-i386-libvirt-pair 21 guest-migrate/src_host/dst_host fail REGR. vs. 
86491
 test-amd64-amd64-xl-qemut-win7-amd64 13 guest-localmigrate fail in 87625 REGR. 
vs. 86491

Tests which are failing intermittently (not blocking):
 test-amd64-i386-xl-qemuu-win7-amd64 12 guest-saverestore fail in 87551 pass in 
87820
 test-amd64-i386-xl-qemut-win7-amd64 15 guest-localmigrate/x10 fail in 87739 
pass in 87551
 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail in 87739 pass 
in 87820
 test-amd64-amd64-libvirt-pair 21 guest-migrate/src_host/dst_host fail pass in 
87551
 test-amd64-amd64-xl-qemut-win7-amd64 12 guest-saverestore   fail pass in 87625
 test-amd64-i386-xl-qemut-win7-amd64 12 guest-saverestorefail pass in 87739

Regressions which are regarded as allowable (not blocking):
 test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail in 87551 like 86491
 build-i386-rumpuserxen6 xen-buildfail   like 86491
 test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail like 86491
 build-amd64-rumpuserxen   6 xen-buildfail   like 86491
 test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop  fail like 86491
 test-armhf-armhf-xl-rtds 11 guest-start  fail   like 86491

Tests which did not succeed, but are not blocking:
 test-amd64-i386-rumpuserxen-i386  1 build-check(1)   blocked  n/a
 test-amd64-amd64-rumpuserxen-amd64  1 build-check(1)   blocked n/a
 test-armhf-armhf-xl-rtds 13 saverestore-support-check fail in 87551 never pass
 test-armhf-armhf-xl-rtds 12 migrate-support-check fail in 87551 never pass
 test-amd64-amd64-xl-pvh-amd  11 guest-start  fail   never pass
 test-amd64-amd64-xl-pvh-intel 11 guest-start  fail  never pass
 test-armhf-armhf-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-xsm 14 guest-saverestorefail   never pass
 test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2  fail never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  12 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-arndale  13 saverestore-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-cubietruck 12 migrate-support-checkfail never pass
 test-armhf-armhf-xl-cubietruck 13 saverestore-support-checkfail never pass
 test-armhf-armhf-xl-multivcpu 13 saverestore-support-checkfail  never pass
 test-armhf-armhf-xl-multivcpu 12 migrate-support-checkfail  never pass
 test-armhf-armhf-xl-xsm  13 saverestore-support-checkfail   never pass
 test-armhf-armhf-xl-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt 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-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail 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-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-armhf-armhf-xl-vhd  11 migrate-support-checkfail   never pass
 test-armhf-armhf-xl-vhd  12 saverestore-support-checkfail   never pass

version targeted for testing:
 xen  04119085f5a2a135e5161535b8821e1aa0d7db8a
baseline version:
 xen  a6f2cdb633bf519244a16674031b8034b581ba7f

Last test of basis86491  2016-03-17 15:24:59 Z   12 days
Failing since 86560  2016-03-18 10:56:34 Z   11 days   15 attempts
Testing same since87461  2016-03-26 13:04:52 Z3 days5 attempts


People who touched revisions under test:
  Andrew Cooper 
  Chunyan Liu 
  Dagaen Golomb 
  Daniel De Gra

Re: [Xen-devel] [PATCH v7 11/17] ARM: XEN: Move xen_early_init() before efi_init()

2016-03-29 Thread Will Deacon

On Sat, Mar 26, 2016 at 12:54:09PM +, Stefano Stabellini wrote:
> are you OK with this patch?

Nothing against it, but the only arm64 bit is:

> > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > index 450987d..6cf5051 100644
> > --- a/arch/arm64/kernel/setup.c
> > +++ b/arch/arm64/kernel/setup.c
> > @@ -313,6 +313,7 @@ void __init setup_arch(char **cmdline_p)
> >  */
> > local_async_enable();
> >  
> > +   xen_early_init();
> > efi_init();
> > arm64_memblock_init();
> >  
> > @@ -334,7 +335,6 @@ void __init setup_arch(char **cmdline_p)
> > } else {
> > psci_acpi_init();
> > }
> > -   xen_early_init();

so it's difficult to care too much ;) I do hope that there won't be a
need to split up efi_init() in future because some of it has to happen
before xen_early_init, but that doesn't sound likely at the moment.

Will

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

Re: [Xen-devel] Xen 4.6.1 raisin build error etherboot undeclared

On Sat, Mar 26, 2016 at 12:46 PM, Holger Schramm  wrote:
> Hi there,
>
> i receive a build error at rombios.c and etherboot not declared. I have
> no idea how to fix this.
>
> One thing i stumbled is this commit:
>
> http://xenbits.xen.org/gitweb/?p=raisin.git;a=commitdiff;h=5fe3855a6cf69c4aaed89c47b7e7937b9c66d07e

It looks like that commit contains a bug -- the patch adds
"--enable-rombios", but the text of the patch seems to indicate that
"--disable-rombios" is what was wanted.

Can you try the attached patch?

 -George
commit 8f40a9a9a61414ef6146da3524420858115600b1
Author: George Dunlap 
Commit: George Dunlap 

raisin: Actually disable rombios

Commit 5fe3855 meant to disable rombios, but didn't.  This causes the following
build failure:

gcc   -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing
-std=gnu99 -Wall -Wstrict-prototypes -Wdeclaration-after-statement
-Wno-unused-but-set-variable -Wno-unused-local-typedefs
-D__XEN_TOOLS__ -MMD -MF .rombios.o.d -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs  -DNDEBUG -Werror
-fno-stack-protector -fno-exceptions -fno-builtin -msoft-float
-I/usr/local/src/xenboil/raisin/xen-dir-remote/tools/firmware/hvmloader/../../../tools/include
-U__XEN_TOOLS__
-D__XEN_INTERFACE_VERSION__=__XEN_LATEST_INTERFACE_VERSION__
-DENABLE_OVMF -DENABLE_ROMBIOS -DENABLE_SEABIOS  -c -o rombios.o rombios.c
rombios.c: In function ‘rombios_load_roms’:
rombios.c:103:39: error: ‘etherboot’ undeclared (first use in this function)
   etherboot);

Disable rombios instead.

Reported-by: Holger Schramm 
Signed-off-by: George Dunlap 
---
CC: Stefano Stabellini 

diff --git a/components/xen b/components/xen
index 894d119..ea290aa 100644
--- a/components/xen
+++ b/components/xen
@@ -45,7 +45,7 @@ function xen_build() {
 export ETHERBOOT_NICS=""
 ./configure --prefix=$PREFIX --with-system-qemu=$PREFIX/lib/xen/bin/qemu-system-i386 \
 --disable-stubdom --disable-qemu-traditional \
---enable-rombios $seabios_opt $ovmf_opt
+--disable-rombios $seabios_opt $ovmf_opt
 $RAISIN_MAKE
 $RAISIN_MAKE install DESTDIR="$INST_DIR"
 unset ETHERBOOT_NICS
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

[Xen-devel] [PATCH] tools/misc/xen-hvmctx: fix the build

Commit 78c5f59e "x86/hvm/viridian: save APIC assist vector" changed
the name of a field in the viridian vcpu save record. Unfortunately this
record has a decode function in xen-hvmctx and so it no longer builds.

This patch fixes the field name in xen-hvmctx and also adds a decode of
the additional field that was added to the save record.

Signed-off-by: Paul Durrant 
Cc: Ian Jackson 
Cc: Stefano Stabellini 
Cc: Wei Liu 
---
 tools/misc/xen-hvmctx.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tools/misc/xen-hvmctx.c b/tools/misc/xen-hvmctx.c
index 5a69245..32be120 100644
--- a/tools/misc/xen-hvmctx.c
+++ b/tools/misc/xen-hvmctx.c
@@ -379,8 +379,9 @@ static void dump_viridian_vcpu(void)
 {
 HVM_SAVE_TYPE(VIRIDIAN_VCPU) p;
 READ(p);
-printf("VIRIDIAN_VCPU: apic_assist 0x%llx\n",
-   (unsigned long long) p.apic_assist);   
+printf("VIRIDIAN_VCPU: apic_assist_msr 0x%llx, apic_assist_vector 
0x%x\n",
+  (unsigned long long) p.apic_assist_msr,
+  p.apic_assist_vector);
 }
 
 static void dump_vmce_vcpu(void)
-- 
2.1.4


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

Re: [Xen-devel] [PATCH v7 14/22] arm/acpi: Create min DT stub for Dom0


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

Create a DT for Dom0 for ACPI-case only. DT contains minimal required
informations such as Dom0 bootargs, initrd, efi description table and


NIT: informations/information/


address of uefi memory table.

Also document this device tree bindings of "hypervisor" and
"hypervisor/uefi" node.

Signed-off-by: Naresh Bhat 
Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v7 15/22] arm/acpi: Permit access all Xen unused SPIs for Dom0


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

Allow DOM0 to use all SPIs but the ones used by Xen. Then when Dom0
configures the interrupt, it could set the interrupt type and route it
to Dom0.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v7 16/22] arm/acpi: Configure SPI interrupt type and route to Dom0 dynamically


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

Interrupt information is described in DSDT and is not available at the
time of booting. Check if the interrupt is permitted to access and set
the interrupt type, route it to guest dynamically only for SPI
and Dom0.

Signed-off-by: Parth Dixit 
Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v7 17/22] arm/gic: Add a new callback to deny Dom0 access to GIC regions


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

Add a new member in gic_hw_operations which is used to deny Dom0 access
to GIC regions.

Signed-off-by: Shannon Zhao 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH] tools/misc/xen-hvmctx: fix the build

2016-03-29 Thread Wei Liu

On Tue, Mar 29, 2016 at 04:55:23PM +0100, Paul Durrant wrote:
> Commit 78c5f59e "x86/hvm/viridian: save APIC assist vector" changed
> the name of a field in the viridian vcpu save record. Unfortunately this
> record has a decode function in xen-hvmctx and so it no longer builds.
> 
> This patch fixes the field name in xen-hvmctx and also adds a decode of
> the additional field that was added to the save record.
> 
> Signed-off-by: Paul Durrant 
> Cc: Ian Jackson 
> Cc: Stefano Stabellini 
> Cc: Wei Liu 

Acked-by: Wei Liu 

> ---
>  tools/misc/xen-hvmctx.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/misc/xen-hvmctx.c b/tools/misc/xen-hvmctx.c
> index 5a69245..32be120 100644
> --- a/tools/misc/xen-hvmctx.c
> +++ b/tools/misc/xen-hvmctx.c
> @@ -379,8 +379,9 @@ static void dump_viridian_vcpu(void)
>  {
>  HVM_SAVE_TYPE(VIRIDIAN_VCPU) p;
>  READ(p);
> -printf("VIRIDIAN_VCPU: apic_assist 0x%llx\n",
> -   (unsigned long long) p.apic_assist);   
> +printf("VIRIDIAN_VCPU: apic_assist_msr 0x%llx, apic_assist_vector 
> 0x%x\n",
> +(unsigned long long) p.apic_assist_msr,
> +p.apic_assist_vector);
>  }
>  
>  static void dump_vmce_vcpu(void)
> -- 
> 2.1.4
> 

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

[Xen-devel] [libvirt test] 87831: tolerable FAIL - PUSHED

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

Failures :-/ but no regressions.

Tests which did not succeed, but are not blocking:
 test-armhf-armhf-libvirt-qcow2 11 migrate-support-checkfail never pass
 test-armhf-armhf-libvirt-qcow2 13 guest-saverestorefail never pass
 test-amd64-i386-libvirt  12 migrate-support-checkfail   never pass
 test-amd64-i386-libvirt-xsm  12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check 
fail never pass
 test-amd64-amd64-libvirt 12 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-vhd 11 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-libvirt 14 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt 12 migrate-support-checkfail   never pass
 test-armhf-armhf-libvirt-raw 13 guest-saverestorefail   never pass
 test-armhf-armhf-libvirt-raw 11 migrate-support-checkfail   never pass
 test-amd64-amd64-libvirt-xsm 12 migrate-support-checkfail   never pass

version targeted for testing:
 libvirt  33a1a7c6f5cae8f7682af98722630b554771ae62
baseline version:
 libvirt  b77cec09db67aff75313b53c931ad15c1aba27bd

Last test of basis87702  2016-03-28 04:22:19 Z1 days
Testing same since87831  2016-03-29 04:26:43 Z0 days1 attempts


People who touched revisions under test:
  Anatole Denis 
  Chunyan Liu 
  Cole Robinson 
  Jim Fehlig 
  John Ferlan 
  Laine Stump 
  Maxim Nestratov 
  Nikolay Shirokovskiy 

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-xsmpass
 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-pairpass
 test-amd64-i386-libvirt-pair pass
 test-armhf-armhf-libvirt-qcow2   fail
 test-armhf-armhf-libvirt-raw fail
 test-amd64-amd64-libvirt-vhd pass



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

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

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

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


Pushing revision :

+ branch=libvirt
+ revision=33a1a7c6f5cae8f7682af98722630b554771ae62
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
 getconfig Repos
 perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./a

Re: [Xen-devel] [PATCH v7 19/22] hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

This new delivery type which is for ARM shares the same value with
HVM_PARAM_CALLBACK_TYPE_VECTOR which is for x86.

val[15:8] is flag: val[7:0] is a PPI.
To the flag, bit 8 stands the interrupt mode is edge(1) or level(0) and
bit 9 stands the interrupt polarity is active low(1) or high(0).

Cc: Ian Jackson 
Cc: Jan Beulich 
Cc: Keir Fraser 
Cc: Tim Deegan 
Signed-off-by: Shannon Zhao 


Reviewed-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v7 20/22] xen/acpi: Fix event-channel interrupt when booting with ACPI


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

Store the event-channel interrupt number and flag in HVM parameter
HVM_PARAM_CALLBACK_IRQ. Then Dom0 could get it through hypercall
HVMOP_get_param.

Signed-off-by: Shannon Zhao 
Reviewed-by: Stefano Stabellini 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v7 12/17] ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI

2016-03-29 Thread Will Deacon

On Thu, Mar 24, 2016 at 10:44:31PM +0800, Shannon Zhao wrote:
> When it's a Xen domain0 booting with ACPI, it will supply a /chosen and
> a /hypervisor node in DT. So check if it needs to enable ACPI.
> 
> Signed-off-by: Shannon Zhao 
> Reviewed-by: Stefano Stabellini 
> Acked-by: Hanjun Guo 
> ---
>  arch/arm64/kernel/acpi.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
> index d1ce8e2..4e92be0 100644
> --- a/arch/arm64/kernel/acpi.c
> +++ b/arch/arm64/kernel/acpi.c
> @@ -67,10 +67,13 @@ static int __init dt_scan_depth1_nodes(unsigned long node,
>  {
>   /*
>* Return 1 as soon as we encounter a node at depth 1 that is
> -  * not the /chosen node.
> +  * not the /chosen node, or /hypervisor node when running on Xen.
>*/
> - if (depth == 1 && (strcmp(uname, "chosen") != 0))
> - return 1;
> + if (depth == 1 && (strcmp(uname, "chosen") != 0)) {
> + if (!xen_initial_domain() || (strcmp(uname, "hypervisor") != 0))
> + return 1;
> + }

Hmm, but xen_initial_domain() is false when xen isn't being used at all,
so it feels to me like this is a bit too far-reaching and is basically
claiming the "/hypervisor" namespace for Xen. Couldn't it be renamed to
"xen,hypervisor" or something?

Mark, got any thoughts on this?

Will

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

Re: [Xen-devel] [PATCH v7 22/22] xen/arm64: Add ACPI support


Hi Shannon,

On 25/03/16 13:48, Shannon Zhao wrote:

Add ACPI support on arm64 xen hypervisor. Enable EFI support on ARM.

Cc: Jan Beulich 
Signed-off-by: Shannon Zhao 
Acked-by: Jan Beulich 
Reviewed-by: Stefano Stabellini 


Acked-by: Julien Grall 

Regards,

--
Julien Grall

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

Re: [Xen-devel] [PATCH v7 00/22] Prepare UEFI and ACPI tables for Dom0 on ARM64