On Fri, 10 Jan 2020 22:41:48 +0300
Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy
> ---
>
Reviewed-by: Greg Kurz
> CC: Cornelia Huck
> CC: Eric Blake
> CC: Kevin Wolf
> CC: Max Reitz
> CC: Greg Kurz
> CC: Stefan Hajnoczi
> CC: Stefano Stabellini
>
On Tue, 2020-01-14 at 16:29 +, Julien Grall wrote:
> > That's the point in appending an IND_WRITE64 operation to the kimage
> > stream. The actual write is done in the last gasp of kexec_reloc()
> > after Xen#1 is quiescent, on the way into purgatory.
>
> I was not sure what you meant by
flight 146077 xen-4.11-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146077/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386-xsm6 xen-buildfail REGR. vs. 144753
flight 146076 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146076/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-credit1 18 guest-localmigrate/x10 fail REGR. vs. 144798
flight 146078 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146078/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64 6 xen-buildfail REGR. vs. 145017
flight 146075 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146075/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
144758
Since qemu-xen can now run in stubdomain too, handle this case when
checking it's state too.
Signed-off-by: Marek Marczykowski-Górecki
---
tools/libxl/libxl_dm.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
index
Since we have those generated files committed to the repo (why?!),
update them after changing configure.ac.
Signed-off-by: Marek Marczykowski-Górecki
---
configure | 14 +-
docs/configure| 14 +-
stubdom/configure | 14 +-
tools/config.h.in | 3
General idea is to allow freely set device_model_version and
device_model_stubdomain_override and choose the right options based on this
choice.
Also, allow to specific path to stubdomain kernel/ramdisk, for greater
flexibility.
First two patches add documentation about expected
libxenvchan.h include xenevtchn.h and xengnttab.h, so applications built
with it needs applicable -I in CFLAGS too.
Signed-off-by: Marek Marczykowski-Górecki
---
tools/Rules.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/Rules.mk b/tools/Rules.mk
index
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:
- save/restore
- QMP socket
- graphics output (e.g., VNC)
Signed-off-by: Eric
Add documentation for upcoming Linux stubdomain for qemu-upstream.
Signed-off-by: Marek Marczykowski-Górecki
---
docs/misc/stubdom.txt | 50 -
1 file changed, 50 insertions(+)
diff --git a/docs/misc/stubdom.txt b/docs/misc/stubdom.txt
index
Qemu supports only 4 emulated IDE disks, when given more (or with higher
indexes), it will fail to start. Since the disks can still be accessible
using PV interface, just ignore emulated path and log a warning, instead
of rejecting the configuration altogether.
Signed-off-by: Marek
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
b053f0c4c9e533f3d97837cf897eb920b8355ed3 "libxl: do not start dom0 qemu
for stubdomain when not
Add a simple proxy for tunneling socket connection over vchan. This is
based on existing vchan-node* applications, but extended with socket
support. vchan-socket-proxy serves both as a client and as a server,
depending on parameters. It can be used to transparently communicate
with an application
Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Jason Andryuk
---
docs/man/xl.cfg.5.pod.in | 23 +++
tools/xl/xl_parse.c | 7 +++
2 files changed, 26 insertions(+), 4 deletions(-)
diff --git a/docs/man/xl.cfg.5.pod.in b/docs/man/xl.cfg.5.pod.in
index
Until xenconsoled learns how to handle multiple consoles, this is needed
for save/restore support (qemu state is transferred over secondary
consoles).
Additionally, Linux-based stubdomain waits for all the backends to
initialize during boot. Lack of some console backends results in
stubdomain
Do not prohibit anymore using stubdomain with qemu-xen.
To help distingushing MiniOS and Linux stubdomain, add helper inline
functions libxl__stubdomain_is_linux() and
libxl__stubdomain_is_linux_running(). Those should be used where really
the difference is about MiniOS/Linux, not
This allows using arguments with spaces, like -append, without
nominating any special "separator" character.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- previous version of this patch "libxl: use \x1b to separate qemu
arguments for linux stubdomain" used specific
Rely on a wrapper script in stubdomain to attach FD 3/4 of qemu to
relevant consoles.
Signed-off-by: Marek Marczykowski-Górecki
---
Changes in v3:
- adjust for qmp_ev*
- assume specific fdset id in qemu set in stubdomain
---
tools/libxl/libxl_dm.c | 23 +++
Let the server know when the client is connected. Otherwise server will
notice only when client send some data.
This change does not break existing clients, as libvchan user should
handle spurious notifications anyway (for example acknowledge of remote
side reading the data).
Signed-off-by: Marek
Add documentation based on reverse-engineered toolstack-ioemu stubdomain
protocol.
Signed-off-by: Marek Marczykowski-Górecki
---
docs/misc/stubdom.txt | 53 -
1 file changed, 53 insertions(+)
diff --git a/docs/misc/stubdom.txt b/docs/misc/stubdom.txt
Access to QMP of QEMU in Linux stubdomain is possible over vchan
connection. Handle the actual vchan connection in a separate process
(vchan-socket-proxy). This simplified integration with QMP (already
quite complex), but also allows preliminary filtering of (potentially
malicious) QMP input.
QEMU running in a stubdom needs to be able to set INTX_DISABLE, and the
MSI(-X) enable flags in the PCI config space. This adds an attribute
'allow_interrupt_control' which when set for a PCI device allows writes
to this flag(s). The toolstack will need to set this for stubdoms.
When enabled,
When booting via EFI, the EFI memory map has information about memory
regions and their type. Improve the check for the type and attribute of
each memory region to figure out whether it is usable memory or not.
This patch brings the check on par with Linux v5.5-rc6 and makes more
memory reusable
flight 146085 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146085/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
On Tue, 14 Jan 2020, Julien Grall wrote:
> Hi Brian,
>
> On 10/01/2020 01:26, Brian Woods wrote:
> > Modify the smmu driver so that it uses the iommu_fwspec helper
> > functions. This means both ARM IOMMU drivers will both use the
> > iommu_fwspec helper functions, making enabling generic device
Hi Brian,
On 10/01/2020 01:26, Brian Woods wrote:
Modify the smmu driver so that it uses the iommu_fwspec helper
functions. This means both ARM IOMMU drivers will both use the
iommu_fwspec helper functions, making enabling generic device tree
bindings in the SMMU driver much cleaner.
Hi Guys,
I'm currently using XEN in order to run side-by-side a DOM-0 with a DOM-U
guest. My use-case scenario requires in the DOM-U direct access to some
dma-capable devices such ethernet and some GPUs.
Since our target platform (i.MX8MM) does not support IOMMU, we can't assign
dma-capable
Hi Brian,
Thank you for the patch.
On 10/01/2020 01:26, Brian Woods wrote:
Restructure some of the code and add supporting functions for adding
generic device tree (DT) binding support. The normal add_device and
dt_xlate functions are wrappers of the legacy functions due to legacy
calls
flight 146091 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146091/
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
On 14/01/2020 20:35, Andrew Cooper wrote:
Xen inherited its list infrastructure from Linux. One area where has fallen
behind is that of prefetching, which as it turns out is a performance penalty
in most cases.
Prefetch of NULL on x86 is now widely measured to have glacial performance
Xen inherited its list infrastructure from Linux. One area where has fallen
behind is that of prefetching, which as it turns out is a performance penalty
in most cases.
Prefetch of NULL on x86 is now widely measured to have glacial performance
properties, and will unconditionally hit on every
If ITSC is not available on CPU (e.g if running nested as PV shim)
then X86_FEATURE_NONSTOP_TSC is not advertised in certain cases, i.e.
all AMD and some old Intel processors. In which case TSC would need to
be restored on CPU from platform time by Xen upon exiting deep C-states.
As platform time
On Tue, Jan 14, 2020 at 12:30:02AM +0100, Rafael J. Wysocki wrote:
> On Mon, Jan 13, 2020 at 10:50 PM Rafael J. Wysocki wrote:
> >
> > On Mon, Jan 13, 2020 at 1:43 PM Peter Zijlstra wrote:
> > >
> > > On Mon, Jan 13, 2020 at 11:43:18AM +, Singh, Balbir wrote:
> > > > For your original
On 14/01/2020 16:45, Jan Beulich wrote:
> On 13.01.2020 18:50, Andrew Cooper wrote:
>> The build-time construction of l2_xenmap[] imposes an arbitrary limit of 16M
>> total, which is a limit looking to be lifted.
>>
>> Move l2_xenmap[] into the bss, and adjust both the BIOS and EFI paths to fill
flight 146081 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146081/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 146048
build-armhf
On Thu, Jan 02, 2020 at 04:13:56PM -0500, Pavel Tatashin wrote:
> The assmbly functions __asm_flush_cache_user_range and
> __asm_invalidate_icache_range have alternatives:
>
> alternative_if ARM64_HAS_CACHE_DIC
> ...
>
> alternative_if ARM64_HAS_CACHE_IDC
> ...
>
> But, the implementation of
flight 146072 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146072/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemuu-ovmf-amd64 10 debian-hvm-install fail REGR. vs.
145767
Tests which did not
On Thu, Jan 02, 2020 at 04:13:54PM -0500, Pavel Tatashin wrote:
> We currently duplicate the logic to enable/disable uaccess via TTBR0,
> with C functions and assembly macros. This is a maintenenace burden
> and is liable to lead to subtle bugs, so let's get rid of the assembly
> macros, and
When placing BARs with sizes smaller than 4K multiple BARs can end
up mapped to the same guest physical address, and thus won't work
correctly.
Align all BARs placement to 4K in hvmloader to prevent such
overlapping.
Note that the guest can still move the BARs around and create this
collisions,
Andrew Cooper writes ("Re: [PATCH 19/20] tools/libxl: Re-position CPUID
handling during domain construction"):
> On 14/01/2020 17:33, Ian Jackson wrote:
> > Is it possible to split out the change to the sequencing, from the new
> > functionality ?
>
> Not easily, no.
Thanks for the explanation.
On Tue, Jan 14, 2020 at 09:41:46AM -0500, Jason Andryuk wrote:
> On Tue, Jan 14, 2020 at 5:04 AM Roger Pau Monné wrote:
> >
> > On Mon, Jan 13, 2020 at 02:01:47PM -0500, Jason Andryuk wrote:
> > > On Fri, Mar 22, 2019 at 3:43 PM Jason Andryuk wrote:
> > > >
> > > > On Thu, Mar 21, 2019 at 11:09
On 14/01/2020 17:33, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 19/20] tools/libxl: Re-position CPUID handling
> during domain construction"):
>> CPUID handling needs to be earlier in construction. Move it from its current
>> position in libxl__build_post() to libxl__build_pre() for
Andrew Cooper writes ("[PATCH 20/20] tools/libxc: Restore CPUID/MSR data found
in the migration stream"):
> With libxl suitably adjusted, it is now safe to restore the CPUID/MSR data
> directly from the migration stream. Adjust the XGR_SDD_MISSING_* flags for
> the static_data_done() callback
Andrew Cooper writes ("[PATCH 19/20] tools/libxl: Re-position CPUID handling
during domain construction"):
> CPUID handling needs to be earlier in construction. Move it from its current
> position in libxl__build_post() to libxl__build_pre() for fresh builds, and
>
Andrew Cooper writes ("[PATCH 18/20] tools/libxl: Plumb domain_create_state
down into libxl__build_pre()"):
> To fix CPUID handling, libxl__build_pre() is going to have to distinguish
> between a brand new VM vs one which is being migrated-in/resumed.
Acked-by: Ian Jackson
Andrew Cooper writes ("[PATCH 17/20] tools/libx[cl]: Plumb static_data_done()
up into libxl"):
> /* callbacks provided by xc_domain_restore */
> struct restore_callbacks {
> +/*
> + * Called once the STATIC_DATA_END record has been received/inferred.
> + * Passes in the blocks of
On 14/01/2020 17:02, Jan Beulich wrote:
> On 13.01.2020 18:50, Andrew Cooper wrote:
>> --- a/xen/arch/x86/boot/head.S
>> +++ b/xen/arch/x86/boot/head.S
>> @@ -687,14 +687,19 @@ trampoline_setup:
>> * handling/walking), and identity map Xen into bootmap (needed for
>> * the
Andrew Cooper writes ("[PATCH 16/20] tools/libxl: Simplify callback handling in
libxl-save-helper"):
> The {save,restore}_callback helpers can have their scope reduced vastly,
This part is OK with me although it would have been nicer to review if
the the move and the rename were separate
Andrew Cooper writes ("[PATCH 12/12] libxc/save: Write X86_{CPUID,MSR}_DATA
records"):
> With all other plumbing in place, obtain the CPU Policy from Xen and
> write it into the migration stream.
This looks good to me but:
This patch may need revision to handle the results of our discussion
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
Andrew Cooper writes ("[PATCH 11/12] libxc/restore: Handle X86_{CPUID,MSR}_DATA
records"):
> For now, the data are just stashed, and discarded at the end. This will
> be addressed when the TODO in x86_static_data_complete() is addressed.
>
> No practical change to behaviour - this is all
Andrew Cooper writes ("[PATCH 09/12] libxc/save: Write a v3 stream"):
> Introduce a new static_data() hook which is responsible for writing out
> any static data records. The HVM side continues to be a no-op, while
> the PV side moves write_x86_pv_info() into this earlier hook. The the
> common
Hi,
On 14/01/2020 16:50, Jan Beulich wrote:
On 14.01.2020 17:26, Julien Grall wrote:
On 14/01/2020 16:08, Jan Beulich wrote:
On 13.01.2020 22:33, Julien Grall wrote:
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -29,7 +29,8 @@
bool hvm_domain_use_pirq(const struct
On 13.01.2020 18:50, Andrew Cooper wrote:
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -687,14 +687,19 @@ trampoline_setup:
> * handling/walking), and identity map Xen into bootmap (needed for
> * the transition into long mode), using 2M superpages.
>
Andrew Cooper writes ("[PATCH 08/12] libxc/restore: Support v3 streams, and
cope with v2 compatibilty"):
> Introduce a static_data_complete() hook which is called when a
> STATIC_DATA_END record is found (v3) or inferred (v2).
>
> Modify handle_page_data() and handle_x86_pv_p2m_frames() to infer
Ian Jackson writes ("Re: [PATCH 01/12] libxc/save: Shrink code volume where
possible"):
> Maybe it would be better to have
> #define MUST(call) ({ rc = (call); if (rc) goto error; })
> and write
> MUST( write_one_vcpu_basic(ctx, i) );
This is not uncommon. BIND9 does something like it:
Andrew Cooper writes ("[PATCH 02/12] libxc/restore: Introduce functionality to
simplify blob handling"):
> During migration, we buffer several blobs of data which ultimately need
> handing back to Xen at an appropriate time.
>
> Currently, this is all handled in an ad-hoc manner, but more blobs
On 14.01.2020 17:26, Julien Grall wrote:
> On 14/01/2020 16:08, Jan Beulich wrote:
>> On 13.01.2020 22:33, Julien Grall wrote:
>>> --- a/xen/arch/x86/hvm/irq.c
>>> +++ b/xen/arch/x86/hvm/irq.c
>>> @@ -29,7 +29,8 @@
>>>
>>> bool hvm_domain_use_pirq(const struct domain *d, const struct pirq
Andrew Cooper writes ("[PATCH 01/12] libxc/save: Shrink code volume where
possible"):
> A property of how the error handling (0 on success, nonzero otherwise)
> allows these calls to be chained together with the ternary operatior.
I'm quite surprised to find a suggestion like this coming from
On 13.01.2020 18:50, Andrew Cooper wrote:
> The build-time construction of l2_xenmap[] imposes an arbitrary limit of 16M
> total, which is a limit looking to be lifted.
>
> Move l2_xenmap[] into the bss, and adjust both the BIOS and EFI paths to fill
> it in dynamically, based on the final linked
Hi Jan,
On 14/01/2020 16:08, Jan Beulich wrote:
On 13.01.2020 22:33, Julien Grall wrote:
--- a/xen/arch/x86/hvm/irq.c
+++ b/xen/arch/x86/hvm/irq.c
@@ -29,7 +29,8 @@
bool hvm_domain_use_pirq(const struct domain *d, const struct pirq *pirq)
{
-return is_hvm_domain(d) && pirq &&
Hi David,
On 14/01/2020 15:20, David Woodhouse wrote:
On Tue, 2020-01-14 at 15:00 +, Julien Grall wrote:
On 14/01/2020 14:48, David Woodhouse wrote:
On Tue, 2020-01-14 at 14:15 +, Julien Grall wrote:
Hi David,
On 13/01/2020 11:54, David Woodhouse wrote:
On Wed, 2020-01-08 at 17:24
On 13.01.2020 18:50, Andrew Cooper wrote:
> Despite being vaguely aware, the difference between PAGE_HYPERVISOR in ASM and
> C code has nevertheless caused several bugs I should have known better about,
> and contributed to review confusion.
>
> There are exactly 4 uses of these constants in asm
On 13.01.2020 18:50, Andrew Cooper wrote:
> Since c/s faa85d4fb3 "x86/boot: Don't map 0 during boot", l1_identmap no
> longer has an alias mapped at 0, meaning that none of the l?_identmap[]
> pagetables are actually an identity map.
>
> Rename them to l?_directmap, which avoids any kind of
On 14.01.2020 17:00, Jürgen Groß wrote:
> On 14.01.20 16:47, Jan Beulich wrote:
>> On 09.01.2020 14:48, Juergen Gross wrote:
>>> --- a/xen/Kconfig.debug
>>> +++ b/xen/Kconfig.debug
>>> @@ -81,6 +81,12 @@ config PERF_ARRAYS
>>> ---help---
>>> Enables software performance counter array
Andrew Cooper writes ("Re: [PATCH 10/12] docs/migration: Specify
X86_{CPUID,MSR}_POLICY records"):
> The migration stream is split into records with no playload (markers
> with external control flow meaning), and data records, which have a payload.
I remember thinking at the time you specified
Andrew Cooper writes ("[PATCH 10/12] docs/migration: Specify
X86_{CPUID,MSR}_POLICY records"):
> These two records move blobs from the XEN_DOMCTL_{get,set}_cpu_policy
> hypercall.
We had an extensive IRL discussion recently about the compatibility
implications of this. Is that written down
On 13.01.2020 22:33, Julien Grall wrote:
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@ -29,7 +29,8 @@
>
> bool hvm_domain_use_pirq(const struct domain *d, const struct pirq *pirq)
> {
> -return is_hvm_domain(d) && pirq && pirq->arch.hvm.emuirq != IRQ_UNBOUND;
> +
Andrew Cooper writes ("[PATCH 06/12] docs/migration Specify migration v3 and
STATIC_DATA_END"):
> Migration data can be split into two parts - that which is invariant of
> guest execution, and that which is not. Separate these two with the
> STATIC_DATA_END record.
>
> The short term, we want
Andrew Cooper writes ("[PATCH 05/12] tools/migration: Drop IHDR_VERSION
constant from libxc and python"):
> Migration v3 is in the process of being introduced, meaning that the code has
> to cope with both versions. Use an explicit 2 for now.
>
> For the verify-stream-v2 and
flight 146073 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146073/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
Andrew Cooper writes ("[PATCH 04/12] libxc/migration: Adjust layout of struct
xc_sr_context"):
> We are shortly going to want to introduce some common x86 fields, so having
> x86_pv and x86_hvm as the top level objects is a problem. Insert a
> surrounding struct x86 and drop the x86 prefix from
On 14.01.20 16:47, Jan Beulich wrote:
On 09.01.2020 14:48, Juergen Gross wrote:
--- a/xen/Kconfig.debug
+++ b/xen/Kconfig.debug
@@ -81,6 +81,12 @@ config PERF_ARRAYS
---help---
Enables software performance counter array histograms.
+config DEBUG_BUGVERBOSE
+ bool
Andrew Cooper writes ("[PATCH 03/12] libxc/migration: Rationalise the
'checkpointed' field to 'stream_type'"):
> Originally, 'checkpointed' was a boolean signalling the difference between a
> plain and a Remus stream. COLO was added later, but several bits of code
> retained boolean-style logic.
On 09.01.2020 14:48, Juergen Gross wrote:
> --- a/xen/Kconfig.debug
> +++ b/xen/Kconfig.debug
> @@ -81,6 +81,12 @@ config PERF_ARRAYS
> ---help---
> Enables software performance counter array histograms.
>
> +config DEBUG_BUGVERBOSE
> + bool "Verbose BUG_ON messages"
> +
On 14.01.20 16:38, Jan Beulich wrote:
On 08.01.2020 16:23, Juergen Gross wrote:
--- a/xen/common/sched/private.h
+++ b/xen/common/sched/private.h
@@ -533,6 +533,7 @@ static inline void sched_unit_unpause(const struct
sched_unit *unit)
struct cpupool
{
int cpupool_id;
On 08.01.2020 16:23, Juergen Gross wrote:
> --- a/xen/common/sched/private.h
> +++ b/xen/common/sched/private.h
> @@ -533,6 +533,7 @@ static inline void sched_unit_unpause(const struct
> sched_unit *unit)
> struct cpupool
> {
> int cpupool_id;
> +#define CPUPOOLID_NONE-1
On Tue, 2020-01-14 at 15:00 +, Julien Grall wrote:
>
> On 14/01/2020 14:48, David Woodhouse wrote:
> > On Tue, 2020-01-14 at 14:15 +, Julien Grall wrote:
> > > Hi David,
> > >
> > > On 13/01/2020 11:54, David Woodhouse wrote:
> > > > On Wed, 2020-01-08 at 17:24 +, David Woodhouse
On 14/01/2020 14:48, David Woodhouse wrote:
On Tue, 2020-01-14 at 14:15 +, Julien Grall wrote:
Hi David,
On 13/01/2020 11:54, David Woodhouse wrote:
On Wed, 2020-01-08 at 17:24 +, David Woodhouse wrote:
So we've settled on a simpler approach — reserve a contiguous region
of
On 14.01.20 15:39, Jan Beulich wrote:
On 14.01.2020 15:33, Jürgen Groß wrote:
On 14.01.20 15:27, Jan Beulich wrote:
On 08.01.2020 16:23, Juergen Gross wrote:
+cpumask_t *cpupool_valid_cpus(struct cpupool *pool)
const twice?
See patch 9.
Well, in such a case either justify the omission
On Tue, 2020-01-14 at 14:15 +, Julien Grall wrote:
> Hi David,
>
> On 13/01/2020 11:54, David Woodhouse wrote:
> > On Wed, 2020-01-08 at 17:24 +, David Woodhouse wrote:
> > > When doing a live update, Xen needs to be very careful not to scribble
> > > on pages which contain guest memory
On Tue, Jan 14, 2020 at 5:04 AM Roger Pau Monné wrote:
>
> On Mon, Jan 13, 2020 at 02:01:47PM -0500, Jason Andryuk wrote:
> > On Fri, Mar 22, 2019 at 3:43 PM Jason Andryuk wrote:
> > >
> > > On Thu, Mar 21, 2019 at 11:09 PM Roger Pau Monné
> > > wrote:
> > > >
> > > > On Wed, Mar 20, 2019 at
On 14.01.2020 15:33, Jürgen Groß wrote:
> On 14.01.20 15:27, Jan Beulich wrote:
>> On 08.01.2020 16:23, Juergen Gross wrote:
>>> +cpumask_t *cpupool_valid_cpus(struct cpupool *pool)
>>
>> const twice?
>
> See patch 9.
Well, in such a case either justify the omission in the description,
or
On 14/01/2020 14:35, Jan Beulich wrote:
> "IRQ: u16 is too narrow for an event channel number" introduced a use of
> evetchn_port_t, but its typedef apparently surfaces indirectly here only
> on x86.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
"IRQ: u16 is too narrow for an event channel number" introduced a use of
evetchn_port_t, but its typedef apparently surfaces indirectly here only
on x86.
Signed-off-by: Jan Beulich
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
On 14.01.20 15:27, Jan Beulich wrote:
On 08.01.2020 16:23, Juergen Gross wrote:
@@ -234,16 +233,6 @@ void domctl_lock_release(void)
spin_unlock(>domain->hypercall_deadlock_mutex);
}
-static inline
-int vcpuaffinity_params_invalid(const struct xen_domctl_vcpuaffinity *vcpuaff)
-{
-
On 08.01.2020 16:23, Juergen Gross wrote:
> @@ -234,16 +233,6 @@ void domctl_lock_release(void)
> spin_unlock(>domain->hypercall_deadlock_mutex);
> }
>
> -static inline
> -int vcpuaffinity_params_invalid(const struct xen_domctl_vcpuaffinity
> *vcpuaff)
> -{
> -return vcpuaff->flags ==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory XSA-312
arm: a CPU may speculate past the ERET instruction
ISSUE DESCRIPTION
=
Some CPUs can speculate past an ERET instruction and potentially perform
speculative accesses to
Hi David,
On 13/01/2020 11:54, David Woodhouse wrote:
On Wed, 2020-01-08 at 17:24 +, David Woodhouse wrote:
When doing a live update, Xen needs to be very careful not to scribble
on pages which contain guest memory or state information for the
domains which are being preserved.
The
flight 146068 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146068/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 146048
build-armhf
On Tue, Jan 14, 2020 at 4:28 AM Jan Beulich wrote:
>
> On 13.01.2020 20:40, Jason Andryuk wrote:
> > On Fri, Dec 27, 2019 at 11:09 AM Andrew Cooper
> > wrote:
> >>
> >> On 20/12/2019 16:23, Jan Beulich wrote:
> >>> On 16.09.2019 11:40, Jan Beulich wrote:
> Using memcpy() may result in
flight 146070 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146070/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 144861
build-arm64
Hi Paul,
On 14/01/2020 09:53, Durrant, Paul wrote:
-Original Message-
From: Xen-devel On Behalf Of
Julien Grall
Sent: 13 January 2020 23:12
To: xen-devel@lists.xenproject.org
Cc: Ross Lagerwall ; Wieczorkiewicz, Pawel
; Julien Grall ; Konrad Rzeszutek
Wilk
Subject: [Xen-devel]
On 13/01/2020 17:50, Andrew Cooper wrote:
> It turns out that the note in c/s a8d27a54cc9cc
>
> Finally, leave a linker assert covering the fact that plenty of code blindly
> assumes that Xen is less that 16M. This wants fixing in due course.
>
> was easier to address than I had originally
On Tue, Jan 14, 2020 at 12:39:21PM +, Andrew Cooper wrote:
> With the 32 PAE build of Xen gone, 32bit PV guests' top level pagetables no
> longer behave exactly like PAE in hardware.
>
> They should have A/D bits set, for the same performance reasons as apply to
> other levels. This brings
On 14.01.2020 13:39, Andrew Cooper wrote:
> With the 32 PAE build of Xen gone, 32bit PV guests' top level pagetables no
> longer behave exactly like PAE in hardware.
>
> They should have A/D bits set, for the same performance reasons as apply to
> other levels. This brings the domain builder in
On 14.01.2020 13:34, Juergen Gross wrote:
> Having Linux kernel drivers for 2.6 based kernels in the Xen tree is
> not really needed any longer. So remove them from the tree.
>
> In case anyone wants to look at them they are still available in
> older branches.
>
> Signed-off-by: Juergen Gross
On Tue, Jan 14, 2020 at 01:34:45PM +0100, Juergen Gross wrote:
> Having Linux kernel drivers for 2.6 based kernels in the Xen tree is
> not really needed any longer. So remove them from the tree.
>
> In case anyone wants to look at them they are still available in
> older branches.
>
>
1 - 100 of 134 matches
Mail list logo
