On 14.05.20 11:50, Jürgen Groß wrote:
On 14.05.20 09:59, Jan Beulich wrote:
On 08.05.2020 17:34, Juergen Gross wrote:
+int hypfs_read_dir(const struct hypfs_entry *entry,
+ XEN_GUEST_HANDLE_PARAM(void) uaddr)
+{
+ const struct hypfs_entry_dir *d;
+ const struct
Philippe Mathieu-Daudé writes:
> The OBJECT() macro is defined as:
>
> #define OBJECT(obj) ((Object *)(obj))
>
> Remove the unnecessary OBJECT() casts when we already know the
> pointer is of Object type.
>
> Patch created mechanically using spatch with this script:
>
> @@
> typedef
flight 150176 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150176/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 150072
test-amd64-i386-xl-pvshim12
flight 150178 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150178/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf f2cdb268ef04eeec51948b5d81eeca5cab5ed9af
baseline version:
ovmf
flight 150177 xen-4.13-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150177/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail blocked in 150073
test-amd64-i386-xl-pvshim12
On Thu, 14 May 2020 at 19:12, Andrew Cooper wrote:
>
> On 14/05/2020 18:38, Julien Grall wrote:
> > Hi,
> >
> > On 14/05/2020 17:18, Bertrand Marquis wrote:
> >>
> >>
> >>> On 14 May 2020, at 16:57, Julien Grall wrote:
> >>>
> >>>
> >>>
> >>> On 14/05/2020 15:28, Bertrand Marquis wrote:
>
On Thu, May 14, 2020 at 12:55 PM Ian Jackson wrote:
>
> Jason Andryuk writes ("[PATCH v5 00/21] Add support for qemu-xen runnning in
> a Linux-based stubdomain"):
> > In coordination with Marek, I'm making a submission of his patches for Linux
> > stubdomain device-model support. I made a few
flight 150174 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150174/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-vhd 7 xen-boot fail REGR. vs. 150151
Tests which did
On 14/05/2020 18:38, Julien Grall wrote:
> Hi,
>
> On 14/05/2020 17:18, Bertrand Marquis wrote:
>>
>>
>>> On 14 May 2020, at 16:57, Julien Grall wrote:
>>>
>>>
>>>
>>> On 14/05/2020 15:28, Bertrand Marquis wrote:
Hi,
>>>
>>> Hi,
>>>
When executing linux on arm64 with KPTI activated (in
flight 150182 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150182/
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
Hi,
On 14/05/2020 17:18, Bertrand Marquis wrote:
On 14 May 2020, at 16:57, Julien Grall wrote:
On 14/05/2020 15:28, Bertrand Marquis wrote:
Hi,
Hi,
When executing linux on arm64 with KPTI activated (in Dom0 or in a DomU), I
have a lot of walk page table errors like this:
(XEN)
On Thu, May 14, 2020 at 05:42:36PM +0100, Ian Jackson wrote:
> Jason Andryuk writes ("[PATCH v5 14/21] libxl: require qemu in dom0 even if
> stubdomain is in use"):
> > From: Marek Marczykowski-Górecki
> >
> > Until xenconsoled learns how to handle multiple consoles, this is needed
> > for
Jason Andryuk writes ("[PATCH v5 00/21] Add support for qemu-xen runnning in a
Linux-based stubdomain"):
> In coordination with Marek, I'm making a submission of his patches for Linux
> stubdomain device-model support. I made a few of my own additions, but Marek
> did the heavy lifting. Thank
On Thu, May 14, 2020 at 05:50:29PM +0200, Jan Beulich wrote:
> [CAUTION - EXTERNAL EMAIL] DO NOT reply, click links, or open attachments
> unless you have verified the sender and know the content is safe.
>
> On 14.05.2020 17:32, Roger Pau Monné wrote:
> > On Thu, May 14, 2020 at 03:38:18PM
Jason Andryuk writes ("[PATCH v5 21/21] tools: Clean up vchan-socket-proxy
socket"):
> To avoid socket files lingering in /run/xen, have vchan-socket-proxy
> clean up the sockets it creates. Use a signal handler as well as atexit
> to handle both means of termination.
This should be done in
Jason Andryuk writes ("[PATCH v5 20/21] libxl: Kill vchan-socket-proxy when
cleaning up qmp"):
> We need to kill the vchan-socket-proxy so we don't leak the daemonized
> processes. libxl__stubdomain_is_linux_running works against the
> guest_domid, but the xenstore path is beneath the
Jason Andryuk writes ("[PATCH v5 19/21] libxl: Refactor kill_device_model to
libxl__kill_xs_path"):
> Move kill_device_model to libxl__kill_xs_path so we have a helper to
> kill a process from a pid stored in xenstore. We'll be using it to kill
> vchan-qmp-proxy.
>
> libxl__kill_xs_path takes a
Jason Andryuk writes ("[PATCH v5 18/21] libxl: Check stubdomain kernel &
ramdisk presence"):
> Just out of context is the following comment for libxl__domain_make:
> /* fixme: this function can leak the stubdom if it fails */
>
> When the stubdomain kernel or ramdisk is not present, the domid
Jason Andryuk writes ("[PATCH v5 17/21] docs: Add device-model-domid to
xenstore-paths"):
> Document device-model-domid for when using a device model stubdomain.
>
Acked-by: Ian Jackson
Jason Andryuk writes ("[PATCH v5 16/21] libxl: consider also qemu in stubdomain
in libxl__dm_active check"):
> From: Marek Marczykowski-Górecki
>
> Since qemu-xen can now run in stubdomain too, handle this case when
> checking it's state too.
Acked-by: Ian Jackson
Jason Andryuk writes ("[PATCH v5 15/21] libxl: ignore emulated IDE disks beyond
the first 4"):
> From: Marek Marczykowski-Górecki
>
> 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
Jason Andryuk writes ("[PATCH v5 14/21] libxl: require qemu in dom0 even if
stubdomain is in use"):
> From: Marek Marczykowski-Górecki
>
> Until xenconsoled learns how to handle multiple consoles, this is needed
> for save/restore support (qemu state is transferred over secondary
> consoles).
>
Jason Andryuk writes ("[PATCH v5 13/21] Regenerate autotools files"):
> From: Marek Marczykowski-Górecki
>
> Since we have those generated files committed to the repo (why?!),
> update them after changing configure.ac.
This should be folded into the patch that changes the input. Can you
please
Jason Andryuk writes ("[PATCH v5 12/21] libxl: use vchan for QMP access with
Linux stubdomain"):
> From: Marek Marczykowski-Górecki
>
> 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).
Jason Andryuk writes ("[PATCH v5 11/21] tools: add simple vchan-socket-proxy"):
> From: Marek Marczykowski-Górecki
>
> 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
Jason Andryuk writes ("[PATCH v5 10/21] tools: add missing libxenvchan cflags"):
> From: Marek Marczykowski-Górecki
>
> libxenvchan.h include xenevtchn.h and xengnttab.h, so applications built
> with it needs applicable -I in CFLAGS too.
Acked-by: Ian Jackson
On Thu, Apr 23, 2020 at 10:39:39AM +0200, Jan Beulich wrote:
> Where gprintk()s get touched anyway to switch to PRI_gfn, also switch to
> %pd for the domain logged.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
Jason Andryuk writes ("[PATCH v5 09/21] libxl: add save/restore support for
qemu-xen in stubdomain"):
> From: Marek Marczykowski-Górecki
>
> Rely on a wrapper script in stubdomain to attach FD 3/4 of qemu to
> relevant consoles.
>
> Signed-off-by: Marek Marczykowski-Górecki
> Address TODO in
On Thu, Apr 23, 2020 at 10:39:17AM +0200, Jan Beulich wrote:
> Do a little bit of style adjustment along the way, and drop the
> "p2m_mem_paging_" prefixes from the now static functions.
>
> Signed-off-by: Jan Beulich
Reviewed-by: Roger Pau Monné
Thanks, Roger.
Jason Andryuk writes ("[PATCH v5 08/21] tools/libvchan: notify server when
client is connected"):
> From: Marek Marczykowski-Górecki
>
> 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
Jason Andryuk writes ("[PATCH v5 07/21] xl: add stubdomain related options to
xl config parser"):
> From: Marek Marczykowski-Górecki
>
> Signed-off-by: Marek Marczykowski-Górecki
> Reviewed-by: Jason Andryuk
> Signed-off-by: Jason Andryuk
Acked-by: Ian Jackson
Jason Andryuk writes ("[PATCH v5 06/21] libxl: write qemu arguments into
separate xenstore keys"):
> +static int libxl__write_stub_linux_dmargs(libxl__gc *gc,
> +int dm_domid, int guest_domid,
> +char **args)
> +{
...
> +
On Thu, Apr 23, 2020 at 10:38:44AM +0200, Jan Beulich wrote:
> While full checking is impossible (as the lock is being acquired/
> released down the call tree), perform at least a lock level check.
I'm slightly confused, doesn't alloc_domheap_page already have it's
own lock order checking?
Jason Andryuk writes ("[PATCH v5 05/21] libxl: Handle Linux stubdomain specific
QEMU options."):
> 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
> On 14 May 2020, at 16:57, Julien Grall wrote:
>
>
>
> On 14/05/2020 15:28, Bertrand Marquis wrote:
>> Hi,
>
> Hi,
>
>> When executing linux on arm64 with KPTI activated (in Dom0 or in a DomU), I
>> have a lot of walk page table errors like this:
>> (XEN) p2m.c:1890: d1v0: Failed to
On Thu, Apr 23, 2020 at 10:38:18AM +0200, Jan Beulich wrote:
> While it should have been this way from the beginning, not doing so will
> become an actual problem with PVH Dom0. The interface change is binary
> compatible, but requires tools side producers to be re-built.
>
> Drop the
Jason Andryuk writes ("[PATCH v5 04/21] libxl: Allow running qemu-xen in
stubdomain"):
> From: Marek Marczykowski-Górecki
>
> Do not prohibit anymore using stubdomain with qemu-xen.
> To help distingushing MiniOS and Linux stubdomain, add helper inline
> functions libxl__stubdomain_is_linux()
Jason Andryuk writes ("[PATCH v5 01/21] Document ioemu MiniOS stubdomain
protocol"):
> From: Marek Marczykowski-Górecki
>
> Add documentation based on reverse-engineered toolstack-ioemu stubdomain
> protocol.
>
> Signed-off-by: Marek Marczykowski-Górecki
> Signed-off-by: Jason Andryuk
Jason Andryuk writes ("[PATCH v5 02/21] Document ioemu Linux stubdomain
protocol"):
> From: Marek Marczykowski-Górecki
>
> Add documentation for upcoming Linux stubdomain for qemu-upstream.
Acked-by: Ian Jackson
This probably shouldn't be committed except with the implmeentation
:-).
Ian.
Jason Andryuk writes ("[PATCH v5 00/21] Add support for qemu-xen runnning in a
Linux-based stubdomain"):
> In coordination with Marek, I'm making a submission of his patches for Linux
> stubdomain device-model support. I made a few of my own additions, but Marek
> did the heavy lifting. Thank
On Thu, Apr 23, 2020 at 10:37:46AM +0200, Jan Beulich wrote:
> Communicating errors from p2m_set_entry() to the caller is not enough:
> Neither the M2P nor the stats updates should occur in such a case.
> Instead the allocated page needs to be freed again; for cleanliness
> reasons also properly
On 14/05/2020 15:28, Bertrand Marquis wrote:
Hi,
Hi,
When executing linux on arm64 with KPTI activated (in Dom0 or in a DomU), I
have a lot of walk page table errors like this:
(XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xff837ebe0cd0
After implementing a call trace, I
On 14.05.2020 17:45, Roger Pau Monné wrote:
> On Thu, Apr 23, 2020 at 10:37:06AM +0200, Jan Beulich wrote:
>> The condition of the second can be true only if the condition of the
>> first was met; the second half of the condition of the second then also
>> is redundant with an earlier check.
On 14.05.2020 17:32, Roger Pau Monné wrote:
> On Thu, May 14, 2020 at 03:38:18PM +0200, Jan Beulich wrote:
>> On 14.05.2020 15:10, Roger Pau Monné wrote:
>>> On Wed, Apr 15, 2020 at 01:55:24PM +0200, Jan Beulich wrote:
While from just a single Skylake system it is already clear that we
On Thu, Apr 23, 2020 at 10:37:06AM +0200, Jan Beulich wrote:
> The condition of the second can be true only if the condition of the
> first was met; the second half of the condition of the second then also
> is redundant with an earlier check. Combine them, drop a pointless
> local variable, and
On 14.05.20 17:02, Jan Beulich wrote:
On 14.05.2020 16:56, Jürgen Groß wrote:
On 14.05.20 14:10, Jan Beulich wrote:
On 14.05.2020 13:48, Jürgen Groß wrote:
On 14.05.20 12:20, Jan Beulich wrote:
On 08.05.2020 17:34, Juergen Gross wrote:
--- a/xen/common/grant_table.c
+++
The dirty_cpu field of struct vcpu denotes which cpu still holds data
of a vcpu. All accesses to this field should be atomic in case the
vcpu could just be running, as it is accessed without any lock held
in most cases. Especially sync_local_execstate() and context_switch()
for the same vcpu
Some problems I found when trying to find a problem with
cpu-on/offlining in core scheduling mode.
Juergen Gross (3):
xen/sched: allow rcu work to happen when syncing cpus in core
scheduling
xen/sched: don't call sync_vcpu_execstate() in
sched_unit_migrate_finish()
xen/sched: fix
With support of core scheduling sched_unit_migrate_finish() gained a
call of sync_vcpu_execstate() as it was believed to be called as a
result of vcpu migration in any case.
In case of migrating a vcpu away from a physical cpu for a short period
of time ionly without ever being scheduled on the
With RCU barriers moved from tasklets to normal RCU processing cpu
offlining in core scheduling might deadlock due to cpu synchronization
required by RCU processing and core scheduling concurrently.
Fix that by bailing out from core scheduling synchronization in case
of pending RCU work.
On Thu, May 14, 2020 at 03:38:18PM +0200, Jan Beulich wrote:
> On 14.05.2020 15:10, Roger Pau Monné wrote:
> > On Wed, Apr 15, 2020 at 01:55:24PM +0200, Jan Beulich wrote:
> >> While from just a single Skylake system it is already clear that we
> >> can't base any of our logic on CPUID leaf 15 [1]
On Thu, May 14, 2020 at 8:52 AM Ian Jackson wrote:
>
> Tamas K Lengyel writes ("[PATCH v18 2/2] tools/libxl: VM forking toolstack
> side"):
> > Add necessary bits to implement "xl fork-vm" commands. The command allows
> > the
> > user to specify how to launch the device model allowing for a
On 14.05.2020 16:56, Jürgen Groß wrote:
> On 14.05.20 14:10, Jan Beulich wrote:
>> On 14.05.2020 13:48, Jürgen Groß wrote:
>>> On 14.05.20 12:20, Jan Beulich wrote:
On 08.05.2020 17:34, Juergen Gross wrote:
> --- a/xen/common/grant_table.c
> +++ b/xen/common/grant_table.c
> @@
On 14.05.2020 16:21, Jürgen Groß wrote:
> On 14.05.20 15:57, Jan Beulich wrote:
>> On 11.05.2020 13:28, Juergen Gross wrote:
>>> With support of core scheduling sched_unit_migrate_finish() gained a
>>> call of sync_vcpu_execstate() as it was believed to be called as a
>>> result of vcpu migration
On 14.05.20 15:03, Jan Beulich wrote:
On 08.05.2020 17:34, Juergen Gross wrote:
Besides the changes made, wouldn't it be worthwhile to change
HYPFS Kconfig help wording from "result in some features not
being available" to something mentioning runtime parameter
setting in particular, and
On 14.05.20 14:10, Jan Beulich wrote:
On 14.05.2020 13:48, Jürgen Groß wrote:
On 14.05.20 12:20, Jan Beulich wrote:
On 08.05.2020 17:34, Juergen Gross wrote:
--- a/xen/common/grant_table.c
+++ b/xen/common/grant_table.c
@@ -85,8 +85,43 @@ struct grant_table {
struct grant_table_arch
flight 150172 linux-5.4 real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150172/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-rtds 16 guest-localmigrate fail like 150122
test-armhf-armhf-xl-rtds 16
Tamas K Lengyel writes ("[PATCH v18 2/2] tools/libxl: VM forking toolstack
side"):
> Add necessary bits to implement "xl fork-vm" commands. The command allows the
> user to specify how to launch the device model allowing for a late-launch
> model
> in which the user can execute the fork without
flight 150175 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150175/
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
Hi,
When executing linux on arm64 with KPTI activated (in Dom0 or in a DomU), I
have a lot of walk page table errors like this:
(XEN) p2m.c:1890: d1v0: Failed to walk page-table va 0xff837ebe0cd0
After implementing a call trace, I found that the problem was coming from the
On 14.05.20 15:57, Jan Beulich wrote:
On 11.05.2020 13:28, Juergen Gross wrote:
With support of core scheduling sched_unit_migrate_finish() gained a
call of sync_vcpu_execstate() as it was believed to be called as a
result of vcpu migration in any case.
In case of migrating a vcpu away from a
This takes effect on everything that uses selecthost(). The result is
that PDU operations are made manual. This can be useful for testing
etc.
Signed-off-by: Ian Jackson
---
Osstest/TestSupport.pm | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Osstest/TestSupport.pm
Signed-off-by: Ian Jackson
---
Osstest/Executive.pm | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Osstest/Executive.pm b/Osstest/Executive.pm
index e741f529..c3dc1261 100644
--- a/Osstest/Executive.pm
+++ b/Osstest/Executive.pm
@@ -1017,11 +1017,12 @@ sub
Thse four small fixes/improvements have been generated as the result
of my buster work. They are not really related to buster.
Many more changes will follow...
Message change only
Signed-off-by: Ian Jackson
---
ts-repeat-test | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ts-repeat-test b/ts-repeat-test
index e6b52465..5e17c335 100755
--- a/ts-repeat-test
+++ b/ts-repeat-test
@@ -56,7 +56,7 @@ my $orgreps = $reps;
$reps *=
These transcripts are huge and not useful.
Still include them if sg-secute-flight failed.
Signed-off-by: Ian Jackson
---
cri-args-hostlists | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/cri-args-hostlists b/cri-args-hostlists
index 3578fe1c..28d576db 100644
---
On Mon, Jul 15, 2019 at 02:39:04PM +, Jan Beulich wrote:
> This is faster than using the software implementation, and the insn is
> available on all half-way recent hardware. Therefore convert
> generic_hweight() to out-of-line functions (without affecting Arm)
> and use alternatives patching
On 14.05.2020 11:29, Jürgen Groß wrote:
> On 14.05.20 11:24, Jan Beulich wrote:
>> On 14.05.2020 10:50, Jürgen Groß wrote:
>>> On 14.05.20 09:10, Jan Beulich wrote:
On 11.05.2020 13:28, Juergen Gross wrote:
> @@ -1956,13 +1958,17 @@ void sync_local_execstate(void)
> void
On 11.05.2020 13:28, Juergen Gross wrote:
> With support of core scheduling sched_unit_migrate_finish() gained a
> call of sync_vcpu_execstate() as it was believed to be called as a
> result of vcpu migration in any case.
>
> In case of migrating a vcpu away from a physical cpu for a short period
On 14.05.2020 15:10, Roger Pau Monné wrote:
> On Wed, Apr 15, 2020 at 01:55:24PM +0200, Jan Beulich wrote:
>> While from just a single Skylake system it is already clear that we
>> can't base any of our logic on CPUID leaf 15 [1] (leaf 16 is
>> documented to be used for display purposes only
flight 150169 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150169/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-vhd 10 debian-di-installfail REGR. vs. 150164
Tests which did
On Thu, May 14, 2020 at 02:31:33PM +0200, Jan Beulich wrote:
> On 14.05.2020 12:01, Roger Pau Monné wrote:
> > On Fri, Mar 13, 2020 at 10:26:47AM +0100, Jan Beulich wrote:
> >> --- a/xen/arch/x86/apic.c
> >> +++ b/xen/arch/x86/apic.c
> >> @@ -499,7 +499,7 @@ static void resume_x2apic(void)
> >>
On 14.05.2020 12:01, Wei Liu wrote:
> On Wed, May 13, 2020 at 04:43:33PM +0100, Hongyan Xia wrote:
>> From: Hongyan Xia
>>
>> The macro version UNMAP_DOMAIN_PAGE() does both NULL checking and
>> variable clearing. Move NULL checking into the function itself so that
>> the semantics is consistent
On Wed, Apr 15, 2020 at 01:55:24PM +0200, Jan Beulich wrote:
> While from just a single Skylake system it is already clear that we
> can't base any of our logic on CPUID leaf 15 [1] (leaf 16 is
> documented to be used for display purposes only anyway), logging this
> information may still give us
On 08.05.2020 17:34, Juergen Gross wrote:
Besides the changes made, wouldn't it be worthwhile to change
HYPFS Kconfig help wording from "result in some features not
being available" to something mentioning runtime parameter
setting in particular, and perhaps also from "might" to "will"?
> ---
On 14.05.2020 13:02, Ian Jackson wrote:
> I've read this thread. Jan, I'm sorry that this causes you
> inconvenience. I'm hoping it won't come down to a choice between
> supporting people who want to ship a dom0 without perl, and people who
> want a dom0 using more-than-a-decade-old coreutils.
On 14.05.2020 12:01, Roger Pau Monné wrote:
> On Fri, Mar 13, 2020 at 10:26:47AM +0100, Jan Beulich wrote:
>> All CPUs get an equal setting of EOI broadcast suppression; no need to
>> log one message per CPU, even if it's only in verbose APIC mode.
>>
>> Only the BSP is eligible to possibly get
On 14.05.20 13:58, Jan Beulich wrote:
On 14.05.2020 11:50, Jürgen Groß wrote:
On 14.05.20 09:59, Jan Beulich wrote:
On 08.05.2020 17:34, Juergen Gross wrote:
+#define HYPFS_FIXEDSIZE_INIT(var, typ, nam, contvar, wr) \
+ struct hypfs_entry_leaf __read_mostly var = { \
+
On 14.05.2020 13:48, Jürgen Groß wrote:
> On 14.05.20 12:20, Jan Beulich wrote:
>> On 08.05.2020 17:34, Juergen Gross wrote:
>>> --- a/xen/common/grant_table.c
>>> +++ b/xen/common/grant_table.c
>>> @@ -85,8 +85,43 @@ struct grant_table {
>>> struct grant_table_arch arch;
>>> };
>>>
On 14.05.2020 11:50, Jürgen Groß wrote:
> On 14.05.20 09:59, Jan Beulich wrote:
>> On 08.05.2020 17:34, Juergen Gross wrote:
>>> +#define HYPFS_FIXEDSIZE_INIT(var, typ, nam, contvar, wr) \
>>> + struct hypfs_entry_leaf __read_mostly var = { \
>>> + .e.type = typ,
flight 150173 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/150173/
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.05.20 12:20, Jan Beulich wrote:
On 08.05.2020 17:34, Juergen Gross wrote:
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -89,6 +89,13 @@ SECTIONS
__start_schedulers_array = .;
*(.data.schedulers)
__end_schedulers_array = .;
+
+#ifdef CONFIG_HYPFS
+
I've read this thread. Jan, I'm sorry that this causes you
inconvenience. I'm hoping it won't come down to a choice between
supporting people who want to ship a dom0 without perl, and people who
want a dom0 using more-than-a-decade-old coreutils.
Jan, can you tell me what the output is of this
From: Paul Durrant
Paul Durrant (5):
xen/common: introduce a new framework for save/restore of 'domain'
context
xen/common/domctl: introduce XEN_DOMCTL_get/setdomaincontext
tools/misc: add xen-domctx to present domain context
common/domain: add a domain context record for
This tool is analogous to 'xen-hvmctx' which presents HVM context.
Subsequent patches will add 'dump' functions when new records are
introduced.
Signed-off-by: Paul Durrant
---
Cc: Ian Jackson
Cc: Wei Liu
v3:
- Re-worked to avoid copying onto stack
- Added optional typecode and instance
To allow enlightened HVM guests (i.e. those that have PV drivers) to be
migrated without their co-operation it will be necessary to transfer 'PV'
state such as event channel state, grant entry state, etc.
Currently there is a framework (entered via the hvm_save/load() functions)
that allows a
... in the save/restore code.
This patch replaces direct mapping of the shared_info_frame (retrieved
using XEN_DOMCTL_getdomaininfo) with save/load of the domain context
SHARED_INFO record.
No modifications are made to the definition of the migration stream at
this point. Subsequent patches will
From: Paul Durrant
... and update xen-domctx to dump some information describing the record.
NOTE: The domain may or may not be using the embedded vcpu_info array so
ultimately separate context records will be added for vcpu_info when
this becomes necessary.
Signed-off-by: Paul
These domctls provide a mechanism to get and set domain context from
the toolstack.
Signed-off-by: Paul Durrant
---
Cc: Daniel De Graaf
Cc: Ian Jackson
Cc: Wei Liu
Cc: Andrew Cooper
Cc: George Dunlap
Cc: Jan Beulich
Cc: Julien Grall
Cc: Stefano Stabellini
v3:
- Addressed comments from
On 08.05.2020 17:34, Juergen Gross wrote:
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -89,6 +89,13 @@ SECTIONS
> __start_schedulers_array = .;
> *(.data.schedulers)
> __end_schedulers_array = .;
> +
> +#ifdef CONFIG_HYPFS
> + . = ALIGN(8);
> +
On Wed, May 13, 2020 at 04:43:33PM +0100, Hongyan Xia wrote:
> From: Hongyan Xia
>
> The macro version UNMAP_DOMAIN_PAGE() does both NULL checking and
> variable clearing. Move NULL checking into the function itself so that
> the semantics is consistent with other similar constructs like
On Fri, Mar 13, 2020 at 10:26:47AM +0100, Jan Beulich wrote:
> All CPUs get an equal setting of EOI broadcast suppression; no need to
> log one message per CPU, even if it's only in verbose APIC mode.
>
> Only the BSP is eligible to possibly get ExtINT enabled; no need to log
> that it gets
On 14.05.20 11:55, Jan Beulich wrote:
On 08.05.2020 17:34, Juergen Gross wrote:
--- /dev/null
+++ b/xen/include/xen/hypfs.h
@@ -0,0 +1,122 @@
+#ifndef __XEN_HYPFS_H__
+#define __XEN_HYPFS_H__
+
+#ifdef CONFIG_HYPFS
+#include
+#include
+#include
+
+struct hypfs_entry_leaf;
+
+struct
On 08.05.2020 17:34, Juergen Gross wrote:
> --- /dev/null
> +++ b/xen/include/xen/hypfs.h
> @@ -0,0 +1,122 @@
> +#ifndef __XEN_HYPFS_H__
> +#define __XEN_HYPFS_H__
> +
> +#ifdef CONFIG_HYPFS
> +#include
> +#include
> +#include
> +
> +struct hypfs_entry_leaf;
> +
> +struct hypfs_entry {
> +
On 14.05.20 11:32, Jan Beulich wrote:
On 08.05.2020 17:34, Juergen Gross wrote:
Add the /buildinfo/config entry to the hypervisor filesystem. This
entry contains the .config file used to build the hypervisor.
Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
with a remark and one
On 14.05.20 09:59, Jan Beulich wrote:
On 08.05.2020 17:34, Juergen Gross wrote:
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -10,6 +10,7 @@ obj-y += domain.o
obj-y += event_2l.o
obj-y += event_channel.o
obj-y += event_fifo.o
+obj-$(CONFIG_HYPFS) += hypfs.o
On 08.05.2020 17:34, Juergen Gross wrote:
> Add the /buildinfo/config entry to the hypervisor filesystem. This
> entry contains the .config file used to build the hypervisor.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Jan Beulich
with a remark and one further adjustment:
> @@ -73,3 +74,14
On 14.05.20 11:24, Jan Beulich wrote:
On 14.05.2020 10:50, Jürgen Groß wrote:
On 14.05.20 09:10, Jan Beulich wrote:
On 11.05.2020 13:28, Juergen Gross wrote:
@@ -1956,13 +1958,17 @@ void sync_local_execstate(void)
void sync_vcpu_execstate(struct vcpu *v)
{
- if ( v->dirty_cpu ==
On 14.05.2020 10:50, Jürgen Groß wrote:
> On 14.05.20 09:10, Jan Beulich wrote:
>> On 11.05.2020 13:28, Juergen Gross wrote:
>>> @@ -1956,13 +1958,17 @@ void sync_local_execstate(void)
>>> void sync_vcpu_execstate(struct vcpu *v)
>>> {
>>> - if ( v->dirty_cpu == smp_processor_id() )
>>> +
On 14.05.2020 11:03, Jan Beulich wrote:
> 1: address x86_insn_is_mem_{access,write}() omissions
> 2: disable FPU/MMX/SIMD insn emulation when !HVM
> 3: support MOVDIR{I,64B} insns
> 4: support ENQCMD insn
> 5: support SERIALIZE
> 6: support X{SUS,RES}LDTRK
> 7: support FNSTENV and FNSAVE
> 8:
1 - 100 of 116 matches
Mail list logo
