This run is configured for baseline tests only.
flight 75637 xen-unstable real [real]
http://osstest.xensource.com/osstest/logs/75637/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 10 debian-di-install
On 12/5/2018 2:37 PM, Liam Merwick wrote:
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, QEMU should be able to boot directly into the
uncompressed Linux kernel binary with
The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.
Signed-off-by:
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.
There already exists
We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.
The original design for PVH entry in Xen guests relies on being able to
obtain the memory map from the hypervisor using a hypercall. When we
extend the PVH entry ABI to support other
We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.
The first step in that direction is to create a new file that will
eventually hold the Xen specific routines.
Signed-off-by: Maran Wilson
Reviewed-by: Juergen Gross
---
Once hypervisors other than Xen start using the PVH entry point for
starting VMs, we would like the option of being able to compile PVH entry
capable kernels without enabling CONFIG_XEN and all the code that comes
along with that. To allow that, we are moving the PVH code out of Xen and
into files
We need to refactor PVH entry code so that support for other hypervisors
like Qemu/KVM can be added more easily.
This patch moves the small block of code used for initializing Xen PVH
virtual machines into the Xen specific file. This initialization is not
going to be needed for Qemu/KVM guests.
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, Qemu should be able to boot directly into the
uncompressed Linux kernel binary without the need to run firmware.
There already exists
In order to pave the way for hypervisors other than Xen to use the PVH
entry point for VMs, we need to factor the PVH entry code into Xen specific
and hypervisor agnostic components. The first step in doing that, is to
create a new config option for PVH entry that can be enabled
independently from
On 05/12/2018 17:40, Jennifer Herbert wrote:
> CC: Juergen Gross
>
> On 04/12/18 17:24, Jennifer Herbert wrote:
>> Since Linux 4.12, there has been a
>> commita1e23a42f1bdc00e32fc4869caef12e4e6272f26
>>
>> “rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs”
>>
>> The commit
flight 131007 linux-4.14 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131007/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install
fail REGR. vs. 130155
flight 130991 linux-4.19 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130991/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm 7 xen-boot fail REGR. vs. 129313
flight 131069 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131069/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
On Wed, Dec 05, 2018 at 10:32:23AM +0100, Roger Pau Monné wrote:
>On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
>> I find some pass-thru devices don't work any more across guest reboot.
>> Assigning it to another guest also meets the same issue. And the only
>> way to make it work
flight 130995 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130995/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 16
guest-start/debianhvm.repeat fail REGR. vs.
Patchew URL:
https://patchew.org/QEMU/1544049446-6359-1-git-send-email-liam.merw...@oracle.com/
Hi,
This series failed the docker-mingw@fedora build test. Please find the testing
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.
=== TEST
flight 131068 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131068/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-armhf-armhf-xl
On Thu, Nov 22, 2018 at 03:49:03PM +, Wei Liu wrote:
> Break out files for build jobs and test jobs. Keep the top level
> .gitlab-ci.yaml small.
>
> Signed-off-by: Wei Liu
Good idea with this split.
Acked-by: Doug Goldstein
___
Xen-devel
For certain applications it is desirable to rapidly boot a KVM virtual
machine. In cases where legacy hardware and software support within the
guest is not needed, QEMU should be able to boot directly into the
uncompressed Linux kernel binary with minimal firmware involvement.
There already
From: Liam Merwick
Add support to read the PVH Entry address from an ELF note in the
uncompressed kernel binary (as defined by the x86/HVM direct boot ABI).
This 32-bit entry point will be used by QEMU to load the kernel in the
guest and jump into the kernel entry point.
For now, a call to this
From: Liam Merwick
The x86/HVM direct boot ABI permits Qemu to be able to boot directly
into the uncompressed Linux kernel binary without the need to run firmware.
https://xenbits.xen.org/docs/unstable/misc/pvh.html
This commit adds the header file that defines the start_info struct
These changes (along with corresponding qboot and Linux kernel changes)
enable a guest to be booted using the x86/HVM direct boot ABI.
This commit adds a load_elfboot() routine to pass the size and
location of the kernel entry point to qboot (which will fill in
the start_info struct information
On Wed, Dec 5, 2018 at 9:20 AM Julien Grall wrote:
> On 04/12/2018 09:08, Christopher Clark wrote:
> > On Sun, Dec 2, 2018 at 12:11 PM Julien Grall wrote:
> >> On 01/12/2018 01:32, Christopher Clark wrote:
> >>> diff --git a/xen/include/public/argo.h b/xen/include/public/argo.h
> >>> ...
> >>>
flight 131053 freebsd-master real [real]
http://logs.test-lab.xenproject.org/osstest/logs/131053/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-freebsd broken
From: Zhongze Liu
Add libxl__sshm_del to unmap static shared memory areas mapped by
libxl__sshm_add during domain creation. The unmapping process is:
* For a owner: decrease the refcount of the sshm region, if the refcount
reaches 0, cleanup the whole sshm path.
* For a borrower:
1) unmap
Hi all,
This series implements a new xl config entry. Users can use the new
config entry to statically setup shared memory areas among VMs that
don't have grant table support so that they could communicate with each
other through the static shared memory areas.
It was originally developed by
From: Zhongze Liu
Add a new structure to the IDL family to represent static shared memory regions
as proposed in the proposal "Allow setting up shared memory areas between VMs
from xl config file" (see [1]).
[1] https://lists.xen.org/archives/html/xen-devel/2017-08/msg03242.html
Signed-off-by:
From: Zhongze Liu
Add the parsing utils for the newly introduced libxl_static_sshm struct
to the libxl/libxlu_* family. And add realated parsing code in xl to
parse the struct from xl config files. This is for the proposal "Allow
setting up shared memory areas between VMs from xl config file"
Shared memory regions need to be advertised to the guest. Fortunately, a
device tree binding for special memory regions already exist:
reserved-memory.
Add a reserved-memory node for each shared memory region, for both
owners and borrowers.
Signed-off-by: Stefano Stabellini
---
Changes in v9:
-
From: Zhongze Liu
The existing XENMAPSPACE_gmfn_foreign subop of XENMEM_add_to_physmap forbids
a Dom0 to map memory pages from one DomU to another, which restricts some useful
yet not dangerous use cases -- such as sharing pages among DomU's so that they
can do shm-based communication.
This
From: Zhongze Liu
Add libxl__sshm_add to map shared pages from one DomU to another, The mapping
process involves the following steps:
* Set defaults and check for further errors in the static_shm configs:
overlapping areas, invalid ranges, duplicated owner domain,
not page aligned, no
From: Zhongze Liu
Author: Zhongze Liu
Add docs to document the motivation, usage, use cases and other
relevant information about the static shared memory feature.
This is for the proposal "Allow setting up shared memory areas between VMs
from xl config file". See:
flight 130989 linux-4.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130989/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-cubietruck 16 guest-start/debian.repeat fail in 130904
pass in 130989
flight 75636 distros-debian-squeeze real [real]
http://osstest.xensource.com/osstest/logs/75636/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-amd64-squeeze-netboot-pygrub 10 debian-di-install fail like
75624
On Wed, 5 Dec 2018, Stefano Stabellini wrote:
> Hi,
>
> This series implements a new xl config entry. Users can use the new
> config entry to statically setup shared memory areas among VMs that
> don't have grant table support so that they could communicate with each
> other through the static
Hi,
This series implements a new xl config entry. Users can use the new
config entry to statically setup shared memory areas among VMs that
don't have grant table support so that they could communicate with each
other through the static shared memory areas.
It was originally developed by
This run is configured for baseline tests only.
flight 75635 xen-4.8-testing real [real]
http://osstest.xensource.com/osstest/logs/75635/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-rumprun-i386 17
On 10/09/2018 11:13, Jan Beulich wrote:
>
>> Equally, it may still be able to service #MC's, so I can't see how it is
>> safe for us to ever free the percpu data.
> I'm having trouble seeing how this remark relates to the series here.
Because you've tried to make NMIs safe, but not made
On 05/12/2018 16:17, Jan Beulich wrote:
> Even if unlikely, donate_page() should not ignore the possible need to
> obtain a domain reference. To make people look more closely when they
> add new uses of domain_adjust_tot_pages(), force its return value to be
> checked. This in turn requires a
On Thu, Nov 22, 2018 at 03:49:02PM +, Wei Liu wrote:
> Also rename the old test to have -gcc suffix.
>
> Signed-off-by: Wei Liu
Acked-by: Doug Goldstein
Nice addition. Sorry for the delay.
___
Xen-devel mailing list
On 05/12/2018 16:17, Jan Beulich wrote:
> Quite a bit of duplicate code has accumulated on the "paging" types
> special case path. Re-use what can be re-used from the common path.
>
> Since it needs touching anyway, slightly re-format and extend the
> gdprintk() on the common path as well.
>
>
On Wed, Dec 05, 2018 at 02:00:43AM -0700, Jan Beulich wrote:
> >>> On 04.12.18 at 22:47, wrote:
> > --- a/xen/drivers/passthrough/amd/iommu_intr.c
> > +++ b/xen/drivers/passthrough/amd/iommu_intr.c
> > @@ -665,6 +665,24 @@ int __init amd_setup_hpet_msi(struct msi_desc
> > *msi_desc)
> >
On 22/11/2018 15:01, Jan Beulich wrote:
On 21.11.18 at 14:21, wrote:
>> --- a/xen/arch/x86/mm/p2m.c
>> +++ b/xen/arch/x86/mm/p2m.c
>> @@ -2184,24 +2184,29 @@ bool_t p2m_altp2m_lazy_copy(struct vcpu *v, paddr_t
>> gpa,
>> unsigned long mask;
>> mfn_t mfn;
>> int rv;
>> +
"3rd slot" is confusing, because it is only correct if you start counting from
the 0-th slot. Most people would expect this to be phrased as "4th slot", but
switch to the entirely unambiguous "slot 3" which is also in line with the
adjacent code.
While fixing that, update the comment to indicate
flight 130985 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130985/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-pygrub 7 xen-boot fail in 130895 pass in 130985
test-armhf-armhf-xl-rtds 6
On 05/12/2018 08:41, Jan Beulich wrote:
On 04.12.18 at 22:35, wrote:
>> The other thing I don't get is why advertise virtualized SSBD when the
>> guest setting it does nothing? If ssbd_opt=true is set, as the code is
>> now, why even advertise it to the guest? I'd suggest either allowing
On 05/12/2018 16:39, Jan Beulich wrote:
On 03.12.18 at 17:18, wrote:
>> At the time of writing, the spec is available from:
>>
>>
>> https://developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreB
>>
>> ypassDisable_Whitepaper_final.pdf
>>
>> Future hardware (Zen v2) is
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 03 December 2018 18:09
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefan Hajnoczi ; Kevin
> Wolf ; Max Reitz ; Stefano Stabellini
>
>
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 04 December 2018 12:11
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefano Stabellini ;
> Stefan Hajnoczi ; Kevin Wolf ; Max
> Reitz
>
Detect "multiboot,dtb" compatible nodes. Add them to the bootmod array
as BOOTMOD_DTB. In kernel_probe, find the right BOOTMOD_DTB and store a
pointer to it in dtb_bootmodule.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/bootfdt.c | 2 ++
xen/arch/arm/kernel.c | 12
We don't have a clear way to know how many virtual SPIs we need for the
boot domains. For simplicity, allocate as many as natively supported,
just like for dom0.
Signed-off-by: Stefano Stabellini
---
xen/arch/arm/domain_build.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff
Hi all,
This small patch series adds device assignment support to Dom0less.
The last patch is the documentation.
Cheers,
Stefano
The following changes since commit 70739427f55d595ad1c575c47fef00c81881e9a2:
pci: apply workaround for Intel errata HSE43 and BDF2/BDX2 (2018-12-04
14:04:54
Scan the user provided dtb fragment at boot. For each device node, map
memory to guests, and route interrupts and setup the iommu.
Device memory is only mapped 1:1. It is not possible to assign devices at
locations that conflict with the DomU memory map.
The iommu is setup by passing the to the
Read the dtb fragment corresponding to a passthrough device from memory
at the location referred to by the "multiboot,dtb" compatible node.
Copy the fragment to the guest dtb.
Add a dtb_bootmodule field to struct kernel_info to find the dtb
fragment for a guest.
Signed-off-by: Stefano
Signed-off-by: Stefano Stabellini
---
docs/misc/arm/device-tree/booting.txt | 108 ++
1 file changed, 108 insertions(+)
diff --git a/docs/misc/arm/device-tree/booting.txt
b/docs/misc/arm/device-tree/booting.txt
index 317a9e9..f5aaf8f 100644
---
Hi Christoffer,
On 04/12/2018 09:08, Christopher Clark wrote:
On Sun, Dec 2, 2018 at 12:11 PM Julien Grall wrote:
On 01/12/2018 01:32, Christopher Clark wrote:
diff --git a/xen/include/public/argo.h b/xen/include/public/argo.h
index 20dabc0..5ad8e2b 100644
--- a/xen/include/public/argo.h
On 05/12/2018 16:50, Jan Beulich wrote:
>
>> --- a/xen/include/asm-x86/cpufeatures.h
>> +++ b/xen/include/asm-x86/cpufeatures.h
>> @@ -25,6 +25,7 @@ XEN_CPUFEATURE(XEN_SMAP,(FSCAPINTS+0)*32+11) /*
>> SMAP gets used by Xen it
>> XEN_CPUFEATURE(LFENCE_DISPATCH, (FSCAPINTS+0)*32+12) /*
On 05/12/2018 16:57, Jan Beulich wrote:
On 03.12.18 at 17:18, wrote:
>> --- a/xen/arch/x86/cpu/amd.c
>> +++ b/xen/arch/x86/cpu/amd.c
>> @@ -419,6 +419,97 @@ static void __init noinline amd_probe_legacy_ssbd(void)
>> }
>>
>> /*
>> + * This is all a gross hack, but Xen really doesn't have
>>> On 03.12.18 at 17:18, wrote:
> --- a/xen/arch/x86/cpu/amd.c
> +++ b/xen/arch/x86/cpu/amd.c
> @@ -419,6 +419,97 @@ static void __init noinline amd_probe_legacy_ssbd(void)
> }
>
> /*
> + * This is all a gross hack, but Xen really doesn't have flexible-enough
> + * per-cpu infrastructure to
>>> On 03.12.18 at 17:18, wrote:
> +static void __init noinline amd_probe_legacy_ssbd(void)
> +{
> + uint64_t new;
> +
> + /*
> + * Search for mechanisms of controlling Memory Disambiguation.
> + *
> + * If the CPU reports that it is fixed, there is nothing to do. If we
>
CC: Juergen Gross
On 04/12/18 17:24, Jennifer Herbert wrote:
Since Linux 4.12, there has been a
commita1e23a42f1bdc00e32fc4869caef12e4e6272f26
“rtc: cmos: Do not assume irq 8 for rtc when there are no legacy irqs”
The commit effectively disabled requesting IRQ 8 for systems without PIC
>>> On 03.12.18 at 17:18, wrote:
> At the time of writing, the spec is available from:
>
>
> https://developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreB
> ypassDisable_Whitepaper_final.pdf
>
> Future hardware (Zen v2) is expect to have hardware MSR_SPEC_CTRL support,
>
>>> On 05.12.18 at 10:18, wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -1002,30 +1002,43 @@ int p2m_change_type_one(struct domain *d, unsigned
> long gfn_l,
> return rc;
> }
>
> -/* Modify the p2m type of a range of gfns from ot to nt. */
> +/* Modify the p2m
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 05 December 2018 16:26
> To: xen-devel@lists.xenproject.org
> Cc: Paul Durrant ; Anthony Perard
> ; Ian Jackson ; Wei Liu
>
> Subject: [PATCH] tools/xenstore: Document failure for
>
On Wed, Dec 05, 2018 at 12:05:23PM +, Paul Durrant wrote:
> > > +value = xs_read(xsh, XBT_NULL, path, NULL);
> >
> > The xenstore.h isn't clear about failure of this function, it is
> > supposed to return a malloced value. Do we actually need to check if value
> > is NULL?
>
> The
>>> On 05.12.18 at 03:19, wrote:
> --- a/drivers/xen/xen-pciback/pci_stub.c
> +++ b/drivers/xen/xen-pciback/pci_stub.c
> @@ -87,6 +87,55 @@ static struct pcistub_device *pcistub_device_alloc(struct
> pci_dev *dev)
> return psdev;
> }
>
> +/*
> + * Reset Xen internal MSI-X state by
Those functions can return NULL on failure, document it in the public
header.
Signed-off-by: Anthony PERARD
---
tools/xenstore/include/xenstore.h | 7 +--
tools/xenstore/xs.c | 1 +
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git
Even if unlikely, donate_page() should not ignore the possible need to
obtain a domain reference. To make people look more closely when they
add new uses of domain_adjust_tot_pages(), force its return value to be
checked. This in turn requires a benign change to assign_pages().
Signed-off-by: Jan
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 04 December 2018 14:25
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefano Stabellini
> Subject: Re: [PATCH 07/18] xen: add event channel
Quite a bit of duplicate code has accumulated on the "paging" types
special case path. Re-use what can be re-used from the common path.
Since it needs touching anyway, slightly re-format and extend the
gdprintk() on the common path as well.
Signed-off-by: Jan Beulich
---
v2: Re-base.
---
A few things I had run into while working on that issue:
1: x86: reduce code duplication in guest_remove_page()
2: make domain_adjust_tot_pages() __must_check
They don't depend on one another, they're grouped together
just because of their origin.
Jan
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 03 December 2018 15:46
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Stefano Stabellini
> Subject: Re: [PATCH 06/18] xen: add grant table
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, unless perhaps sitting on an error path
next to a call which gets changed (in which case I think the error
path better remains consistent with the respective main path).
Signed-off-by: Jan Beulich
For now only the ones used during entering/exiting of idle states are
converted. Additionally pm_idle{,_save} and lapic_timer_{on,off} can't
be converted, as they may get established rather late (when Dom0 is
already active).
Note that for patching to be deferred until after the pre-SMP initcalls
This looks to be the only frequently executed hook; don't bother
patching any other ones.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Acked-by: Andrew Cooper
---
v2: New.
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -364,7 +364,8 @@ int
For (I hope) obvious reasons only the ones used at runtime get
converted.
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
Acked-by: Andrew Cooper
---
v2: Drop open-coded numbers from macro invocations.
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -29,12 +29,12 @@
void
While we don't mean to run their objtool over our generated code, it
still seems desirable to avoid calls to further functions before a
function's frame pointer is set up.
Suggested-by: Andrew Cooper
Signed-off-by: Jan Beulich
Reviewed-by: Wei Liu
---
v6: Fix build issue with old gcc.
v5: New.
We don't need bigger alignment except when calling EFI boot or runtime
services functions (and we don't guarantee that either, as explained
close to the top of xen/common/efi/runtime.c in the struct efi_rs_state
declaration). Hence if the compiler supports reducing stack alignment
from the ABI
While not strictly necessary, change the VMX initialization logic to
update the function table in start_vmx() from NULL rather than to NULL,
to make more obvious that we won't ever change an already (explicitly)
initialized function pointer.
Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
as well as nested, VM event, and altp2m ones (they can all be done
later, if so desired). Virtual Interrupt delivery ones will be dealt
with in a subsequent
In a number of cases the targets of indirect calls get determined once
at boot time. In such cases we can replace those calls with direct ones
via our alternative instruction patching mechanism.
Some of the targets (in particular the hvm_funcs ones) get established
only in pre-SMP initcalls,
While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many other cases the indirection solely exists to abstract from e.g.
vendor specific
flight 130971 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130971/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
test-amd64-i386-xl-qemut-ws16-amd64
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 03 December 2018 14:43
> To: Paul Durrant
> Cc: qemu-bl...@nongnu.org; qemu-de...@nongnu.org; xen-
> de...@lists.xenproject.org; Kevin Wolf ; Max Reitz
> ; Stefano Stabellini
> Subject: Re: [PATCH
Current approximation of paging memory usage is based on the required
amount when running in shadow mode and doesn't take into account the
memory required by the IOMMU page tables.
Fix this by introducing a function to calculate the amount of memory
required by HAP/IOMMU page tables. The formula
To note it's calculating the approximate amount of memory required by
shadow paging.
No functional change.
Signed-off-by: Roger Pau Monné
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Wei Liu
Cc: andrei.seme...@bertin.fr
---
xen/arch/x86/dom0_build.c| 4 ++--
flight 130970 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/130970/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 7 xen-boot fail REGR.
vs. 130862
On 05.12.18 15:13, Julien Grall wrote:
I need at least some sort of proof that Xen might corrupt the kernel. I don't
believe we manage to just corrupt the kernel memory subsystem with good enough
value reliably. So maybe we should start looking at more plausible cause.
I think I would be
> -Original Message-
> From: Anthony PERARD [mailto:anthony.per...@citrix.com]
> Sent: 05 December 2018 13:59
> To: Paul Durrant
> Cc: Kevin Wolf ; Stefano Stabellini
> ; qemu-bl...@nongnu.org; qemu-de...@nongnu.org;
> Max Reitz ; xen-devel@lists.xenproject.org
> Subject: Re: [PATCH
On 12/5/18 4:32 AM, Roger Pau Monné wrote:
> On Wed, Dec 05, 2018 at 10:19:17AM +0800, Chao Gao wrote:
>> I find some pass-thru devices don't work any more across guest reboot.
>> Assigning it to another guest also meets the same issue. And the only
>> way to make it work again is un-binding and
On Wed, Dec 05, 2018 at 12:43:57PM +, Paul Durrant wrote:
> > > > +value = g_strdup_vprintf(fmt, ap);
> > >
> > > Looks like g_vasprintf() would be better, since it returns the lenght as
> > > well.
> > >
> >
> > Yes.
>
> I tried this and it appears not to exist in the version of glib in
>>> On 05.12.18 at 14:15, wrote:
> Ah ok... no, I got what you meant and just completely typo-ed it. I'll send
> v4 unless you're happy to fix on commit.
I'm fine adjusting this while committing; I hope I won't overlook the note
I've taken once I get there.
Jan
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 December 2018 13:13
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Andrew Cooper
> ; Roger Pau Monne ; Wei
> Liu ; xen-devel
> Subject: RE: [PATCH v3 1/4] amd-iommu: add flush iommu_ops
>
>
On 05/12/2018 12:40, Andrii Anisov wrote:
On 05.12.18 14:15, Julien Grall wrote:
Yes, it thinks so. But it is not linked to domain .
What do you mean?
It should be read as "But it is not linked to domain memory size".
So if you increase the memory of the dom0 you will still see the
>>> On 05.12.18 at 13:58, wrote:
>> From: Paul Durrant
>> Sent: 05 December 2018 12:57
>>
>> > From: Jan Beulich [mailto:jbeul...@suse.com]
>> > Sent: 05 December 2018 11:46
>> >
>> > >>> On 05.12.18 at 12:29, wrote:
>> > > --- a/xen/drivers/passthrough/amd/iommu_map.c
>> > > +++
> -Original Message-
> From: Paul Durrant
> Sent: 05 December 2018 12:57
> To: 'Jan Beulich'
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Andrew Cooper
> ; Roger Pau Monne ; Wei
> Liu ; xen-devel
> Subject: RE: [PATCH v3 1/4] amd-iommu: add flush iommu_ops
>
> > -Original
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 05 December 2018 11:46
> To: Paul Durrant
> Cc: Brian Woods ; Suravee Suthikulpanit
> ; Andrew Cooper
> ; Roger Pau Monne ; Wei
> Liu ; xen-devel
> Subject: Re: [PATCH v3 1/4] amd-iommu: add flush iommu_ops
>
>
> -Original Message-
> From: Qemu-devel [mailto:qemu-devel-
> bounces+paul.durrant=citrix@nongnu.org] On Behalf Of Paul Durrant
> Sent: 05 December 2018 12:05
> To: Anthony Perard
> Cc: Kevin Wolf ; Stefano Stabellini
> ; qemu-bl...@nongnu.org; qemu-de...@nongnu.org;
> Max Reitz ;
On Wed, Dec 05, 2018 at 01:06:29PM +0100, Roger Pau Monne wrote:
> diff --git a/xen/arch/x86/hvm/dom0_build.c b/xen/arch/x86/hvm/dom0_build.c
> index 2af2bd8c3d..7217b2404a 100644
> --- a/xen/arch/x86/hvm/dom0_build.c
> +++ b/xen/arch/x86/hvm/dom0_build.c
> @@ -358,6 +358,9 @@ static int __init
1 - 100 of 139 matches
Mail list logo
