On 15.01.20 17:32, Sergey Dyasli wrote:
On 15/01/2020 11:09, Jürgen Groß wrote:
On 15.01.20 11:54, Sergey Dyasli wrote:
Hi Juergen,
On 08/01/2020 15:20, Sergey Dyasli wrote:
It is incorrect to call pmd_populate_kernel() multiple times for the
same page table. Xen notices it during
Hi
Am 16.01.20 um 07:41 schrieb Daniel Vetter:
> On Wed, Jan 15, 2020 at 01:52:26PM +0100, Thomas Zimmermann wrote:
>> In drm_atomic_helper_fake_vblank() the DRM core sends out VBLANK events
>> if struct drm_crtc_state.no_vblank is enabled in the check() callbacks.
>>
>> For drivers that have
flight 146101 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146101/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 144798
On Wed, Jan 15, 2020 at 01:52:26PM +0100, Thomas Zimmermann wrote:
> In drm_atomic_helper_fake_vblank() the DRM core sends out VBLANK events
> if struct drm_crtc_state.no_vblank is enabled in the check() callbacks.
>
> For drivers that have neither an enable_vblank() callback nor a check()
>
Hello guys,
Does anyone run Xen on RPi4 and can help?
I just found
https://www.mail-archive.com/xen-devel@lists.xenproject.org/msg50685.html but
there doesn't work HDMI and memory limitation.
Best regards,
Ivan Sheihets
Infopulse Ukraine
+38-097-913-10-01
[cid:image001.png@01D0A777.74430340]
flight 146100 xen-4.12-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146100/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qcow217 guest-localmigrate/x10 fail like 145017
test-amd64-i386-xl-pvshim12
flight 146131 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146131/
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
On Wed, Jan 15, 2020 at 05:32:32PM -0500, Boris Ostrovsky wrote:
>
>
> On 1/15/20 11:48 AM, Roger Pau Monné wrote:
> > On Wed, Jan 15, 2020 at 02:46:29AM +0100, Marek Marczykowski-Górecki wrote:
> > > QEMU running in a stubdom needs to be able to set INTX_DISABLE, and the
> > > MSI(-X) enable
flight 146097 xen-4.9-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146097/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-win7-amd64 16 guest-localmigrate/x10 fail REGR. vs.
144758
On 1/15/20 11:48 AM, Roger Pau Monné wrote:
On Wed, Jan 15, 2020 at 02:46:29AM +0100, Marek Marczykowski-Górecki wrote:
QEMU running in a stubdom needs to be able to set INTX_DISABLE, and the
MSI(-X) enable flags in the PCI config space. This adds an attribute
'allow_interrupt_control' which
> On Jan 14, 2020, at 21:42, Marek Marczykowski-Górecki
> wrote:
> Since we have those generated files committed to the repo (why?!),
> update them after changing configure.ac.
Is there any reason not to remove the generated configure files? A developer
using generated files on system B
Andrew Cooper writes ("[PATCH 0.5/12] tools/migration: Formatting and style
cleanup"):
> The code has devating from the prevailing style in many ways. Adjust spacing,
> indentation, position of operators, layout of multiline comments, removal of
> superfluous comments, constness, trailing
flight 146118 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146118/
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
On 14/01/2020 16:48, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 01/12] libxc/save: Shrink code volume where
> possible"):
>> A property of how the error handling (0 on success, nonzero otherwise)
>> allows these calls to be chained together with the ternary operatior.
> I'm quite
The code has devating from the prevailing style in many ways. Adjust spacing,
indentation, position of operators, layout of multiline comments, removal of
superfluous comments, constness, trailing commas, and use of unqualified
'unsigned'.
No functional change.
Signed-off-by: Andrew Cooper
---
Hi,
On 15/01/2020 18:43, Andrew Cooper wrote:
This logic was inherited from x86 (which was updated several times since).
Unlike x86 (at the time) however, while NULL isn't mapped in ARM, 0xf000
is, making this actively dangerous.
Drop the logic entirely, and leave 'current' as NULL during
The BUG_ON() is confusing to follow. The (!is_idle_domain(d) || vcpu_id) part
is a vestigial remnant of architectures poisioning idle_vcpu[0] with non-NULL
pointers.
Now that idle_vcpu[0] is NULL on all architectures, and d->max_vcpus specified
before vcpu_create() is called, we can properly
This logic was inherited from x86 (which was updated several times since).
Unlike x86 (at the time) however, while NULL isn't mapped in ARM, 0xf000
is, making this actively dangerous.
Drop the logic entirely, and leave 'current' as NULL during early boot.
Signed-off-by: Andrew Cooper
---
On Fri, 10 Jan 2020 22:41:49 +0300
Vladimir Sementsov-Ogievskiy wrote:
> Here is introduced ERRP_AUTO_PROPAGATE macro, to be used at start of
> functions with errp OUT parameter.
>
> It has three goals:
>
> 1. Fix issue with error_fatal & error_prepend/error_append_hint: user
> can't see this
I should have added more people to this change. The issue without this fix is
that entries such as
L: xen-devel
break get_maintainer.pl and thus add_maintainers.pl
Lars
On 10/01/2020, 21:19, "Lars Kurth" wrote:
From: Lars Kurth
Prior to this change e-mail addresses of the
On 1/15/20 9:21 AM, Andrew Cooper wrote:
> That is the command line for dom0 which is a VM. You need the Xen
> hypervisor command line.
thx. done.
> You'll need to edit xen-4.13.0_04-lp151.688.cfg which will be somewhere
> on the ESP (wherever that is mounted in an openSUSE system).
On Wed, Jan 15, 2020 at 09:25:53PM +0530, madhuparnabhowmi...@gmail.com wrote:
> From: Madhuparna Bhowmik
>
> list_for_each_entry_rcu has built-in RCU and lock checking.
> Pass cond argument to list_for_each_entry_rcu.
>
> Signed-off-by: Madhuparna Bhowmik
Acked-by: Wei Liu
On 15/01/2020 17:19, PGNet Dev wrote:
> hi
>
> On 1/15/20 9:10 AM, Andrew Cooper wrote:
>>> Is this a known/fixable issue?
>> The APIC errors aren't fatal. They need looking into and addressing in
>> due course.
>>
>> The real crash is EFI firmware falling over a NULL pointer which is
>> wildly
hi
On 1/15/20 9:10 AM, Andrew Cooper wrote:
>> Is this a known/fixable issue?
>
> The APIC errors aren't fatal. They need looking into and addressing in
> due course.
>
> The real crash is EFI firmware falling over a NULL pointer which is
> wildly known issue. Fixing it requires following the
flight 146094 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/146094/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-qemuu-rhel6hvm-intel 11 guest-stop fail REGR. vs. 146058
Tests which did
Anthony PERARD writes ("[XEN PATCH] linkfarm: Exclude .*.tmp"):
> Exclude intermidiate files .*.tmp from the linkfarm, those are
> generated by %.o:%.c rules in xen/Rules.mk when
> CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.
>
> Signed-off-by: Anthony PERARD
Acked-by: Ian Jackson
On 15/01/2020 16:52, PGNet Dev wrote:
> dev @distro suggested I post this here ...
>
> I've a recently upgraded Xen & Kernel on
>
> lsb_release -rd
> Description:openSUSE Leap 15.1
> Release:15.1
>
> Atm, I'm running
>
> Xen 4.13.0_04
>
> server,
On 1/15/20 12:22 PM, Lars Kurth wrote:
> @George, @Ian: let me know whether this is better and addresses your
> concerns
This looks good to me.
One side note:
> The way how a reviewer expresses feedback, has a big impact on how the author
"The way how X happens" isn't grammatically correct;
Kconfig can check if $(CC) is clang or not, if it is
CONFIG_CC_IS_CLANG will be set.
With that patch, the hypervisor can be built using clang by running
`make CC=clang CXX=clang++` without needed to provide an extra clang
parameter.
`make clang=y` still works as Config.mk will set CC and CXX.
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.build-system-xen-kconfig-v3
v3:
- change in patch 2. gcc-version.sh now behave like clang-version.sh.
otherwise, the series should be ready.
v2:
- nit changes in patch 1 and 2.
The check for $(CC) -fvisibility=hidden is done by both arm and x86,
so the patch also move the check to the common area.
The check doesn't check if $(CC) is gcc, and clang can accept that
option as well, so s/GCC/CC/ is done to the define name.
Signed-off-by: Anthony PERARD
Acked-by: Andrew
This import several files from Linux v5.3
- scripts/Kconfig.include
- scripts/clang-version.sh
- scripts/gcc-version.sh
and several config values from from Linux's init/Kconfig file.
But gcc-version.sh have been modified to return "0" when $CC isn't
GCC, like clang-version.sh do.
Files are
This is in preparation of importing Kbuild to build Xen. We won't be
able to include Config.mk so we will need a replacement for the macro
`cc-ifversion'.
This patch imports parts of "scripts/Kbuild.include" from Linux v5.4,
the macro cc-ifversion. It makes use of CONFIG_GCC_VERSION that
Kconfig
Now that Kconfig has the capability to run shell command when
generating CONFIG_* we can use it in some cases to test CFLAGS.
CONFIG_INDIRECT_THUNK is a good example that wants to exist both in
Makefile and as a C macro, which Kconfig do. So use Kconfig to
generate CONFIG_INDIRECT_THUNK and have
dev @distro suggested I post this here ...
I've a recently upgraded Xen & Kernel on
lsb_release -rd
Description:openSUSE Leap 15.1
Release:15.1
Atm, I'm running
Xen 4.13.0_04
server, on EFI hardware + Intel Xeon E3 CPU, with kernel
On Wed, Jan 15, 2020 at 02:46:29AM +0100, Marek Marczykowski-Górecki wrote:
> QEMU running in a stubdom needs to be able to set INTX_DISABLE, and the
> MSI(-X) enable flags in the PCI config space. This adds an attribute
> 'allow_interrupt_control' which when set for a PCI device allows writes
>
Exclude intermidiate files .*.tmp from the linkfarm, those are
generated by %.o:%.c rules in xen/Rules.mk when
CONFIG_ENFORCE_UNIQUE_SYMBOLS=y.
Signed-off-by: Anthony PERARD
---
tools/firmware/xen-dir/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/firmware/xen-dir/Makefile
On 14/01/2020 17:30, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 17/20] tools/libx[cl]: Plumb static_data_done()
> up into libxl"):
>> /* callbacks provided by xc_domain_restore */
>> struct restore_callbacks {
>> +/*
>> + * Called once the STATIC_DATA_END record has been
On 15/01/2020 11:09, Jürgen Groß wrote:
> On 15.01.20 11:54, Sergey Dyasli wrote:
>> Hi Juergen,
>>
>> On 08/01/2020 15:20, Sergey Dyasli wrote:
>>> It is incorrect to call pmd_populate_kernel() multiple times for the
>>> same page table. Xen notices it during kasan_populate_early_shadow():
>>>
On 15.01.2020 17:29, Andrew Cooper wrote:
> On 15/01/2020 16:27, Jan Beulich wrote:
>> On 15.01.2020 15:36, Andrew Cooper wrote:
>>> On 15/01/2020 10:26, Jan Beulich wrote:
While it has been me to introduce this, the use of | there has become
(and perhaps was from the very beginning)
On 15.01.2020 15:36, Andrew Cooper wrote:
> On 15/01/2020 10:26, Jan Beulich wrote:
>> While it has been me to introduce this, the use of | there has become
>> (and perhaps was from the very beginning) misleading. Rather than
>> avoiding the right side of it when linking the xen.efi intermediate
On 15/01/2020 16:27, Jan Beulich wrote:
> On 15.01.2020 15:36, Andrew Cooper wrote:
>> On 15/01/2020 10:26, Jan Beulich wrote:
>>> While it has been me to introduce this, the use of | there has become
>>> (and perhaps was from the very beginning) misleading. Rather than
>>> avoiding the right side
On 15.01.2020 14:44, Roger Pau Monné wrote:
> On Wed, Jan 15, 2020 at 01:49:22PM +0100, Jan Beulich wrote:
>> What I'm then worried about is too
>> little progress observable by guests. The PV time protocol
>> ought to be fine in this regard (and consumers of raw TSC values
>> are on their own
On 14/01/2020 17:27, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 16/20] tools/libxl: Simplify callback handling
> in libxl-save-helper"):
>> The {save,restore}_callback helpers can have their scope reduced vastly,
> This part is OK with me although it would have been nicer to review if
>
On Wed, Jan 15, 2020 at 02:36:24PM +, Andrew Cooper wrote:
> On 15/01/2020 10:26, Jan Beulich wrote:
> > While it has been me to introduce this, the use of | there has become
> > (and perhaps was from the very beginning) misleading. Rather than
> > avoiding the right side of it when linking
From: Madhuparna Bhowmik
list_for_each_entry_rcu has built-in RCU and lock checking.
Pass cond argument to list_for_each_entry_rcu.
Signed-off-by: Madhuparna Bhowmik
---
drivers/net/xen-netback/hash.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
On 14/01/2020 17:21, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 12/12] libxc/save: Write X86_{CPUID,MSR}_DATA
> records"):
>> With all other plumbing in place, obtain the CPU Policy from Xen and
>> write it into the migration stream.
> This looks good to me but:
>
> This patch may need
On 14/01/2020 16:12, Ian Jackson wrote:
> Andrew Cooper writes ("Re: [PATCH 10/12] docs/migration: Specify
> X86_{CPUID,MSR}_POLICY records"):
>> The migration stream is split into records with no playload (markers
>> with external control flow meaning), and data records, which have a payload.
>
On Wed, Jan 15, 2020 at 8:35 PM Wei Liu wrote:
> On Wed, Jan 15, 2020 at 07:48:40PM +0530, madhuparnabhowmi...@gmail.com
> wrote:
> > From: Madhuparna Bhowmik
> >
> > list_for_each_entry_rcu has built-in RCU and lock checking.
> > Pass cond argument to list_for_each_entry_rcu.
> >
> >
On Wed, Jan 15, 2020 at 8:34 PM Wei Liu wrote:
> On Wed, Jan 15, 2020 at 07:36:38PM +0530, Madhuparna Bhowmik wrote:
> [...]
> >
> > > The surrounding code makes it pretty clear that the lock is already
> held
> > > by the time list_for_each_entry_rcu is called, yet the checking
> involved
> > >
On 14/01/2020 16:08, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 10/12] docs/migration: Specify
> X86_{CPUID,MSR}_POLICY records"):
>> These two records move blobs from the XEN_DOMCTL_{get,set}_cpu_policy
>> hypercall.
> We had an extensive IRL discussion recently about the compatibility
>
On 14/01/2020 16:05, Ian Jackson wrote:
> Andrew Cooper writes ("[PATCH 05/12] tools/migration: Drop IHDR_VERSION
> constant from libxc and python"):
>> Migration v3 is in the process of being introduced, meaning that the code has
>> to cope with both versions. Use an explicit 2 for now.
>>
>>
On Wed, Jan 15, 2020 at 07:48:40PM +0530, madhuparnabhowmi...@gmail.com wrote:
> From: Madhuparna Bhowmik
>
> list_for_each_entry_rcu has built-in RCU and lock checking.
> Pass cond argument to list_for_each_entry_rcu.
>
> Signed-off-by: Madhuparna Bhowmik
You seem to have dropped the second
On Wed, Jan 15, 2020 at 07:36:38PM +0530, Madhuparna Bhowmik wrote:
[...]
>
> > The surrounding code makes it pretty clear that the lock is already held
> > by the time list_for_each_entry_rcu is called, yet the checking involved
> > in lockdep_is_held is not trivial, so I'm afraid I don't
On 15/01/2020 12:54, Jan Beulich wrote:
> On 15.01.2020 13:47, Igor Druzhinin wrote:
>> On 15/01/2020 12:39, Jan Beulich wrote:
>>> On 15.01.2020 13:28, Igor Druzhinin wrote:
On 15/01/2020 11:32, Jan Beulich wrote:
> On 14.01.2020 20:36, Igor Druzhinin wrote:
>> If ITSC is not
On 15/01/2020 13:23, Roger Pau Monné wrote:
> On Wed, Jan 15, 2020 at 12:36:08PM +, Igor Druzhinin wrote:
>> On 15/01/2020 09:47, Roger Pau Monné wrote:
>>> On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
If ITSC is not available on CPU (e.g if running nested as PV shim)
On 15/01/2020 10:26, Jan Beulich wrote:
> While it has been me to introduce this, the use of | there has become
> (and perhaps was from the very beginning) misleading. Rather than
> avoiding the right side of it when linking the xen.efi intermediate file
> at a different base address, make the
From: Madhuparna Bhowmik
list_for_each_entry_rcu has built-in RCU and lock checking.
Pass cond argument to list_for_each_entry_rcu.
Signed-off-by: Madhuparna Bhowmik
---
drivers/net/xen-netback/hash.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Despite being vaguely aware, the difference between PAGE_HYPERVISOR in ASM and
C code has nevertheless caused several bugs I should have known better about,
and contributed to review confusion.
There are exactly 4 uses of these constants in asm code (and one is shortly
going to disappear).
On Wed, Jan 15, 2020 at 7:26 PM Wei Liu wrote:
> Thanks for the patch.
>
> There is a typo in the subject line. It should say xen-netback, not
> xen-netbank.
>
> Hi,
I am sorry about this, I will send this patch again.
> On Wed, Jan 15, 2020 at 06:11:28PM +0530, madhuparnabhowmi...@gmail.com
Thanks for the patch.
There is a typo in the subject line. It should say xen-netback, not
xen-netbank.
On Wed, Jan 15, 2020 at 06:11:28PM +0530, madhuparnabhowmi...@gmail.com wrote:
> From: Madhuparna Bhowmik
>
> list_for_each_entry_rcu has built-in RCU and lock checking.
> Pass cond argument
On Wed, Jan 15, 2020 at 01:49:22PM +0100, Jan Beulich wrote:
> On 15.01.2020 12:53, Roger Pau Monné wrote:
> > On Wed, Jan 15, 2020 at 12:40:27PM +0100, Jan Beulich wrote:
> >> On 15.01.2020 10:47, Roger Pau Monné wrote:
> >>> On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
>
On Wed, Jan 15, 2020 at 12:36:08PM +, Igor Druzhinin wrote:
> On 15/01/2020 09:47, Roger Pau Monné wrote:
> > On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
> >> If ITSC is not available on CPU (e.g if running nested as PV shim)
> >> then X86_FEATURE_NONSTOP_TSC is not
On 15.01.2020 13:53, Andrew Cooper wrote:
> On 14/01/2020 16:25, Jan Beulich wrote:
>>> --- a/xen/include/asm-x86/x86_64/page.h
>>> +++ b/xen/include/asm-x86/x86_64/page.h
>>> @@ -172,18 +172,11 @@ static inline intpte_t put_pte_flags(unsigned int x)
>>> #define PAGE_HYPERVISOR_RX
Hi,
On 15-01-2020 13:52, Thomas Zimmermann wrote:
(Resending because I did not cc dri-devel properly.)
Instead of faking VBLANK events by themselves, drivers without VBLANK
support can enable drm_crtc_vblank.no_vblank and let DRM do the rest.
The patchset makes this official and converts over
From: Madhuparna Bhowmik
list_for_each_entry_rcu has built-in RCU and lock checking.
Pass cond argument to list_for_each_entry_rcu.
Signed-off-by: Madhuparna Bhowmik
---
drivers/net/xen-netback/hash.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
On 15.01.2020 13:47, Igor Druzhinin wrote:
> On 15/01/2020 12:39, Jan Beulich wrote:
>> On 15.01.2020 13:28, Igor Druzhinin wrote:
>>> On 15/01/2020 11:32, Jan Beulich wrote:
On 14.01.2020 20:36, Igor Druzhinin wrote:
> If ITSC is not available on CPU (e.g if running nested as PV shim)
On 14/01/2020 16:25, Jan Beulich wrote:
>> --- a/xen/include/asm-x86/x86_64/page.h
>> +++ b/xen/include/asm-x86/x86_64/page.h
>> @@ -172,18 +172,11 @@ static inline intpte_t put_pte_flags(unsigned int x)
>> #define PAGE_HYPERVISOR_RX (__PAGE_HYPERVISOR_RX | _PAGE_GLOBAL)
>> #define
In drm_atomic_helper_fake_vblank(), the DRM core sends out VBLANK
events if struct drm_crtc_state.no_vblank is enabled. Replace cirrus'
VBLANK events with the DRM core's functionality.
v2:
* set struct_drm_crtc_state.no_vblank in cirrus_pipe_check()
Signed-off-by: Thomas Zimmermann
---
Drivers for CRTC hardware without support for VBLANK interrupts can set
struct drm_crtc_state.no_vblank and let DRM's atomic commit helpers
generate the VBLANK events automatically. Document this in order to make
it official.
Signed-off-by: Thomas Zimmermann
---
(Resending because I did not cc dri-devel properly.)
Instead of faking VBLANK events by themselves, drivers without VBLANK
support can enable drm_crtc_vblank.no_vblank and let DRM do the rest.
The patchset makes this official and converts over several drivers.
Ast already uses the functionality
In drm_atomic_helper_fake_vblank() the DRM core sends out VBLANK events
if struct drm_crtc_state.no_vblank is enabled in the check() callbacks.
For drivers that have neither an enable_vblank() callback nor a check()
callback, the simple-KMS helpers enable VBLANK generation by default. This
CRTC state properties should be computed in atomic_check(). Do so for
the no_vblank field.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
On 15.01.2020 12:53, Roger Pau Monné wrote:
> On Wed, Jan 15, 2020 at 12:40:27PM +0100, Jan Beulich wrote:
>> On 15.01.2020 10:47, Roger Pau Monné wrote:
>>> On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@
On 15/01/2020 12:39, Jan Beulich wrote:
> On 15.01.2020 13:28, Igor Druzhinin wrote:
>> On 15/01/2020 11:32, Jan Beulich wrote:
>>> On 14.01.2020 20:36, Igor Druzhinin wrote:
If ITSC is not available on CPU (e.g if running nested as PV shim)
then X86_FEATURE_NONSTOP_TSC is not advertised
On 15.01.2020 13:31, Igor Druzhinin wrote:
> On 15/01/2020 12:25, Igor Druzhinin wrote:
>> On 15/01/2020 11:40, Jan Beulich wrote:
>>> On 15.01.2020 10:47, Roger Pau Monné wrote:
On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
> --- a/xen/arch/x86/time.c
> +++
On 15/01/2020 11:17, Jan Beulich wrote:
> On 14.01.2020 21:35, Andrew Cooper wrote:
>> Xen inherited its list infrastructure from Linux. One area where has fallen
>> behind is that of prefetching, which as it turns out is a performance penalty
>> in most cases.
>>
>> Prefetch of NULL on x86 is
On 15.01.2020 13:28, Igor Druzhinin wrote:
> On 15/01/2020 11:32, Jan Beulich wrote:
>> On 14.01.2020 20:36, Igor Druzhinin wrote:
>>> If ITSC is not available on CPU (e.g if running nested as PV shim)
>>> then X86_FEATURE_NONSTOP_TSC is not advertised in certain cases, i.e.
>>> all AMD and some
On 15/01/2020 09:47, Roger Pau Monné wrote:
> On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
>> If ITSC is not available on CPU (e.g if running nested as PV shim)
>> then X86_FEATURE_NONSTOP_TSC is not advertised in certain cases, i.e.
>> all AMD and some old Intel processors. In
On 15/01/2020 12:25, Igor Druzhinin wrote:
> On 15/01/2020 11:40, Jan Beulich wrote:
>> On 15.01.2020 10:47, Roger Pau Monné wrote:
>>> On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
--- a/xen/arch/x86/time.c
+++ b/xen/arch/x86/time.c
@@ -955,10 +955,16 @@ u64
On 15/01/2020 11:32, Jan Beulich wrote:
> On 14.01.2020 20:36, Igor Druzhinin wrote:
>> If ITSC is not available on CPU (e.g if running nested as PV shim)
>> then X86_FEATURE_NONSTOP_TSC is not advertised in certain cases, i.e.
>> all AMD and some old Intel processors. In which case TSC would need
On 15/01/2020 11:40, Jan Beulich wrote:
> On 15.01.2020 10:47, Roger Pau Monné wrote:
>> On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
>>> --- a/xen/arch/x86/time.c
>>> +++ b/xen/arch/x86/time.c
>>> @@ -955,10 +955,16 @@ u64 stime2tsc(s_time_t stime)
>>>
>>> void
On 15/01/2020, 10:47, "George Dunlap" wrote:
On 1/13/20 9:21 PM, Lars Kurth wrote:
>
>
> On 13/01/2020, 19:54, "George Dunlap" wrote:
>
>
> > On Dec 30, 2019, at 7:32 PM, Lars Kurth
wrote:
> >
> > From: Lars Kurth
> >
>
On Wed, Jan 15, 2020 at 12:40:27PM +0100, Jan Beulich wrote:
> On 15.01.2020 10:47, Roger Pau Monné wrote:
> > On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
> >> --- a/xen/arch/x86/time.c
> >> +++ b/xen/arch/x86/time.c
> >> @@ -955,10 +955,16 @@ u64 stime2tsc(s_time_t stime)
> >>
On 15.01.2020 10:47, Roger Pau Monné wrote:
> On Tue, Jan 14, 2020 at 07:36:21PM +, Igor Druzhinin wrote:
>> --- a/xen/arch/x86/time.c
>> +++ b/xen/arch/x86/time.c
>> @@ -955,10 +955,16 @@ u64 stime2tsc(s_time_t stime)
>>
>> void cstate_restore_tsc(void)
>> {
>> +struct cpu_time *t =
On 14.01.2020 20:36, Igor Druzhinin wrote:
> If ITSC is not available on CPU (e.g if running nested as PV shim)
> then X86_FEATURE_NONSTOP_TSC is not advertised in certain cases, i.e.
> all AMD and some old Intel processors. In which case TSC would need to
> be restored on CPU from platform time
On 15/01/2020 10:39, Roger Pau Monné wrote:
> On Tue, Jan 14, 2020 at 08:35:45PM +, Andrew Cooper wrote:
>> Xen inherited its list infrastructure from Linux. One area where has fallen
>> behind is that of prefetching, which as it turns out is a performance penalty
>> in most cases.
>>
>>
On 14.01.2020 21:35, Andrew Cooper wrote:
> Xen inherited its list infrastructure from Linux. One area where has fallen
> behind is that of prefetching, which as it turns out is a performance penalty
> in most cases.
>
> Prefetch of NULL on x86 is now widely measured to have glacial performance
Hello,
For the last days I've been trying to figure out how to properly
perform flushes of guest TLBs from the hypervisor. We currently
provide a hypercall to HVM guests (HVMOP_flush_tlbs). The hypercall
however pauses all vCPUs that require a flush and then call
paging_update_cr3, which is
On 15.01.20 11:54, Sergey Dyasli wrote:
Hi Juergen,
On 08/01/2020 15:20, Sergey Dyasli wrote:
It is incorrect to call pmd_populate_kernel() multiple times for the
same page table. Xen notices it during kasan_populate_early_shadow():
(XEN) mm.c:3222:d155v0 mfn 3704b already pinned
This
On 14/01/2020 21:39, Jorge Pereira wrote:
Hi Guys,
Hello,
I’m currently using XEN in order to run side-by-side a DOM-0 with a
DOM-U guest. My use-case scenario requires in the DOM-U direct access to
some dma-capable devices such ethernet and some GPUs.
Since our target platform
On 09/01/2020 10:33, Vlastimil Babka wrote:
> On 1/8/20 4:21 PM, Sergey Dyasli wrote:
>> From: Ross Lagerwall
>>
>> When KASAN (or SLUB_DEBUG) is turned on, the normal expectation that
>> allocations are aligned to the next power of 2 of the size does not
>> hold.
>
> Hmm, really? They should
On 15.01.2020 03:39, Marek Marczykowski-Górecki wrote:
> Add a simple proxy for tunneling socket connection over vchan. This is
> based on existing vchan-node* applications, but extended with socket
> support. vchan-socket-proxy serves both as a client and as a server,
> depending on parameters.
Hi Juergen,
On 08/01/2020 15:20, Sergey Dyasli wrote:
> It is incorrect to call pmd_populate_kernel() multiple times for the
> same page table. Xen notices it during kasan_populate_early_shadow():
>
> (XEN) mm.c:3222:d155v0 mfn 3704b already pinned
>
> This happens for kasan_early_shadow_pte
On 1/13/20 9:21 PM, Lars Kurth wrote:
>
>
> On 13/01/2020, 19:54, "George Dunlap" wrote:
>
>
> > On Dec 30, 2019, at 7:32 PM, Lars Kurth
> wrote:
> >
> > From: Lars Kurth
> >
> > This guide covers the bulk on Best Practice related to code review
> > It
On 14.01.2020 18:03, Julien Grall wrote:
> On 14/01/2020 16:50, Jan Beulich wrote:
>> On 14.01.2020 17:26, Julien Grall wrote:
>>> On 14/01/2020 16:08, Jan Beulich wrote:
On 13.01.2020 22:33, Julien Grall wrote:
> --- a/xen/arch/x86/hvm/irq.c
> +++ b/xen/arch/x86/hvm/irq.c
> @@
On Tue, Jan 14, 2020 at 08:35:45PM +, Andrew Cooper wrote:
> Xen inherited its list infrastructure from Linux. One area where has fallen
> behind is that of prefetching, which as it turns out is a performance penalty
> in most cases.
>
> Prefetch of NULL on x86 is now widely measured to have
While it has been me to introduce this, the use of | there has become
(and perhaps was from the very beginning) misleading. Rather than
avoiding the right side of it when linking the xen.efi intermediate file
at a different base address, make the expression cope with that case,
thus verifying
On 15/01/2020 07:40, David Woodhouse wrote:
On Tue, 2020-01-14 at 16:29 +, Julien Grall wrote:
That's the point in appending an IND_WRITE64 operation to the kimage
stream. The actual write is done in the last gasp of kexec_reloc()
after Xen#1 is quiescent, on the way into purgatory.
I
Hi Stefano,
On 14/01/2020 23:31, Stefano Stabellini wrote:
When booting via EFI, the EFI memory map has information about memory
regions and their type. Improve the check for the type and attribute of
each memory region to figure out whether it is usable memory or not.
This patch brings the
1 - 100 of 114 matches
Mail list logo
