>>> On 09.10.18 at 02:28, wrote:
> this #define is unnecessary since XSM_INLINE is redefined in
> xsm/dummy.h, it's a risk of build breakage, so remove it.
>
> Signed-off-by: Xin Li
>
> ---
> CC: Daniel De Graaf
> CC: George Dunlap
> CC: Jan Beulich
> CC: Konrad Rzeszutek Wilk
> CC: Stefano
>>> On 08.10.18 at 20:33, wrote:
> At the moment, the implementation of Set/Way operations will go through
> all the entries of the guest P2M and flush them. However, this is very
> expensive and may render unusable a guest OS using them.
>
> For instance, Linux 32-bit will use Set/Way operations
>>> On 09.10.18 at 01:37, wrote:
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -535,6 +535,20 @@ static XSM_INLINE int
> xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, str
> return xsm_default_action(action, d, t);
> }
>
> +/*
> + * Be aware that this is not
> >>> On 09.10.18 at 02:28, wrote:
> > v5:
> > 1. move the removal of #define to this new patch.
> > 2. fix wrong git author
>
> Thanks, but one more formal request: Would you please include the version of
> a patch/series in side the square brackets of the mail subject, like everyone
> else does
> > ---
> > CC: Daniel De Graaf
> > CC: George Dunlap
> > CC: Jan Beulich
> > CC: Konrad Rzeszutek Wilk
> > CC: Stefano Stabellini
> > CC: Tim Deegan
> > CC: Wei Liu
> > CC: Sergey Dyasli
> > CC: Andrew Cooper
> > CC: Ming Lu
> >
> > v5:
> > 1. move the removal of #define to this new patc
flight 128496 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128496/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64 7 xen-boot fail REGR. vs. 128476
test-amd64-i386-xl-q
flight 128498 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128498/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-examine4 memdisk-try-append fail in 128478 pass in 128498
test-amd64-i386-libvirt-pair 24
Since commit 2c257bd6 "x86/hvm: remove default ioreq server (again)" the
GFNs allocated by the toolstack and set in HVM_PARAM_IOREQ_PFN and
HVM_PARAM_BUFIOREQ_PFN have been unused. This patch allows them to be used
by (non-default) ioreq servers.
While in the area, also make sure HVM_PARAM_[BUF]IO
On Mon, Oct 08, 2018 at 07:06:10AM -0600, Jan Beulich wrote:
> All,
>
> both releases are due in about a month's time. Please point out
> backports you find missing from their respective staging branches,
> but which you consider relevant. On top of what I've just pushed
> there I have
>
> 2fb57e
On 8 October 2018 at 19:00, Julien Grall wrote:
> Per the Linux arm64 booting protocol [1], the load offset can definitely be
> 0. The bootloader (here QEMU) should not assume a specific text offset,
> Linux actually provides an option to randomize the text offset in order to
> test that assumptio
>>> On 09.10.18 at 09:50, wrote:
>> > ---
>> > CC: Daniel De Graaf
>> > CC: George Dunlap
>> > CC: Jan Beulich
>> > CC: Konrad Rzeszutek Wilk
>> > CC: Stefano Stabellini
>> > CC: Tim Deegan
>> > CC: Wei Liu
>> > CC: Sergey Dyasli
>> > CC: Andrew Cooper
>> > CC: Ming Lu
>> >
>> > v5:
>> >
>>> On 09.10.18 at 10:38, wrote:
> On Mon, Oct 08, 2018 at 07:06:10AM -0600, Jan Beulich wrote:
>> All,
>>
>> both releases are due in about a month's time. Please point out
>> backports you find missing from their respective staging branches,
>> but which you consider relevant. On top of what I'
On Tue, 9 Oct 2018 09:58:14 +0100
Peter Maydell wrote:
Hi,
> On 8 October 2018 at 19:00, Julien Grall wrote:
> > Per the Linux arm64 booting protocol [1], the load offset can
> > definitely be 0. The bootloader (here QEMU) should not assume a
> > specific text offset, Linux actually provides an
On Fri 05-10-18 13:40:05, Arun KS wrote:
> When free pages are done with higher order, time spend on
> coalescing pages by buddy allocator can be reduced. With
> section size of 256MB, hot add latency of a single section
> shows improvement from 50-60 ms to less than 1 ms, hence
> improving the hot
On Fri 05-10-18 13:40:06, Arun KS wrote:
> They not only increase the code footprint, they actually make things
> slower rather than faster. Remove them as contemporary hardware doesn't
> need any hint.
I agree with the change but it is much better to add some numbers
whenever arguing about perfor
this #define is unnecessary since XSM_INLINE is redefined in
xsm/dummy.h, it's a risk of build breakage, so remove it.
Signed-off-by: Xin Li
Reviewed-by: Jan Beulich
---
CC: Daniel De Graaf
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim Deegan
C
When SILO is enabled, there would be no page-sharing or event notifications
between unprivileged VMs (no grant tables or event channels).
Signed-off-by: Xin Li
Acked-by: Daniel De Graaf
---
CC: Daniel De Graaf
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellin
Introduce new boot parameter xsm to choose which xsm module is enabled,
and set default to dummy. And add new option in Kconfig to choose the
default XSM implementation.
Signed-off-by: Xin Li
Acked-by: Daniel De Graaf
---
CC: Daniel De Graaf
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzesz
On 15/02/2018 13:02, Daniel Kiper wrote:
> Hi Juergen,
>
> Sorry for huge delay. It looks that I am recovering slowly and
> probably I will have more time for reviews.
>
> On Wed, Nov 29, 2017 at 02:46:42PM +0100, Juergen Gross wrote:
>> This patch series adds support for booting Linux as PVH gue
When switching the memory decoding bit in the command register the
rest of the changes where dropped, leading to only the memory decoding
bit being updated.
Fix this by unconditionally writing the guest-requested command except
for the memory decoding bit, which will be updated once the p2m
change
No functional change expected.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/dom0_build.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/dom0_build.c b/xen/arch/x86/dom0_build.c
index 86eb7db1da..dc
BAR map/unmap is a long running operation that needs to be preempted
in order to avoid overrunning the assigned vCPU time (or even
triggering the watchdog).
Current logic for this preemption is wrong, and won't work at all for
AMD since only Intel makes use of hvm_io_pending (and even in that
case
A PVH Dom0 might use TSC scaling or other HVM specific TSC
adjustments, so only short-circuit the TSC setup for a classic PV
Dom0.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
---
xen/arch/x86/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
Make sure the MSIX MMIO regions don't have p2m entries setup, so that
accesses to them trap into the hypervisor and can be handled by vpci.
This is a side-effect of commit 042678762 for PVH Dom0, which added
mappings for all the reserved regions into the Dom0 p2m.
Signed-off-by: Roger Pau Monné
Add an option to allow trapping accesses to IO port 0xe9 for a PVH
Dom0, so it can print to the HVM debug console. Note this is not
enabled by default in order to prevent clashes with hardware on the
system using 0xe9.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei
Hello,
The following series contain miscellaneous fixes for a PVH Dom0. I've
found out this issues while trying to boot on an AMD EPYC box.
The series can be found on my git repo on top of "x86/vtd: fix
iommu_share_p2m_table":
git://xenbits.xen.org/people/royger/xen.git fixes_pvh
Thanks, Roger.
flight 75377 distros-debian-snapshot real [real]
http://osstest.xensource.com/osstest/logs/75377/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-pvopsbroken
build-i386
On 2018-10-09 14:59, Michal Hocko wrote:
On Fri 05-10-18 13:40:05, Arun KS wrote:
When free pages are done with higher order, time spend on
coalescing pages by buddy allocator can be reduced. With
section size of 256MB, hot add latency of a single section
shows improvement from 50-60 ms to less
Hi Jan,
On 09/10/2018 08:04, Jan Beulich wrote:
On 08.10.18 at 20:33, wrote:
At the moment, the implementation of Set/Way operations will go through
all the entries of the guest P2M and flush them. However, this is very
expensive and may render unusable a guest OS using them.
For instance, Li
On Wed, 2018-10-03 at 12:53 +0200, Juergen Gross wrote:
> On 02/10/2018 17:49, George Dunlap wrote:
> > Commit 3b4adba ("tools/libxl: include scheduler parameters in the
> > output of xl list -l") added scheduling parameters to the set of
> > information collected by libxl_retrieve_domain_configura
Hi,
On 04/10/2018 08:11, Amit Tomer wrote:
+reg = meson_s905_read(uart, UART_CONTROL);
+reg &= ~(UART_RX_RST | UART_TX_RST | UART_CLEAR_ERR);
I am not sure why you are clearing those bits. AFAIU, init_preirq will reset
the serials, so you want to set thoses bits. This seems to be conf
While booting on an AMD EPYC box the stack canary would detect stack
overflows when using the current PVH early stack size (256). Switch to
using the value defined by BOOT_STACK_SIZE, which prevents the stack
overflow.
Signed-off-by: Roger Pau Monné
---
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc:
Commit 2916951c1 ("mm / iommu: include need_iommu() test in
iommu_use_hap_pt()") included need_iommu() in iommu_use_hap_pt and
91d4eca7add (" mm / iommu: split need_iommu() into has_iommu_pt() and
need_iommu_pt_sync()") made things finer grain by spliting need_iommu
into three states.
The destruct
In case the rsdp address in struct boot_params is specified don't try
to find the table by searching, but take the address directly as set
by the boot loader.
Signed-off-by: Juergen Gross
---
V3: use a generic retrieval function with a __weak annotated default
function (Ingo Molnar)
V4: chec
The boot loader version reported via sysfs is wrong in case of the
kernel being booted via the Xen PVH boot entry. it should be 2.12
(0x020c), but it is reported to be 2.18 (0x0212).
As the current way to set the version is error prone use the more
readable variant (2 << 8) | 12.
Cc: # 4.12
Sign
Xen PVH guests receive the address of the RSDP table from Xen. In order
to support booting a Xen PVH guest via Grub2 using the standard x86
boot entry we need a way for Grub2 to pass the RSDP address to the
kernel.
For this purpose expand the struct setup_header to hold the physical
address of the
In the non-EFI boot path the ACPI RSDP table is currently found via
either EBDA or by searching through low memory for the RSDP magic.
This requires the RSDP to be located in the first 1MB of physical
memory. Xen PVH guests, however, get the RSDP address via the start of
day information block.
In
Hi Andrew,
On 05/10/2018 15:54, Andrew Cooper wrote:
On the ARM side, lift the code to select the appropriate GIC version when
NATIVE is requested.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
Regardless the decision on the hook nam
Hi,
I'm testing Xen Hypervisor 4.10 performance on UltraZed-EG board with
carrier card.
I created bare-metal application in Xilinx SDK.
In bm application I:
- start triple timer counter (ttc) which generates
interrupt every 1us
- turn on PS LED
- call function 100 t
On 09/10/18 07:43, Jan Beulich wrote:
> 56fff3e5e9 ("x86: nuke PV superpage option and code") has introduced a
> (luckily latent only) bug here, in that it didn't make reference
> dropping dependent on whether the page was mapped writable. The only
> current source of large page mappings for PV dom
On 09/10/2018 12:32, Roger Pau Monne wrote:
> While booting on an AMD EPYC box the stack canary would detect stack
> overflows when using the current PVH early stack size (256). Switch to
> using the value defined by BOOT_STACK_SIZE, which prevents the stack
> overflow.
>
> Signed-off-by: Roger Pa
Retrieve the memory map from the hypervisor and normalize it to contain
no overlapping entries and to be sorted by address.
Signed-off-by: Juergen Gross
---
grub-core/kern/i386/xen/pvh.c | 98 +++
1 file changed, 98 insertions(+)
diff --git a/grub-core/ke
Rearrange grub-core/kern/xen/init.c to prepare adding PVH mode support
to it. This includes putting some code under #ifdef GRUB_MACHINE_XEN
as it will not be used when running as PVH.
Signed-off-by: Juergen Gross
---
grub-core/kern/xen/init.c | 60 +++
Initialize the grant tab in a dedicated function. This will enable
using it for PVH guests, too.
Call the new function from grub_machine_init() as this will later
be common between Xen PV and Xen PVH mode.
Signed-off-by: Juergen Gross
---
V2: update commit message (Daniel Kiper)
---
grub-core/k
Add the needed code to setup the hypercall page for calling into the
Xen hypervisor.
Signed-off-by: Juergen Gross
---
grub-core/kern/i386/xen/pvh.c | 70 +++
1 file changed, 70 insertions(+)
diff --git a/grub-core/kern/i386/xen/pvh.c b/grub-core/kern/i386
Add all usable memory regions to grub memory management and add the
needed mmap iterate code.
As we are running in 32-bit mode don't add memory above 4GB.
Signed-off-by: Juergen Gross
---
grub-core/kern/i386/xen/pvh.c | 35 +++
1 file changed, 35 insertions(+)
d
Add the code for the Xen PVH mode boot entry.
Signed-off-by: Juergen Gross
---
grub-core/kern/i386/xen/startup_pvh.S | 50 +++
1 file changed, 50 insertions(+)
diff --git a/grub-core/kern/i386/xen/startup_pvh.S
b/grub-core/kern/i386/xen/startup_pvh.S
index e18ee
This patch series adds support for booting Linux as PVH guest.
Similar to i386/xen and x86_64/xen platforms the new i386/xenpvh
platform grub is booted as a standalone image directly by Xen.
For booting Linux kernel it is using the standard linux kernel
loader. The only modification of the linux
Add the hooks to current code needed for Xen PVH.
Signed-off-by: Juergen Gross
---
grub-core/kern/i386/xen/pvh.c | 36 +++
grub-core/kern/i386/xen/startup_pvh.S | 29
grub-core/kern/xen/init.c | 6 ++
include/g
include/grub/offsets.h needs some defines for Xen PVH mode.
Add them. While at it line up the values in the surrounding lines to
start at the same column.
Signed-off-by: Juergen Gross
---
include/grub/offsets.h | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff -
Support platform i386/xenpvh in configure.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
---
configure.ac | 3 +++
1 file changed, 3 insertions(+)
diff --git a/configure.ac b/configure.ac
index 5e63c4af3..96d81a3f2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -151,6 +151,7 @@ case
Some common code needs to be special cased for Xen PVH mode. This hits
mostly Xen PV mode specific areas.
Signed-off-by: Juergen Gross
---
grub-core/kern/i386/tsc.c | 2 +-
include/grub/i386/pc/int.h| 3 +++
include/grub/i386/tsc.h | 2 +-
include/grub/i386/xen/hypercal
Xen PVH mode needs some headers including the common i386 headers.
Add those to the tree.
Signed-off-by: Juergen Gross
---
include/grub/i386/xenpvh/boot.h| 1 +
include/grub/i386/xenpvh/console.h | 1 +
include/grub/i386/xenpvh/int.h | 1 +
include/grub/i386/xenpvh/memory.h | 1 +
inclu
Add xenpvh support to grub-install.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
---
include/grub/util/install.h | 1 +
util/grub-install-common.c | 1 +
util/grub-install.c | 7 +++
3 files changed, 9 insertions(+)
diff --git a/include/grub/util/install.h b/include/grub
Xen PVH guests will have the RSDP at an arbitrary address. Support that
by passing the RSDP address via the boot parameters to Linux.
The new protocol version 2.14 requires to set version to 0x8000 ored
with the actually use protocol version (the minimum of the kernel
supplied protocol version and
flight 128505 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128505/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 128108
build-arm64
Add the modifications to the build system needed to build a xenpvh
grub.
Signed-off-by: Juergen Gross
Reviewed-by: Daniel Kiper
---
gentpl.py | 4 ++--
grub-core/Makefile.am | 12
grub-core/Makefile.core.def | 35 +++
3 files
In order to support grub2 in Xen PVH environment some additional Xen
headers are needed as grub2 will be started in PVH mode requiring to
use several HVM hypercalls and structures.
Add the needed headers from Xen 4.10 being the first Xen version with
full (not only experimental) PVH guest support.
From: Hans van Kranenburg
This solves the build failing with "Error: no symbol table and no
.moddeps section"
Also see:
- 6371e9c10433578bb236a8284ddb9ce9e201eb59
- https://savannah.gnu.org/bugs/?49012
Signed-off-by: Hans van Kranenburg
---
V2: new patch
Signed-off-by: Juergen Gross
---
util
Support mkimage for xenpvh.
In order to avoid using plain integers for the ELF notes use the
available Xen include instead. While at it replace the plain numbers
for Xen PV mode, too.
Signed-off-by: Juergen Gross
---
V2: some style adjustments (Daniel Kiper)
use defines for elf-notes (Daniel
Initialize the needed Xen specific data. This is:
- the Xen start of day page containing the console and Xenstore ring
page PFN and event channel
- the grant table
- the shared info page
Set the RSDP address for the guest from the start_info page passed
as boot parameter.
Signed-off-by: Juerge
On Tue 09-10-18 15:24:13, Arun KS wrote:
> On 2018-10-09 14:59, Michal Hocko wrote:
> > On Fri 05-10-18 13:40:05, Arun KS wrote:
> > > When free pages are done with higher order, time spend on
> > > coalescing pages by buddy allocator can be reduced. With
> > > section size of 256MB, hot add latenc
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 09 October 2018 11:42
> To: xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Roger Pau Monne
> ; Paul Durrant ; Wei Liu
> ; Kevin Tian
> Subject: [PATCH] x86/vtd: fix IOMMU share PT destruction path
>
> Commit 291
Hi Andrew,
On 05/10/2018 15:54, Andrew Cooper wrote:
The purpose of this is to move the auduting to be earlier than
arch_domain_create().
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Stefano Stabellini
CC: Julien Grall
The max_vcpus setting for GIC_V3 is somewhat confu
Hi Andrew,
On 05/10/2018 15:54, Andrew Cooper wrote:
This reverts commit 703d9d5ec13a0f487e7415174ba54e0e3ca158db. The domain
creation logic has been adjusted to set up d->max_vcpus early enough to be
usable in vgic_v3_domain_init().
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Paul Durrant
> Sent: 09 October 2018 12:23
> To: Wei Liu ; xen-devel@lists.xenproject.org
> Cc: Kevin Tian ; Wei Liu ; Jan
> Beulich ; Roger Pau Monne
> Subject: Re: [Xen-devel] [PATCH] x8
>>> On 09.10.18 at 12:16, wrote:
> On 09/10/2018 08:04, Jan Beulich wrote:
> On 08.10.18 at 20:33, wrote:
>>> This patch adds a new per-arch helper is introduced to perform actions just
>>> before the guest is first unpaused. This will be used to invalidate the
>>> P2M to track access from th
Hi Stefano,
On 05/10/2018 19:47, Stefano Stabellini wrote:
Add a new document to provide information on how to use dom0less related
features and their current limitations.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- rename to .txt
- improve wording
Changes in v3:
- add patch
---
Hi Jan,
On 09/10/2018 12:43, Jan Beulich wrote:
On 09.10.18 at 12:16, wrote:
On 09/10/2018 08:04, Jan Beulich wrote:
On 08.10.18 at 20:33, wrote:
This patch adds a new per-arch helper is introduced to perform actions just
before the guest is first unpaused. This will be used to invalidate t
On Tue, Oct 09, 2018 at 11:35:28AM +0200, Juergen Gross wrote:
> On 15/02/2018 13:02, Daniel Kiper wrote:
> > Hi Juergen,
> >
> > Sorry for huge delay. It looks that I am recovering slowly and
> > probably I will have more time for reviews.
> >
> > On Wed, Nov 29, 2017 at 02:46:42PM +0100, Juergen
On Tue, Oct 09, 2018 at 12:22:34PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 09 October 2018 11:42
> > To: xen-devel@lists.xenproject.org
> > Cc: Jan Beulich ; Roger Pau Monne
> > ; Paul Durrant ; Wei Liu
> > ; Kevin Tian
> >
On Tue, Oct 09, 2018 at 12:38:41PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > Of Paul Durrant
> > Sent: 09 October 2018 12:23
> > To: Wei Liu ; xen-devel@lists.xenproject.org
> > Cc: Kevin Tian ; Wei Li
flight 128503 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128503/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail never pass
test-amd64-i386-xl
>>> On 09.10.18 at 14:57, wrote:
> On Tue, Oct 09, 2018 at 12:22:34PM +0100, Paul Durrant wrote:
>> > -Original Message-
>> > From: Wei Liu [mailto:wei.l...@citrix.com]
>> > Sent: 09 October 2018 11:42
>> > To: xen-devel@lists.xenproject.org
>> > Cc: Jan Beulich ; Roger Pau Monne
>> > ; P
On 10/9/18 6:54 AM, Juergen Gross wrote:
> +
> +u64 x86_default_get_root_pointer(void)
> +{
> + return boot_params.hdr.acpi_rsdp_addr;
> +}
Should we then update init_pvh_bootparams() with
pvh_bootparams.hdr.acpi_rsdp_addr = pvh_start_info.rsdp_paddr;
(and drop x86_init.acpi.get_root_po
On 05/10/2018 19:47, Stefano Stabellini wrote:
Introduce a new array to store the cmdline of each boot module. It is
separate from struct bootmodules. Remove the cmdline field from struct
boot_module. This way, kernels and initrds with the same address in
memory can share struct bootmodule (imp
On 09/10/2018 15:22, Boris Ostrovsky wrote:
> On 10/9/18 6:54 AM, Juergen Gross wrote:
>> +
>> +u64 x86_default_get_root_pointer(void)
>> +{
>> +return boot_params.hdr.acpi_rsdp_addr;
>> +}
>
>
> Should we then update init_pvh_bootparams() with
>
> pvh_bootparams.hdr.acpi_rsdp_addr = pvh
On Tue, Oct 09, 2018 at 12:43:05AM -0600, Jan Beulich wrote:
> 56fff3e5e9 ("x86: nuke PV superpage option and code") has introduced a
> (luckily latent only) bug here, in that it didn't make reference
It seems that the bug was from the original superpage code -- see
put_spage_pages.
> dropping de
On Tue, Oct 09, 2018 at 01:58:14PM +0100, Wei Liu wrote:
> On Tue, Oct 09, 2018 at 12:38:41PM +0100, Paul Durrant wrote:
> > > -Original Message-
> > > From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> > > Of Paul Durrant
> > > Sent: 09 October 2018 12:23
> > > To:
Hi Stefano,
On 05/10/2018 19:47, Stefano Stabellini wrote:
Don't add duplicate boot modules (same kind and same start address),
they are freed later, we don't want to introduce double-free errors.
Introduce a domU flag in struct bootmodule and struct bootcmdline. Set
it for kernels and ramdisks
Hi all,
## Agenda
The agenda can be found at
https://docs.google.com/document/d/1ZfZ1SJRauLrISiTLXzM0DPxQL8beNkAQS5MwLLNtRKc/edit?usp=sharing
The document is R/W already
But in a nutshell
* Admin Items: When to have winter meetings (DST effect)
* Open / Closed Actions from Previous c
> >Ian, any objections?
Sorry for dropping this. It's been a while!
> >> > When a MSI interrupt is bound to a guest using
> >> > xc_domain_update_msi_irq (XEN_DOMCTL_bind_pt_irq) the interrupt
> >> > is left masked by default.
> >> >
> >> > This causes problems with guests that first configure
>
On 07/10/2018 22:05, Boris Ostrovsky wrote:
> Xend-based toolstacks don't have static-max entry in xenstore. The
> equivalent node for those toolstacks is memory_static_max.
>
> Fixes: 5266b8e4445c (xen: fix booting ballooned down hvm guest)
> Signed-off-by: Boris Ostrovsky
> Cc: # 4.13
Reviewe
On 05/10/18 18:29, Ian Jackson wrote:
> From: Bastian Blank
>
> libxenstat does not have a stable ABI. Set its version to the current
> Xen release version.
>
> Signed-off-by: Ian Jackson
> ---
> tools/xenstat/libxenstat/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff
The unstable ABI version is 4.12, not 4.11
Signed-off-by: Andrew Cooper
---
CC: Ian Jackson
CC: Wei Liu
---
tools/xenstat/libxenstat/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/xenstat/libxenstat/Makefile
b/tools/xenstat/libxenstat/Makefile
index 8c6ddf8
On Tue, Oct 09, 2018 at 03:06:32PM +0100, Andrew Cooper wrote:
> The unstable ABI version is 4.12, not 4.11
>
> Signed-off-by: Andrew Cooper
Acked-by: Wei Liu
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mail
On Tue, Oct 09, 2018 at 11:42:17AM +0100, Wei Liu wrote:
> Commit 2916951c1 ("mm / iommu: include need_iommu() test in
> iommu_use_hap_pt()") included need_iommu() in iommu_use_hap_pt and
> 91d4eca7add (" mm / iommu: split need_iommu() into has_iommu_pt() and
> need_iommu_pt_sync()") made things fi
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 09 October 2018 14:38
> To: Paul Durrant
> Cc: Wei Liu ; xen-devel@lists.xenproject.org; Kevin
> Tian ; Jan Beulich ; Roger Pau
> Monne
> Subject: Re: [PATCH] x86/vtd: fix IOMMU share PT destruction path
>
> On Tue
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 09 October 2018 15:26
> To: xen-devel@lists.xenproject.org
> Cc: Jan Beulich ; Roger Pau Monne
> ; Paul Durrant ; Wei Liu
> ; Kevin Tian
> Subject: Re: [PATCH] x86/vtd: fix IOMMU share PT destruction path
>
> On Tue
On Mon, 2018-10-01 at 09:16 +0200, Juergen Gross wrote:
> The Xen specific queue spinlock wait function has two issues which
> could result in a hanging system.
>
> They have a similar root cause of clearing a pending wakeup of a
> waiting vcpu and later going to sleep waiting for the just cleared
On Tue, Oct 09, 2018 at 03:32:51PM +0100, Paul Durrant wrote:
> > -Original Message-
> > From: Wei Liu [mailto:wei.l...@citrix.com]
> > Sent: 09 October 2018 15:26
> > To: xen-devel@lists.xenproject.org
> > Cc: Jan Beulich ; Roger Pau Monne
> > ; Paul Durrant ; Wei Liu
> > ; Kevin Tian
> >
On 09/10/2018 16:40, David Woodhouse wrote:
> On Mon, 2018-10-01 at 09:16 +0200, Juergen Gross wrote:
>> The Xen specific queue spinlock wait function has two issues which
>> could result in a hanging system.
>>
>> They have a similar root cause of clearing a pending wakeup of a
>> waiting vcpu and
On Tue, Oct 9, 2018 at 7:41 AM Lars Kurth wrote:
>
> Hi all,
>
> ## Agenda
> The agenda can be found at
> https://docs.google.com/document/d/1ZfZ1SJRauLrISiTLXzM0DPxQL8beNkAQS5MwLLNtRKc/edit?usp=sharing
> The document is R/W already
I've added a last minute item I would like to discuss if po
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 09 October 2018 15:41
> To: Paul Durrant
> Cc: Wei Liu ; xen-devel@lists.xenproject.org; Jan
> Beulich ; Roger Pau Monne ; Kevin
> Tian
> Subject: Re: [PATCH] x86/vtd: fix IOMMU share PT destruction path
>
> On Tue
Commit 2916951c1 ("mm / iommu: include need_iommu() test in
iommu_use_hap_pt()") included need_iommu() in iommu_use_hap_pt and
91d4eca7add ("mm / iommu: split need_iommu() into has_iommu_pt() and
need_iommu_pt_sync()") made things finer grain by spliting need_iommu
into three states.
The destructi
tl;dr
The Debian Xen packages have had a very bad patch which I propose to
simply drop, with minor compatibility implications, unless someone
can explain what it is for and why it is still needed, and/or has a
better plan.
I have been going through delta queue in the Debian Xen package.
flight 128519 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128519/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf a7ab1c315c3cf5e804897471e992655c9b5baa0f
baseline version:
ovmf d20ae95a13e851d56c661
> -Original Message-
> From: Wei Liu [mailto:wei.l...@citrix.com]
> Sent: 09 October 2018 15:57
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Jan Beulich
> ; Roger Pau Monne ; Wei Liu
> ; Kevin Tian
> Subject: [PATCH v2] x86/vtd: fix IOMMU share PT destruction path
>
> Commit
On Tue, Oct 02, 2018 at 04:49:26PM +0100, George Dunlap wrote:
> Commit 3b4adba ("tools/libxl: include scheduler parameters in the
> output of xl list -l") added scheduling parameters to the set of
> information collected by libxl_retrieve_domain_configuration(), in
> order to report that informati
On 09/10/2018 12:25, Bharat Bhushan wrote:
Hi,
Hi Bharat,
-Original Message-
From: Julien Grall
Sent: Friday, October 5, 2018 6:51 PM
To: Bharat Bhushan ; Xen-
de...@lists.xenproject.org
Subject: Re: [Xen-devel] ARM64: PCIe in DOM0
Hi,
On 05/10/2018 12:06, Bharat Bhushan wrote:
1 - 100 of 140 matches
Mail list logo
