flight 120120 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120120/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm 16 guest-localmigrate/x10 fail
REGR. vs. 120037
tes
flight 120122 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120122/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-xsm 14 saverestore-support-checkfail like 120084
test-armhf-armhf-libvirt 14 saveresto
flight 120177 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120177/
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
On Fri, Mar 2, 2018 at 8:39 AM, Lars Kurth wrote:
> Hi all,
> (sorry for the extensive distribution list - I went through MAINTAINERS and
> people who may have an interest)
>
> I would like to start organizing a recurring x86 community call to discuss
> and sync-up on upcoming features for Xen o
flight 120116 xen-4.8-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120116/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-xl-rtds 17 guest-start.2 fail blocked in 119771
test-amd64-amd64-xl-qemut-win7-am
On Wed, 28 Feb 2018, Julien Grall wrote:
> Commit 7d623b358a4 "arm/mem_access: Add long-descriptor based gpt"
> assumed the read-write lock can be taken recursively. However, this
> assumption is wrong and will lead to deadlock when the lock is
> contended.
>
> To avoid the nested lock, rework the
On Tue, 27 Feb 2018, julien.gr...@arm.com wrote:
> From: Stewart Hildebrand
>
> Since commit "xen/arm: domain_build: Rework the way to allocate the
> event channel interrupt", it is not possible for an irq to be both below 16
> and greater/equal than 32.
>
> Also fix the reference to linux docum
On Tue, 27 Feb 2018, julien.gr...@arm.com wrote:
> From: Julien Grall
>
> At the moment, a placeholder will be created in the device-tree for the
> event channel information. Later in the domain construction, the
> interrupt for the event channel upcall will be allocated the device-tree
> fixed u
On Tue, 27 Feb 2018, julien.gr...@arm.com wrote:
> From: Julien Grall
>
> A follow-up patch will require to have all interrupts routed to the
> hardware registered before calling prepare_dtb/prepare_acpi.
>
> At the moment, it is not necessary to call platform specific mappings
> (gic and platfo
flight 120169 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120169/
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
On 3/2/2018 1:20 PM, Konrad Rzeszutek Wilk wrote:
On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote:
The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass informati
On Fri, Mar 02, 2018 at 04:39:59PM +0100, Lars Kurth wrote:
> Hi all,
> (sorry for the extensive distribution list - I went through MAINTAINERS and
> people who may have an interest)
>
> I would like to start organizing a recurring x86 community call to discuss
> and sync-up on upcoming feature
On Fri, Mar 02, 2018 at 12:54:29PM -0800, Maran Wilson wrote:
> The start info structure that is defined as part of the x86/HVM direct boot
> ABI and used for starting Xen PVH guests would be more versatile if it also
> included a way to pass information about the memory map to the guest. This
> wo
The start info structure that is defined as part of the x86/HVM direct boot
ABI and used for starting Xen PVH guests would be more versatile if it also
included a way to pass information about the memory map to the guest. This
would allow KVM guests to share the same entry point.
Signed-off-by: Ma
Here is the patch for updating the canonical definition of the
hvm_start_info struct corresponding to the discussion happening on the
linux-kernel and kvm mailing lists regarding Qemu/KVM use of the PVH
entry point:
KVM: x86: Allow Qemu/KVM to use PVH entry point
https://lkml.org/lkml/2018/2
flight 120111 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120111/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-amd64-pvgrub broken
test-amd64-amd64-xl-qemut-ws16-amd64
On 02/03/18 07:10, Jan Beulich wrote:
On 01.03.18 at 17:58, wrote:
>> On 01/03/18 10:54, Jan Beulich wrote:
>> On 01.03.18 at 11:36, wrote:
On Thu, Mar 01, 2018 at 12:28:27AM -0700, Jan Beulich wrote:
Andrew Cooper 02/28/18 7:20 PM >>>
>> On 28/02/18 16:22, Jan Beulich
Introduce a new document about big.LITTLE and update the documentation
of hmp-unsafe.
Also update the warning messages to point users to the docs.
Signed-off-by: Stefano Stabellini
Acked-by: Julien Grall
CC: jbeul...@suse.com
CC: konrad.w...@oracle.com
CC: t...@xen.org
CC: wei.l...@citrix.com
C
Even different cpus in big.LITTLE systems are expected to have the same
dcache line size. Unless the minimum of all dcache line sizes is used
across all cpu cores, cache coherency protocols can go wrong. Instead,
for now, just disable any cpu with a different dcache line size.
This check is not co
On big.LITTLE systems not all cores have the same MIDR. Instead of
storing only one VPIDR per domain, initialize it to the value of the
MIDR of the pCPU where the vCPU will run.
This way, assuming that the vCPU has been created with the right pCPU
affinity, the guest will be able to read the right
On 28/02/18 12:57, Jan Beulich wrote:
> These gain register forms now.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
From: Julien Grall
From: Julien Grall
Xen does not properly support big.LITTLE platform. All vCPUs of a guest
will always have the MIDR of the boot CPU (see arch_domain_create).
At best the guest may see unreliable performance (vCPU switching between
big and LITTLE), at worst the guest will bec
Hi all,
This series changes the initialization of two virtual registers to make
sure they match the value of the underlying physical cpu.
It also disables cpus different from the boot cpu, unless a newly
introduced command line option is specified. In that case, it explains
how to setup the syste
On big.LITTLE systems not all cores have the same ACTLR. Instead of
reading ACTLR and setting v->arch.actlr in vcpu_initialise, do it later
on the same pcpu where the vcpu will run.
This way, assuming that the vcpu has been created with the right pcpu
affinity, the guest will be able to read the r
See the corresponding Linux commit as reference:
commit f91e2c3bd427239c198351f44814dd39db91afe0
Author: Catalin Marinas
Date: Tue Dec 7 16:52:04 2010 +0100
ARM: 6527/1: Use CTR instead of CCSIDR for the D-cache line size on ARMv7
The current implementation of the dcache_lin
There can be processors of different kinds on a single system. Make
processor a per_cpu variable pointing to the right processor type for
each core.
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabellini
Reviewed-by: Julien Grall
---
Changes in v2:
- add patch
---
xen/arch/arm/processor.
On 02/03/18 11:09, Wei Liu wrote:
> On Thu, Mar 01, 2018 at 05:01:55PM +, Roger Pau Monné wrote:
>> On Thu, Mar 01, 2018 at 04:01:23PM +, Wei Liu wrote:
>>> On Thu, Mar 01, 2018 at 03:57:18PM +, Andrew Cooper wrote:
On 01/03/18 12:22, Wei Liu wrote:
> On Wed, Feb 28, 2018 at 10
flight 120164 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120164/
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 causes objdump not to try and disassemble the data.
While altering this area, switch to using .balign, and fill with 0xc2 to help
highlight the embedded padding (rather than having it filled with 0f 1f 40 00
which is a long nop). Also, shorten the labels by stripping off the _start
suffix.
On 02/03/2018 18:35, Stefano Stabellini wrote:
On Fri, 2 Mar 2018, Andrew Cooper wrote:
On 02/03/18 18:26, Stefano Stabellini wrote:
Suggested-by: Julien Grall
Signed-off-by: Stefano Stabellini
---
Changes in v3:
- new patch
---
Interestingly I couldn't find a better way in C89 to print
On 02/03/2018 18:33, Stefano Stabellini wrote:
On Fri, 2 Mar 2018, Stefano Stabellini wrote:
On Fri, 2 Mar 2018, Julien Grall wrote:
Hi,
On 01/03/18 23:27, Stefano Stabellini wrote:
See the corresponding Linux commit as reference:
commit f91e2c3bd427239c198351f44814dd39db91afe0
Aut
On Fri, 2 Mar 2018, Andrew Cooper wrote:
> On 02/03/18 18:26, Stefano Stabellini wrote:
> >
> >>> Suggested-by: Julien Grall
> >>> Signed-off-by: Stefano Stabellini
> >>>
> >>> ---
> >>> Changes in v3:
> >>> - new patch
> >>>
> >>> ---
> >>> Interestingly I couldn't find a better way in C89 to pr
On Fri, 2 Mar 2018, Stefano Stabellini wrote:
> On Fri, 2 Mar 2018, Julien Grall wrote:
> > Hi,
> >
> > On 01/03/18 23:27, Stefano Stabellini wrote:
> > > See the corresponding Linux commit as reference:
> > >
> > >commit f91e2c3bd427239c198351f44814dd39db91afe0
> > >Author: Catalin Marin
On 02/03/18 18:26, Stefano Stabellini wrote:
>
>>> Suggested-by: Julien Grall
>>> Signed-off-by: Stefano Stabellini
>>>
>>> ---
>>> Changes in v3:
>>> - new patch
>>>
>>> ---
>>> Interestingly I couldn't find a better way in C89 to printk a size_t
>>> than casting it to unsigned long.
>> You can
Thanks, I'll mention it in the commit message.
On Fri, 2 Mar 2018, Julien Grall wrote:
> Hi,
>
> I forgot to mention in the title:
>
> You read the minimum D-Cache line size. The minimum I-Cache line size is read
> from CTR_EL0.IminLine.
>
> Cheers,
>
> On 01/03/18 23:27, Stefano Stabellini wr
On Fri, 2 Mar 2018, Julien Grall wrote:
> Hi,
>
> On 01/03/18 23:27, Stefano Stabellini wrote:
> > See the corresponding Linux commit as reference:
> >
> >commit f91e2c3bd427239c198351f44814dd39db91afe0
> >Author: Catalin Marinas
> >Date: Tue Dec 7 16:52:04 2010 +0100
> >
> >
On Fri, 2 Mar 2018, Julien Grall wrote:
> Hi Stefano,
>
> On 01/03/18 23:26, Stefano Stabellini wrote:
> > Even different cpus in big.LITTLE systems are expected to have the same
> > cacheline size. Unless the minimum of all cacheline sizes is used across
> > all cpu cores, cache coherency protoco
On 02/03/18 14:35, Jan Beulich wrote:
> Other than for the main mappings, don't even do this in release builds,
> as there are no huge page shattering concerns here.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper , although I think
somewhere (even if its only the commit message) might wan
On Tue, Feb 27, 2018 at 02:50:32PM +, Andrew Cooper wrote:
> The correct way to check a boolean is `cmpb $0` or `testb $0xff`, whereas a
> lot of our entry code uses `testb $1`. This will work in principle for values
> which are really C _Bool types, but won't work for other integer types whic
On Fri, Mar 02, 2018 at 10:23:08AM -0700, Jim Fehlig wrote:
> On 03/02/2018 05:40 AM, Wei Liu wrote:
> > On Fri, Mar 02, 2018 at 12:29:31PM +, Wei Liu wrote:
> > > On Mon, Feb 26, 2018 at 09:53:38AM -0700, Jim Fehlig wrote:
> > > > On 02/26/2018 01:46 AM, Juergen Gross wrote:
> > > > > When cre
On 02/03/18 18:09, Andrew Cooper wrote:
> On 02/03/18 17:05, Juergen Gross wrote:
>> On 02/03/18 17:51, Jan Beulich wrote:
>> On 02.03.18 at 17:25, wrote:
On 02/03/18 16:18, Jan Beulich wrote:
On 02.03.18 at 17:04, wrote:
>> The proper way to do this is indeed by a nominated
Linus,
Please git pull the following tag:
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git
for-linus-4.16a-rc4-tag
xen: fixes for v4.16-rc4
It contains 5 minor fixes for Xen-specific drivers.
Thanks.
Juergen
arch/x86/xen/enlighten_pv.c | 6 --
drivers/net/xen-netfront.
On 02/03/18 17:04, Jan Beulich wrote:
On 02.03.18 at 17:53, wrote:
>> On 02/03/18 14:34, Jan Beulich wrote:
>>> Note that the removed BUILD_BUG_ON()s don't get replaced by anything -
>>> there already is a suitable ASSERT() in xen.lds.S.
>> This isn't quite true. You've changed the mechanism
On 03/02/2018 05:40 AM, Wei Liu wrote:
On Fri, Mar 02, 2018 at 12:29:31PM +, Wei Liu wrote:
On Mon, Feb 26, 2018 at 09:53:38AM -0700, Jim Fehlig wrote:
On 02/26/2018 01:46 AM, Juergen Gross wrote:
When creating a pthread in xs_watch() try to get the minimal needed
size of the thread from g
On 03/02/2018 03:39 PM, Lars Kurth wrote:
> Hi all,
> (sorry for the extensive distribution list - I went through MAINTAINERS and
> people who may have an interest)
>
> I would like to start organizing a recurring x86 community call to discuss
> and sync-up on upcoming features for Xen on x86.
flight 120113 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120113/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 2157bc9c8b8be30ada11fe2e64454157d3ae528f
baseline version:
ovmf f0c69b614cf56df1e7908
On 02/03/18 16:39, Lars Kurth wrote:
> Hi all,
> (sorry for the extensive distribution list - I went through MAINTAINERS and
> people who may have an interest)
>
> I would like to start organizing a recurring x86 community call to discuss
> and sync-up on upcoming features for Xen on x86. This
On Mar 2, 2018, at 10:39, Lars Kurth wrote:
> I would suggest to start with a 1 hour monthly meeting: possibly every 2nd
> Tue or Thu each month (depends on timing). I know that people are spread
> across different timezones (from China to the US), so I would like to gather
> thoughts before ch
On 02/03/18 17:05, Juergen Gross wrote:
> On 02/03/18 17:51, Jan Beulich wrote:
> On 02.03.18 at 17:25, wrote:
>>> On 02/03/18 16:18, Jan Beulich wrote:
>>> On 02.03.18 at 17:04, wrote:
> The proper way to do this is indeed by a nominated (guest) physical
> address, at which point
On Fri, Mar 02, 2018 at 04:39:59PM +0100, Lars Kurth wrote:
> Hi all,
> (sorry for the extensive distribution list - I went through MAINTAINERS and
> people who may have an interest)
>
> I would like to start organizing a recurring x86 community call to discuss
> and sync-up on upcoming feature
On 02/03/18 17:51, Jan Beulich wrote:
On 02.03.18 at 17:25, wrote:
>> On 02/03/18 16:18, Jan Beulich wrote:
>> On 02.03.18 at 17:04, wrote:
The proper way to do this is indeed by a nominated (guest) physical
address, at which point Xen can make all/any updates at times of its
>
>>> On 02.03.18 at 17:53, wrote:
> On 02/03/18 14:34, Jan Beulich wrote:
>> Note that the removed BUILD_BUG_ON()s don't get replaced by anything -
>> there already is a suitable ASSERT() in xen.lds.S.
>
> This isn't quite true. You've changed the mechanism by which the stubs
> get mapped (from e
On Fri, Mar 02, 2018 at 09:47:45AM -0700, Jan Beulich wrote:
> >>> On 02.03.18 at 17:23, wrote:
> > +static inline void invpcid(unsigned int pcid, unsigned long addr,
> > + unsigned int type)
> > +{
> > +struct {
> > +uint64_t pcid:12;
> > +uint64_t re
On 02/03/18 16:47, Jan Beulich wrote:
On 02.03.18 at 17:23, wrote:
>> +static inline void invpcid(unsigned int pcid, unsigned long addr,
>> + unsigned int type)
>> +{
>> +struct {
>> +uint64_t pcid:12;
>> +uint64_t reserved:52;
>> +uint64_
On 02/03/18 15:39, Lars Kurth wrote:
> Hi all,
> (sorry for the extensive distribution list - I went through MAINTAINERS and
> people who may have an interest)
>
> I would like to start organizing a recurring x86 community call to discuss
> and sync-up on upcoming features for Xen on x86. This c
On Fri, Mar 02, 2018 at 04:46:25PM +, Wei Liu wrote:
> Xen also uses clang's assembler when it is possible. Change the macro
> names to not be GAS specific.
>
> Patch produced with:
>
> $ for f in `git grep HAVE_GAS_ | cut -d':' -f1`; \
> do sed -i 's/HAVE_GAS_/HAVE_AS_/g' $f; done
grep
On 02/03/18 17:25, Julien Grall wrote:
>
>
> On 02/03/18 16:18, Jan Beulich wrote:
> On 02.03.18 at 17:04, wrote:
>>> The proper way to do this is indeed by a nominated (guest) physical
>>> address, at which point Xen can make all/any updates at times of its
>>> choosing, and the guests page
> -Original Message-
> From: Lars Kurth [mailto:lars.kurth@gmail.com]
> Sent: 02 March 2018 15:40
> To: xen-devel
> Cc: committ...@xenproject.org; Jan Beulich ; Andrew
> Cooper ; Susie Li ; John Ji
> ; Hurwitz, Sherry ; Brian
> Woods ; Babu Moger ;
> Chao Peng ; daniel.ki...@oracle.com
Several of the VMs in the Massachusetts Xen Project Test Lab, which
runs our community osstest instance, need to be upgraded. And we want
to sort out some oddities with the way the storage is configured.
This will involve a long outage, maybe 3 days or so.
We should schedule this when it is conv
On 02/03/18 16:46, Wei Liu wrote:
> Xen also uses clang's assembler when it is possible. Change the macro
> names to not be GAS specific.
>
> Patch produced with:
>
> $ for f in `git grep HAVE_GAS_ | cut -d':' -f1`; \
> do sed -i 's/HAVE_GAS_/HAVE_AS_/g' $f; done
andrewcoop@andrewcoop:/local/x
On 02/03/18 14:34, Jan Beulich wrote:
> Commit 422588e885 ("x86/xpti: Hide almost all of .text and all
> .data/.rodata/.bss mappings") carefully limited the Xen image cloning to
> just entry code, but then overwrote the just allocated and populated L3
> entry with the normal one again covering both
>>> On 02.03.18 at 17:46, wrote:
> Xen also uses clang's assembler when it is possible. Change the macro
> names to not be GAS specific.
>
> Patch produced with:
>
> $ for f in `git grep HAVE_GAS_ | cut -d':' -f1`; \
> do sed -i 's/HAVE_GAS_/HAVE_AS_/g' $f; done
>
> Signed-off-by: Wei Liu
>>> On 02.03.18 at 17:25, wrote:
> On 02/03/18 16:18, Jan Beulich wrote:
> On 02.03.18 at 17:04, wrote:
>>> The proper way to do this is indeed by a nominated (guest) physical
>>> address, at which point Xen can make all/any updates at times of its
>>> choosing, and the guests pagetable/permi
Any chance ALSA community may also review the below?
BTW, the driver, with the changes proposed, is at [1]
Thank you,
Oleksandr
On 02/05/2018 10:24 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Hi, all!
Foreword
This change is aimed to add support for explicit
>>> On 02.03.18 at 17:41, wrote:
> On 02/03/18 17:10, Jan Beulich wrote:
> On 02.03.18 at 16:43, wrote:
>>> On 02/03/18 15:35, Jan Beulich wrote:
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -5576,6 +5576,14 @@ void memguard_unguard_stack(void *p)
>>> On 02.03.18 at 17:23, wrote:
> +static inline void invpcid(unsigned int pcid, unsigned long addr,
> + unsigned int type)
> +{
> +struct {
> +uint64_t pcid:12;
> +uint64_t reserved:52;
> +uint64_t addr;
> +} desc = { .pcid = pcid, .addr
Xen also uses clang's assembler when it is possible. Change the macro
names to not be GAS specific.
Patch produced with:
$ for f in `git grep HAVE_GAS_ | cut -d':' -f1`; \
do sed -i 's/HAVE_GAS_/HAVE_AS_/g' $f; done
Signed-off-by: Wei Liu
---
Cc: Jan Beulich
Cc: Andrew Cooper
---
xen/arc
>>> On 27.02.18 at 15:50, wrote:
> v2:
> * Use domain_crash() rather than domain_crash_sync(). All callers
>immediately continue to {compat_}test_all_events
> * Count the number of frame[] entries correctly
> * Consistently use 64bit operations when adjusting the root frame
> * Introduce
On 02/03/18 17:10, Jan Beulich wrote:
On 02.03.18 at 16:43, wrote:
>> On 02/03/18 15:35, Jan Beulich wrote:
>>> --- a/xen/arch/x86/mm.c
>>> +++ b/xen/arch/x86/mm.c
>>> @@ -5576,6 +5576,14 @@ void memguard_unguard_stack(void *p)
>>> STACK_SIZE - PRIMARY_STACK_SIZE -
Hi,
On 19/02/18 15:43, Julien Grall wrote:
>
>
> On 19/02/18 15:32, Andre Przywara wrote:
>> Hi,
>
> Hi Andre,
>
>> On 16/02/18 17:16, Julien Grall wrote:
>>> On 09/02/18 14:39, Andre Przywara wrote:
+
+ /* Loop over all IRQs affected by this read */
+ for ( i = 0; i < len
On Fri, Mar 02, 2018 at 04:39:59PM +0100, Lars Kurth wrote:
> Hi all,
> (sorry for the extensive distribution list - I went through MAINTAINERS and
> people who may have an interest)
>
> I would like to start organizing a recurring x86 community call to discuss
> and sync-up on upcoming feature
On 02/03/18 16:23, Wei Liu wrote:
> Provide the functions needed for different modes. Add cpu_has_invpcid.
>
> Signed-off-by: Wei Liu
> Reviewed-by: Juergen Gross
Reviewed-by: Andrew Cooper
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
ht
>>> On 27.02.18 at 15:50, wrote:
> The correct way to check a boolean is `cmpb $0` or `testb $0xff`, whereas a
> lot of our entry code uses `testb $1`. This will work in principle for values
> which are really C _Bool types, but won't work for other integer types which
> are intended to have bool
On Fri, Mar 02, 2018 at 08:23:50AM -0700, Jan Beulich wrote:
> >>> On 02.03.18 at 15:36, wrote:
> > On Fri, Mar 02, 2018 at 07:31:43AM -0700, Jan Beulich wrote:
> >> >>> On 02.03.18 at 15:22, wrote:
> >> > I'd be in favor of merging the 4.8.3pre-shim-comet and
> >> > 4.10.0-shim-comet branches in
On 02/03/18 16:18, Jan Beulich wrote:
On 02.03.18 at 17:04, wrote:
The proper way to do this is indeed by a nominated (guest) physical
address, at which point Xen can make all/any updates at times of its
choosing, and the guests pagetable/permissions state at an instantaneous
moment don't mat
On 02/03/18 16:18, Jan Beulich wrote:
On 02.03.18 at 17:04, wrote:
>> The proper way to do this is indeed by a nominated (guest) physical
>> address, at which point Xen can make all/any updates at times of its
>> choosing, and the guests pagetable/permissions state at an instantaneous
>> mome
Provide the functions needed for different modes. Add cpu_has_invpcid.
Signed-off-by: Wei Liu
Reviewed-by: Juergen Gross
---
Cc: Jan Beulich
Cc: Andrew Cooper
Cc: Juergen Gross
---
xen/arch/x86/Rules.mk| 1 +
xen/include/asm-x86/cpufeature.h | 1 +
xen/include/asm-x86/invpcid.h
Commit 406817 doesn't update nested VMX code in order to take into
account L1 CR4 host mask when nested guest (L2) writes to CR4, and
thus the mask written to CR4_GUEST_HOST_MASK is likely not as
restrictive as it should be.
Also the VVMCS GUEST_CR4 value should be updated to match the
underlying
>>> On 02.03.18 at 17:04, wrote:
> The proper way to do this is indeed by a nominated (guest) physical
> address, at which point Xen can make all/any updates at times of its
> choosing, and the guests pagetable/permissions state at an instantaneous
> moment don't matter.
>
> If you've got time to
Hi Stefano,
On 01/03/18 19:17, Stefano Stabellini wrote:
In recognition of his expertise and commitment to Xen Project, please
join me in welcoming Julien among the Committers and REST Maintainers.
Signed-off-by: Stefano Stabellini
Thank you for the nomination! FWIW:
Acked-by: Julien Grall
On Fri, Mar 02, 2018 at 02:29:54PM +, Sergey Dyasli wrote:
> On Thu, 2018-03-01 at 16:19 +, Roger Pau Monne wrote:
> > Commit 406817 doesn't update nested VMX code in order to take into
> > account L1 CR4 host mask when nested guest (L2) writes to CR4, and
> > thus the mask written to CR4_G
flight 120151 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120151/
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
>>> On 02.03.18 at 16:59, wrote:
> On 02/03/18 15:54, Jan Beulich wrote:
> On 21.02.18 at 15:02, wrote:
>>> @@ -872,7 +879,7 @@ map_grant_ref(
>>> struct grant_table *lgt, *rgt;
>>> struct vcpu *led;
>>> grant_handle_t handle;
>>> -unsigned long frame = 0;
>>> +mf
>>> On 02.03.18 at 16:43, wrote:
> On 02/03/18 15:35, Jan Beulich wrote:
>> --- a/xen/arch/x86/mm.c
>> +++ b/xen/arch/x86/mm.c
>> @@ -5576,6 +5576,14 @@ void memguard_unguard_stack(void *p)
>> STACK_SIZE - PRIMARY_STACK_SIZE - IST_MAX *
>> PAGE_SIZE);
>> }
>>
>> +bo
>>> On 21.02.18 at 15:02, wrote:
> --- a/xen/arch/x86/pv/emul-priv-op.c
> +++ b/xen/arch/x86/pv/emul-priv-op.c
> @@ -43,16 +43,6 @@
> #include "emulate.h"
> #include "mm.h"
>
> -/* Override macros from asm/page.h to make them work with mfn_t */
> -#undef mfn_to_page
> -#define mfn_to_page(mfn)
On 02/03/18 15:57, Julien Grall wrote:
> Hi,
>
> While I was looking at some unrelated problem with Xen ARM P2M code, I
> noticed that the function update_runstate_area is using guest virtual
> address to update the vCPU runstate. That function will be called when
> context switch to a vCPU. Howeve
Hi Jan,
On 02/03/18 15:54, Jan Beulich wrote:
On 21.02.18 at 15:02, wrote:
@@ -872,7 +879,7 @@ map_grant_ref(
struct grant_table *lgt, *rgt;
struct vcpu *led;
grant_handle_t handle;
-unsigned long frame = 0;
+mfn_t frame = _mfn(0);
If the initializer is needed at
On 02/03/18 15:18, Jan Beulich wrote:
On 21.02.18 at 15:02, wrote:
@@ -1735,14 +1743,14 @@ static void init_heap_pages(
if ( unlikely(!avail[nid]) )
{
-unsigned long s = page_to_mfn(pg + i);
-unsigned long e = page_to_mfn(pg + nr_pages - 1) + 1;
>>> On 21.02.18 at 15:02, wrote:
> @@ -160,7 +162,8 @@ static int m2p_mapped(unsigned long spfn)
>
> static int share_hotadd_m2p_table(struct mem_hotadd_info *info)
> {
> -unsigned long i, n, v, m2p_start_mfn = 0;
> +unsigned long i, n, v;
> +mfn_t m2p_start_mfn = _mfn(0);
INVALID
Hi,
While I was looking at some unrelated problem with Xen ARM P2M code, I
noticed that the function update_runstate_area is using guest virtual
address to update the vCPU runstate. That function will be called when
context switch to a vCPU. However, that vCPU may run in userspace
context. Wh
>>> On 21.02.18 at 15:02, wrote:
> @@ -872,7 +879,7 @@ map_grant_ref(
> struct grant_table *lgt, *rgt;
> struct vcpu *led;
> grant_handle_t handle;
> -unsigned long frame = 0;
> +mfn_t frame = _mfn(0);
If the initializer is needed at all, I think it should again become
I
On 02/03/18 15:35, Jan Beulich wrote:
> Other than for the main mappings, don't even do this in release builds,
> as there are no huge page shattering concerns here.
>
> Signed-off-by: Jan Beulich
> ---
> v2: New.
>
> --- a/xen/arch/x86/smpboot.c
> +++ b/xen/arch/x86/smpboot.c
> @@ -799,7 +799,8
Hi all,
(sorry for the extensive distribution list - I went through MAINTAINERS and
people who may have an interest)
I would like to start organizing a recurring x86 community call to discuss and
sync-up on upcoming features for Xen on x86. This call would mirror and follow
a similar structure
>>> On 21.02.18 at 15:02, wrote:
> The current prototype is slightly confusing because it takes a guest
> physical address and a machine physical frame (not address!). Switching to
> MFN will improve safety and reduce the chance to mistakenly invert the
> 2 parameters.
>
> Signed-off-by: Julien g
>>> On 21.02.18 at 15:02, wrote:
> @@ -95,11 +101,18 @@ static unsigned int max_order(const struct domain *d)
> return min(order, MAX_ORDER + 0U);
> }
>
> +/* Helper to copy a typesafe MFN to guest */
> +#define copy_mfn_to_guest(hnd, off, mfn)\
> +({
On 02/03/18 15:47, Wei Liu wrote:
> Provide the functions needed for different modes. And cpu_has_invpcid.
>
> Signed-off-by: Wei Liu
> ---
> This is useful for Juergen's XPTI improvement series.
>
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Juergen Gross
> ---
> xen/arch/x86/Rules.mk
Hello.How can I configure Xen and limit users for create VMs and set quota for
them? For example, users can't create a VM that have more than 1GB RAM.
Thank you.___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailma
>>> On 02.03.18 at 15:36, wrote:
> On Fri, Mar 02, 2018 at 07:31:43AM -0700, Jan Beulich wrote:
>> >>> On 02.03.18 at 15:22, wrote:
>> > I'd be in favor of merging the 4.8.3pre-shim-comet and
>> > 4.10.0-shim-comet branches into staging-4.8 and staging-4.10
>> > respectively (assuming that's suit
On Fri, Mar 02, 2018 at 02:47:13PM +, Wei Liu wrote:
> Provide the functions needed for different modes. And cpu_has_invpcid.
>
> Signed-off-by: Wei Liu
> ---
> This is useful for Juergen's XPTI improvement series.
>
> Cc: Jan Beulich
> Cc: Andrew Cooper
> Cc: Juergen Gross
> ---
> xen/a
flight 120105 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120105/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemut-rhel6hvm-amd 12 guest-start/redhat.repeat fail REGR. vs.
12
test-am
1 - 100 of 169 matches
Mail list logo
