On 15.07.20 19:16, peter@protonmail.com wrote:
Hello,
I have a question from all Xen Project developers and users.
What? Not from me. ;-)
Is OpenSUSE supporting Xen Project?
Why do you ask this here, instead of an OpenSUSE list/forum/whatever?
Did anyone install OpenSUSE?
I know se
flight 151923 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151923/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf e77966b341b993291ab2d95718b88a6a0d703d0c
baseline version:
ovmf c7195b9ec3c5f8f40119c
flight 151922 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151922/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-rtds 18 guest-localmigrate/x10 fail REGR. vs. 151899
Tests which did not suc
flight 151914 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151914/
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.
151065
test-amd64-amd
flight 151908 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151908/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-xsm 16 guest-start/debian.repeat fail REGR. vs. 151214
build-i386-pvops
# Session Notes on Xen system boot: launching VMs (DomB mode of dom0less)
Sessions Host: Christopher Clark. Scribing: Daniel Smith & Christopher Clark.
The DomB-mode-for-dom0less topic was covered in two design session slots
at the Xen Design & Developer Summit 2020.
## Session 1: Xen system boo
On 7/15/20 4:49 PM, Anchal Agarwal wrote:
> On Mon, Jul 13, 2020 at 11:52:01AM -0400, Boris Ostrovsky wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>> the content is safe.
>>
>>
>>
>>
On 7/15/20 3:49 PM, Anchal Agarwal wrote:
> On Mon, Jul 13, 2020 at 03:43:33PM -0400, Boris Ostrovsky wrote:
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you can confirm the sender and know
>> the content is safe.
>>
>>
>>
>>
flight 151903 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151903/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt 17 guest-start.2fail REGR. vs. 151884
Tests which did no
On 7/15/20 9:07 AM, osstest service owner wrote:
flight 151910 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151910/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-build
This issue with Xen 4.13 and Ceph/RBD was last discussed back in February.
> Remote network Ceph image works fine with Xen 4.12.x ...
>
> In Xen 4.13.0 which I have tested recently it blames with the error
> message "no such file or directory" as it would try accessing the image
> over filesystem
flight 151921 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151921/
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
Hello,
I have a question from all Xen Project developers and users. Is OpenSUSE
supporting Xen Project?
Did anyone install OpenSUSE? Why OpenSUSE not have any option about installing
Xen during installation but have an option about KVM?
Why Xen package doesn't included?
Cheers.
On Tue, Jul 07, 2020 at 09:39:48PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Implement domctl to manage the runtime state of
> processor trace feature.
>
> Signed-off-by: Michal Leszczynski
> ---
> xen/arch/x86/domctl.c | 50 +
>
On Tue, Jul 07, 2020 at 09:39:47PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Allow to map processor trace buffer using
> acquire_resource().
>
> Signed-off-by: Michal Leszczynski
> ---
> xen/common/memory.c | 31 +++
> xen/include/publi
Ian Jackson writes ("[PATCH 08/12] tools: move libxenctrl below tools/libs"):
> From: Juergen Gross
>
> Today tools/libxc needs to be built after tools/libs as libxenctrl is
> depending on some libraries in tools/libs. This in turn blocks moving
> other libraries depending on libxenctrl below too
Ian Jackson writes ("[PATCH 07/12] tools/libxc: untangle libxenctrl from
libxenguest"):
> From: Juergen Gross
>
> Sources of libxenctrl and libxenguest are completely entangled. In
> practice libxenguest is a user of libxenctrl, so don't let any source
> libxenctrl include xg_private.h.
>
> Thi
On Sat, 11 Jul 2020, Michael S. Tsirkin wrote:
> On Fri, Jul 10, 2020 at 10:23:22AM -0700, Stefano Stabellini wrote:
> > Sorry for the late reply -- a couple of conferences kept me busy.
> >
> >
> > On Wed, 1 Jul 2020, Michael S. Tsirkin wrote:
> > > On Wed, Jul 01, 2020 at 10:34:53AM -0700, Stef
Stefano Stabellini writes ("Re: [PATCH 00/12] tools: move more libraries into
tools/libs"):
> On Wed, 15 Jul 2020, Ian Jackson wrote:
> > [ NB: this patch series is actually from Juergen Gross.
> >
> > It is being experiemntally handled as a Merge Reqeust in gitlab, in
> > part to see what pr
Ian Jackson writes ("[PATCH 06/12] tools/misc: don't use libxenctrl internals
from misc tools"):
> From: Juergen Gross
>
> xen-hptool and xen-mfndump are using internals from libxenctrl e.g. by
> including private headers. Fix that by using either the correct
> official headers or use other mean
From: Juergen Gross
Library related make variables (CFLAGS_lib*, SHDEPS_lib*, LDLIBS_lib*
and SHLIB_lib*) mostly have a common pattern for their values. Generate
most of this content automatically by adding a new per-library variable
defining on which other libraries a lib is depending. This in t
From: Juergen Gross
There is no reason why libvchan is not placed in the tools/libs
directory.
At the same time move libxenvchan.h to a dedicated include directory
in tools/libs/vchan in order to follow the same pattern as the other
libraries in tools/libs.
As tools/libvchan now contains no lib
Ian Jackson writes ("[PATCH 04/12] tools: don't call make recursively from
libs.mk"):
> From: Juergen Gross
>
> During build of a xen library make is called again via libs.mk. This is
> not necessary as the same can be achieved by a simple dependency.
Reviewed-by: Ian Jackson
From: Juergen Gross
There is no reason why libxenstat is not placed in the tools/libs
directory.
At the same time move xenstat.h to a dedicated include directory
in tools/libs/stat in order to follow the same pattern as the other
libraries in tools/libs.
As now xentop is the only left directory
From: Juergen Gross
There is no reason why libxenstore is not placed in the tools/libs
directory.
The common files between libxenstore and xenstored are kept in the
tools/xenstore directory to be easily accessible by xenstore-stubdom
which needs the xenstored files to be built.
Signed-off-by: J
On Wed, 15 Jul 2020, Jan Beulich wrote:
> asm/domain.h is a dependency of xen/sched.h, and hence should not itself
> include xen/sched.h. Nor should any of the other #include-s used by it.
> While at it, also drop two other #include-s that aren't needed by this
> particular header.
>
> Signed-off-
On Wed, 15 Jul 2020, Ian Jackson wrote:
> [ NB: this patch series is actually from Juergen Gross.
>
> It is being experiemntally handled as a Merge Reqeust in gitlab, in
> part to see what problems there are with that workflow that will
> need extra tooling or whatever.
>
> I have manuall
From: Juergen Gross
During build of a xen library make is called again via libs.mk. This is
not necessary as the same can be achieved by a simple dependency.
Signed-off-by: Juergen Gross
---
tools/libs/libs.mk | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/libs/lib
From: Juergen Gross
In order to harmonize names of library related make variables switch
XEN_LIBXEN* names to XEN_libxen*, as all other related variables (e.g.
CFLAGS_libxen*, SHDEPS_libxen*, ...) already use this pattern.
Rename XEN_LIBXC to XEN_libxenctrl, XEN_XENSTORE to XEN_libxenstore,
XEN_
From: Juergen Gross
xen-hptool and xen-mfndump are using internals from libxenctrl e.g. by
including private headers. Fix that by using either the correct
official headers or use other means.
Signed-off-by: Juergen Gross
---
tools/libxc/xg_save_restore.h | 4 --
tools/misc/Makefile
[ NB: this patch series is actually from Juergen Gross.
It is being experiemntally handled as a Merge Reqeust in gitlab, in
part to see what problems there are with that workflow that will
need extra tooling or whatever.
I have manually generated this series using git-format-patch,
scri
From: Juergen Gross
Today tools/libxc needs to be built after tools/libs as libxenctrl is
depending on some libraries in tools/libs. This in turn blocks moving
other libraries depending on libxenctrl below tools/libs.
So carve out libxenctrl from tools/libxc and move it into
tools/libs/ctrl.
Si
From: Juergen Gross
The headers.chk target in tools/Rules.mk tries to compile all headers
stand alone for testing them not to include any internal header.
Unfortunately the headers tested against are not complete, as any
header for a Xen library is not included in the include path of the
test co
The runes for this manual osstest were wrong. It needs to run as
osstest, and cr-for-branches should be run from testing.git.
Signed-off-by: Ian Jackson
---
docs/process/branching-checklist.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/process/branching-checkl
From: Juergen Gross
Today there are multiple copies of the ROUNDUP() macro in various
sources and headers. Define it once in tools/include/xen-tools/libs.h.
Using xen-tools/libs.h enables removing copies of MIN() and MAX(), too.
Signed-off-by: Juergen Gross
---
tools/console/daemon/io.c
From: Juergen Gross
Sources of libxenctrl and libxenguest are completely entangled. In
practice libxenguest is a user of libxenctrl, so don't let any source
libxenctrl include xg_private.h.
This can be achieved by moving all definitions used by libxenctrl from
xg_private.h to xc_private.h. Addit
From: Juergen Gross
stubdom/mini-os.mk should contain paths used by Mini-OS when built as
stubdom.
Signed-off-by: Juergen Gross
---
stubdom/mini-os.mk | 17 +
1 file changed, 17 insertions(+)
create mode 100644 stubdom/mini-os.mk
diff --git a/stubdom/mini-os.mk b/stubdom/mini
On Tue, Jul 07, 2020 at 09:39:46PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Use Intel Processor Trace feature to provide vmtrace_pt_*
> interface for HVM/VMX.
>
> Signed-off-by: Michal Leszczynski
> ---
> xen/arch/x86/hvm/vmx/vmx.c | 110 +
Hi all,
Xen 4.14 RC6 is tagged. You can check that out from xen.git:
git://xenbits.xen.org/xen.git 4.14.0-rc6
For your convenience there is also a tarball at:
https://downloads.xenproject.org/release/xen/4.14.0-rc6/xen-4.14.0-rc6.tar.gz
And the signature is at:
https://downloads.xenproject.org/
flight 151907 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151907/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf c7195b9ec3c5f8f40119c96ac4a0ab1e8cebe9dc
baseline version:
ovmf 256c4470f86e53661c070
On Tue, Jul 07, 2020 at 09:39:45PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Implement necessary changes in common code/HVM to support
> processor trace features. Define vmtrace_pt_* API and
> implement trace buffer allocation/deallocation in common
> code.
>
> Signed-off-b
The runes for this manual osstest were wrong. It needs to run as
osstest, and cr-for-branches should be run from testing.git.
Signed-off-by: Ian Jackson
---
docs/process/branching-checklist.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/docs/process/branching-checkl
From: Edwin Török
Sent: 15 July 2020 16:10
To: xen-devel@lists.xenproject.org
Cc: Edwin Torok; Christian Lindig; David Scott; Ian Jackson; Wei Liu; Igor
Druzhinin
Subject: [PATCH v1 1/1] oxenstored: fix ABI breakage introduced in Xen 4.9.0
dbc84d2983969b
On Tue, Jul 07, 2020 at 09:39:44PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Allow to specify the size of per-vCPU trace buffer upon
> domain creation. This is zero by default (meaning: not enabled).
>
> Signed-off-by: Michal Leszczynski
> ---
> docs/man/xl.cfg.5.pod.in
dbc84d2983969bb47d294131ed9e6bbbdc2aec49 (Xen >= 4.9.0) deleted XS_RESTRICT
from oxenstored, which caused all the following opcodes to be shifted by 1:
reset_watches became off-by-one compared to the C version of xenstored.
Looking at the C code the opcode for reset watches needs:
XS_RESET_WATCHES
dbc84d2983969bb47d294131ed9e6bbbdc2aec49 (Xen >= 4.9.0) deleted XS_RESTRICT
from oxenstored, which caused all the following opcodes to be shifted by 1,
breaking the ABI compared to the C version and guests.
The affected opcode is 'reset watches', e.g. Linux uses this during kexec if a
suitable
co
On Tue, Jul 07, 2020 at 09:39:43PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Add vmtrace_pt_size domain parameter in live domain and
> vmtrace_pt_order parameter in xen_domctl_createdomain.
>
> Signed-off-by: Michal Leszczynski
> ---
> xen/arch/x86/domain.c | 6
flight 151910 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151910/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-i386-libvirt
On Wed, Jul 15, 2020 at 03:51:17PM +0200, Jan Beulich wrote:
> On 15.07.2020 15:32, Roger Pau Monné wrote:
> > On Wed, Jul 15, 2020 at 02:36:49PM +0200, Jan Beulich wrote:
> >> On 15.07.2020 14:13, Roger Pau Monné wrote:
> >>> On Wed, Jul 15, 2020 at 01:56:47PM +0200, Jan Beulich wrote:
> @@ -
On 15.07.20 16:37, George Dunlap wrote:
On Jul 13, 2020, at 3:47 PM, Jan Beulich wrote:
On 13.07.2020 16:03, Juergen Gross wrote:
In docs/misc/hypfs-paths.pandoc the supported paths in the hypervisor
file system are specified. Make it more clear that path availability
might change, e.g. due
> On Jul 13, 2020, at 3:47 PM, Jan Beulich wrote:
>
> On 13.07.2020 16:03, Juergen Gross wrote:
>> In docs/misc/hypfs-paths.pandoc the supported paths in the hypervisor
>> file system are specified. Make it more clear that path availability
>> might change, e.g. due to scope widening or narrowi
On Wed, 15 Jul 2020, 14:42 Jan Beulich, wrote:
> On 15.07.2020 12:46, Julien Grall wrote:
> > On Wed, 15 Jul 2020, 12:17 Jan Beulich, wrote:
> >
> >> Neither the code nor the original commit provide any justification for
> >> the need to 8-byte align the struct in all cases. Enforce just as much
On 15.07.2020 15:32, Roger Pau Monné wrote:
> On Wed, Jul 15, 2020 at 02:36:49PM +0200, Jan Beulich wrote:
>> On 15.07.2020 14:13, Roger Pau Monné wrote:
>>> On Wed, Jul 15, 2020 at 01:56:47PM +0200, Jan Beulich wrote:
@@ -1160,6 +1162,14 @@ void rtc_guest_write(unsigned int port,
ca
On Wed, Jul 15, 2020 at 02:36:49PM +0200, Jan Beulich wrote:
> On 15.07.2020 14:13, Roger Pau Monné wrote:
> > On Wed, Jul 15, 2020 at 01:56:47PM +0200, Jan Beulich wrote:
> >> @@ -1160,6 +1162,14 @@ void rtc_guest_write(unsigned int port,
> >> case RTC_PORT(1):
> >> if ( !ioports_acc
On 29.05.2020 13:11, Hongyan Xia wrote:
> From: Hongyan Xia
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
with a sufficiently minor remark:
> --- a/xen/arch/x86/mm.c
> +++ b/xen/arch/x86/mm.c
> @@ -4918,10 +4918,11 @@ mfn_t alloc_xen_pagetable_new(void)
>
On 15.07.20 15:01, Jan Beulich wrote:
On 15.07.2020 14:51, Juergen Gross wrote:
Move some more libraries under tools/libs, including libxenctrl. This
is resulting in a lot of cleanup work regarding building libs and
restructuring of the tools directory.
I have (for now) left out some more libra
On 29.05.2020 13:11, Hongyan Xia wrote:
> From: Wei Liu
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
On 29.05.2020 13:11, Hongyan Xia wrote:
> From: Wei Liu
>
> Signed-off-by: Wei Liu
> Signed-off-by: Hongyan Xia
Reviewed-by: Jan Beulich
On 15.07.2020 14:51, Juergen Gross wrote:
> Move some more libraries under tools/libs, including libxenctrl. This
> is resulting in a lot of cleanup work regarding building libs and
> restructuring of the tools directory.
>
> I have (for now) left out some more libraries like libxenguest and
> lib
Move some more libraries under tools/libs, including libxenctrl. This
is resulting in a lot of cleanup work regarding building libs and
restructuring of the tools directory.
I have (for now) left out some more libraries like libxenguest and
libxl, but I can have a try moving those, too, if wanted.
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2020 13:05
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Roger Pau Monné
> ; Wei Liu
> ; Paul Durrant
> Subject: [PATCH 3/3] x86/HVM: fold both instances of looking up a
> hvm_ioreq_vcpu with a request
> pending
>
>
On 15.07.2020 14:47, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 15 July 2020 13:04
>>
>> @@ -139,20 +132,24 @@ static bool hvm_wait_for_io(struct hvm_i
>> p->state = STATE_IOREQ_NONE;
>> data = p->data;
>> break;
>> +
>
> Possibly mention the style fi
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2020 13:04
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Roger Pau Monné
> ; Wei Liu
> ; Paul Durrant
> Subject: [PATCH 2/3] x86/HVM: re-work hvm_wait_for_io() a little
>
> Convert the function's main loop to a more o
On 15.07.2020 14:40, Paul Durrant wrote:
>> From: Jan Beulich
>> Sent: 15 July 2020 13:04
>>
>> static bool hvm_wait_for_io(struct hvm_ioreq_vcpu *sv, ioreq_t *p)
>> {
>> unsigned int prev_state = STATE_IOREQ_NONE;
>> +uint64_t data = ~0;
>>
>> -while ( sv->pending )
>> -{
>> +
On 15.07.2020 12:46, Julien Grall wrote:
> On Wed, 15 Jul 2020, 12:17 Jan Beulich, wrote:
>
>> Neither the code nor the original commit provide any justification for
>> the need to 8-byte align the struct in all cases. Enforce just as much
>> alignment as the structure actually needs - 4 bytes -
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2020 13:04
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Roger Pau Monné
> ; Wei Liu
> ; Paul Durrant
> Subject: [PATCH 1/3] x86/HVM: fold hvm_io_assist() into its only caller
>
> While there are two call sites, the f
On 15.07.2020 14:13, Roger Pau Monné wrote:
> On Wed, Jul 15, 2020 at 01:56:47PM +0200, Jan Beulich wrote:
>> @@ -1160,6 +1162,14 @@ void rtc_guest_write(unsigned int port,
>> case RTC_PORT(1):
>> if ( !ioports_access_permitted(currd, RTC_PORT(0), RTC_PORT(1)) )
>> break;
> -Original Message-
> From: Jan Beulich
> Sent: 15 July 2020 12:57
> To: xen-devel@lists.xenproject.org
> Cc: Andrew Cooper ; Paul Durrant ;
> Wei Liu ;
> Roger Pau Monné
> Subject: [PATCH v3 1/2] x86: restore pv_rtc_handler() invocation
>
> This was lost when making the logic accessib
On 07.07.2020 21:39, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Allow to acquire large resources by allowing acquire_resource()
> to process items in batches, using hypercall continuation.
>
> Be aware that this modifies the behavior of acquire_resource
> call with frame_list=NULL.
On Wed, Jul 15, 2020 at 01:56:47PM +0200, Jan Beulich wrote:
> This was lost when making the logic accessible to PVH Dom0.
>
> While doing so make the access to the global function pointer safe
> against races (as noticed by Roger): The only current user wants to be
> invoked just once (but can to
On 15.07.2020 11:36, Roger Pau Monné wrote:
> On Tue, Jul 07, 2020 at 09:39:40PM +0200, Michał Leszczyński wrote:
>> @@ -1599,8 +1629,17 @@ long do_memory_op(unsigned long cmd,
>> XEN_GUEST_HANDLE_PARAM(void) arg)
>> #endif
>>
>> case XENMEM_acquire_resource:
>> -rc = acquire_resou
It seems pretty likely that the "break" in the loop getting replaced in
handle_hvm_io_completion() was meant to exit both nested loops at the
same time. Re-purpose what has been hvm_io_pending() to hand back the
struct hvm_ioreq_vcpu instance found, and use it to replace the two
nested loops.
Sign
Convert the function's main loop to a more ordinary one, without goto
and without initial steps not needing to be inside a loop at all.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/hvm/ioreq.c
+++ b/xen/arch/x86/hvm/ioreq.c
@@ -106,24 +106,17 @@ bool hvm_io_pending(struct vcpu *v)
static bool
While there are two call sites, the function they're in can be slightly
re-arranged such that the code sequence can be added at its bottom. Note
that the function's only caller has already checked sv->pending, and
that the prior while() loop was just a slightly more fancy if()
(allowing an early br
Much of what gets done here was discussed in the context of
"ioreq: handle pending emulation racing with ioreq server
destruction" already.
1: fold hvm_io_assist() into its only caller
2: re-work hvm_wait_for_io() a little
3: fold both instances of looking up a hvm_ioreq_vcpu with a request pendin
This was lost when making the logic accessible to PVH Dom0.
While doing so make the access to the global function pointer safe
against races (as noticed by Roger): The only current user wants to be
invoked just once (but can tolerate to be invoked multiple times),
zapping the pointer at that point
... in order to also intercept accesses through the alias ports.
Also stop intercepting accesses to the CMOS ports if we won't ourselves
use the CMOS RTC.
Signed-off-by: Jan Beulich
---
v3: Re-base over change to earlier patch.
v2: Re-base.
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physde
The first patch addresses a recent regression and hence ought to be
considered for 4.14, despite it getting late. I noticed the problem
while re-basing the 2nd patch here, which I decided to now re-post
despite the original discussion on v1 not having lead to any clear
result (i.e. the supposed "le
"Old" tested version had not actually been tested; therefore in this
flight we test it, rather than a new candidate. The baseline, if
any, is the most recent actually tested revision.
flight 151900 qemu-upstream-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151900/
Fa
Use ALTERNATIVE directly, such that at the use sites it is visible that
alternative code patching is in use. Similarly avoid hiding the fact in
SAVE_ALL.
No change to generated code.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -2165,9 +2165,9 @@ void acti
There's little point in having two separate headers both getting
included by asm_defns.h. This in particular reduces the number of
instances of guarding asm(".include ...") suitably in such dual use
headers.
No change to generated code.
Signed-off-by: Jan Beulich
--- a/xen/Makefile
+++ b/xen/Ma
Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had
to introduce a number of #ifdef-s to make the build work with older tool
chains. Introduce an assembler macro covering for tool chains not
knowing of CET-SS, allowing some conditionals where just SETSSBSY is the
problem to be d
Introduce proper assembler macros instead, enabled only when the
assembler itself doesn't support the insns. To avoid duplicating the
macros for assembly and C files, have them processed into asm-macros.h.
This in turn requires adding a multiple inclusion guard when generating
that header.
No chan
Hello Oleksandr Tyshchenko,
Thanks for your quick response. With Xen stable 4.13 branch, the mentioned
issue is solved.
Is there any document which I could refer to bring up Xen[DOM0] and have an
hands on ? because am currently seeing no output after this
(XEN) *** Serial input to DOM0 (type 'C
On Wed, 15 Jul 2020, 12:17 Jan Beulich, wrote:
> Neither the code nor the original commit provide any justification for
> the need to 8-byte align the struct in all cases. Enforce just as much
> alignment as the structure actually needs - 4 bytes - by using alignof()
> instead of a literal number
Parts of this were discussed in the context of Andrew's CET-SS work.
Other parts simply fit the underlying picture.
1: replace __ASM_{CL,ST}AC
2: reduce CET-SS related #ifdef-ary
3: drop ASM_{CL,ST}AC
4: fold indirect_thunk_asm.h into asm-defns.h
Jan
There is no need for platform-wide, system-wide, or per-domain control
in this case. Hence avoid including this dead code in the build.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -23,7 +23,6 @@ obj-$(CONFIG_GDBSX) += debug.o
obj-y += delay.o
obj-y +=
This is in preparation of making the building of sysctl.c conditional.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
@@ -396,3 +397,36 @@ void call_function_interrupt(struct cpu_
This is in preparation of making the building of domctl.c conditional.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -294,6 +294,173 @@ void update_guest_memory_policy(struct v
}
}
+void domain_cpu_policy_changed(struct domain *d)
+{
+const str
A subsequent change will exclude domctl.c from getting built for a
particular configuration, yet the two functions get used from elsewhere.
Signed-off-by: Jan Beulich
--- a/xen/common/bitmap.c
+++ b/xen/common/bitmap.c
@@ -9,6 +9,9 @@
#include
#include
#include
+#include
+#include
+#incl
asm/domain.h is a dependency of xen/sched.h, and hence should not itself
include xen/sched.h. Nor should any of the other #include-s used by it.
While at it, also drop two other #include-s that aren't needed by this
particular header.
Signed-off-by: Jan Beulich
--- a/xen/include/asm-arm/domain.h
While this won't affect overall memory overhead (struct vcpu as well as
struct domain get allocated as single pages) nor code size (the offsets
into the base structures are too large to be representable as signed 8-
bit displacements), it'll allow the tail of struct pv_{domain,vcpu} to
share a cach
There's no need for xen.efi at all, and there's also no need for EFI
support in xen.gz since the shim runs in PVH mode, i.e. without any
firmware (and hence by implication also without EFI one).
The slightly odd looking use of $(space) is to ensure the new ifneq()
evaluates consistently between "b
With changes done over time and as far as linking goes, the only special
thing about building with EFI support enabled is the need for the dummy
relocations object for xen.gz uniformly in all build stages. All other
efi/*.o can be consumed from the built_in*.o files.
In efi/Makefile, besides movin
This is in part a just loosely connected set of changes in particular
aiming at further shim binary reduction.
Patch 3 depends functionally (but not contextually in any way) on the
previously submitted "x86/shadow: dirty VRAM tracking is needed for
HVM only". But I could imagine anyway that this e
Neither the code nor the original commit provide any justification for
the need to 8-byte align the struct in all cases. Enforce just as much
alignment as the structure actually needs - 4 bytes - by using alignof()
instead of a literal number.
Take the opportunity and also
- add so far missing val
Use ENXIO instead of EINVAL to cover the two cases of the address not
satisfying the requirements. This will make an issue here better stand
out at the call site.
Also add a missing compat-mode related size check: If the sizes
differed, other code in the function would need changing. Accompany thi
There are a few largely cosmetic things that were discussed in the
context of the XSA, but which weren't really XSA material.
1: common: map_vcpu_info() cosmetics
2: evtchn/fifo: don't enforce higher than necessary alignment
Jan
flight 151916 xen-unstable-coverity real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151916/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xen 1969576661f3e34318e9b0a61a1a38f9a5aee16f
baseline version:
xen 02d6
On 15.07.2020 12:01, Paul Durrant wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: 15 July 2020 10:47
>> To: xen-devel@lists.xenproject.org
>> Cc: Andrew Cooper ; Paul Durrant ;
>> Wei Liu ;
>> Roger Pau Monné
>> Subject: [PATCH v2 1/2] x86: restore pv_rtc_handler() invocation
1 - 100 of 128 matches
Mail list logo
