DIV_ROUND_UP has implemented the code-opened function. Therefore, just
replace the implementation with DIV_ROUND_UP.
Signed-off-by: zhong jiang
---
drivers/block/xen-blkback/common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/xen-blkback/common.h
On Tue, Sep 11, 2018 at 12:08:42PM -0600, Tamas K Lengyel wrote:
> On Mon, Sep 3, 2018 at 9:48 AM Adrian Pop wrote:
> >
> > From: Vlad Ioan Topan
> >
> > The default value for the "suppress #VE" bit set by set_mem_access()
> > currently depends on whether the call is made from the same domain
On Tue, Sep 11, 2018 at 12:02:39PM -0600, Tamas K Lengyel wrote:
> On Mon, Sep 3, 2018 at 9:48 AM Adrian Pop wrote:
> >
> > Signed-off-by: Adrian Pop
>
> Acked-by: Tamas K Lengyel
Thanks!
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
flight 127504 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127504/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-examine 4 memdisk-try-append fail REGR. vs. 127489
Tests which did
On Tue, 28 Aug 2018, Julien Grall wrote:
> Hi Stefano,
>
> As Jan said on the previous version, the CC list is too short. All the REST
> should be included for public interface change. Please have a look at
> scripts/add_maintainers.pl, it will do the job for you...
Ah! I added all the REST
branch xen-unstable
xenbranch xen-unstable
job test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm
testid debian-hvm-install
Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git
Tree: qemu
On Tue, 28 Aug 2018, Julien Grall wrote:
> Hi,
>
> On 11/08/18 01:00, Stefano Stabellini wrote:
> > Shared memory regions need to be advertised to the guest. Fortunately, a
> > device tree binding for special memory regions already exist:
> > reserved-memory.
> >
> > Add a reserved-memory node
flight 127497 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127497/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install
fail REGR. vs. 125898
On Tue, 28 Aug 2018, Julien Grall wrote:
> Hi,
>
> On 11/08/18 01:00, Stefano Stabellini wrote:
> > From: Zhongze Liu
> >
> > Author: Zhongze Liu
> >
> > Add a new structure to the IDL family to represent static shared memory
> > regions
> > as proposed in the proposal "Allow setting up
On 9/5/18 3:37 PM, Jim Fehlig wrote:
On 08/24/2018 02:58 AM, Wei Liu wrote:
On Wed, Aug 22, 2018 at 04:52:27PM -0600, Jim Fehlig wrote:
On 08/21/2018 05:14 AM, Jan Beulich wrote:
On 21.08.18 at 03:11, wrote:
flight 126201 xen-4.9-testing real [real]
This run is configured for baseline tests only.
flight 75200 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75200/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm
On 9/11/18 4:20 PM, Thomas Gleixner wrote:
> On Tue, 11 Sep 2018, Boris Ostrovsky wrote:
>
>> For unprivileged Xen PV guests this is normal memory and ioremap will
>> not be able to properly map it.
>>
>> While at it, since ioremap may return NULL, add a test for pointer's
>> validity.
> I assume
On Tue, 11 Sep 2018, Boris Ostrovsky wrote:
> For unprivileged Xen PV guests this is normal memory and ioremap will
> not be able to properly map it.
>
> While at it, since ioremap may return NULL, add a test for pointer's
> validity.
I assume this goes back to very dead kernels, so that should
For unprivileged Xen PV guests this is normal memory and ioremap will
not be able to properly map it.
While at it, since ioremap may return NULL, add a test for pointer's
validity.
Reported-by: Andy Smith
Signed-off-by: Boris Ostrovsky
---
arch/x86/kernel/eisa.c | 10 --
1 file
flight 127508 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127508/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
On 9/7/18 10:31 AM, Olaf Hering wrote:
> The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:
>
> BUG: unable to handle kernel NULL pointer dereference at 02d8
> PGD 0 P4D 0
> Oops: [#1] PREEMPT SMP NOPTI
> CPU: 7 PID: 65 Comm: xenwatch Not tainted
On 9/7/18 12:49 PM, Marek Marczykowski-Górecki wrote:
> Scrubbing pages on initial balloon down can take some time, especially
> in nested virtualization case (nested EPT is slow). When HVM/PVH guest is
> started with memory= significantly lower than maxmem=, all the extra
> pages will be scrubbed
Hi Julien,
On 11.09.18 16:37, Julien Grall wrote:
Hi Volodymyr,
On 10/09/18 19:04, Volodymyr Babchuk wrote:
On 10.09.18 17:02, Julien Grall wrote:
On 03/09/18 17:54, Volodymyr Babchuk wrote:
[...]
+ if ( !pages_data_xen_start )
+ return false;
+
+ shm_buf =
Hi Julien,
On 11.09.18 14:53, Julien Grall wrote:
On 10/09/18 18:44, Volodymyr Babchuk wrote:
Hi Julien,
On 10.09.18 16:01, Julien Grall wrote:
Hi Volodymyr,
On 03/09/18 17:54, Volodymyr Babchuk wrote:
OP-TEE usually uses the same idea with command buffers (see
previous commit) to issue
Hi,
On 11.09.18 16:56, Julien Grall wrote:
On 10/09/18 19:14, Volodymyr Babchuk wrote:
On 10.09.18 18:34, Julien Grall wrote:
On 03/09/18 17:54, Volodymyr Babchuk wrote:
static struct shm_buf *allocate_shm_buf(struct domain_ctx *ctx,
uint64_t
Rename the functions to guest_{rd,wr}msr_viridian() for consistency, and
because the _regs() suffix isn't very appropriate.
Update them to take a vcpu pointer rather than presuming that they act on
current, which is safe for all implemented operations, and switch their return
ABI to use
Split apart from v2, to make all the dispatching code obvious in patch 1. See
individual patches for changes.
Andrew Cooper (3):
x86/msr: Dispatch Xen and Viridian MSRs from guest_{wr,rd}msr()
x86/viridan: Clean up Viridian MSR infrastructure
x86: Clean up the Xen MSR infrastructure
Despite the complicated diff in {svm,vmx}_msr_write_intercept(), it is just
the 0 case losing one level of indentation, as part of removing the call to
wrmsr_hypervisor_regs().
The case blocks in guest_{wr,rd}msr() use raw numbers, partly for consistency
with the CPUID side of things, but mainly
Rename them to guest_{rd,wr}msr_xen() for consistency, and because the _regs
suffix isn't very appropriate.
Update them to take a vcpu pointer rather than presuming that they act on
current, and switch to using X86EMUL_* return values.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei
On Mon, Sep 3, 2018 at 9:48 AM Adrian Pop wrote:
>
> From: Vlad Ioan Topan
>
> The default value for the "suppress #VE" bit set by set_mem_access()
> currently depends on whether the call is made from the same domain (the
> bit is set when called from another domain and cleared if called from
>
On Mon, Sep 3, 2018 at 9:48 AM Adrian Pop wrote:
>
> Signed-off-by: Adrian Pop
Acked-by: Tamas K Lengyel
> ---
> tools/libxc/include/xenctrl.h | 2 ++
> tools/libxc/xc_altp2m.c | 26 +++
> xen/arch/x86/hvm/hvm.c | 19 ++
>
Dear community members,
The proposed agenda is at
https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/edit#
And below in text form:
== Open / Closed Actions from Previous calls ==
[Open] Lars to bring up x86 bottleneck at next AB call – due to the Aug
holidays we
On Tue, Sep 11, 2018 at 9:13 AM Dario Faggioli wrote:
>
> On Mon, 2018-09-10 at 15:45 -0600, Tamas K Lengyel wrote:
> > On Fri, Aug 24, 2018 at 3:16 AM Dario Faggioli
> > wrote:
> > >
> > > Note that I'll be off for ~2 weeks, effective next Monday, so feel
> > > free
> > > to comment, reply,
flight 127503 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127503/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Poisoning idle_vcpu[0] with the sanity debug value isn't actually a clever
idea, because it passes a NULL pointer check but isn't a usable vcpu. It is
also the reason for the (!is_idle_domain(d) || vcpu_id) part of the existing
sanity BUG_ON().
Now that d->max_vcpus is appropriately set up
This patch adds image size and flags to XEN image header. It uses
those fields according to the updated Linux kernel image definition.
With this patch bootloader can now place XEN image anywhere in system
RAM at 2MB aligned address without to worry about relocation.
For instance, it fixes the XEN
On Thu, 2018-08-30 at 16:31 +0100, Andrew Cooper wrote:
> There original reason for this patch was to fix a livepatching
> problem;
> unnecesserily large livepatchs due to the use of __LINE__.
>
> A second problem is one of debugability. A number of domain_crash()
> invocations have no logging
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 11 September 2018 14:15
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; Wei Liu ; George Dunlap
>
> Subject: [PATCH v2 3/4] x86/HVM: implement memory read caching
>
> Emulation requiring device model
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 11 September 2018 14:15
> To: xen-devel
> Cc: Andrew Cooper ; Paul Durrant
> ; Wei Liu ; George Dunlap
>
> Subject: [PATCH v2 2/4] x86/mm: use optional cache in guest_walk_tables()
>
> The caching isn't actually
On Thu, 2018-09-06 at 15:01 +0100, Andrew Cooper wrote:
> alloc_vcpu()'s call to domain_update_node_affinity() has existed for
> a decade,
> but its effort is mostly wasted.
>
> alloc_vcpu() is called in a loop for each vcpu, bringing them into
> existence.
> The values of the affinity masks are
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 11 September 2018 15:48
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Stefano Stabellini ; xen-devel de...@lists.xenproject.org>; Konrad Rzeszutek Wilk
> ;
On Tue, 2018-09-11 at 02:29 -0600, Jan Beulich wrote:
> > > > On 11.09.18 at 10:10, wrote:
> >
> > From: Andrii Anisov
> >
> > diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c
> > index 84e744b..7170172 100644
> >
> > @@ -701,10 +704,11 @@ static unsigned int
> -Original Message-
> From: Xen-devel [mailto:xen-devel-boun...@lists.xenproject.org] On Behalf
> Of Jan Beulich
> Sent: 11 September 2018 15:31
> To: Paul Durrant
> Cc: Kevin Tian ; Stefano Stabellini
> ; Wei Liu ; Jun Nakajima
> ; Razvan Cojocaru ;
> Konrad Rzeszutek Wilk ; George
On 11/09/18 16:36, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Signed-off-by: Andrii Anisov
Acked-by: Andrew Cooper
> ---
> xen/common/domain.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/common/domain.c b/xen/common/domain.c
> index 78c450e..aec10a7
On 09/11/2018 04:19 PM, Andrii Anisov wrote:
>
> On 11.09.18 13:44, George Dunlap wrote:
>> What I do in xenalyze is to have the timestamps in seconds, but always
>> print down to the nanosecond. (For this I actually break cpu cycles
>> into s and ns separately, and then print "%u.%09u".)
>
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/arch/arm/traps.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 9ae64ae..7bfdda8 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/common/domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 78c450e..aec10a7 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -155,7 +155,7 @@ struct
flight 127502 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127502/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1ad635b283812283e8db457ba4809d5d38433f17
baseline version:
ovmf
On 11.09.18 13:44, George Dunlap wrote:
What I do in xenalyze is to have the timestamps in seconds, but always
print down to the nanosecond. (For this I actually break cpu cycles
into s and ns separately, and then print "%u.%09u".)
Here, we can have the same. With the 0current formula in
This run is configured for baseline tests only.
flight 75198 linux-3.18 real [real]
http://osstest.xensource.com/osstest/logs/75198/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64
>>> On 23.08.18 at 11:47, wrote:
> --- a/xen/common/iommu_op.c
> +++ b/xen/common/iommu_op.c
> @@ -123,6 +123,156 @@ static int iommu_op_enable_modification(
> return 0;
> }
>
> +static int iommuop_map(struct xen_iommu_op_map *op)
> +{
> +struct domain *d, *currd = current->domain;
>
On Mon, 2018-09-10 at 15:45 -0600, Tamas K Lengyel wrote:
> On Fri, Aug 24, 2018 at 3:16 AM Dario Faggioli
> wrote:
> >
> > Note that I'll be off for ~2 weeks, effective next Monday, so feel
> > free
> > to comment, reply, etc, but expect me to reply back only in
> > September.
>
> Hi Dario,
>
On 9/11/18 10:38 AM, Jan Beulich wrote:
On 11.09.18 at 16:17, wrote:
>> On 9/11/18 3:54 AM, Jan Beulich wrote:
>> On 10.09.18 at 23:56, wrote:
On 09/10/2018 10:03 AM, Jan Beulich wrote:
> Having noticed that VMLOAD alone is about as fast as a single of the
> involved
9pfs support has been a documented feature since Xen 4.9, but QEMU will
not be built with backend support unless VirtFS is enabled, which is
predicated on the libcap and libattr dev packages being installed. This is
not obvious to anyone intending to use 9pfs.
This patch adds an 'enable-9pfs'
>>> On 23.08.18 at 11:47, wrote:
> ...for some uses of get_page_from_gfn().
>
> There are many occurences of the following pattern in the code:
>
> q = ? P2M_ALLOC : P2M_UNSHARE;
Especially with this UNSHARE in mind - is "paged" in the helper
function's name really suitable? Since we (I
>>> On 23.08.18 at 11:47, wrote:
> This patch adds an iommu_op which checks whether it is possible or
> safe for a domain to modify its own IOMMU mappings and, if so, creates
> a rangeset to track modifications.
Now this can surely grow pretty big?
> --- a/xen/common/iommu_op.c
> +++
Hi,
On 03/09/18 17:54, Volodymyr Babchuk wrote:
If TEE support is enabled with "tee=1" option in xl.cfg,
then we need to inform guest about available TEE.
Currently only OP-TEE is supported, so we'll create DT
node in a way that is expected by optee driver in linux.
Signed-off-by: Volodymyr
>>> On 11.09.18 at 16:17, wrote:
> On 9/11/18 3:54 AM, Jan Beulich wrote:
> On 10.09.18 at 23:56, wrote:
>>> On 09/10/2018 10:03 AM, Jan Beulich wrote:
Having noticed that VMLOAD alone is about as fast as a single of the
involved WRMSRs, I thought it might be a reasonable idea to
>>> On 11.09.18 at 16:06, wrote:
>> -Original Message-
>> From: Paul Durrant
>> Sent: 11 September 2018 15:04
>> To: 'Jan Beulich'
>> Cc: Julien Grall ; Andrew Cooper
>> ; Wei Liu ; George
>> Dunlap ; Ian Jackson ;
>> Stefano Stabellini ; xen-devel > de...@lists.xenproject.org>; Konrad
On 11/09/18 16:29, Boris Ostrovsky wrote:
> On 9/11/18 7:25 AM, Juergen Gross wrote:
>>
>> Reviewed-by: Juergen Gross
>
> So is it v3 or v4, you gave R-b for both. (I slightly prefer v3, but
> either is fine).
V4 is better as it does the online test only after acquiring the
hotplug lock.
On 09/11/2018 03:04 PM, Andrii Anisov wrote:
> So what would be the conclusion?
>
> I'm going to change timestamps format to decimal for all keyhandlers.
> But what about the format itself? Does existing plain ns PRI_stime have
> a chance to be acked?
>
> Or should I think of an extended format
On 9/11/18 7:25 AM, Juergen Gross wrote:
>
> Reviewed-by: Juergen Gross
So is it v3 or v4, you gave R-b for both. (I slightly prefer v3, but
either is fine).
-boris
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
Hi Volodymyr,
On 03/09/18 17:54, Volodymyr Babchuk wrote:
This boolean option controls if TEE access is enabled for the domain.
If access is enabled, xl will call xc_dom_tee_enable(...) to ask
hypervisor to enable TEE support.
Signed-off-by: Volodymyr Babchuk
---
docs/man/xl.cfg.pod.5.in
flight 127489 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127489/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stopfail like 127463
test-armhf-armhf-libvirt 14
> -Original Message-
> From: Paul Durrant
> Sent: 11 September 2018 15:04
> To: 'Jan Beulich'
> Cc: Julien Grall ; Andrew Cooper
> ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Stefano Stabellini ; xen-devel de...@lists.xenproject.org>; Konrad Rzeszutek Wilk
> ; Tim (Xen.org)
> Subject:
> -Original Message-
> From: Jan Beulich [mailto:jbeul...@suse.com]
> Sent: 11 September 2018 14:45
> To: Paul Durrant
> Cc: Julien Grall ; Andrew Cooper
> ; Wei Liu ; George
> Dunlap ; Ian Jackson ;
> Stefano Stabellini ; xen-devel de...@lists.xenproject.org>; Konrad Rzeszutek Wilk
> ;
On 9/11/18 3:54 AM, Jan Beulich wrote:
On 10.09.18 at 23:56, wrote:
>> On 09/10/2018 10:03 AM, Jan Beulich wrote:
>>> Having noticed that VMLOAD alone is about as fast as a single of the
>>> involved WRMSRs, I thought it might be a reasonable idea to also use it
>>> for PV. Measurements,
So what would be the conclusion?
I'm going to change timestamps format to decimal for all keyhandlers.
But what about the format itself? Does existing plain ns PRI_stime have
a chance to be acked?
Or should I think of an extended format (seconds with fractions, ms with
fractions)?
On
>>> On 10.09.18 at 16:26, wrote:
> @@ -148,14 +146,17 @@ int hvm_save_one(struct domain *d, unsigned int
> typecode, unsigned int instance,
> !hvm_sr_handlers[typecode].save )
> return -EINVAL;
>
> +if ( instance >= d->max_vcpus &&
> +
On 10/09/18 19:14, Volodymyr Babchuk wrote:
On 10.09.18 18:34, Julien Grall wrote:
On 03/09/18 17:54, Volodymyr Babchuk wrote:
static struct shm_buf *allocate_shm_buf(struct domain_ctx *ctx,
uint64_t cookie,
>>> On 11.09.18 at 15:37, wrote:
> 9pfs support has been a documented feature since Xen 4.9, but QEMU will
> not be built with backend support unless VirtFS is enabled, which is
> predicated on the libcap and libattr dev packages being installed. This is
> not obvious to anyone intending to use
On 9/11/18 4:13 PM, Jan Beulich wrote:
> The caching isn't actually implemented here, this is just setting the
> stage.
>
> Touching these anyway also
> - make their return values gfn_t
> - gva -> gla in their names
> - name their input arguments gla
>
> At the use sites do the conversion to
>>> On 30.08.18 at 10:13, wrote:
> On Wed, Aug 29, 2018 at 10:03:01AM -0600, Jan Beulich wrote:
>> Eliminates a couple of branches in particular from the context switch
>> path.
>>
>> Signed-off-by: Jan Beulich
>
> Reviewed-by: Wei Liu
Andrew?
Jan
This looks to be the only frequently executed hook; don't bother
patching any other ones.
Signed-off-by: Jan Beulich
---
v2: New.
--- a/xen/drivers/cpufreq/utility.c
+++ b/xen/drivers/cpufreq/utility.c
@@ -364,7 +364,8 @@ int __cpufreq_driver_target(struct cpufr
{
unsigned int
9pfs support has been a documented feature since Xen 4.9, but QEMU will
not be built with backend support unless VirtFS is enabled, which is
predicated on the libcap and libattr dev packages being installed. This is
not obvious to anyone intending to use 9pfs.
This patch adds an 'enable-9pfs'
This reduces the post-init memory footprint, eliminates a pointless
level of indirection at the use sites, and allows for subsequent
alternatives call patching.
Take the opportunity and also add a name to the PowerNow! instance.
Signed-off-by: Jan Beulich
---
v2: New.
---
Hi Volodymyr,
On 10/09/18 19:04, Volodymyr Babchuk wrote:
On 10.09.18 17:02, Julien Grall wrote:
On 03/09/18 17:54, Volodymyr Babchuk wrote:
+ struct {
+ uint64_t pages_list[PAGELIST_ENTRIES_PER_PAGE];
+ uint64_t next_page_data;
+ } *pages_data_guest, *pages_data_xen,
For now only the ones used during entering/exiting of idle states are
converted. Additionally pm_idle{,_save} and lapic_timer_{on,off} can't
be converted, as they may get established rather late (when Dom0 is
already active).
Note that for patching to be deferred until after the pre-SMP initcalls
For (I hope) obvious reasons only the ones used at runtime get
converted.
Signed-off-by: Jan Beulich
---
v2: Drop open-coded numbers from macro invocations.
--- a/xen/arch/x86/smp.c
+++ b/xen/arch/x86/smp.c
@@ -29,12 +29,12 @@
void send_IPI_mask(const cpumask_t *mask, int vector)
{
-
Instead of loading a pointer at each use site, have a single runtime
instance of struct genapic, copying into it from the individual
instances. The individual instances can this way also be moved to .init
(also adjust apic_probe[] at this occasion).
Signed-off-by: Jan Beulich
---
Signed-off-by: Jan Beulich
---
v2: Drop open-coded number from macro invocation.
--- a/xen/arch/x86/cpu/common.c
+++ b/xen/arch/x86/cpu/common.c
@@ -184,7 +184,7 @@ void ctxt_switch_levelling(const struct
}
if (ctxt_switch_masking)
- ctxt_switch_masking(next);
+
While not strictly necessary, change the VMX initialization logic to
update the function table in start_vmx() from NULL rather than to NULL,
to make more obvious that we won't ever change an already (explictly)
initialized function pointer.
Signed-off-by: Jan Beulich
Acked-by: Kevin Tian
---
This is intentionally not touching hooks used rarely (or not at all)
during the lifetime of a VM, like {domain,vcpu}_initialise or cpu_up,
as well as nested, VM event, and altp2m ones (they can all be done
later, if so desired). Virtual Interrupt delivery ones will be dealt
with in a subsequent
In a number of cases the targets of indirect calls get determined once
at boot time. In such cases we can replace those calls with direct ones
via our alternative instruction patching mechanism.
Some of the targets (in particular the hvm_funcs ones) get established
only in pre-SMP initcalls,
On 11/09/18 12:31, Volodymyr Babchuk wrote:
On 11.09.18 14:19, Julien Grall wrote:
On 10/09/18 18:37, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
On 05.09.18 18:17, Julien Grall wrote:
Hi,
On 09/03/2018 05:54 PM, Volodymyr Babchuk wrote:
Main way to communicate with OP-TEE is to issue
While indirect calls have always been more expensive than direct ones,
their cost has further increased with the Spectre v2 mitigations. In a
number of cases we simply pointlessly use them in the first place. In
many other cases the indirection solely exists to abstract from e.g.
vendor specific
Since strictly speaking it is incorrect for guest_walk_tables() to read
L3 entries during PAE page walks, try to overcome this where possible by
pre-loading the values from hardware into the cache. Sadly the
information is available in the EPT case only. On the positive side for
NPT the spec
Emulation requiring device model assistance uses a form of instruction
re-execution, assuming that the second (and any further) pass takes
exactly the same path. This is a valid assumption as far use of CPU
registers goes (as those can't change without any other instruction
executing in between),
The caching isn't actually implemented here, this is just setting the
stage.
Signed-off-by: Jan Beulich
---
v2: Don't wrongly use top_gfn for non-root gpa calculation. Re-write
cache entries after setting A/D bits (an alternative would be to
suppress their setting upon cache hits).
---
The caching isn't actually implemented here, this is just setting the
stage.
Touching these anyway also
- make their return values gfn_t
- gva -> gla in their names
- name their input arguments gla
At the use sites do the conversion to gfn_t as suitable.
Signed-off-by: Jan Beulich
Reviewed-by:
Emulation requiring device model assistance uses a form of instruction
re-execution, assuming that the second (and any further) pass takes
exactly the same path. This is a valid assumption as far as use of CPU
registers goes (as those can't change without any other instruction
executing in
flight 127499 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/127499/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-arm64-arm64-xl-xsm 13 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm
Hello George,
On 11.09.18 13:48, George Dunlap wrote:
I like the idea; but what does 'LE' mean in this context?
Little endian. Most significant 32bit word is at a higher index in the
array.
--
*Andrii Anisov*
___
Xen-devel mailing list
On 10/09/18 18:44, Volodymyr Babchuk wrote:
Hi Julien,
On 10.09.18 16:01, Julien Grall wrote:
Hi Volodymyr,
On 03/09/18 17:54, Volodymyr Babchuk wrote:
OP-TEE usually uses the same idea with command buffers (see
previous commit) to issue RPC requests. Problem is that initially
it has no
Hi,
A more meaningful title would be:
"xen/domain: Remove trailing whitespace"
This would help to understand...
On 11/09/18 12:38, Andrii Anisov wrote:
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/common/domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
From: Andrii Anisov
Signed-off-by: Andrii Anisov
---
xen/common/domain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 78c450e..aec10a7 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -155,7 +155,7 @@ struct
Hello Julien,
On 11.09.18 14:31, Julien Grall wrote:
That's your problem. You are using a deprecated e-mail address here.
This should be replaced by xen-devel@lists.xenproject.org.
I've got the point.
Thank you for taking care to help me sort it out.
But the --to here should not be
On 11.09.18 14:19, Julien Grall wrote:
On 10/09/18 18:37, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
On 05.09.18 18:17, Julien Grall wrote:
Hi,
On 09/03/2018 05:54 PM, Volodymyr Babchuk wrote:
Main way to communicate with OP-TEE is to issue standard SMCCC
NIT: The main way
call.
On 11.09.18 13:42, Julien Grall wrote:
@@ -1429,7 +1430,8 @@ static void do_debug_trap(struct cpu_user_regs
*regs, unsigned int code)
{
uint32_t reg;
uint32_t domid = current->domain->domain_id;
While you are at fixing coding style: newline here.
- switch ( code ) {
+
On 11/09/18 12:22, Andrii Anisov wrote:
Hello Julien,
Hello Julien,
On 11.09.18 13:40, Julien Grall wrote:
What's your full command?
For this particular patch it was:
git format-patch -1 --to "xen-de...@lists.xen.org"
That's your problem. You are using a deprecated e-mail address
On 07/09/18 08:30, Olaf Hering wrote:
> The command 'xl vcpu-set 0 0', issued in dom0, will crash dom0:
>
> BUG: unable to handle kernel NULL pointer dereference at 02d8
> PGD 0 P4D 0
> Oops: [#1] PREEMPT SMP NOPTI
> CPU: 7 PID: 65 Comm: xenwatch Not tainted
Hello Julien,
Hello Julien,
On 11.09.18 13:40, Julien Grall wrote:
What's your full command?
For this particular patch it was:
git format-patch -1 --to "xen-de...@lists.xen.org"
git send-email --cc-cmd=scripts/get_maintainer.pl
0001-traps-coding-style-fixes.patch
All occurrence of
On 10/09/18 18:37, Volodymyr Babchuk wrote:
Hi Julien,
Hi,
On 05.09.18 18:17, Julien Grall wrote:
Hi,
On 09/03/2018 05:54 PM, Volodymyr Babchuk wrote:
Main way to communicate with OP-TEE is to issue standard SMCCC
NIT: The main way
call. "Standard" is a SMCCC term and it means that
On 11/09/18 12:48, Olaf Hering wrote:
> Am Tue, 11 Sep 2018 09:52:58 +0200
> schrieb Olaf Hering :
>
>> As Jürgen suggested in another mail, Xen should probably disable hotplugging
>> for cpu#0 in the generic setup code. Then cpu_is_hotpluggable(cpu) would
>> do the right thing.
>
> The relevant
I'll let Dario review this one; one comment:
On 09/10/2018 05:41 PM, Andrii Anisov wrote:
> From: Andrii Anisov
>
> Allign rtds:repl_budget trace record format to the current code.
s/allign/align/g;
Otherwise:
Reviewed-by: George Dunlap
-G
___
1 - 100 of 160 matches
Mail list logo
