Re: [PATCH] x86/paravirt: use %rip-relative addressing in hook calls

On 05.10.2021 09:43, Juergen Gross wrote: > On 30.09.21 14:40, Jan Beulich via Virtualization wrote: >> While using a plain (constant) address works, its use needlessly invokes >> a SIB addressing mode, making every call site one byte larger than >> necessary. Instead of us

[PATCH] x86/paravirt: use %rip-relative addressing in hook calls

nt, which the 64-bit compiler will translate to %rip-relative addressing. This way we also tell the compiler the truth about operand usage - the memory location gets actually read, after all. 32-bit code generation is unaffected by the change. Signed-off-by: Jan Beulich --- a/arch/x86/include/asm/pa

Re: [PATCH] x86/ioperm: add new paravirt function update_io_bitmap

ir I/O bitmaps via a >>> hypercall. >>> >>> Fixes: 111e7b15cf10f6 ("x86/ioperm: Extend IOPL config to control ioperm() >>> as well") >>> Reported-by: Jan Beulich >>> Cc: # 5.5 >>> Signed-off-by: Juergen Gross >>> Reviewe

Re: [Xen-devel] [PATCH 0/2] Remove 32-bit Xen PV guest support

On 15.07.2019 19:28, Andy Lutomirski wrote: > On Mon, Jul 15, 2019 at 9:34 AM Andi Kleen wrote: >> >> Juergen Gross writes: >> >>> The long term plan has been to replace Xen PV guests by PVH. The first >>> victim of that plan are now 32-bit PV guests, as those are used only >>> rather seldom

[PATCH RESEND] x86-64: use RIP-relative calls for paravirt indirect ones

This saves one insn byte per instance, summing up to a savings of over 4k in my (stripped down) configuration. No variant of to be patched in replacement code relies on the one byte larger size. Signed-off-by: Jan Beulich Reviewed-by: Juergen Gross --- Resend to include x86 maintainers, who

Re: [Xen-devel] [PATCH 04/10] x86/paravirt: use a single ops structure

