>>> 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
>>> 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
>>> 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++;
>> >
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
>>> 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)
>> > (
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
>> > UA
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:
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:
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 fro
>>> 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 >=
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
>>> 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
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
>>> possib
>>> 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
> -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 viri
> -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 wr
> -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 Mar
>>> 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,
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_pac
>>> 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
>> > > crea
>>> 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 st
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
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 "qu
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.
>>> 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
>>> 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_MAGI
> -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 AP
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:
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):
-
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
>>> 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
> 0x8
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 gu
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/sch
> -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
>
> > -Origin
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 =
* 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
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
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
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 failu
> -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 th
>>> 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 b
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 |
>>> 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"):
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-qem
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_doma
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
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)
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 chan
>>> 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 proble
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
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 G
-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
==
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.htm
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 p
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
_
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
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
X
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 th
>>> 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 tha
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 missi
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
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
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
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
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 diff
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 C
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
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 under
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 search
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
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);
> > > > > +
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
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)
>>
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 i
> >> +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 COD
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;
> > > > >
>>> 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-
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
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 test
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
Regar
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
_
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 di
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
>>> 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_xsav
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_buil
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-am
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/a
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=5fe3855a6cf69c4aaed89c4
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
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
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
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
S
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
Xe
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 fix
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-sav
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 i
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
Regard
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
> ---
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
___
Hi Jan,
On 29/03/16 08:12, Jan Beulich wrote:
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
1 - 100 of 157 matches
Mail list logo
