Hello Stefano,
On 30.07.18 20:48, Stefano Stabellini wrote:
Add a "Platform Support" choice with four kconfig options: QEMU, RCAR3,
MPSOC and ALL_PLAT. They enable the required options for their hardware
platform. ALL_PLAT enables all available platforms and it's the default.
It doesn't automat
>>> On 31.07.18 at 17:33, wrote:
> On Tue, Jul 31, 2018 at 08:39:22AM -0600, Jan Beulich wrote:
>> >>> On 27.07.18 at 17:31, wrote:
>> > Introduce a new iommu=inclusive generic option that supersedes
>> > iommu_inclusive_mapping. This should be a non-functional change on
>> > Intel hardware, whil
>>> On 31.07.18 at 19:19, wrote:
> On Tue, Jul 31, 2018 at 5:53 AM Jan Beulich wrote:
>> >>> On 25.07.18 at 13:49, wrote:
>> > -vcpu_altp2m(curr).veinfo_gfn = _gfn(a.u.enable_notify.gfn);
>> > -altp2m_vcpu_update_vmfunc_ve(curr);
>> > +vcpu_altp2m(v).veinfo_gfn = _gfn(a.u
On 08/01/2018 11:23 AM, Jan Beulich wrote:
On 31.07.18 at 19:19, wrote:
>> On Tue, Jul 31, 2018 at 5:53 AM Jan Beulich wrote:
>> On 25.07.18 at 13:49, wrote:
-vcpu_altp2m(curr).veinfo_gfn = _gfn(a.u.enable_notify.gfn);
-altp2m_vcpu_update_vmfunc_ve(curr);
On 01/08/2018 09:20, Jan Beulich wrote:
On 31.07.18 at 17:33, wrote:
>> On Tue, Jul 31, 2018 at 08:39:22AM -0600, Jan Beulich wrote:
>> On 27.07.18 at 17:31, wrote:
Introduce a new iommu=inclusive generic option that supersedes
iommu_inclusive_mapping. This should be a non-func
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 01 August 2018 09:21
> To: Roger Pau Monne
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu ; George Dunlap
> ; Andrew Cooper
> ; Ian Jackson ; Tim
> (Xen.org) ; Julie
On 01/08/2018 09:23, Jan Beulich wrote:
On 31.07.18 at 19:19, wrote:
>> On Tue, Jul 31, 2018 at 5:53 AM Jan Beulich wrote:
>> On 25.07.18 at 13:49, wrote:
-vcpu_altp2m(curr).veinfo_gfn = _gfn(a.u.enable_notify.gfn);
-altp2m_vcpu_update_vmfunc_ve(curr);
+
First of all I think your Cc list is too short here - all of REST should be
included imo.
>>> On 31.07.18 at 20:23, wrote:
> --- a/xen/include/xsm/dummy.h
> +++ b/xen/include/xsm/dummy.h
> @@ -535,6 +535,21 @@ static XSM_INLINE int
> xsm_map_gmfn_foreign(XSM_DEFAULT_ARG struct domain *d, str
>
On Wed, Aug 01, 2018 at 02:20:36AM -0600, Jan Beulich wrote:
> >>> On 31.07.18 at 17:33, wrote:
> > On Tue, Jul 31, 2018 at 08:39:22AM -0600, Jan Beulich wrote:
> >> >>> On 27.07.18 at 17:31, wrote:
> >> > Introduce a new iommu=inclusive generic option that supersedes
> >> > iommu_inclusive_mappi
>>> On 01.08.18 at 01:27, wrote:
> ---
> xen/arch/arm/domain_build.c | 42 +++---
> xen/arch/arm/setup.c| 7 ++-
> xen/include/asm-arm/setup.h | 3 +++
> xen/include/asm-x86/setup.h | 2 ++
The (trivial) x86 addition
Acked-by: Jan Beulich
albeit
On 07/23/2018 01:29 PM, George Dunlap wrote:
> On 07/20/2018 07:02 PM, Razvan Cojocaru wrote:
>> On 07/20/2018 08:18 PM, George Dunlap wrote:
>>> Furthermore, imagine the following scenario:
>>>
>>> * dom0 enables altp2m on domain A
>>> * dom0 switches altp2m to view 1 on domain A
>>> * dom0 enable
Delete trailing spaces and refer to XSM instead of an internal
function in the public header.
Signed-off-by: Wei Liu
---
xen/arch/x86/hvm/hvm.c | 8
xen/include/public/hvm/params.h | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/xen/arch/x86/hvm/hvm.c b/x
>>> On 01.08.18 at 01:28, wrote:
> Today Ctrl-AAA is used to switch between Xen and Dom0. Extend the
> mechanism to allow for switching between Xen, Dom0, and any of the
> initial DomU created from Xen alongside Dom0 out of information provided
> via device tree.
>
> Rename xen_rx to console_rx t
>>> On 01.08.18 at 10:32, wrote:
> On 01/08/2018 09:20, Jan Beulich wrote:
> On 31.07.18 at 17:33, wrote:
>>> On Tue, Jul 31, 2018 at 08:39:22AM -0600, Jan Beulich wrote:
>>> On 27.07.18 at 17:31, wrote:
> Introduce a new iommu=inclusive generic option that supersedes
> iommu_inc
>>> On 01.08.18 at 10:33, wrote:
>> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
>> Of Jan Beulich
>> Sent: 01 August 2018 09:21
>> >>> On 31.07.18 at 17:33, wrote:
>> > On Tue, Jul 31, 2018 at 08:39:22AM -0600, Jan Beulich wrote:
>> >> >>> On 27.07.18 at 17:31, wrot
>>> On 01.08.18 at 10:38, wrote:
> On 01/08/2018 09:23, Jan Beulich wrote:
> On 31.07.18 at 19:19, wrote:
>>> On Tue, Jul 31, 2018 at 5:53 AM Jan Beulich wrote:
>>> On 25.07.18 at 13:49, wrote:
> -vcpu_altp2m(curr).veinfo_gfn = _gfn(a.u.enable_notify.gfn);
> -alt
On 08/01/2018 10:03 AM, Wei Liu wrote:
> Delete trailing spaces and refer to XSM instead of an internal
> function in the public header.
>
> Signed-off-by: Wei Liu
Reviewed-by: George Dunlap
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
>>> On 01.08.18 at 11:03, wrote:
> Delete trailing spaces and refer to XSM instead of an internal
> function in the public header.
>
> Signed-off-by: Wei Liu
Acked-by: Jan Beulich
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://l
On Tue, Jul 31, 2018 at 10:19:05PM +0200, Marek Marczykowski-Górecki wrote:
> Signed-off-by: Marek Marczykowski-Górecki
> ---
> This is on top of "tools/gdbsx: fix 'g' packet response for 64bit
> guests" patch.
> ---
> tools/debugger/gdbsx/gx/gx_local.c | 17 +-
> tools/debugger/gdbsx/gx
On 01/08/2018 10:10, Jan Beulich wrote:
>> Furthermore, on by default is the only reasonable option. Dom0 is
>> specifically given cpu mappings of the reserved regions, therefore it
>> should have matching IOMMU mappings.
> I don't think I can uniformly agree with this: There are reserved
> region
Hi,
On 31/07/18 19:23, Stefano Stabellini wrote:
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
masters and slaves.
Signed
On 01/08/2018 10:14, Jan Beulich wrote:
On 01.08.18 at 10:38, wrote:
>> On 01/08/2018 09:23, Jan Beulich wrote:
>> On 31.07.18 at 19:19, wrote:
On Tue, Jul 31, 2018 at 5:53 AM Jan Beulich wrote:
On 25.07.18 at 13:49, wrote:
>> -vcpu_altp2m(curr).veinfo_gfn = _
On 01/08/18 00:27, Stefano Stabellini wrote:
Move a few constants defined by libxl_arm.c to
xen/include/public/device_tree_defs.h, so that they can be used from Xen
and libxl. Prepend GUEST_ to avoid conflicts.
Move the DT_IRQ_TYPE* definitions from libxl_arm.c to
public/device_tree_defs.h. Us
On Wed, Aug 01, 2018 at 10:19:17AM +0100, Wei Liu wrote:
> On Tue, Jul 31, 2018 at 10:19:05PM +0200, Marek Marczykowski-Górecki wrote:
> > Signed-off-by: Marek Marczykowski-Górecki
> > ---
> > This is on top of "tools/gdbsx: fix 'g' packet response for 64bit
> > guests" patch.
> > ---
> > tools/d
Hi Stefano,
On 01/08/18 00:27, 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 v3:
- add patch
---
docs/misc/arm/dom0less | 47
Hi Stefano,
On 01/08/18 00:27, Stefano Stabellini wrote:
In order to make make_memory_node and make_hypervisor_node more
reusable, do not pass them dt_host. As they only use it to calculate
addrcells and sizecells, pass addrcells and sizecells directly.
Signed-off-by: Stefano Stabellini
Acke
Hi Stefano,
On 01/08/18 00:27, Stefano Stabellini wrote:
In the case of domUs, evtchn_irq is allocated by arch_domain_create and
set to GUEST_EVTCHN_PPI.
To make make_hypervisor_node more reusable, move the call to
evtchn_allocate out of make_hypervisor_node, to the dom0 specific caller
(handle
flight 125723 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125723/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 6aaa9fb308171ec58ddf4cf058ad5341f81a65cf
baseline version:
xen acd0
On 01/08/18 00:27, Stefano Stabellini wrote:
acpi_make_chosen_node is actually generic and can be reused. Rename it
to make_chosen_node and make it available to non-ACPI builds.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
---
Removed Julien's ack due to small change below
C
>>> On 01.08.18 at 11:20, wrote:
> On 01/08/2018 10:10, Jan Beulich wrote:
>>> Furthermore, on by default is the only reasonable option. Dom0 is
>>> specifically given cpu mappings of the reserved regions, therefore it
>>> should have matching IOMMU mappings.
>> I don't think I can uniformly agre
>>> On 11.07.18 at 15:15, wrote:
> 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 exist
On 01/08/18 10:59, Jan Beulich wrote:
On 01.08.18 at 11:20, wrote:
>> On 01/08/2018 10:10, Jan Beulich wrote:
Furthermore, on by default is the only reasonable option. Dom0 is
specifically given cpu mappings of the reserved regions, therefore it
should have matching IOMMU mapp
On Wed, Aug 01, 2018 at 10:33:23AM +0100, Wei Liu wrote:
> On Wed, Aug 01, 2018 at 10:19:17AM +0100, Wei Liu wrote:
> > On Tue, Jul 31, 2018 at 10:19:05PM +0200, Marek Marczykowski-Górecki wrote:
> > > Signed-off-by: Marek Marczykowski-Górecki
> > >
> > > ---
> > > This is on top of "tools/gdbsx:
Hi Stefano,
On 01/08/18 00:27, 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 bootmo
To select the iommu configuration used by Dom0. This option supersedes
iommu=dom0-strict|dom0-passthrough.
No functional change.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Ian Jackson
Cc: Jan Beulich
Cc: Julien Gra
Remove the handling for different page sizes now that ia64 is gone.
No functional change.
Reported by: Jan Beulich
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
Cc: Kevin Tian
---
xen/drivers/passthrough/vtd/x86/vtd.c | 17 -
1 file changed,
Several people have reported hardware issues (malfunctioning USB
controllers) due to iommu page faults on Intel hardware. Those faults
are caused by missing RMRR (VTd) entries in the ACPI tables. Those can
be worked around on VTd hardware by manually adding RMRR entries on
the command line, this is
Hello,
The following series implement a workaround for missing RMRR
entries for a PVH Dom0. It's based on the iommu_inclusive_mapping VTd
option.
The PVH workaround identity maps all regions marked as reserved in the
memory map.
Note that this workaround is enabled by default on Intel hardware.
So it's done before the iommu is initialized. This is required in
order to be able to fetch the MMCFG regions from the domain struct.
No functional change.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- New in this version.
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arch/x86/hvm/d
Introduce a new dom0-iommu=inclusive generic option that supersedes
iommu_inclusive_mapping. The prevcious behaviour is preserved and the
option should only be enabled by default on Intel hardware.
No functional change intended.
Signed-off-by: Roger Pau Monné
---
Changes since v1:
- Use dom0-io
Hi Stefano,
On 01/08/18 00:27, Stefano Stabellini wrote:
Don't add duplicate boot modules (same kind and same start address).
Please explain why you don't want to duplicate it.
Mark kernels and ramdisks of "xen,domain" nodes as BOOTMOD_KERNEL_DOMAIN
and BOOTMOD_RAMDISK_DOMAIN respectively,
On 01/08/18 12:03, Roger Pau Monne wrote:
> @@ -1198,6 +1204,32 @@ detection of systems known to misbehave upon accesses
> to that port.
>
> >> Enable IOMMU debugging code (implies `verbose`).
>
> +### dom0-iommu
> +> `= List of [ none | strict | relaxed ]`
> +
> +> Sub-options are of boolean
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Roger Pau Monne
> Sent: 01 August 2018 12:04
> To: xen-devel@lists.xenproject.org
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu ; Suravee
> Suthikulpanit ; George Dunlap
> ; Andrew Coop
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Roger Pau Monne
> Sent: 01 August 2018 12:04
> To: xen-devel@lists.xenproject.org
> Cc: Kevin Tian ; Roger Pau Monne
>
> Subject: [Xen-devel] [PATCH v2 1/5] iommu/vtd: cleanup
> vtd_set_hw
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Roger Pau Monne
> Sent: 01 August 2018 12:04
> To: xen-devel@lists.xenproject.org
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu ; George Dunlap
> ; Andrew Cooper
> ; Ian Jackson ; Tim
>
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Roger Pau Monne
> Sent: 01 August 2018 12:04
> To: xen-devel@lists.xenproject.org
> Cc: Stefano Stabellini ; Wei Liu
> ; George Dunlap ;
> Andrew Cooper ; Ian Jackson
> ; Tim (Xen.org) ; Ju
Hi,
On 01/08/18 00:28, Stefano Stabellini wrote:
Introduce an allocate_memory function able to allocate memory for DomUs
and map it at the right guest addresses, according to the guest memory
map: GUEST_RAM0_BASE and GUEST_RAM1_BASE.
Signed-off-by: Stefano Stabellini
---
Changes in v3:
- new p
flight 125695 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125695/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl broken
test-armhf-armhf-xl
If the EPTP pointer can't be located in the altp2m list, the domain
is (legitimately) crashed.
Under those circumstances, execution will continue and guarentee to hit the
BUG_ON(idx >= MAX_ALTP2M) (unfortunately, just out of context).
Return from vmx_vmexit_handler() after the domain_crash(), whi
On 08/01/2018 03:07 PM, Andrew Cooper wrote:
> If the EPTP pointer can't be located in the altp2m list, the domain
> is (legitimately) crashed.
>
> Under those circumstances, execution will continue and guarentee to hit the
> BUG_ON(idx >= MAX_ALTP2M) (unfortunately, just out of context).
>
> Ret
There is no need for the syncrhonous varient, as the vmentry failure path can
just return to processing softirqs.
This is in aid of trying to remove domain_crash_syncrhonous() from the
codebase.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Jun Nakajima
CC: Kevin Tian
---
xen/arch/x86
>>> On 01.08.18 at 14:55, wrote:
> There is no need for the syncrhonous varient, as the vmentry failure path can
> just return to processing softirqs.
>
> This is in aid of trying to remove domain_crash_syncrhonous() from the
> codebase.
>
> Signed-off-by: Andrew Cooper
With the name of the fu
flight 125729 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125729/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
domain_crash_synchronous() is unsafe to use in general as it may leave
spinlocks held, temporary memory allocated, etc.
With domain_crash_synchronous() removed from the ARM code in 4.11, take the
opportunity to remove the infrastructure completely by opencoding the softirq
loop in the remaining ca
This patch adds a new method to the VT-d IOMMU implementation to find the
MFN currently mapped by the specified BFN along with a wrapper function in
generic IOMMU code to call the implementation if it exists.
This functionality will be used by a subsequent patch.
Signed-off-by: Paul Durrant
Revi
This patch adds an iommu_op to allow the domain IOMMU reserved ranges to be
queried by the guest.
NOTE: The number of reserved ranges is determined by system firmware, in
conjunction with Xen command line options, and is expected to be
small. Thus, to avoid over-complicating the code,
...to simplify the implementation and turn need_iommu back into a boolean.
As noted in [1] the tri-state nature of need_iommu after commit 3e06b989 is
confusing, as is the implementation of pre-emption using relmem_list.
This patch instead uses a simple count of pages already populated stored in
The idea of a paravirtual IOMMU interface was last discussed on xen-devel
several years ago and narrowed down on a draft specification [1].
There was also an RFC patch series posted with an implementation, however
this was never followed through.
In this patch series I have tried to simplify the i
...meaning 'bus frame number' i.e. a frame number mapped in the IOMMU
rather than the MMU.
This patch is a largely cosmetic change that substitutes the terms 'gfn'
and 'gaddr' for 'bfn' and 'baddr' in all the places where the frame number
or address relate to the IOMMU rather than the MMU.
The pa
Turn iommu_map/unmap_page() into straightforward wrappers that check the
existence of the relevant iommu_op and call through to it. This makes them
usable by PV IOMMU code to be delivered in future patches.
Leave the decision on whether to invoke domain_crash() up to the caller.
This has the added
This patch modifies the methods in struct iommu_ops to use type-safe BFN
and MFN. This follows on from the prior patch that modified the functions
exported in xen/iommu.h.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
---
Cc: Suravee Suthikulpanit
Cc: Jan Beulich
Cc: Kevin Tian
Cc: Andrew
Ranges that should be considered reserved in the IOMMU are not necessarily
limited to RMRRs. If iommu_inclusive_mapping is set then any frame number
falling within an E820 reserved region should also be considered as
reserved in the IOMMU.
This patch adds a rangeset to the domain_iommu structure th
This patch modifies the declaration of the entry points to the IOMMU
sub-system to use bfn_t and mfn_t in place of unsigned long. A subsequent
patch will similarly modify the methods in the iommu_ops structure.
Signed-off-by: Paul Durrant
Reviewed-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Coop
>>> On 01.08.18 at 15:29, wrote:
> domain_crash_synchronous() is unsafe to use in general as it may leave
> spinlocks held, temporary memory allocated, etc.
>
> With domain_crash_synchronous() removed from the ARM code in 4.11, take the
> opportunity to remove the infrastructure completely by ope
This patch introduces the boilerplate for a new hypercall to allow a
domain to control IOMMU mappings for its own pages.
Whilst there is duplication of code between the native and compat entry
points which appears ripe for some form of combination, I think it is
better to maintain the separation as
On Wed, Aug 01, 2018 at 02:29:35PM +0100, Andrew Cooper wrote:
> domain_crash_synchronous() is unsafe to use in general as it may leave
> spinlocks held, temporary memory allocated, etc.
>
> With domain_crash_synchronous() removed from the ARM code in 4.11, take the
> opportunity to remove the inf
This patch adds an iommu_op which checks whether it is possible or
safe for a domain to modify its own IOMMU mappings and, if so, creates
a rangeset to track modifications.
NOTE: The actual map and unmap operations are introduced by subsequent
patches.
Signed-off-by: Paul Durrant
---
Cc: J
This patch adds iommu_ops to add (map) or remove (unmap) frames in the
domain's IOMMU mappings, and an iommu_op to synchronize (flush) those
manipulations with the hardware.
Mappings added by the map operation are tracked and only those mappings
may be removed by a subsequent unmap operation. Fram
This patch allows a domain to add or remove foreign frames from its
IOMMU mappings by grant reference as well as GFN. This is necessary,
for example, to support a PV network backend that needs to construct a
packet buffer that can be directly accessed by a NIC.
Signed-off-by: Paul Durrant
---
Cc:
The name 'iommu_use_hap_pt' suggests that that P2M table is in use as the
domain's IOMMU pagetable which, prior to this patch, is not strictly true
since the macro did not test whether the domain actually has IOMMU
mappings.
Signed-off-by: Paul Durrant
---
Cc: Jun Nakajima
Cc: Kevin Tian
Cc: Ge
...for some uses of get_page_from_gfn().
There are many occurences of the following pattern in the code:
q = ? P2M_ALLOC : P2M_UNSHARE;
page = get_page_from_gfn(d, gfn, &p2mt, q);
if ( p2m_is_paging(p2mt) )
{
if ( page )
put_page(page);
p2m_mem_pagin
The name 'need_iommu' is a little confusing as it suggests a domain needs
to use the IOMMU but something might not be set up yet, when in fact it
doesn't become true until IOMMU mappings for the domain have been created.
Two different meanings are also inferred from it in various places in the
cod
On 01/08/18 14:50, Roger Pau Monné wrote:
> On Wed, Aug 01, 2018 at 02:29:35PM +0100, Andrew Cooper wrote:
>> domain_crash_synchronous() is unsafe to use in general as it may leave
>> spinlocks held, temporary memory allocated, etc.
>>
>> With domain_crash_synchronous() removed from the ARM code in
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Roger Pau Monné
> Sent: 01 August 2018 14:50
> To: Andrew Cooper
> Cc: Julien Grall ; Stefano Stabellini
> ; Wei Liu ; Jan Beulich
> ; Xen-devel
> Subject: Re: [Xen-devel] [PATCH] xen: Re
When putting CPUs to sleep permanently, we should try to put them into
the most power conserving state possible. For now it is unclear whether,
especially in a deep C-state, the P-state also matters, so this series only
arranges for the C-state side of things (plus some cleanup).
1: x86/cpuidle: r
On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
wrote:
> When qemu is running in stubdomain, any attempt to initialize vnc/sdl
> there will crash it (on failed attempt to load a keymap from a file). If
> vfb is present, all those cases are skipped. But since
> b053f0c4c9e533f3d97837cf
On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
wrote:
> From: Eric Shelton
>
> This enum gives the ability to select between a MiniOS-based QEMU
> traditional stub domain and a Linux-based QEMU upstream stub domain. To
> use the Linux-based stubdomain, the following two lines shoul
On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
wrote:
> From: Eric Shelton
>
> This patch creates an appropriate command line for the QEMU instance
> running in a Linux-based stubdomain.
>
> NOTE: a number of items are not currently implemented for Linux-based
> stubdomains, such as
On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
wrote:
> From: Eric Shelton
>
> This will build a Linux-based stubdomain with QEMU upstream.
>
> Signed-off-by: Eric Shelton
>
> Simon:
> * use initramfs instead of disk with rootfs
> * don't initialize qmp (unused in Qubes)
> * Mak
flight 125698 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/125698/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-shadow 20 guest-start/debian.repeat fail in 125677 pass in
125698
test-armhf-armhf-xl
On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
wrote:
> From: Simon Gaiser
>
> There is no QMP socket access, re-use the same mechanism as for MiniOS
> based stubdom.
Later you add some QMP support. Is this preferred because your QMP
support is unreliable?
> @@ -1010,7 +1011,15
On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
wrote:
> The forced vkb device is meant for better performance of qemu access
> (at least according to ebbd2561b4cefb299f0f68a88b2788504223de18 "libxl:
> Add a vkbd frontend/backend pair for HVM guests"), which isn't used if
> there is n
This run is configured for baseline tests only.
flight 75032 xen-unstable real [real]
http://osstest.xensource.com/osstest/logs/75032/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-4 63 xtf/test-hvm64-xsa-204
In order to be able to wake parked CPUs from default_dead_idle(), the
function must not itself loop. Move the loop into play_dead(), and use
play_dead() as well on the AP boot error path.
Furthermore, not the least considering the comment in play_dead(),
make sure NMI raised (for now this would be
The address of an array slot can't be NULL. Instead add a bounds check
to make sure the array indexing is valid (the check is against 2 since
slot zero of the array - corresponding to C0 - is of no interest here).
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/acpi/cpu_idle.c
+++ b/xen/arch/x86/a
When the mwait-idle driver isn't used, C-state information becomes
available only in the course of Dom0 starting up. Use the provided data
to allow parked CPUs to sleep in a more energy efficient way, by waking
them briefly (via NMI) once the data has been recorded.
This involves re-arranging how/
Don't log the same global information once per CPU. Don't log the same
information (here: the currently active state) twice. Don't prefix
decimal numbers with zeros (giving the impression they're octal). Use
format specifiers matching the type of the corresponding expressions.
Don't split printk()-
This is presumably more power efficient than keeping them in a HLT loop,
and I supposed also the state in which they're being handed off by
firmware.
Split off from wakeup_secondary_cpu() the code to assert/deassert INIT
(and in turn also recurring wait-for-send-completion code), and re-use
it fro
On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
wrote:
> Rely on a wrapper script in stubdomain to attach FD 3/4 of qemu to
> relevant consoles.
Should FD 3 & 4 be defined in some header? That's not useful from a
wrapper shell script, but it should be documented somewhere.
Reviewed
On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
wrote:
> This allows using arguments with spaces, like -append.
> Stubdomain side of this require "xenstore-client: Add option for raw
> in-/output" commit.
I had to look up \x1b - it is ascii escape. Since I was on the
www.asciitable.
On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
wrote:
No Signed-off-by
> ---
> docs/man/xl.cfg.pod.5.in | 23 +++
> tools/xl/xl_parse.c | 7 +++
> 2 files changed, 26 insertions(+), 4 deletions(-)
>
> diff --git a/docs/man/xl.cfg.pod.5.in b/docs/man/x
On Wed, Aug 01, 2018 at 10:26:06AM -0400, Jason Andryuk wrote:
> On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
> wrote:
> > From: Eric Shelton
> >
> > This will build a Linux-based stubdomain with QEMU upstream.
> >
> > Signed-off-by: Eric Shelton
> >
> > Simon:
> > * use initram
On 01/08/18 15:31, Jan Beulich wrote:
> The address of an array slot can't be NULL. Instead add a bounds check
> to make sure the array indexing is valid (the check is against 2 since
> slot zero of the array - corresponding to C0 - is of no interest here).
>
> Signed-off-by: Jan Beulich
Wouldn't
On 01/08/18 15:33, Jan Beulich wrote:
> Don't log the same global information once per CPU. Don't log the same
> information (here: the currently active state) twice. Don't prefix
> decimal numbers with zeros (giving the impression they're octal). Use
> format specifiers matching the type of the co
On Ma, 2018-07-31 at 07:08 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 25.07.18 at 14:14, wrote:
> > This patch is focused on moving the for loop to the caller so
> > now we can save info for a single vcpu instance with the save_one
> > handlers.
> >
> > Signed-off-by: Alexandru Isa
On Wed, Aug 1, 2018 at 10:37 AM, Marek Marczykowski-Górecki
wrote:
> On Wed, Aug 01, 2018 at 10:26:06AM -0400, Jason Andryuk wrote:
>> On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
>> wrote:
>> > From: Eric Shelton
>> >
>> > This will build a Linux-based stubdomain with QEMU upstr
On Ma, 2018-07-31 at 06:16 -0600, Jan Beulich wrote:
> >
> > >
> > > >
> > > > On 25.07.18 at 14:14, wrote:
> > This is used to save data from a single instance.
> >
> > Signed-off-by: Alexandru Isaila
> >
> > ---
> > Changes since v11:
> > - hvm_save_mtrr_msr() now returns err from
> >
>>> On 01.08.18 at 16:57, wrote:
> On Ma, 2018-07-31 at 06:16 -0600, Jan Beulich wrote:
>> > > > On 25.07.18 at 14:14, wrote:
>> > --- a/xen/arch/x86/hvm/mtrr.c
>> > +++ b/xen/arch/x86/hvm/mtrr.c
>> > @@ -718,52 +718,59 @@ int hvm_set_mem_pinned_cacheattr(struct
>> > domain *d,
>> > uint64_t gfn
>>> On 01.08.18 at 16:50, wrote:
> On Ma, 2018-07-31 at 07:08 -0600, Jan Beulich wrote:
>> >
>> > >
>> > > >
>> > > > On 25.07.18 at 14:14, wrote:
>> > This patch is focused on moving the for loop to the caller so
>> > now we can save info for a single vcpu instance with the save_one
>> > hand
>>> On 01.08.18 at 16:33, wrote:
> On 01/08/18 15:31, Jan Beulich wrote:
>> The address of an array slot can't be NULL. Instead add a bounds check
>> to make sure the array indexing is valid (the check is against 2 since
>> slot zero of the array - corresponding to C0 - is of no interest here).
>>
1 - 100 of 138 matches
Mail list logo