>>> On 10.08.18 at 13:52, wrote: > --- a/arch/x86/hyperv/mmu.c > +++ b/arch/x86/hyperv/mmu.c > @@ -228,9 +228,9 @@ void hyperv_setup_mmu_ops(void) > > if (!(ms_hyperv.hints & HV_X64_EX_PROCESSOR_MASKS_RECOMMENDED)) { > pr_info("Using hypercall for remote TLB flush\n"); > -

[PATCH] x86-64: use RIP-relative calls for paravirt indirect ones

This saves one insn byte per instance, summing up to a savings of over 4k in my (stripped down) configuration. No variant of to be patched in replacement code relies on the one byte larger size. Signed-off-by: Jan Beulich --- arch/x86/include/asm/paravirt_types.h |6 ++ 1 file changed

Re: [Xen-devel] [PATCH v2 5/6] virt, sched: add cpu pinning to smp_call_sync_on_phys_cpu()

>>> On 21.03.16 at 13:24, wrote: > @@ -758,9 +759,14 @@ struct smp_sync_call_struct { > static void smp_call_sync_callback(struct work_struct *work) > { > struct smp_sync_call_struct *sscs; > + unsigned int cpu = smp_processor_id(); So this obtains the vCPU number,

Re: [Xen-devel] kasan_map_early_shadow() on Xen

On 03.03.15 at 10:40, mcg...@suse.com wrote: Let's go down the rabbit hole for a bit. HAVE_ARCH_KASAN will be selected on x86 when: if X86_64 SPARSEMEM_VMEMMAP Now Xen should not have SPARSEMEM_VMEMMAP Why would that be? Jan ___

Re: [Xen-devel] [PATCH] xen: remove unused Kconfig parameter

On 09.07.13 at 02:26, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: Could you explain to me please why the check in the scripts is superfluous? This is not really the question - _any_ such check can only be wrong. The boot loader has absolutely no business caring about kernel internals,

Re: [Xen-devel] [PATCH] xen: remove unused Kconfig parameter

On 09.07.13 at 16:48, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: Dom0 has been both - but there is nothing wrong with seperating these two labels. And therein I was thinking that the 'hardware backend domain' should be the introduced. I am not good with names so the best option seems

Re: [PATCH 2/2] xen: remove bm_rld_set of xen_processor_flags

On 04.06.13 at 10:05, liguang lig.f...@cn.fujitsu.com wrote: bm_rld_set seems obsolete now Signed-off-by: liguang lig.f...@cn.fujitsu.com --- include/xen/interface/platform.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/include/xen/interface/platform.h

Re: [PATCH] xen-pciback: fix error return code in pcistub_irq_handler_switch()

. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Acked-by: Jan Beulich jbeul...@suse.com ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [Xen-devel] Readonly GDT

On 10.04.13 at 02:43, H. Peter Anvin h...@zytor.com wrote: OK, thinking about the GDT here. The GDT is quite small -- 256 bytes on i386, 128 bytes on x86-64. As such, we probably don't want to allocate a full page to it for only that. This means that in order to create a readonly mapping

Re: [PATCH v3 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE

On 04.01.13 at 18:25, Daniel Kiper daniel.ki...@oracle.com wrote: Right, so where is virtual mapping of control page established? I could not find relevant code in SLES kernel which does that. In the hypervisor (xen/arch/x86/machine_kexec.c:machine_kexec_load()).

Re: [PATCH v3 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE

On 07.01.13 at 13:52, Daniel Kiper daniel.ki...@oracle.com wrote: On Mon, Jan 07, 2013 at 09:48:20AM +, Jan Beulich wrote: On 04.01.13 at 18:25, Daniel Kiper daniel.ki...@oracle.com wrote: Right, so where is virtual mapping of control page established? I could not find relevant code

Re: [PATCH] drivers/xen: avoid out-of-range write in xen_add_device

On 07.01.13 at 16:08, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Sat, Jan 05, 2013 at 02:18:46PM -0500, Nickolai Zeldovich wrote: xen_add_device() in drivers/xen/pci.c allocates a struct physdev_pci_device_add on the stack and then writes to optarr[0]. The previous declaration of

Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation

On 04.01.13 at 15:22, Daniel Kiper daniel.ki...@oracle.com wrote: On Wed, Jan 02, 2013 at 11:26:43AM +, Andrew Cooper wrote: /sbin/kexec can load the Xen crash kernel itself by issuing hypercalls using /dev/xen/privcmd. This would remove the need for the dom0 kernel to distinguish

Re: [PATCH v3 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE

On 04.01.13 at 16:15, Daniel Kiper daniel.ki...@oracle.com wrote: On Thu, Jan 03, 2013 at 09:34:55AM +, Jan Beulich wrote: On 27.12.12 at 03:18, Daniel Kiper daniel.ki...@oracle.com wrote: Some implementations (e.g. Xen PVOPS) could not use part of identity page table to construct

Re: [Xen-devel] [PATCH v3 00/11] xen: Initial kexec/kdump implementation

On 02.01.13 at 12:26, Andrew Cooper andrew.coop...@citrix.com wrote: On 27/12/12 18:02, Eric W. Biederman wrote: It probably make sense to split them apart a little even. Thinking about this split, there might be a way to simply it even more. /sbin/kexec can load the Xen crash kernel

Re: [PATCH v3 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE

On 27.12.12 at 03:18, Daniel Kiper daniel.ki...@oracle.com wrote: Some implementations (e.g. Xen PVOPS) could not use part of identity page table to construct transition page table. It means that they require separate PUDs, PMDs and PTEs for virtual and physical (identity) mapping. To

Re: [PATCH v2 01/11] kexec: introduce kexec_ops struct

On 22.11.12 at 18:37, H. Peter Anvin h...@zytor.com wrote: I actually talked to Ian Jackson at LCE, and mentioned among other things the bogosity of requiring a PUD page for three-level paging in Linux -- a bogosity which has spread from Xen into native. It's a page wasted for no good

Re: [PATCH v2 01/11] kexec: introduce kexec_ops struct

On 23.11.12 at 11:37, Daniel Kiper daniel.ki...@oracle.com wrote: On Fri, Nov 23, 2012 at 09:53:37AM +, Jan Beulich wrote: On 23.11.12 at 02:56, Andrew Cooper andrew.coop...@citrix.com wrote: On 23/11/2012 01:38, H. Peter Anvin wrote: I still don't really get why it can't be isolated

Re: [PATCH v2 02/11] x86/kexec: Add extra pointers to transition page table PGD, PUD, PMD and PTE

On 20.11.12 at 16:04, Daniel Kiper daniel.ki...@oracle.com wrote: Some implementations (e.g. Xen PVOPS) could not use part of identity page table to construct transition page table. It means that they require separate PUDs, PMDs and PTEs for virtual and physical (identity) mapping. To

Re: [Xen-devel] linux-next: Tree for Oct 24 (xen)

On 25.10.12 at 15:46, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote: On Thu, Oct 25, 2012 at 11:48:30AM +0100, Stefano Stabellini wrote: On Thu, 25 Oct 2012, Jan Beulich wrote: On 24.10.12 at 23:33, Randy Dunlap rdun...@xenotime.net wrote: On 10/23/2012 09:19 PM, Stephen Rothwell

Re: [Xen-devel] potential integer overflow in xenbus_file_write()

On 15.10.12 at 12:25, Ian Campbell ian.campb...@citrix.com wrote: On Thu, 2012-09-13 at 19:00 +0300, Dan Carpenter wrote: Hi, Thanks Dan. I'm not sure anyone from Xen-land really monitors virtualization@. Adding xen-devel and Konrad. I was reading some code and had a question in

Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()

On 15.10.12 at 12:27, Ian Campbell ian.campb...@citrix.com wrote: My static analyzer complains about potential memory corruption in HYPERVISOR_physdev_op() arch/x86/include/asm/xen/hypercall.h 389 static inline int 390 HYPERVISOR_physdev_op(int cmd, void *arg) 391 { 392

Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()

On 15.10.12 at 12:27, Ian Campbell ian.campb...@citrix.com wrote: On Fri, 2012-09-14 at 14:24 +0300, Dan Carpenter wrote: My static analyzer complains about potential memory corruption in HYPERVISOR_physdev_op() arch/x86/include/asm/xen/hypercall.h 389 static inline int 390

Re: [Xen-devel] memory corruption in HYPERVISOR_physdev_op()

On 15.10.12 at 12:58, Ian Campbell ian.campb...@citrix.com wrote: On Mon, 2012-10-15 at 11:48 +0100, Jan Beulich wrote: On 15.10.12 at 12:27, Ian Campbell ian.campb...@citrix.com wrote: On Fri, 2012-09-14 at 14:24 +0300, Dan Carpenter wrote: My static analyzer complains about potential

Re: [Xen-devel] [patch 3/3] xen/privcmd: remove const modifier from declaration

On 08.09.12 at 11:58, Dan Carpenter dan.carpen...@oracle.com wrote: When we use this pointer, we cast away the const modifier and modify the data. I think it was an accident to declare it as const. NAK - the const is very valid here, as the v2 interface (as opposed to the v1 one) does _not_

Re: [Xen-devel] [PATCH 05/27] xen, cpu hotplug: Don't call cpu_bringup() in xen_play_dead()

On 01.06.12 at 11:11, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead() is invoked in the cpu down path, whereas cpu_bringup() (as the name suggests) is useful in the cpu bringup path. This might not be

Re: [Xen-devel] [PATCH 05/27] xen, cpu hotplug: Don't call cpu_bringup() in xen_play_dead()

On 01.06.12 at 17:13, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: On 06/01/2012 06:29 PM, Jan Beulich wrote: On 01.06.12 at 11:11, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: xen_play_dead calls cpu_bringup() which looks weird, because xen_play_dead() is invoked

Re: [Xen-devel] [PATCH RFC V8 0/17] Paravirtualized ticket spinlocks

On 07.05.12 at 19:25, Ingo Molnar mi...@kernel.org wrote: (apologies for the late reply, the mail just now made it to my inbox via xen-devel) I'll hold off on the whole thing - frankly, we don't want this kind of Xen-only complexity. If KVM can make use of PLE then Xen ought to be able to

Re: [Xen-devel] [PATCH 0001/001] xen: multi page ring support for block devices

On 14.03.12 at 18:17, Justin T. Gibbs gi...@scsiguy.com wrote: On Mar 6, 2012, at 1:34 AM, Jan Beulich wrote: On 05.03.12 at 22:49, Santosh Jodh santosh.j...@citrix.com wrote: … + } + /* Create shared ring, alloc event channel. */ err = setup_blkring(dev, info

Re: [Xen-devel] [PATCH 0001/001] xen: multi page ring support for block devices

On 14.03.12 at 07:32, Justin Gibbs just...@spectralogic.com wrote: There's another problem here that I brought up during the Xen Hack-a-thon. The ring macros require that the ring element count be a power of two. This doesn't mean that the ring will be a power of 2 pages in size. To

Re: [Xen-devel] [PATCH 0001/001] xen: multi page ring support for block devices

On 14.03.12 at 07:32, Justin Gibbs just...@spectralogic.com wrote: There's another problem here that I brought up during the Xen Hack-a-thon. The ring macros require that the ring element count be a power of two. This doesn't mean that the ring will be a power of 2 pages in size. To

Re: [Xen-devel] [PATCH 0001/001] xen: multi page ring support for block devices

On 06.03.12 at 18:20, Konrad Rzeszutek Wilk kon...@darnok.org wrote: - the usage of XenbusStateInitWait? Why do we introduce that? Looks like a fix to something. No, this is required to get the negotiation working (the frontend must not try to read the new nodes until it can be certain that

Re: [PATCH 0001/001] xen: multi page ring support for block devices

On 05.03.12 at 22:49, Santosh Jodh santosh.j...@citrix.com wrote: Could this be split up into 3 patches, for easier reviewing: - one adjusting the xenbus interface to allow for multiple ring pages (and maybe even that one should be split into the backend and frontend related parts), syncing

Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy

On 20.02.12 at 11:35, Andrew Jones drjo...@redhat.com wrote: - Original Message - On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote: On Thu, Feb 16, 2012 at 12:33:32PM -0500, Andrew Jones wrote: Hmm, I should maybe self-nack this. The bug that led me to writing

Re: [Xen-devel] [PATCH] blkfront: don't change to closing if we're busy

On 21.02.12 at 10:23, Andrew Jones drjo...@redhat.com wrote: On 20.02.12 at 11:35, Andrew Jones drjo...@redhat.com wrote: On Fri, Feb 17, 2012 at 05:52:54PM +0100, Andrew Jones wrote: There was another fix that sounds similar to this in the backend.

[Xen-devel] Re: [PATCH] xen: drop anti-dependency on X86_VISWS

On 08.04.11 at 17:25, Jeremy Fitzhardinge jer...@goop.org wrote: On 04/07/2011 11:38 PM, Ian Campbell wrote: Is there any downside to this patch (is X86_CMPXCHG in the same sort of boat?) Only if we don't use cmpxchg in shared memory with other domains or the hypervisor. (I don't think it

Re: [PATCH 13/14] x86/ticketlock: add slowpath logic

On 19.01.11 at 19:55, Jeremy Fitzhardinge jer...@goop.org wrote: On 01/19/2011 10:39 AM, Srivatsa Vaddagiri wrote: I have tested quite extensively with booting a 16-vcpu guest (on a 16-pcpu host) and running kernel compine (with 32-threads). Without this patch, I had difficulty

Re: [PATCH 09/14] xen/pvticketlock: Xen implementation for PV ticket locks

On 16.11.10 at 22:08, Jeremy Fitzhardinge jer...@goop.org wrote: +static void xen_lock_spinning(struct arch_spinlock *lock, unsigned want) { - struct xen_spinlock *xl = (struct xen_spinlock *)lock; - struct xen_spinlock *prev; int irq = __get_cpu_var(lock_kicker_irq); -

Re: [PATCH 13/14] x86/ticketlock: add slowpath logic

On 16.11.10 at 22:08, Jeremy Fitzhardinge jer...@goop.org wrote: +static inline void __ticket_enter_slowpath(struct arch_spinlock *lock) +{ + if (sizeof(lock-tickets.tail) == sizeof(u8)) + asm (LOCK_PREFIX orb %1, %0 + : +m (lock-tickets.tail) +

Re: [PATCH 13/14] x86/ticketlock: add slowpath logic

On 17.11.10 at 10:08, Jeremy Fitzhardinge jer...@goop.org wrote: On 11/17/2010 12:56 AM, Jeremy Fitzhardinge wrote: On 11/17/2010 12:52 AM, Jeremy Fitzhardinge wrote: But, yes, %z0 sounds interesting. Is it documented anywhere? I think I've tried to use it in the past and run into gcc bugs.

Re: [Xen-devel] Re: [PATCH 09/14] xen/pvticketlock: Xen implementation for PV ticket locks

On 17.11.10 at 10:57, Jeremy Fitzhardinge jer...@goop.org wrote: On 11/17/2010 12:52 AM, Jeremy Fitzhardinge wrote: On 11/17/2010 12:11 AM, Jan Beulich wrote: On 16.11.10 at 22:08, Jeremy Fitzhardinge jer...@goop.org wrote: +static void xen_lock_spinning(struct arch_spinlock *lock, unsigned

Re: [Xen-devel] Re: Next steps with pv_ops for Xen

It breaks with: Intel machine check architecture supported. (XEN) traps.c:1734:d0 Domain attempted WRMSR 0404 from :0001 to :. Intel machine check reporting enabled on CPU#0. general protection fault: [#1] SMP Modules linked in: Hm. Looks like

Re: [Xen-devel] Re: Next steps with pv_ops for Xen

The oops and backtrace doesn't suggest it's an MSR write. Does a crX Oh, right, the MSR write is being ignored, not failed. write take the same path through the emulator as an MSR write? No, the two operations take different paths. Jan ___

Re: [Xen-devel] [patch 21/33] xen: Xen SMP guest support

--- a/arch/i386/xen/time.c +++ b/arch/i386/xen/time.c @@ -105,17 +105,15 @@ static void get_runstate_snapshot(struct preempt_enable(); } -static void setup_runstate_info(void) +static void setup_runstate_info(int cpu) { struct vcpu_register_runstate_memory_area area; -

Re: [Xen-devel] [patch 14/33] xen: xen time implementation

Andi Kleen [EMAIL PROTECTED] 06.06.07 14:18 Yes, this could be an issue. Is there any way to get an interrupt or MCE when thermal throttling occurs? Yes you can get an thermal interrupt from the local APIC. See the Linux kernel source. Of course there would be still a race window. On the

Re: [patch 1/2] Relocate VDSO ELF headers to match mapped location with COMPAT_VDSO

+static __cpuinit void reloc_dyn(Elf32_Ehdr *ehdr, unsigned offset) +{ + Elf32_Dyn *dyn = (void *)ehdr + offset; + + for(; dyn-d_tag != DT_NULL; dyn++) + switch(dyn-d_tag) { + case DT_PLTGOT: + case DT_HASH: + case DT_STRTAB: +

Re: [patch 1/2] Relocate VDSO ELF headers to match mapped location with COMPAT_VDSO

Jeremy Fitzhardinge [EMAIL PROTECTED] 05.04.07 09:31 Jan Beulich wrote: While there's a certain level of control on what DT_* may appear in the vDSO, not even considering other than the above types seems fragile to me. Since future additions to the set are supposedly following a fixed scheme

Re: [patch 1/2] Relocate VDSO ELF headers to match mapped location with COMPAT_VDSO

+ for(; dyn-d_tag != DT_NULL; dyn++) + switch(dyn-d_tag) { + case DT_PLTGOT: + case DT_HASH: + case DT_STRTAB: + case DT_SYMTAB: + case DT_RELA: + case DT_INIT: + case DT_FINI: +