Hello all,
I need to setup Xen on Snapdragon 820 platform - armv8 64 bit architecture.
Is there support available for the same ? Is there Xen implementation on
any other similar platform ?
Thanks and Regards,
Jay
___
Xen-devel mailing list
Xen-devel@lis
On 03/20/2018 10:22 PM, Takashi Iwai wrote:
On Mon, 19 Mar 2018 08:22:19 +0100,
Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello, all!
In order to provide explicit synchronization between backend and
frontend the following changes are introduced in the protocol:
- bump pro
On 20.03.2018 13:05, Michael S. Tsirkin wrote:
> On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
>> Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
>>> QEMU coding style at the moment asks for all non-system
>>> include files to be used with #include "foo.h".
>>> However this ru
On Wed, 21 Mar 2018 08:15:36 +0100,
Oleksandr Andrushchenko wrote:
>
> On 03/20/2018 10:22 PM, Takashi Iwai wrote:
> > On Mon, 19 Mar 2018 08:22:19 +0100,
> > Oleksandr Andrushchenko wrote:
> >> From: Oleksandr Andrushchenko
> >>
> >> Hello, all!
> >>
> >> In order to provide explicit synchroniza
On 03/21/2018 09:20 AM, Takashi Iwai wrote:
On Wed, 21 Mar 2018 08:15:36 +0100,
Oleksandr Andrushchenko wrote:
On 03/20/2018 10:22 PM, Takashi Iwai wrote:
On Mon, 19 Mar 2018 08:22:19 +0100,
Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hello, all!
In order to provide explici
>>> On 20.03.18 at 21:53, wrote:
> On Tue, 20 Mar 2018 03:36:57 -0600
> "Jan Beulich" wrote:
> On 19.03.18 at 22:20, wrote:
>>> On Mon, 19 Mar 2018 17:49:09 +
>>> Roger Pau Monné wrote:
On Tue, Mar 13, 2018 at 04:33:56AM +1000, Alexey Gerasimenko wrote:
> +switch (PCIE
>>> On 21.03.18 at 05:10, wrote:
> On 03/20/2018 10:35 AM, Jan Beulich wrote:
> On 15.03.18 at 21:30, wrote:
>>> If we change something in a vCPU that affects its runnability or
>>> otherwise needs the vCPU's attention, we might need to tell the scheduler
>>> about it.
>>> We are using this i
On 03/21/2018 05:06 AM, Manish Jaggi wrote:
On 03/20/2018 01:13 PM, Julien Grall wrote:
On 03/16/2018 11:58 AM, Manish Jaggi wrote:
diff --git a/xen/arch/arm/cpuerrata.c b/xen/arch/arm/cpuerrata.c
index fe9e9facbe..d49698f785 100644.
--- a/xen/arch/arm/cpuerrata.c
+++ b/xen/arch/arm/cpuerrata
On 19/03/18 14:37, Jan Beulich wrote:
> Introduce a synthetic feature flag to use alternative instruction
> patching to NOP out all code on entry/exit paths. Having NOPs here is
> generally better than using conditional branches.
>
> Also change the limit on the number of bytes we can patch in one
On 19/03/18 14:39, Jan Beulich wrote:
> Now that we zero all registers early on all entry paths, use that to
> avoid a couple of immediates here.
>
> Signed-off-by: Jan Beulich
> Acked-by: Andrew Cooper
Tested-by: Juergen Gross
Reviewed-by: Juergen Gross
Juergen
___
On 19/03/18 14:40, Jan Beulich wrote:
> The STI instances were moved (or added in the INT80 case) to meet TLB
> flush requirements. When XPTI is disabled, they can be put back where
> they were (or omitted in the INT80 case).
>
> Signed-off-by: Jan Beulich
Tested-by: Juergen Gross
Reviewed-by:
On 19/03/18 14:40, Jan Beulich wrote:
> This exposes less code pieces and at the same time reduces the range
> covered from slightly above 3 pages to a little below 2 of them.
>
> The code being moved is unchanged, except for the removal of trailing
> blanks, insertion of blanks between operands,
On 19/03/18 14:41, Jan Beulich wrote:
> ... despite quite likely the gain being rather limited.
>
> Signed-off-by: Jan Beulich
Tested-by: Juergen Gross
Reviewed-by: Juergen Gross
Juergen
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
ht
Hi,
On Wed, Mar 21, 2018 at 11:27 AM, Jayadev Kumaran wrote:
> Hello all,
>
> I need to setup Xen on Snapdragon 820 platform - armv8 64 bit architecture.
> Is there support available for the same ? Is there Xen implementation on any
> other similar platform ?
From Initial investigation(I may be
Hi Manish,
On 03/16/2018 11:58 AM, Manish Jaggi wrote:
This patch is ported to xen from linux commit
d70c7b31a60f2458f35c226131f2a01a7a98b6cf
Add a handler for reading/writing the guest's view of the ICC_BPR1_EL1
register, which is located in the ICH_VMCR_EL2.BPR1 field.
Signed-off-by: Manish
> On 20 Mar 2018, at 17:38, George Dunlap wrote:
>
> On 03/19/2018 04:37 PM, Lars Kurth wrote:
>> And this time with patch: note to myself - never try sendmail with --compose
>> again (-;
>>
>> This patch contains a proposal to change
>> https://xenproject.org/security-policy.html
>> such t
flight 121017 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121017/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 12 guest-start fail REGR. vs. 120949
Tests which
On 03/16/2018 11:58 AM, Manish Jaggi wrote:
This patch is ported to xen from linux commit:
f8b630bc542e0368886ae193d3519c832b270359
Add a handler for reading/writing the guest's view of the
ICC_IGRPEN1_EL1
The wrapping looks wrong.
register, which is located in the ICH_VMCR_EL2.VENG1 field
On 03/20/2018 03:47 PM, Daniel Vetter wrote:
On Tue, Mar 20, 2018 at 01:58:01PM +0200, Oleksandr Andrushchenko wrote:
On 03/19/2018 05:28 PM, Daniel Vetter wrote:
There should be no difference between immediate removal and delayed
removal of the drm_device from the xenbus pov. The lifetimes of
On 03/21/2018 04:58 AM, Manish Jaggi wrote:
Hi Julien,
On 03/20/2018 01:16 PM, Julien Grall wrote:
On 03/16/2018 11:58 AM, Manish Jaggi wrote:
This patchset is a Xen port of Marc's patchset.
arm64: KVM: Mediate access to GICv3 sysregs at EL2 [1]
The current RFC patchset is a subset of [1
On Tue, Mar 20, 2018 at 10:03:51PM -0500, Doug Goldstein wrote:
> Doug Goldstein (8):
> ci: add README and makefile for containers
> ci: add Dockerfile for CentOS 7.2
> ci: add Dockerfile for Ubuntu 14.04
> ci: add Dockerfile for Ubuntu 16.04
> ci: add Dockerfile for Debian jessie
> ci:
On Mon, Mar 19, 2018 at 07:43:09AM -0600, Jan Beulich wrote:
> >>> On 19.03.18 at 14:38, wrote:
> > Use the respective ARCH_CAPABILITIES MSR bit, but don't expose the MSR
> > to guests yet.
> >
> > Signed-off-by: Jan Beulich
> > Tested-by: Juergen Gross
> > Reviewed-by: Juergen Gross
> > Revie
On Wed, Mar 21, 2018 at 10:58:40AM +1000, Alexey G wrote:
> On Tue, 20 Mar 2018 08:50:48 +
> Roger Pau Monné wrote:
>
> >On Tue, Mar 20, 2018 at 05:49:22AM +1000, Alexey G wrote:
> >> On Mon, 19 Mar 2018 15:58:02 +
> >> Roger Pau Monné wrote:
> >>
> >> >On Tue, Mar 13, 2018 at 04:33:5
Hi Manish,
On 03/13/2018 03:20 PM, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
IORT has a hierarchical structure containing PCIRC nodes, IORT nodes
and SMMU nodes. Each node has with it an array of ids and a mapping
which maps a range of ids to another node's ids.
PCIRC(requesterid)->S
On Tue, Mar 20, 2018 at 09:48:56AM -0700, Maran Wilson wrote:
> 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
> wo
Title: Please drop the full stop.
On 03/13/2018 03:20 PM, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
IORT has a hierarchical structure containing PCIRC nodes, IORT nodes
and SMMU nodes. Each node has with it an array of ids and a mapping
which maps a range of ids to another node's ids
On 03/21/2018 02:59 PM, Julien Grall wrote:
Hi Manish,
Hi Julien,
On 03/13/2018 03:20 PM, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
IORT has a hierarchical structure containing PCIRC nodes, IORT nodes
and SMMU nodes. Each node has with it an array of ids and a mapping
which maps
> -Original Message-
>
> > The question is why IOREQ_TYPE_COPY -> IOREQ_TYPE_PCI_CONFIG
> > translation is a must have thing at all? It won't make handling simpler.
> > For current QEMU implementation IOREQ_TYPE_COPY (MMIO accesses for
> > MMCONFIG) would be preferable as it allows to use
On Tue, Mar 20, 2018 at 09:50:50AM -0700, Maran Wilson wrote:
> From: Boris Ostrovsky
>
> Since hvm_start_info has now been expanded to include memory map (i.e.
> e820) we need to know size of this map by the time we create
> dom->start_info_seg in alloc_magic_pages_hvm().
>
> To do so we have t
On 03/21/2018 02:15 PM, Julien Grall wrote:
On 03/21/2018 04:58 AM, Manish Jaggi wrote:
Hi Julien,
On 03/20/2018 01:16 PM, Julien Grall wrote:
On 03/16/2018 11:58 AM, Manish Jaggi wrote:
This patchset is a Xen port of Marc's patchset.
arm64: KVM: Mediate access to GICv3 sysregs at EL2
On 21/03/18 10:28, Roger Pau Monné wrote:
> On Tue, Mar 20, 2018 at 09:48:56AM -0700, Maran Wilson wrote:
>> 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 informati
Hi,
On 03/21/2018 09:34 AM, Manish Jaggi wrote:
On 03/21/2018 02:59 PM, Julien Grall wrote:
Hi Manish,
Hi Julien,
On 03/13/2018 03:20 PM, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
IORT has a hierarchical structure containing PCIRC nodes, IORT nodes
and SMMU nodes. Each node has
On Tue, Mar 20, 2018 at 09:50:51AM -0700, Maran Wilson wrote:
> From: Boris Ostrovsky
> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
> index 7cbbfd0..651b7d5 100644
> --- a/tools/libxl/libxl_x86.c
> +++ b/tools/libxl/libxl_x86.c
> @@ -582,6 +582,10 @@ static int domain_construct_
Hi Manish,
On 03/21/2018 09:38 AM, Manish Jaggi wrote:
On 03/21/2018 02:15 PM, Julien Grall wrote:
On 03/21/2018 04:58 AM, Manish Jaggi wrote:
Hi Julien,
On 03/20/2018 01:16 PM, Julien Grall wrote:
On 03/16/2018 11:58 AM, Manish Jaggi wrote:
This patchset is a Xen port of Marc's patc
flight 121022 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121022/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 7a1358bbe73e5f749c3d2f53478dc1f30720f949
baseline version:
xen 0012
On Tue, Mar 20, 2018 at 09:50:52AM -0700, Maran Wilson wrote:
> From: Boris Ostrovsky
>
> Signed-off-by: Boris Ostrovsky
> Signed-off-by: Maran Wilson
> ---
> tools/libxc/xc_dom_x86.c | 29 -
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/tools/
Title: Please drop the full stop.
On 03/13/2018 03:20 PM, mja...@caviumnetworks.com wrote:
From: Manish Jaggi
Code to query estimated IORT size for hardware domain.
IORT for hardware domain is generated using the requesterid and
deviceid map. Xen code requires the size to be predeterminded.
On 21/03/2018 09:05, Wei Liu wrote:
> On Tue, Mar 20, 2018 at 10:03:51PM -0500, Doug Goldstein wrote:
>> Doug Goldstein (8):
>> ci: add README and makefile for containers
>> ci: add Dockerfile for CentOS 7.2
>> ci: add Dockerfile for Ubuntu 14.04
>> ci: add Dockerfile for Ubuntu 16.04
>>
On 03/21/2018 03:01 AM, Doug Goldstein wrote:
> Created a new section just called 'CI' since this is adding GitLab CI
> and still leaving the old Travis CI files around. This consolidates the
> two sections and adds the new files as well as adding another Travis
> file that was missing.
>
> Signed
flight 120964 linux-next real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120964/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-xsm 20 guest-start/debian.repeat fail REGR. vs. 120866
test-armhf-armhf-lib
flight 121021 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/121021/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-xl-xsm 12 guest-start fail REGR. vs. 120949
Tests which
> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: 20 March 2018 15:16
> To: xen-devel@lists.xenproject.org
> Cc: Boris Ostrovsky ; Konrad Rzeszutek Wilk
> ; Roger Pau Monne ; Ian
> Jackson ; Wei Liu ; Andrew
> Cooper ; George Dunlap
> ; Jan Beulich ; Julien
> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: 20 March 2018 15:16
> To: xen-devel@lists.xenproject.org
> Cc: Boris Ostrovsky ; Konrad Rzeszutek Wilk
> ; Roger Pau Monne ; Jan
> Beulich ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Julien
> Grall ;
> -Original Message-
> From: Roger Pau Monne [mailto:roger@citrix.com]
> Sent: 20 March 2018 15:16
> To: xen-devel@lists.xenproject.org
> Cc: Boris Ostrovsky ; Konrad Rzeszutek Wilk
> ; Roger Pau Monne ; Jan
> Beulich ; Andrew Cooper
> ; George Dunlap
> ; Ian Jackson ; Julien
> Grall ;
For mitigation of Meltdown the current L4 page table is copied to the
cpu local root page table each time a 64 bit pv guest is entered.
Copying can be avoided in cases where the guest L4 page table hasn't
been modified while running the hypervisor, e.g. when handling
interrupts or any hypercall no
Avoid flushing the complete TLB when switching %cr3 for mitigation of
Meltdown by using the PCID feature if available.
We are using 4 PCID values for a 64 bit pv domain subject to XPTI and
2 values for the non-XPTI case:
- guest active and in kernel mode
- guest active and in user mode
- hypervis
Today cpu_info->xen_cr3 is either 0 to indicate %cr3 doesn't need to
be switched on entry to Xen, or negative for keeping the value while
indicating not to restore %cr3, or positive in case %cr3 is to be
restored.
Switch to use a flag byte instead of a negative xen_cr3 value in order
to allow %cr3
If possible use the INVPCID instruction for flushing the TLB instead of
toggling cr4.pge for that purpose.
While at it remove the dependency on cr4.pge being required for mtrr
loading, as this will be required later anyway.
Add a command line option "noinvpcid" for deactivating the use of
INVPCID
Instead of switching XPTI globally on or off add a per-domain flag for
that purpose. This allows to modify the xpti boot parameter to support
running dom0 without Meltdown mitigations. Using "xpti=nodom0" as boot
parameter will achieve that.
Move the xpti boot parameter handling to xen/arch/x86/pv
When switching to a 64-bit pv context the TLB is flushed twice today:
the first time when switching to the new address space in
write_ptbase(), the second time when switching to guest mode in
restore_to_guest.
Avoid the first TLB flush in that case.
Signed-off-by: Juergen Gross
---
V3:
- omit se
Instead of flushing the TLB from global pages when switching address
spaces with XPTI being active just disable global pages via %cr4
completely when a domain subject to XPTI is active. This avoids the
need for extra TLB flushes as loading %cr3 will remove all TLB
entries.
In order to avoid states
This patch series aims at reducing the overhead of the XPTI Meltdown
mitigation. It is based on Jan's XPTI speedup series.
Patch 1 had been posted before, the main changes in this patch are due
to addressing Jan's comments on my first version. The main objective of
that patch is to avoid copying t
On Wed, Mar 21, 2018 at 08:16:00AM +0100, Thomas Huth wrote:
> On 20.03.2018 13:05, Michael S. Tsirkin wrote:
> > On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> >> Le 20/03/2018 à 02:54, Michael S. Tsirkin a écrit :
> >>> QEMU coding style at the moment asks for all non-system
>
Am 21.03.2018 um 14:08 schrieb Michael S. Tsirkin:
> It still leaves us with a host of problems e.g. the problem of stale
> headers in the source directory.
There have already been suggestions in the past to forbid in-tree
builds. Would it help if configure would refuse to run from the root
source
On 03/21/2018 05:42 AM, Roger Pau Monné wrote:
> On Tue, Mar 20, 2018 at 09:50:51AM -0700, Maran Wilson wrote:
>> From: Boris Ostrovsky
>> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
>> index 7cbbfd0..651b7d5 100644
>> --- a/tools/libxl/libxl_x86.c
>> +++ b/tools/libxl/libxl_x86
On Wed, Mar 21, 2018 at 02:15:20PM +0100, Stefan Weil wrote:
> Am 21.03.2018 um 14:08 schrieb Michael S. Tsirkin:
> > It still leaves us with a host of problems e.g. the problem of stale
> > headers in the source directory.
>
> There have already been suggestions in the past to forbid in-tree
> bu
On 20/03/18 18:05, Paul Durrant wrote:
> Only in the legacy 'default server' case do we pass anything other than
> current->domain->domain_id, and in that case we pass the value of
> HVM_PARAM_DM_DOMAIN.
>
> The only known user of HVM_PARAM_DM_DOMAIN is qemu-trad, which always sets
I'd include the
On Wed, Mar 21, 2018 at 03:08:36PM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 21, 2018 at 08:16:00AM +0100, Thomas Huth wrote:
> > On 20.03.2018 13:05, Michael S. Tsirkin wrote:
> > > On Tue, Mar 20, 2018 at 09:58:23AM +0100, Laurent Vivier wrote:
> > >> Le 20/03/2018 à 02:54, Michael S. Tsirki
On 03/21/2018 06:07 AM, Roger Pau Monné wrote:
> On Tue, Mar 20, 2018 at 09:50:52AM -0700, Maran Wilson wrote:
>> From: Boris Ostrovsky
>>
>> Signed-off-by: Boris Ostrovsky
>> Signed-off-by: Maran Wilson
>> ---
>> tools/libxc/xc_dom_x86.c | 29 -
>> 1 file changed, 2
On Wed, Mar 21, 2018 at 01:29:53PM +, Daniel P. Berrangé wrote:
> On Wed, Mar 21, 2018 at 03:08:36PM +0200, Michael S. Tsirkin wrote:
> > On Wed, Mar 21, 2018 at 08:16:00AM +0100, Thomas Huth wrote:
> > > On 20.03.2018 13:05, Michael S. Tsirkin wrote:
> > > > On Tue, Mar 20, 2018 at 09:58:23AM
flight 120971 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120971/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm broken in
120734
test-amd64-amd64-qemuu-n
>>> On 21.03.18 at 05:47, wrote:
> From: Wei Liu
>
> In a follow-up patches, some callers will be switched to pass
> INVALID_MFN instead of zero for non-present mappings. So skip
> incrementing mfn if it is not a valid one.
>
> Signed-off-by: Wei Liu
> Signed-off-by: Julien Grall
> [Rework th
>>> On 21.03.18 at 05:47, wrote:
> +static inline unsigned long __copy_mfn_to_guest(XEN_GUEST_HANDLE(xen_pfn_t)
> hnd,
> +size_t off, mfn_t mfn)
> +{
> +xen_pfn_t mfn_ = mfn_x(mfn);
> +
> +return __copy_to_guest_offset(hnd, off, &mfn_, 1);
>
On Wed, Mar 21, 2018 at 09:37:09AM -0400, Boris Ostrovsky wrote:
> On 03/21/2018 06:07 AM, Roger Pau Monné wrote:
> > On Tue, Mar 20, 2018 at 09:50:52AM -0700, Maran Wilson wrote:
> >> From: Boris Ostrovsky
> >>
> >> Signed-off-by: Boris Ostrovsky
> >> Signed-off-by: Maran Wilson
> >> ---
> >>
On Wed, 21 Mar 2018 09:09:11 +
Roger Pau Monné wrote:
>On Wed, Mar 21, 2018 at 10:58:40AM +1000, Alexey G wrote:
[...]
>> According to public slides for the feature, both PCI conf and MMIO
>> accesses can be routed to the designated device model. It looks like
>> for this particular setup it
On Wed, 21 Mar 2018 09:36:04 +
Paul Durrant wrote:
>>
>> Although this is the most common scenario, it's not the only one
>> supported by Xen. Your proposed solution breaks the usage of multiple
>> IOREQ servers as PCI device emulators.
>
>Indeed it will, and that is not acceptable even in th
The start_info size calculated in bootlate_hvm is wrong. It should use
HVMLOADER_MODULE_MAX_COUNT instead of dom->num_modules and it doesn't
take into account the size of the modules command line.
This is not a problem so far because the actually used amount of
memory doesn't cross a page boundary
Hello,
Following two patches fix two bugs related to the mapping and handling
of the hvm_start_info.
Thanks, Roger.
Roger Pau Monne (2):
libxc/x86: fix mapping of the start_info area
libxc/x86: do not unconditionally set the module cmdline address
tools/libxc/xc_dom_x86.c | 11 +++
This will lead to writing a wrong module command line physical memory
address if no command line is actually provided.
This hasn't caused problems so far because hvmloader is the only
consumer of the modules command line, and it's unconditionally set
in that case.
Signed-off-by: Roger Pau Monné
Our current scheme is to use
#include ""
for internal headers, and
#include <>
for external ones.
Unfortunately this is not based on compiler support: from C point of
view, the "" form merely looks up headers in the current directory
and then falls back on <> directories.
Thus, for example, a s
At this moment the Debug events for the AMD architecture are not
forwarded to the monitor layer.
This patch adds the Debug event to the common capabilities, adds
the VMEXIT_ICEBP then forwards the event to the monitor layer.
Chapter 2: SVM Processor and Platform Extensions: "Note: A vector 1
exce
> -Original Message-
> From: Alexey G [mailto:x19...@gmail.com]
> Sent: 21 March 2018 14:26
> To: Roger Pau Monne
> Cc: xen-devel@lists.xenproject.org; Andrew Cooper
> ; Ian Jackson ; Jan
> Beulich ; Wei Liu ; Paul Durrant
> ; Anthony Perard ;
> Stefano Stabellini
> Subject: Re: [Xen-deve
>>> On 21.03.18 at 15:47, wrote:
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -209,6 +209,8 @@ struct hvm_function_table {
> bool_t access_w, bool_t access_x);
>
> void (*enable_msr_interception)(struct domain *d, uint32_t
On 21/03/18 14:47, Alexandru Isaila wrote:
> diff --git a/xen/include/asm-x86/hvm/hvm.h b/xen/include/asm-x86/hvm/hvm.h
> index 2376ed6..8d8c325 100644
> --- a/xen/include/asm-x86/hvm/hvm.h
> +++ b/xen/include/asm-x86/hvm/hvm.h
> @@ -209,6 +209,8 @@ struct hvm_function_table {
>
From: Oleksandr Andrushchenko
Hello!
This patch series adds support for Xen [1] para-virtualized
frontend display driver. It implements the protocol from
include/xen/interface/io/displif.h [2].
Accompanying backend [3] is implemented as a user-space application
and its helper library [4], capabl
> -Original Message-
> From: Alexey G [mailto:x19...@gmail.com]
> Sent: 21 March 2018 14:35
> To: Paul Durrant
> Cc: Roger Pau Monne ; xen-
> de...@lists.xenproject.org; Andrew Cooper ;
> Ian Jackson ; Jan Beulich ;
> Wei Liu
> Subject: Re: [Xen-devel] [RFC PATCH 07/12] hvmloader: allocat
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], capable of running as a Weston client
or DRM master.
Configuration of both backend and frontend is done via
X
On 21/03/2018 15:46, Michael S. Tsirkin wrote:
> +if (m@^\s*#include\s+"qemu/@o) {
> +s@^(\s*#include\s+)"qemu/([^"]+)"(.*)$@$1$3@o) {
> +} else {
> +s@^(\s*#include\s+)"([^"]+)"(.*)$@$1$3@o) {
> +}
Can you explain the changes in the source tree layout?
Also, s{}{} and m{} are a bit more
On Wed, Mar 21, 2018 at 04:04:29PM +0100, Paolo Bonzini wrote:
> On 21/03/2018 15:46, Michael S. Tsirkin wrote:
> > +if (m@^\s*#include\s+"qemu/@o) {
> > +s@^(\s*#include\s+)"qemu/([^"]+)"(.*)$@$1$3@o) {
> > +} else {
> > +s@^(\s*#include\s+)"([^"]+)"(.*)$@$1$3@o) {
> > +}
>
> Can you expl
On Wed, Mar 21, 2018 at 04:46:32PM +0200, Michael S. Tsirkin wrote:
> Our current scheme is to use
> #include ""
> for internal headers, and
> #include <>
> for external ones.
>
> Unfortunately this is not based on compiler support: from C point of
> view, the "" form merely looks up headers in
On 21/03/2018 16:11, Michael S. Tsirkin wrote:
>> Can you explain the changes in the source tree layout?
> include/qemu -> include/qemu/common
> include/* -> include/qemu/*
Ok, then perhaps "util" instead of common would match the source layout
more.
Paolo
> Thus one uses any qemu headers with
>
On Thu, Mar 15, 2018 at 05:31:50PM +, Anoob Soman wrote:
> --with-system-ipxe allows the user to specify ipxe rom. If this option
> is given, use system supplied ipxe instead of building and installing
> our own version
>
> Plumbing for using iPXE roms, specified with --with-system-ipxe, doesn
On Thu, Mar 15, 2018 at 05:31:51PM +, Anoob Soman wrote:
> This allows to load iPXE rom as a firmware module, instead of requiring
> it to be embedded into hvmloader.
>
> Signed-off-by: Anoob Soman
> ---
> tools/libxc/xc_dom_x86.c | 13 +
> 1 file changed, 13 insertions(+)
>
> d
On Thu, Mar 22, 2018 at 12:25:40AM +1000, Alexey G wrote:
> Roger, Paul,
>
> Here is what you suggest, just to clarify:
>
> 1. Add to Xen a new hypercall (+corresponding dmop) so QEMU can tell
> Xen where QEMU emulates machine's MMCONFIG (chipset-specific emulation
> of PCIEXBAR/HECBASE/etc mmcfg
On 03/15/2018 06:35 PM, Dario Faggioli wrote:
> From: Dario Faggioli
>
> Whether or not a vCPU has a soft-affinity which is
> effective, i.e., with the power of actually affecting
> the scheduling of the vCPU itself, happens in an
> helper function, called has_soft_affinity().
This is a bit conf
On Thu, Mar 15, 2018 at 05:31:52PM +, Anoob Soman wrote:
> Load iPXE ROM from a file pointed to by IPXE_PATH. If --with-system-ipxe
> is not specified default Xen firmware directory is picked up as
> IPXE_PATH
>
> Signed-off-by: Anoob Soman
> ---
> tools/libxl/libxl_dom.c | 12 +
On 03/15/2018 06:35 PM, Dario Faggioli wrote:
> From: Dario Faggioli
>
> For now, just as a way to give a scheduler an "heads up",
> about the fact that the affinity changed.
>
> This enables some optimizations, such as pre-computing
> and storing (e.g., in flags) facts like a vcpu being
> exclu
Am 21.03.2018 um 15:46 hat Michael S. Tsirkin geschrieben:
> Our current scheme is to use
> #include ""
> for internal headers, and
> #include <>
> for external ones.
>
> Unfortunately this is not based on compiler support: from C point of
> view, the "" form merely looks up headers in the curre
On Thu, Mar 15, 2018 at 06:51:14PM +0100, Dario Faggioli wrote:
> Hi,
>
> Version 3 of this series.
>
> v2:
> https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg02177.html
> v1:
> https://lists.xenproject.org/archives/html/xen-devel/2018-02/msg02029.html
>
> I think I've addressed
On Wed, Mar 21, 2018 at 03:19:22PM +, Daniel P. Berrangé wrote:
> On Wed, Mar 21, 2018 at 04:46:32PM +0200, Michael S. Tsirkin wrote:
> > Our current scheme is to use
> > #include ""
> > for internal headers, and
> > #include <>
> > for external ones.
> >
> > Unfortunately this is not based
On Wed, Mar 21, 2018 at 05:39:48PM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 21, 2018 at 03:19:22PM +, Daniel P. Berrangé wrote:
> > On Wed, Mar 21, 2018 at 04:46:32PM +0200, Michael S. Tsirkin wrote:
> > > Our current scheme is to use
> > > #include ""
> > > for internal headers, and
> >
On Mi, 2018-03-21 at 08:57 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 21.03.18 at 15:47, wrote:
> > --- a/xen/include/asm-x86/hvm/hvm.h
> > +++ b/xen/include/asm-x86/hvm/hvm.h
> > @@ -209,6 +209,8 @@ struct hvm_function_table {
> > bool_t access_w, bool
On Wed, Mar 21, 2018 at 04:34:39PM +0100, Kevin Wolf wrote:
> Am 21.03.2018 um 15:46 hat Michael S. Tsirkin geschrieben:
> > Our current scheme is to use
> > #include ""
> > for internal headers, and
> > #include <>
> > for external ones.
> >
> > Unfortunately this is not based on compiler suppo
On Mi, 2018-03-21 at 08:57 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 21.03.18 at 15:47, wrote:
> > --- a/xen/include/asm-x86/hvm/hvm.h
> > +++ b/xen/include/asm-x86/hvm/hvm.h
> > @@ -209,6 +209,8 @@ struct hvm_function_table {
> > bool_t access_w, bool
On Fri, Mar 16, 2018 at 06:29:24PM +, Roger Pau Monné wrote:
> On Thu, Mar 15, 2018 at 02:35:18PM -0700, Maran Wilson wrote:
> > From: Boris Ostrovsky
> >
> > Signed-off-by: Boris Ostrovsky
> > Signed-off-by: Maran Wilson
> > ---
> > tools/libxc/xc_dom_x86.c | 30 ++
On 3/21/18 6:11 AM, George Dunlap wrote:
> On 03/21/2018 03:01 AM, Doug Goldstein wrote:
>> Created a new section just called 'CI' since this is adding GitLab CI
>> and still leaving the old Travis CI files around. This consolidates the
>> two sections and adds the new files as well as adding anoth
On Wed, Mar 14, 2018 at 03:36:08PM +0100, Marek Marczykowski-Górecki wrote:
> When LIBXL_SUSPEND_NO_SAVE flag is set, no savefile will be written, but
> the domain will still be suspended (but not destroyed). The main reason
> for this functionality is to suspend the host while some domains are
> r
On Tue, Mar 20, 2018 at 05:10:09AM -0600, Jan Beulich wrote:
> >>> On 16.03.18 at 14:29, wrote:
> > This functionality is going to reside in vpci.c (and the corresponding
> > vpci.h header), and should be arch-agnostic. The handlers introduced
> > in this patch setup the basic functionality requir
On Mon, Mar 19, 2018 at 07:13:40PM +, Andrew Cooper wrote:
> The data it stores is initialised and exclusively used within
> libxl__domain_make(), with the important details written back elsewhere by
> libxl__arch_domain_save_config(). Prepare xc_config on libxl__domain_make()'s
> stack, and d
On 03/15/2018 05:51 PM, Dario Faggioli wrote:
> Make it possible to get and set a (Credit1) scheduler's
> vCPU migration delay via the SCHEDOP sysctl, from both
> libxl and xl (no change needed in libxc).
>
> Signed-off-by: Dario Faggioli
> Acked-by: Wei Liu
Reviewed-by: George Dunlap
___
1 - 100 of 216 matches
Mail list logo
