>>> On 09.03.18 at 08:32, wrote:
> It seems to be solved by your patch !
Thanks for confirming; I'll take the liberty and add your Tested-by
then too.
Jan
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/
>>> On 09.03.18 at 06:23, wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Thursday, March 8, 2018 9:39 PM
>>
>> > --- a/xen/include/asm-x86/domain.h
>> > +++ b/xen/include/asm-x86/domain.h
>> > @@ -622,7 +622,8 @@ unsigned long pv_guest_cr4_fixup(const struct
>> vcpu *, unsigned
On Wed, Mar 07, Juergen Gross wrote:
> On 07/03/18 13:06, ian.jack...@citrix.com wrote:
> > Juergen Gross writes ("Re: [PATCH] tools/xenstore: add libdl dependency to
> > libxenstore"):
> >> On 07/03/18 12:19, Ian Jackson wrote:
> >>> Juergen Gross writes ("[PATCH] tools/xenstore: add libdl depen
On 09/03/18 09:34, Jan Beulich wrote:
On 09.03.18 at 06:23, wrote:
>>> From: Jan Beulich [mailto:jbeul...@suse.com]
>>> Sent: Thursday, March 8, 2018 9:39 PM
>>>
--- a/xen/include/asm-x86/domain.h
+++ b/xen/include/asm-x86/domain.h
@@ -622,7 +622,8 @@ unsigned long pv_guest_cr
On Thu, Mar 08, 2018 at 03:13:50PM +, Julien Grall wrote:
>Hi,
>
>On 08/03/18 12:43, Peng Fan wrote:
>>I am not sure whether this issue cause DomU big/Little not work.
>
>Well, I would recommend to speak with NXP whether this errata affects
>TLB flush for Hypervisor Page-Table o
Offlining a CPU involves stopping the cpufreq governor. The on-demand
governor will kill the timer before letting generic code proceed, but
since that generally isn't happening on the subject CPU,
cpufreq_dbs_timer_resume() may run in parallel. If that managed to
invoke the timer handler, that hand
Specifically https://en.wikipedia.org/wiki/POWER9.
Qubes user here. Due to the ongoing manufacturer lock-down of the x86
arch. and security vulnerabilities introduced by same, I'm looking into
hardware alternatives. One promising candidate appears to be the POWER
architecture.
What would it take
On 09/03/18 09:36, Olaf Hering wrote:
> On Wed, Mar 07, Juergen Gross wrote:
>
>> On 07/03/18 13:06, ian.jack...@citrix.com wrote:
>>> Juergen Gross writes ("Re: [PATCH] tools/xenstore: add libdl dependency to
>>> libxenstore"):
On 07/03/18 12:19, Ian Jackson wrote:
> Juergen Gross write
On 09/03/2018 09:37, awokd wrote:
> Specifically https://en.wikipedia.org/wiki/POWER9.
>
> Qubes user here. Due to the ongoing manufacturer lock-down of the x86
> arch. and security vulnerabilities introduced by same, I'm looking into
> hardware alternatives. One promising candidate appears to be t
>>> On 08.03.18 at 18:37, wrote:
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -620,6 +620,7 @@ Note that other devices are available but not security
> supported.
>
> ### x86/Emulated platform devices (QEMU):
>
> +Status, PCI host bridge: Supported
> Status, piix3: Supported
That's w
>>> On 08.03.18 at 19:07, wrote:
> On 08/03/2018, 18:44, "Ian Jackson" wrote:
>
> Lars Kurth writes ("[PATCH] Move missing items from
> docs/misc/qemu-xen-security to SUPPORT.md"):
> > x86/Emulated platform devices (QEMU):
> > - Aded PCI host bridge (as in xen.git:docs/misc/qemu-xe
>>> On 09.03.18 at 11:03, wrote:
> On 09/03/2018 09:37, awokd wrote:
>> Lastly, along the lines of those who fail to learn from history are doomed
>> to repeat it, what happened to the Xen PPC port a decade ago? I found an
>> archive of the xen-ppc-devel mailing list but don't see any drama; seems
Hi Peng,
On 09/03/18 09:05, Peng Fan wrote:
On Thu, Mar 08, 2018 at 03:13:50PM +, Julien Grall wrote:
On 08/03/18 12:43, Peng Fan wrote:
There are a major difference between Dom0 and DomU in your setup.
Dom0 vCPUs are pinned to a specific pCPU, so they can't move around.
For DomU, each vCPU
On Fri, Mar 09, Juergen Gross wrote:
> So how does this work?
No idea, at least this output differs:
abuild@latitude:~> readelf -Wa /usr/lib64/libpython2.7.so | grep dlsym
003e5e08 00d90007 R_X86_64_JUMP_SLOT
dlsym@GLIBC_2.2.5 + 0
217:
On 09/03/2018, 11:07, "Jan Beulich" wrote:
>>> On 08.03.18 at 18:37, wrote:
> --- a/SUPPORT.md
> +++ b/SUPPORT.md
> @@ -620,6 +620,7 @@ Note that other devices are available but not
security supported.
>
> ### x86/Emulated platform devices (QEMU):
>
> +
On 09/03/2018, 11:08, "Jan Beulich" wrote:
>>> On 08.03.18 at 19:07, wrote:
> @Jan: this should be backported to 4.10 also
I'll try to remember that, but let's first get it into master (and as
you've likely seen, I'm not entirely happy with this first version).
I wi
Hi Lars,
On 08/03/18 17:37, Lars Kurth wrote:
x86/Emulated platform devices (QEMU):
- Aded PCI host bridge (as in xen.git:docs/misc/qemu-xen-security)
New: x86/Emulated Storage Image Formats
- Added raw, qcow, qcow2, vhd (as in xen.git:docs/misc/qemu-xen-security)
Is there any reason to be x86
On 03/09/2018 10:07 AM, Jan Beulich wrote:
On 08.03.18 at 18:37, wrote:
>> --- a/SUPPORT.md
>> +++ b/SUPPORT.md
>> @@ -620,6 +620,7 @@ Note that other devices are available but not security
>> supported.
>>
>> ### x86/Emulated platform devices (QEMU):
>>
>> +Status, PCI host bridge:
On 03/08/2018 06:07 PM, Lars Kurth wrote:
>
> On 08/03/2018, 18:44, "Ian Jackson" wrote:
>
> Lars Kurth writes ("[PATCH] Move missing items from
> docs/misc/qemu-xen-security to SUPPORT.md"):
> > x86/Emulated platform devices (QEMU):
> > - Aded PCI host bridge (as in xen.git:docs/m
On 09/03/2018, 11:32, "George Dunlap" wrote:
On 03/08/2018 06:07 PM, Lars Kurth wrote:
>
> On 08/03/2018, 18:44, "Ian Jackson" wrote:
>
> Lars Kurth writes ("[PATCH] Move missing items from
docs/misc/qemu-xen-security to SUPPORT.md"):
> > x86/Emulated platfo
On 09/03/2018, 11:31, "Julien Grall" wrote:
Hi Lars,
On 08/03/18 17:37, Lars Kurth wrote:
> x86/Emulated platform devices (QEMU):
> - Aded PCI host bridge (as in xen.git:docs/misc/qemu-xen-security)
> New: x86/Emulated Storage Image Formats
> - Added raw, qcow, qcow
On 03/09/2018 10:31 AM, Julien Grall wrote:
> Hi Lars,
>
> On 08/03/18 17:37, Lars Kurth wrote:
>> x86/Emulated platform devices (QEMU):
>> - Aded PCI host bridge (as in xen.git:docs/misc/qemu-xen-security)
>> New: x86/Emulated Storage Image Formats
>> - Added raw, qcow, qcow2, vhd (as in xen.git:
On Fri, March 9, 2018 10:03 am, Andrew Cooper wrote:
> On 09/03/2018 09:37, awokd wrote:
>
> Xen currently has x86 and ARM as supported architectures, so there is a
> reasonable split between common and arch-specific code. As a start, you'd
> need to implement enough of the arch stubs to make Pow
On 03/09/2018 10:34 AM, Lars Kurth wrote:
>
>
> On 09/03/2018, 11:32, "George Dunlap" wrote:
>
> On 03/08/2018 06:07 PM, Lars Kurth wrote:
> >
> > On 08/03/2018, 18:44, "Ian Jackson" wrote:
> >
> > Lars Kurth writes ("[PATCH] Move missing items from
> docs/misc/qemu
On 09/03/2018, 11:38, "George Dunlap" wrote:
On 03/09/2018 10:34 AM, Lars Kurth wrote:
>
> On 09/03/2018, 11:32, "George Dunlap" wrote:
>
> On 03/08/2018 06:07 PM, Lars Kurth wrote:
> >
> > @Jan: this should be backported to 4.10 also
>
flight 120312 xen-4.6-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120312/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 119227
test-amd64-amd6
>>> On 08.03.18 at 23:24, wrote:
> flight 120287 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/120287/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-migrupgrade 11 xen-boot/dst_ho
>>> On 09.03.18 at 11:30, wrote:
> On 03/09/2018 10:07 AM, Jan Beulich wrote:
> On 08.03.18 at 18:37, wrote:
>>> --- a/SUPPORT.md
>>> +++ b/SUPPORT.md
>>> @@ -620,6 +620,7 @@ Note that other devices are available but not security
>>> supported.
>>>
>>> ### x86/Emulated platform devices (Q
>>> On 09.03.18 at 11:28, wrote:
> On 09/03/2018, 11:07, "Jan Beulich" wrote:
>
> >>> On 08.03.18 at 18:37, wrote:
> > --- a/SUPPORT.md
> > +++ b/SUPPORT.md
> > @@ -620,6 +620,7 @@ Note that other devices are available but not
> security supported.
> >
> > ### x86/E
Please update the qemu-xen tree to include 75e5b70e6b ("memfd: fix
configure test"). Currently xen.git#staging fails like this:
xen-staging/tools/qemu-xen-dir/util/memfd.c:40:12: error: static declaration of
'memfd_create' follows non-static declaration
Thank you.
Olaf
signature.asc
Descripti
On Fri, Mar 09, 2018 at 10:38:00AM -, awokd wrote:
> On Fri, March 9, 2018 10:03 am, Andrew Cooper wrote:
> > On 09/03/2018 09:37, awokd wrote:
>
> >
> > Xen currently has x86 and ARM as supported architectures, so there is a
> > reasonable split between common and arch-specific code. As a st
On Fri, Mar 09, Olaf Hering wrote:
> abuild@latitude:~> readelf -Wa /usr/lib64/libpython2.7.so | grep dlsym
> 003e5e08 00d90007 R_X86_64_JUMP_SLOT
> dlsym@GLIBC_2.2.5 + 0
>217: 0 FUNCGLOBAL DEFAULT UND dlsym@GLIBC_2.2.5
> (10)
>
>>> On 06.03.18 at 21:24, wrote:
> Introduce common helpers for saving and restoring FPU state. During
> emul_test_init(), calculate whether to use xsave or fxsave, and tweak the
> existing mxcsr_mask logic to avoid using another large static buffer.
>
> Signed-off-by: Andrew Cooper
Reviewed-b
Hi,
On 09/03/18 10:38, awokd wrote:
> On Fri, March 9, 2018 10:03 am, Andrew Cooper wrote:
>> On 09/03/2018 09:37, awokd wrote:
>
>>
>> Xen currently has x86 and ARM as supported architectures, so there is a
>> reasonable split between common and arch-specific code. As a start, you'd
>> need to
On 09/03/18 10:38, awokd wrote:
> On Fri, March 9, 2018 10:03 am, Andrew Cooper wrote:
>> On 09/03/2018 09:37, awokd wrote:
>> Xen currently has x86 and ARM as supported architectures, so there is a
>> reasonable split between common and arch-specific code. As a start, you'd
>> need to implement e
Eduardo Habkost writes ("Re: [PATCH 03/11] xen: defer call to xen_restrict
until just before os_setup_post"):
> On Thu, Mar 08, 2018 at 05:39:09PM +, Ian Jackson wrote:
> [...]
> > diff --git a/vl.c b/vl.c
> > +xen_setup_post();
>
> I don't think we should have accelerator-specific code i
On Fri, March 9, 2018 11:25 am, Andrew Cooper wrote:
> I expect that once the ball is rolling, it will pick up momentum, given
> the interest I've already seen on IRC. You probably want to hang out on
> freenode #xendevel
Thanks again for your and the other replies.
I have some hardware already
>>> On 06.03.18 at 21:24, wrote:
> Currently with then native toolchain on Debian Jessie ./test_x86_emulator
> yeilds:
>
> Testing AVX2 256bit single native execution...okay
> Testing AVX2 256bit single 64-bit code sequence...[line 933] failed!
>
> The bug is that libc's memcpy() in read() u
On 09/03/18 11:41, Jan Beulich wrote:
On 06.03.18 at 21:24, wrote:
>> Currently with then native toolchain on Debian Jessie ./test_x86_emulator
>> yeilds:
>>
>> Testing AVX2 256bit single native execution...okay
>> Testing AVX2 256bit single 64-bit code sequence...[line 933] failed!
>>
>>
>>> On 06.03.18 at 21:24, wrote:
> --- a/tools/tests/x86_emulator/test_x86_emulator.c
> +++ b/tools/tests/x86_emulator/test_x86_emulator.c
> @@ -16,6 +16,53 @@
> #include "xop.h"
>
> #define verbose false /* Switch to true for far more logging. */
> +#define fn_width (int)(sizeof("cmpxchg") -
On Fri, March 9, 2018 11:24 am, Andre Przywara wrote:
>
> If you are serious about it, you need a team. Which is about to stay
> around! At least two people, who both know the architecture *and* Xen well.
> And it will probably take them more than a year to get something
> into a state where you c
On Fri, Mar 09, 2018 at 12:05:18PM +0100, Olaf Hering wrote:
> Please update the qemu-xen tree to include 75e5b70e6b ("memfd: fix
> configure test").
Done. I've pushed the commit to qemu-xen staging.
Thanks for the report.
--
Anthony PERARD
___
Xen-d
>>> On 09.03.18 at 12:45, wrote:
> On 09/03/18 11:41, Jan Beulich wrote:
> On 06.03.18 at 21:24, wrote:
>>> Currently with then native toolchain on Debian Jessie ./test_x86_emulator
>>> yeilds:
>>>
>>> Testing AVX2 256bit single native execution...okay
>>> Testing AVX2 256bit single 64-bi
On Fri, Mar 9, 2018 at 11:24 AM, Andre Przywara wrote:
> Hi,
>
> On 09/03/18 10:38, awokd wrote:
>> On Fri, March 9, 2018 10:03 am, Andrew Cooper wrote:
>>> On 09/03/2018 09:37, awokd wrote:
>>
>>>
>>> Xen currently has x86 and ARM as supported architectures, so there is a
>>> reasonable split bet
Ian Jackson writes ("Re: [PATCH 03/11] xen: defer call to xen_restrict until
just before os_setup_post"):
> Eduardo Habkost writes ("Re: [PATCH 03/11] xen: defer call to xen_restrict
> until just before os_setup_post"):
> > I don't think we should have accelerator-specific code in main(),
> > if
Ian Jackson writes ("Re: [PATCH 03/11] xen: defer call to xen_restrict until
just before os_setup_post"):
> How about this ?
And here's the corresponding change to the Xen-specific patch.
From d6140681a877c4d468c4fcf5cac075cdffbea22c Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Fri, 9 Mar 2
Ian Jackson writes ("Re: [PATCH 03/11] xen: defer call to xen_restrict until
just before os_setup_post"):
> Ian Jackson writes ("Re: [PATCH 03/11] xen: defer call to xen_restrict until
> just before os_setup_post"):
> > How about this ?
>
> And here's the corresponding change to the Xen-specific
On Fri, March 9, 2018 12:04 pm, George Dunlap wrote:
> I'm all for encouraging people to jump into Xen, but I agree with
> Andre here, that you should really count the cost. I doubt this is
> the sort of thing a single person could really write and maintain unpaid on
> evenings and weekends. Rem
On Fri, Mar 9, 2018 at 12:17 PM, awokd wrote:
> On Fri, March 9, 2018 12:04 pm, George Dunlap wrote:
>
>> I'm all for encouraging people to jump into Xen, but I agree with
>> Andre here, that you should really count the cost. I doubt this is
>> the sort of thing a single person could really write
>>> On 06.03.18 at 21:24, wrote:
> +void emul_save_fpu_state(void)
> +{
> +if ( use_xsave )
> +asm volatile ( "xsave" __OS " %[ptr]"
> + : [ptr] "=m" (fpu_save_area)
> + : "a" (~0ull), "d" (~0ull) );
Wait, this doesn't build as 32-bit binary
On 03/08/2018 10:33 PM, Boris Ostrovsky wrote:
> On 03/08/2018 05:57 AM, Joao Martins wrote:
>
>> @@ -372,6 +376,15 @@ read_acpi_id(acpi_handle handle, u32 lvl, void
>> *context, void **rv)
>>
>> pr_debug("ACPI CPU%u w/ PBLK:0x%lx\n", acpi_id, (unsigned long)pblk);
>>
>> +/* It has
On Fri, Mar 09, 2018 at 11:33:35AM +, Ian Jackson wrote:
> Eduardo Habkost writes ("Re: [PATCH 03/11] xen: defer call to xen_restrict
> until just before os_setup_post"):
> > On Thu, Mar 08, 2018 at 05:39:09PM +, Ian Jackson wrote:
> > [...]
> > > diff --git a/vl.c b/vl.c
> > > +xen_se
On Fri, Mar 09, 2018 at 12:07:21PM +, Ian Jackson wrote:
> Ian Jackson writes ("Re: [PATCH 03/11] xen: defer call to xen_restrict until
> just before os_setup_post"):
> > Eduardo Habkost writes ("Re: [PATCH 03/11] xen: defer call to xen_restrict
> > until just before os_setup_post"):
> > > I
flight 120309 xen-4.7-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120309/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-5 50 xtf/test-hvm64-lbr-tsx-vmentry fail REGR. vs. 119780
test-arm64-arm6
At the moment, there is a tight coupling between the domid and the use of
DOMCRF_dummy. Instead of using DOMCRF_dummy, base the one relevent decision
on domid alone.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Jan Beulich
CC: Konrad Rzeszutek Wilk
CC: Stefano Stabellini
CC: Tim De
This series is in preparation for passing more parameters via
XEN_DOMCTL_createdomain. It is hypervisor side cleanup, with a couple of
related tangents. The toolstack side of this work is forthcoming.
This series has been compile tested on all architecture, and functionally
tested on x86.
Andre
With DOMCRF_dummy removed, all remaining DOMCRF_* idenitcally match their
DOMCTL counterparts. Avoid having a conversion between two different bit
layouts, and use the DOMCTL_CDF_* constants everywhere.
Signed-off-by: Andrew Cooper
---
CC: George Dunlap
CC: Ian Jackson
CC: Jan Beulich
CC: Kon
ARM guests are HVM and have hardware assisted paging. There are no PV guests
or shadow paging, and all other creation flags are x86 specific.
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Julien Grall
CC: Ian Jackson
CC: Wei Liu
RFC. This is untested, but I noticed it when pu
The share_xen_page_with_guest() functions are used by common code, and are
implemented the same by each arch. Move the declarations into the common mm.h
rather than duplicating them in each arch/mm.h
Turn an int readonly into a boolean enum, to retain ro/rw context at the
callsites, but use short
Neither domcr_flags nor config are used on either side. Drop them, making
{hvm,pv}_domain_initialise() symmetric with all the other domain/vcpu
initialise/destroy calls.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/arch/x86/domain.c | 4
In future patches, the structure will be extended with further information,
and this is far cleaner than adding extra parameters.
One minor tweak is that the setting of guest_type needs to be deferred until
config is known-good to dereference, but this doesn't result in any changed
behaviour as sy
The only relevent initialisation for the idle domain is the context switch and
poisoned pointers. Collect these bits together early in the function and exit
when complete (although as a consequence, the e820 and vtsc lock
initialisation are moved forwards). This allows us to remove subsequent
is_
Hi Julien,
On Fri, Mar 09, 2018 at 10:22:09AM +, Julien Grall wrote:
>Hi Peng,
>
>On 09/03/18 09:05, Peng Fan wrote:
>>On Thu, Mar 08, 2018 at 03:13:50PM +, Julien Grall wrote:
>>>On 08/03/18 12:43, Peng Fan wrote:
>>>There are a major difference between Dom0 and DomU in your setup.
>>>Dom0
>>> On 09.03.18 at 13:37, wrote:
On 06.03.18 at 21:24, wrote:
>> +void emul_save_fpu_state(void)
>> +{
>> +if ( use_xsave )
>> +asm volatile ( "xsave" __OS " %[ptr]"
>> + : [ptr] "=m" (fpu_save_area)
>> + : "a" (~0ull), "d" (~0ull) );
>
flight 120305 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/120305/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-libvirt 7 xen-boot fail REGR. vs. 118324
test-amd64-i386-xl-
On 09/03/18 13:38, Jan Beulich wrote:
On 09.03.18 at 13:37, wrote:
> On 06.03.18 at 21:24, wrote:
>>> +void emul_save_fpu_state(void)
>>> +{
>>> +if ( use_xsave )
>>> +asm volatile ( "xsave" __OS " %[ptr]"
>>> + : [ptr] "=m" (fpu_save_area)
>>> +
Currently with the native tool chain on Debian Jessie ./test_x86_emulator
yields:
Testing AVX2 256bit single native execution...okay
Testing AVX2 256bit single 64-bit code sequence...[line 933] failed!
The bug is that libc's memcpy() in read() uses %xmm8 (specifically, in
__memcpy_sse2_unalig
We have a robot that is trying to send copies of the commits to
xen.git#staging (and I think also staging-NN) to the mailing list
xen-stag...@lists.xenproject.org.
That list was retired, apparently by mistake, in November[1]. But
no-one has complained.
We could reinstate the list, or shut down t
On Fri, Mar 09, 2018 at 01:18:36PM +, Andrew Cooper wrote:
> At the moment, there is a tight coupling between the domid and the use of
> DOMCRF_dummy. Instead of using DOMCRF_dummy, base the one relevent decision
> on domid alone.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
On Fri, Mar 09, 2018 at 01:18:37PM +, Andrew Cooper wrote:
> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> index 50f7422..a73e1a4 100644
> --- a/xen/common/domctl.c
> +++ b/xen/common/domctl.c
> @@ -498,7 +498,6 @@ long do_domctl(XEN_GUEST_HANDLE_PARAM(xen_domctl_t)
> u_domctl)
>
Hi all,
I didn't even know we had that list and have also not advertised it on the
website for this reason.
However, we also have https://lists.xenproject.org/archives/html/xen-changelog
Wouldn't it make sense to send commits to there (with an appropriate prefix).
It already has commits to sta
On Fri, Mar 09, 2018 at 01:18:39PM +, Andrew Cooper wrote:
> Neither domcr_flags nor config are used on either side. Drop them, making
> {hvm,pv}_domain_initialise() symmetric with all the other domain/vcpu
> initialise/destroy calls.
>
> Signed-off-by: Andrew Cooper
Reviewed-by: Wei Liu
Add an option to control when vTSC emulation will be activated for a
domU with tsc_mode=default. Without such option each TSC access from
domU will be emulated, which causes a significant perfomance drop for
workloads that make use of rdtsc.
Add a new domctl XEN_DOMCTL_set_vtsc_tolerance_khz to ad
On 09/03/18 14:12, Wei Liu wrote:
> On Fri, Mar 09, 2018 at 01:18:37PM +, Andrew Cooper wrote:
>> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
>> index 50f7422..a73e1a4 100644
>> --- a/xen/common/domctl.c
>> +++ b/xen/common/domctl.c
>> @@ -498,7 +498,6 @@ long do_domctl(XEN_GUEST_HAN
On Fri, Mar 09, 2018 at 02:14:48PM +, Andrew Cooper wrote:
> On 09/03/18 14:12, Wei Liu wrote:
> > On Fri, Mar 09, 2018 at 01:18:37PM +, Andrew Cooper wrote:
> >> diff --git a/xen/common/domctl.c b/xen/common/domctl.c
> >> index 50f7422..a73e1a4 100644
> >> --- a/xen/common/domctl.c
> >> ++
Instead of "syncing" the live value to what mmu_cr4_features has, make
sure vCPU-s run with the value most recently loaded into %cr4, such that
after the next VM exit we continue to run with the intended value rather
than a possibly stale one.
Signed-off-by: Jan Beulich
---
TBD: Is the conditiona
On 09/03/18 14:18, Jan Beulich wrote:
> Instead of "syncing" the live value to what mmu_cr4_features has, make
> sure vCPU-s run with the value most recently loaded into %cr4, such that
> after the next VM exit we continue to run with the intended value rather
> than a possibly stale one.
>
> Signe
On 08/03/18 16:06, Jan Beulich wrote:
On 02.03.18 at 09:14, wrote:
>> @@ -123,22 +142,14 @@ unsigned int flush_area_local(const void *va, unsigned
>> int flags)
>> u32 t = pre_flush();
>>
>> if ( !cpu_has_invpcid )
>> -{
>> -unsigned lo
>>> On 09.03.18 at 15:35, wrote:
> On 09/03/18 14:18, Jan Beulich wrote:
>> Instead of "syncing" the live value to what mmu_cr4_features has, make
>> sure vCPU-s run with the value most recently loaded into %cr4, such that
>> after the next VM exit we continue to run with the intended value rather
Hi,
On 09/03/18 13:30, Peng Fan wrote:
Hi Julien,
On Fri, Mar 09, 2018 at 10:22:09AM +, Julien Grall wrote:
Hi Peng,
On 09/03/18 09:05, Peng Fan wrote:
On Thu, Mar 08, 2018 at 03:13:50PM +, Julien Grall wrote:
On 08/03/18 12:43, Peng Fan wrote:
There are a major difference between Do
On Fri, Mar 09, 2018 at 01:18:40PM +, Andrew Cooper wrote:
> The only relevent initialisation for the idle domain is the context switch and
> poisoned pointers. Collect these bits together early in the function and exit
> when complete (although as a consequence, the e820 and vtsc lock
> initi
On Fri, Mar 09, 2018 at 01:18:41PM +, Andrew Cooper wrote:
> In future patches, the structure will be extended with further information,
> and this is far cleaner than adding extra parameters.
>
> One minor tweak is that the setting of guest_type needs to be deferred until
> config is known-go
On Fri, Mar 09, 2018 at 01:18:42PM +, Andrew Cooper wrote:
> The share_xen_page_with_guest() functions are used by common code, and are
> implemented the same by each arch. Move the declarations into the common mm.h
> rather than duplicating them in each arch/mm.h
>
> Turn an int readonly int
c/s d1d6fc97d "x86/xpti: really hide almost all of Xen image" accidentially
moved idt_table[] from .bss to .data by virtue of using the page_aligned
section. We also have .bss.page_aligned, so use that.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Wei Liu
CC: Roger Pau Monné
---
xen/
The prototype for gic_remove_from_lr_pending() is the last function in
gic.h which references a VGIC data structure.
Move it over to vgic.h, so that we can remove the inclusion of vgic.h
from gic.h. We add it to asm/domain.h instead, where it is actually
needed.
Signed-off-by: Andre Przywara
Revi
To get away from that scary xx/57 number in the new vGIC series, these
are the first few patches split off. They prepare the existing Xen code
to better observe the split between the vGIC emulation and the physical
GIC driver.
This affects the first 20 patches from the new vGIC series. Most of them
domain_max_vcpus(), which is used by generic Xen code, returns the
maximum number of VCPUs for a domain, which on ARM is mostly limited by
the VGIC model emulated (a (v)GICv2 can only handle 8 CPUs).
Our current implementation lives in arch/arm/domain.c, but reaches into
VGIC internal data structur
The last patch removed the usage of the hardware's redistributor-stride
value from our (Dom0) GICv3 emulation. This means we no longer need to
store this value in the VGIC data structure.
Remove that variable and every code snippet that handled that, instead
simply always use the architected value.
gic_event_needs_delivery() is not named very intuitively, especially
the gic_ prefix is somewhat misleading.
Rename it to vgic_pending_irq(), which makes it clear that this relates
to the virtual GIC and is about interrupts.
Signed-off-by: Andre Przywara
---
Changelog:
- Add vcpu parameter
- Rena
Normally there is only one GICv3 redistributor region, and we use
that for DomU guests using a GICv3.
Explain the background in a comment and why we need to keep the number
of hardware regions for Dom0.
Signed-off-by: Andre Przywara
Acked-by: Julien Grall
---
xen/arch/arm/vgic-v3.c | 12 +++
The bit definition for the CPUID mask in the GICv2 LR register was
wrong, fortunately the current implementation does not use that bit.
Fix it up (it's starting at bit 10, not bit 9) and clean up some
nearby definitions on the way.
This will be used by the new VGIC shortly.
Signed-off-by: Andre Pr
The code to generate the DT node or MADT table for Dom0 reaches into the
domain's vGIC structure to learn the number of redistributor regions and
their base addresses.
Since those values are copied from the hardware, we can as well use
those hardware values directly when setting up the hardware dom
If we change something in a vCPU that affects its runnability or
otherwise needs the vCPU's attention, we might need to tell the scheduler
about it.
We are using this in one place (vIRQ injection) at the moment, but will
need this at more places soon.
So let's factor out this functionality, using t
The two central functions to synchronise our emulated VGIC state with
the GIC hardware (the LRs, really), are named somewhat confusingly.
Rename them from gic_inject() to vgic_sync_to_lrs() and from
gic_clear_lrs() to vgic_sync_from_lrs(), to make the code more readable.
Signed-off-by: Andre Przyw
Currently vgic.h both contains prototypes used by Xen arch code outside
of the actual VGIC (for instance vgic_vcpu_inject_irq()), and prototypes
for functions used by the VGIC internally.
Group them to later allow an easy split with one #ifdef.
Signed-off-by: Andre Przywara
Reviewed-by: Julien Gr
The redistributor-stride property in a GICv3 DT node is only there to
cover broken platforms where this value deviates from the architected one.
Since we emulate the GICv3 distributor even for Dom0, we don't need to
copy the broken behaviour. All the special handling for Dom0s using
GICv3 is just f
The GICv2 uses bitmaps spanning several MMIO registers for holding some
interrupt state. Similar to GICv3, add a poke helper functions to set a bit
for a given irq_desc in one of those bitmaps.
At the moment there is only one use in gic-v2.c, but there will be more
coming soon.
Signed-off-by: Andr
So far the number of list registers (LRs) a GIC implements is only
needed in the hardware facing side of the VGIC code (gic-vgic.c).
The new VGIC will need this information in more and multiple places, so
export a function that returns the number.
Signed-off-by: Andre Przywara
Reviewed-by: Julien
At the moment vgic_vcpu_inject_irq() is the interface for Xen internal
code and virtual devices to inject IRQs into a guest. This interface has
two shortcomings:
1) It requires a VCPU pointer, which we may not know (and don't need!)
for shared interrupts. A second function (vgic_vcpu_inject_spi()),
On a GICv3 in non-compat mode the hypervisor interface is always
accessed via system registers. Those register names have a "ICH_" prefix
in the manual, to differentiate them from the MMIO registers. Also those
registers are mostly 64-bit (compared to the 32-bit GICv2 registers) and
use different b
1 - 100 of 192 matches
Mail list logo
