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
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 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.
> -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 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 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 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 -
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 )
>> -{
>> +
> -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: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: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
>
>
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.
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
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.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: 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 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 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, 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 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 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 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:
> @@ -
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 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
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
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
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
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
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
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
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
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/
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 +
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
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
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 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
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
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
[ 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
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
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-
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
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
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
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
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
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
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
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
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 +
>
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.
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
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
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
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 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.
>>
>>
>>
>>
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.
>>
>>
>>
>>
# 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
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
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 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 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
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
Hi Manikandan,
> On 15 Jul 2020, at 08:47, Manikandan Chockalingam (RBEI/ECF3)
> wrote:
>
> 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
Except for hvm_shadow_max_featuremask and deep_features they're
referenced by __init functions only.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpuid.c
+++ b/xen/arch/x86/cpuid.c
@@ -16,12 +16,15 @@
const uint32_t known_features[] = INIT_KNOWN_FEATURES;
const uint32_t special_features[] = I
flight 151895 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151895/
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
Hello all
[Sorry for the possible format issues]
> > 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
>
The actual document I am aware of [1]. *Although this is not exactly how to
bring up Xen Dom0*, this i
On Wed, Jul 15, 2020 at 08:36:10AM +0200, Jan Beulich wrote:
> On 14.07.2020 16:29, Roger Pau Monné wrote:
> > On Wed, Jul 01, 2020 at 12:27:37PM +0200, Jan Beulich wrote:
> >> The original intention was to ignore padding fields, but the pattern
> >> matched only ones whose names started with an un
On Wed, Jul 15, 2020 at 08:42:44AM +0200, Jan Beulich wrote:
> On 14.07.2020 16:58, Roger Pau Monné wrote:
> > On Wed, Jul 01, 2020 at 12:28:07PM +0200, Jan Beulich wrote:
> >> Translation macros aren't needed at all (or else a devicetree_label
> >> entry would have been missing), and userlist has
On Wed, Jul 01, 2020 at 12:25:15PM +0200, Jan Beulich wrote:
> As was pointed out by 0e2e54966af5 ("mm: fix public declaration of
> struct xen_mem_acquire_resource"), we're not currently handling structs
> correctly that have uint64_aligned_t fields. #pragma pack(4) suppresses
> the necessary align
On 15.07.2020 10:34, Roger Pau Monné wrote:
> On Wed, Jul 15, 2020 at 08:36:10AM +0200, Jan Beulich wrote:
>> On 14.07.2020 16:29, Roger Pau Monné wrote:
>>> On Wed, Jul 01, 2020 at 12:27:37PM +0200, Jan Beulich wrote:
--- a/xen/common/compat/memory.c
+++ b/xen/common/compat/memory.c
flight 151899 xen-4.14-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151899/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-armhf-armhf-xl-rtds16 guest-start/debian.repeat fail REGR. vs. 151892
Tests which did not suc
On 15.07.2020 10:41, Roger Pau Monné wrote:
> On Wed, Jul 15, 2020 at 08:42:44AM +0200, Jan Beulich wrote:
>> On 14.07.2020 16:58, Roger Pau Monné wrote:
>>> On Wed, Jul 01, 2020 at 12:28:07PM +0200, Jan Beulich wrote:
Translation macros aren't needed at all (or else a devicetree_label
en
On 15.07.2020 10:43, Roger Pau Monné wrote:
> On Wed, Jul 01, 2020 at 12:25:15PM +0200, Jan Beulich wrote:
>> As was pointed out by 0e2e54966af5 ("mm: fix public declaration of
>> struct xen_mem_acquire_resource"), we're not currently handling structs
>> correctly that have uint64_aligned_t fields.
xen-hhoks.mak contains hard wired paths for the used libraries of
qemu-trad. Replace those by the make variables from Xen's Rules.mk,
which is already included.
This in turn removes the need to add the runtime link paths of the
libraries the directly used libraries depend on.
Signed-off-by: Juerg
On Tue, Jul 07, 2020 at 09:39:40PM +0200, 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
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
... 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
---
v2: Re-base.
--- a/xen/arch/x86/physdev.c
+++ b/xen/arch/x86/physdev.c
@@ -670,6 +670,80 @@ ret_t do_physdev_
This was lost when making the logic accessible to PVH Dom0.
Fixes: 835d8d69d96a ("x86/rtc: provide mediated access to RTC for PVH dom0")
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -1160,6 +1160,10 @@ void rtc_guest_write(unsigned int port,
case RTC_POR
This in particular goes a few small steps further towards proper
!HVM and !PV config handling (i.e. no carrying of unnecessary
baggage).
1: x86/shadow: dirty VRAM tracking is needed for HVM only
2: x86/shadow: shadow_table[] needs only one entry for PV-only configs
3: x86/PV: drop a few misleading
Move shadow_track_dirty_vram() into hvm.c (requiring two static
functions to become non-static). More importantly though make sure we
don't de-reference d->arch.hvm.dirty_vram for a non-HVM guest. This was
a latent issue only just because the field lives far enough into struct
hvm_domain to be outs
The only guest/shadow level dependent piece here is the call to
sh_make_shadow(). Make a pointer to the respective function an
argument of sh_set_toplevel_shadow(), allowing it to be moved to
common.c.
This implies making get_shadow_status() available to common.c; its set
and delete counterparts a
Furthermore the field isn't needed at all with shadow support disabled -
move it into struct shadow_vcpu.
Introduce for_each_shadow_table(), shortening loops for the 4-level case
at the same time.
Adjust loop variables and a function parameter to be "unsigned int"
where applicable at the same tim
... by the very fact that they're 3-level specific, while PV always gets
run in 4-level mode. This requires adding some seemingly redundant
#ifdef-s - some of them will be possible to drop again once 2- and
3-level guest code doesn't get built anymore in !HVM configs, but I'm
afraid there's still q
The filling and cleaning up of v->arch.guest_table in new_guest_cr3()
was apparently inconsistent so far: There was a type ref acquired
unconditionally for the new top level page table, but the dropping of
the old type ref was conditional upon !paging_mode_refcounts(). Mirror
this also to arch_set_
On Tue, Jul 07, 2020 at 09:39:42PM +0200, Michał Leszczyński wrote:
> From: Michal Leszczynski
>
> Check if Intel Processor Trace feature is supported by current
> processor. Define vmtrace_supported global variable.
IIRC there was some discussion in previous versions about whether
vmtrace_suppo
> -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
>
> This was lost when making the logic accessib
1: install sync_cache hook on demand
2: use clear_page() in alloc_pgtable_maddr()
Jan
For full pages this is (meant to be) more efficient. Also change the
type and reduce the scope of the involved local variable.
Signed-off-by: Jan Beulich
--- a/xen/drivers/passthrough/vtd/iommu.c
+++ b/xen/drivers/passthrough/vtd/iommu.c
@@ -199,7 +199,6 @@ static void sync_cache(const void *add
Instead of checking inside the hook whether any non-coherent IOMMUs are
present, simply install the hook only when this is the case.
To prove that there are no other references to the now dynamically
updated ops structure (and hence that its updating happens early
enough), make it static and renam
On Wed, Jul 15, 2020 at 10:52:28AM +0200, Jan Beulich wrote:
> On 15.07.2020 10:41, Roger Pau Monné wrote:
> > On Wed, Jul 15, 2020 at 08:42:44AM +0200, Jan Beulich wrote:
> >> On 14.07.2020 16:58, Roger Pau Monné wrote:
> >>> On Wed, Jul 01, 2020 at 12:28:07PM +0200, Jan Beulich wrote:
> Tran
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
