flight 128518 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128518/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stopfail like 128449
test-armhf-armhf-libvirt 14
Hello,
I'm developing an application that runs in Dom0 and needs to read memory
from a guest given a guest address (for instance, reading RIP from the
guest CPU context and then reading the current instruction). I'm using
xenforeignmemory_map() to map the guest memory, but this function takes the
flight 128558 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128558/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 128513
build-armhf
Hi Juergen,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/x86/core]
[also build test ERROR on v4.19-rc7 next-20181009]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
flight 128556 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128556/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 128513
build-armhf
flight 128552 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128552/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 128513
This run is configured for baseline tests only.
flight 75380 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75380/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
flight 128506 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128506/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-debianhvm-amd64 15 guest-saverestore.2 fail REGR. vs.
128156
Tests
flight 128546 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128546/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 128513
branch xen-unstable-smoke
xenbranch xen-unstable-smoke
job build-arm64-xsm
testid xen-build
Tree: qemuu git://xenbits.xen.org/qemu-xen.git
Tree: xen git://xenbits.xen.org/xen.git
*** Found and reproduced problem changeset ***
Bug is in tree: xen git://xenbits.xen.org/xen.git
Bug
Lars,
This NIST document ("A Methodology for Determining Forensic Data Requirements
for Detecting Hypervisor Attacks" [1]) appears to be focused on the application
of LibVMI in some contexts. It is a NIST Interagency or Internal Report
(NISTIR) document with a narrower scope than other NIST
flight 128540 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128540/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 128513
This run is configured for baseline tests only.
flight 75379 xen-4.11-testing real [real]
http://osstest.xensource.com/osstest/logs/75379/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
The function iommu_share_p2m_table is used by both ARM and x86 but
hap_enabled macro is x86 only. Put the ASSERT under CONFIG_X86.
Signed-off-by: Wei Liu
---
xen/drivers/passthrough/iommu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xen/drivers/passthrough/iommu.c
flight 128534 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128534/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 128513
Hi all,
I added a NIST Security Paper to the agenda which is currently under review and
is full of inaccuracies and could potentially become very problematic to the
project and vendors using Xen if officially published by NIST without being
corrected (it needs responses by the end of week). I
flight 128504 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128504/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-1 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 127900
Hi,
I'm observing a huge performance drop for memcached workload on x86
with the following commit, which was merged to Linux kernel 4.5.
Before this patch, memcached overhead is about 113% (i.e. 13% slower
than native Linux) [1], but with this patch it becomes 175%. I
observed even bigger
On Tue, 2018-10-09 at 12:59 +0200, Milan Boberic wrote:
> Hi,
>
Hi Milan,
> 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
Thanks for all the replies. I will work through them.
One remark now:
Am Mon, 1 Oct 2018 13:39:51 +0100
schrieb Andrew Cooper :
> > With the new option the host admin can decide how a domU should behave
> > when it is migrated across systems of the same class. Since there is
> > always some
flight 128527 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/128527/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 128513
Hi. Thanks for taking the time to help.
Bastian Blank writes ("Re: [Pkg-xen-devel] Ill-advised use of xs_open flag
1UL<<2 by Debian"):
> On Tue, Oct 09, 2018 at 04:04:24PM +0100, Ian Jackson wrote:
> > The Debian Xen packages have had a very bad patch which I propose to
> > simply drop,
On 10/9/18 6:41 AM, Christian Borntraeger wrote:
>
>
> On 10/09/2018 11:54 AM, Filippo Sironi wrote:
>> Start populating /sys/hypervisor with KVM entries when we're running on
>> KVM. This is to replicate functionality that's available when we're
>> running on Xen.
>>
>> Let's start with
xenbus_va_dev_error() will try to write error messages to Xenstore
under the error//error node (with something like
"device/vbd/51872"). This will fail normally and another message
about this failure is added to dmesg.
I believe this is a remnant from very ancient times, as it was added
in the
Tamas: I saw it. Thank you
On 09/10/2018, 16:13, "Andrew Cooper" wrote:
On 09/10/18 15:53, Tamas K Lengyel wrote:
> On Tue, Oct 9, 2018 at 7:41 AM Lars Kurth wrote:
>> Hi all,
>>
>> ## Agenda
>> The agenda can be found at
Hi Ian
On Tue, Oct 09, 2018 at 04:04:24PM +0100, Ian Jackson wrote:
> 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
> > >Ian, any objections?
>
> Sorry for dropping this. It's been a while!
No problem, Ian, we have this heads-up now.
>
> > >> > 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.
> > >> >
>
On 09/10/18 15:53, Tamas K Lengyel wrote:
> 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
Scrubbing RAM during boot may take a long time on machines with lots
of RAM. Add 'idle' option to bootscrub which marks all pages dirty
initially so they will eventually be scrubbed in idle-loop on every
online CPU.
It's guaranteed that the allocator will return scrubbed pages by doing
eager
On Tue, Oct 09, 2018 at 04:16:48PM +0100, George Dunlap wrote:
> On 10/09/2018 04:12 PM, Wei Liu wrote:
> > 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
On 10/09/2018 04:12 PM, Wei Liu wrote:
> 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
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
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
> -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
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
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.
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
> -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
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
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
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 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
> -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
> -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
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
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
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
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
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
> >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
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
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
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
> > >
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
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 =
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
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
>>> 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
>> > ;
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
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
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 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
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
---
>>> 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
> -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]
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
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
> -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
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
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
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
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
---
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
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:
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
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
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
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(+)
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
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 ++
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 +-
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
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)
---
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 +++
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
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
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
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
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
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
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
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
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:
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
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
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
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
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,
1 - 100 of 131 matches
Mail list logo
