Re: [Xen-devel] [RFC 0/2] x86, vdso, pvclock: Cleanups and speedups

, Acked-by: Paolo Bonzini pbonz...@redhat.com For patch 2 I will defer to Marcelo and Glauber (and the Xen folks). Paolo ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel

Re: [Xen-devel] [RFC 0/2] x86, vdso, pvclock: Cleanups and speedups

On 23/12/2014 09:16, Andy Lutomirski wrote: Any thoughts as to whether it should be tagged for stable? I haven't looked closely enough at the old pvclock code or the generated code to have much of an opinion there. It'll be a big speedup for non-pvclock users at least. Yes, please. Paolo

Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

On 23/12/2014 16:14, Boris Ostrovsky wrote: +do { +version = pvti-version; + +/* This is also a read barrier, so we'll read version first. */ +rdtsc_barrier(); +tsc = __native_read_tsc(); This will cause VMEXIT on Xen with TSC_MODE_ALWAYS_EMULATE

Re: [Xen-devel] [v3 1/5] Qemu-Xen-vTPM: Support for Xen stubdom vTPM command line options

On 31/12/2014 00:02, Quan Xu wrote: Signed-off-by: Quan Xu quan...@intel.com --- configure| 14 ++ hmp.c| 7 +++ qapi-schema.json | 19 --- qemu-options.hx | 13 +++-- tpm.c| 7 ++- 5 files changed, 54

Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

On 05/01/2015 20:17, Marcelo Tosatti wrote: But there is no guarantee that vCPU-N has updated its pvti when vCPU-M resumes guest instruction execution. You're right. So the cost this patch removes is mainly from __getcpu (==RDTSCP?) ? Perhaps you can use Gleb's idea to stick vcpu id into

Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

On 05/01/2015 19:56, Andy Lutomirski wrote: 1) State: all pvtis marked as PVCLOCK_TSC_STABLE_BIT. 1) Update request for all vcpus, for a TSC_STABLE_BIT - ~TSC_STABLE_BIT transition. 2) vCPU-1 updates its pvti with new values. 3) vCPU-0 still has not updated its pvti with new values.

Re: [Xen-devel] [PATCH] xen-pt: Fix PCI devices re-attach failed

On 12/01/2015 14:35, Li, Liang Z wrote: diff --git a/hw/xen/xen_pt.c b/hw/xen/xen_pt.c index c1bf357..f2893b2 100644 --- a/hw/xen/xen_pt.c +++ b/hw/xen/xen_pt.c @@ -736,7 +736,7 @@ static int xen_pt_initfn(PCIDevice *d) } out: -memory_listener_register(s-memory_listener,

Re: [Xen-devel] [v3 5/5] Qemu-Xen-vTPM: QEMU machine class is initialized before tpm_init()

On 31/12/2014 00:03, Quan Xu wrote: make sure QEMU machine class is initialized and QEMU has registered Xen stubdom vTPM driver when call tpm_init() Signed-off-by: Quan Xu quan...@intel.com --- vl.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git

Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

On 06/01/2015 17:56, Andy Lutomirski wrote: Still no good. We can migrate a bunch of times so we see the same CPU all three times There are no three times. The CPU you see here: // ... compute nanoseconds from pvti and tsc ... rmb(); } while(v != pvti-version); is the

Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

On 06/01/2015 19:26, Andy Lutomirski wrote: Don't you stil need: version++; write the rest; version++; with possible smp_wmb() in there to keep the compiler from messing around? No, see my other reply. Separating the version write is a real bug, but that should be all that it's

Re: [Xen-devel] [RFC 2/2] x86, vdso, pvclock: Simplify and speed up the vdso pvclock reader

On 07/01/2015 08:18, Andy Lutomirski wrote: Thus far, I've been told unambiguously that a guest can't observe pvti while it's being written, and I think you're now telling me that this isn't true and that a guest *can* observe pvti while it's being written while the low bit of the

Re: [Xen-devel] ARM: KVM/XEN: how should we support virt-what?

On 25/03/2015 10:44, Andrew Jones wrote: 2) create a specific DT node that will get exposed through sysfs, or somewhere. Looking at custom DT nodes is what PowerPC does. Paolo ___ Xen-devel mailing list Xen-devel@lists.xen.org

Re: [Xen-devel] [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

On 14/05/2015 14:02, Markus Armbruster wrote: It should certainly be off for pc-q35-2.4 and newer. Real Q35 boards commonly don't have an FDC (depends on the Super I/O chip used). We may want to keep it off for pc-i440fx-2.4 and newer. I doubt there's a real i440FX without an

Re: [Xen-devel] [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

On 14/05/2015 14:45, Markus Armbruster wrote: Paolo Bonzini pbonz...@redhat.com writes: On 14/05/2015 14:02, Markus Armbruster wrote: It should certainly be off for pc-q35-2.4 and newer. Real Q35 boards commonly don't have an FDC (depends on the Super I/O chip used). We may want

Re: [Xen-devel] [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

On 14/05/2015 15:25, Sander Eikelenboom wrote: I tend to kindly disagree if you look at the broader perspective, yes it's could be a storm in a tea cup, but there seems to be a pattern. From a cmdline user / platform emulation point of view i can imagine that some sort of auto

Re: [Xen-devel] [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

On 14/05/2015 16:39, Stefano Stabellini wrote: On Thu, 14 May 2015, Paolo Bonzini wrote: On 14/05/2015 15:25, Sander Eikelenboom wrote: I tend to kindly disagree if you look at the broader perspective, yes it's could be a storm in a tea cup, but there seems to be a pattern. From

Re: [Xen-devel] [Qemu-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

On 14/05/2015 13:47, Michael S. Tsirkin wrote: I would be OK with a new property too, as we could set it from libxl or libvirt. Anybody would be happy to pick this one up or should I do it? Pls go ahead, I can merge it in the pc tree. Note that because of the -drive if=none,id=fdd1

Re: [Xen-devel] [PATCH] Do not emulate a floppy drive when -nodefaults

On 15/05/2015 09:50, Markus Armbruster wrote: --nodefaults must continue to disable all optional parts of the board. What exactly is optional is for the board / machine type to define. It can't be changed once the machine type is released. When in doubt, make it optional. I agree

Re: [Xen-devel] [PATCH] Add a property to disable the floppy controller

On 14/05/2015 16:41, Stefano Stabellini wrote: Do not change default settings for any machines at the moment: this patch does not introduce any changes in behavior unless the user asks for no-fdc=on. Can we avoid the double negative? Paolo Signed-off-by: Stefano Stabellini

Re: [Xen-devel] [PATCH] xen-pt: Fix bug cause PCI devices re-attach failed

On 15/04/2015 16:14, Li, Liang Z wrote: Yes, it's the right place. Put aside the bug fix, I think the memory_region_ref/unref pair should be move to xen_pt_region_update after the conditional as you point out. Do you think so? It would make sense, but I was just guessing... I'm still

Re: [Xen-devel] [PATCH] xen-pt: Fix bug cause PCI devices re-attach failed

On 13/04/2015 16:12, Liang Li wrote: 2. Do the attach and detach operation with a time interval. eg. 10s. The error message will not disappear if retry, in this case, it's a bug. In the 'xen_pt_region_add' and 'xen_pt_region_del', we should only care about the

Re: [Xen-devel] qemu mainline regression with xen-unstable: unable to start QMP

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/06/2015 12:11, Stefano Stabellini wrote: Hopefully I will get to a change to Xen. However getting the Xen change back-ported to enough version(s) will not be quick... Yeah, this is basically an ABI breakage. We have been trying to

Re: [Xen-devel] [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API

On 28/07/2015 03:08, Andy Lutomirski wrote: On Mon, Sep 1, 2014 at 10:39 AM, Andy Lutomirski l...@amacapital.net wrote: This fixes virtio on Xen guests as well as on any other platform that uses virtio_pci on which physical addresses don't match bus addresses. This can be tested with:

Re: [Xen-devel] [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API

On 29/07/2015 02:47, Andy Lutomirski wrote: If new kernels ignore the IOMMU for devices that don't set the flag and there are physical devices that already exist and don't set the flag, then those devices won't work reliably on most modern non-virtual platforms, PPC included. Are

Re: [Xen-devel] [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API

On 28/07/2015 12:12, Benjamin Herrenschmidt wrote: That is an experimental feature (it's x-iommu), so it can change. The plan was: - for PPC, virtio never honors IOMMU - for non-PPC, either have virtio always honor IOMMU, or enforce that virtio is not under IOMMU. I

Re: [Xen-devel] [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API

On 28/07/2015 15:11, Jan Kiszka wrote: This doesn't matter much, since the only guests that implement an IOMMU in QEMU are (afaik) PPC and x86, and x86 does not yet promise any kind of stability. Hmm I think Jan (cc) said it was already used out there. Yes, no known issues with

Re: [Xen-devel] [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API

On 28/07/2015 18:42, Jan Kiszka wrote: On the other hand interrupt remapping is absolutely necessary for production use, hence my point that x86 does not promise API stability. Well, we currently implement the features that the Q35 used to expose. Adding interrupt remapping will require

Re: [Xen-devel] [PATCH v4 0/4] virtio: Clean up scatterlists and use the DMA API

On 28/07/2015 19:19, Jan Kiszka wrote: On 2015-07-28 19:15, Paolo Bonzini wrote: On 28/07/2015 18:42, Jan Kiszka wrote: On the other hand interrupt remapping is absolutely necessary for production use, hence my point that x86 does not promise API stability. Well, we currently implement

Re: [Xen-devel] [PATCH] Qemu/Xen: Fix early freeing MSIX MMIO memory region

On 12/10/2015 13:09, Stefano Stabellini wrote: > On Sun, 11 Oct 2015, Lan Tianyu wrote: >> From: > >> >> msix->mmio is added to XenPCIPassthroughState's object as property. >> object_finalize_child_property is called for XenPCIPassthroughState's >> object, which calls

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

On 10/09/2015 16:24, Kevin Davis wrote: > Further leading me to guess that any actual use of those > implementations could lead to you actually needing to hire a real > attorney and not one that you find on YouTube. The good thing is that attorneys have already figured it out. IBM figured out

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 17/09/2015 11:31, Borislav Petkov wrote: > >> > Crashing the bootup on an unknown MSR is bad. Many MSR reads and writes >> > are >> > non-critical and returning the 'safe' result is much better than crashing >> > or >> > hanging the bootup. > ... and prepending all MSR accesses with

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 17/09/2015 10:58, Peter Zijlstra wrote: > But the far greater problem I have with the whole virt thing is that > you cannot use rdmsr_safe() to probe if an MSR exists at all because, as > you told me, these virt thingies return 0 for all 'unknown' MSRs instead > of faulting. At least for

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 17/09/2015 17:26, Andy Lutomirski wrote: > Maybe Paolo can fix QEMU to fail bad MSR accesses for real... I was afraid of someone proposing exactly that. :) I can do it since the list of MSRs can be lifted from KVM. Let's first see the direction these patches go... Paolo

Re: [Xen-devel] [PATCH 0/3] x86/paravirt: Fix baremetal paravirt MSR ops

On 17/09/2015 17:31, Arjan van de Ven wrote: >> >> What about 0 + WARN? > > why 0? > > 0xdeadbeef or any other pattern (even 0x3636363636) makes more sense (of > course also WARN... but most folks don't read dmesg for WARNs) > > (it's the same thing we do for list or slab poison stuff)

Re: [Xen-devel] [PULL 21/29] xen/pt: Sync up the dev.config and data values.

On 15/09/2015 15:28, Stefano Stabellini wrote: > >> > 2). Send an follow up patch to change this to abort()? (and wherever else >> > I used >> > assert(..)? > Yes, that would be good. > > >> > 3). Wait till Paolo is done going through the patchset and then revisit >> > 1) or 2)? > I

Re: [Xen-devel] [PULL 0/19] xen-2015-09-08-tag

On 10/09/2015 12:29, Stefano Stabellini wrote: > +if (lseek(config_fd, pos, SEEK_SET) != pos) { > +return -errno; > +} > do { > -rc = pread(config_fd, (uint8_t *), len, pos); > +rc = read(config_fd, (uint8_t *), len); > } while (rc < 0 && (errno == EINTR

Re: [Xen-devel] [PULL 21/29] xen/pt: Sync up the dev.config and data values.

On 10/09/2015 19:15, Stefano Stabellini wrote: > + > +switch (reg->size) { > +case 1: rc = xen_host_pci_get_byte(>real_device, offset, (uint8_t > *)); A bit ugly, and it relies on the host being little endian. > +break; > +case 2: rc =

Re: [Xen-devel] [edk2] EDK II & GPL - Re: OVMF BoF @ KVM Forum 2015

r Graf <ag...@suse.de>; qemu devel list <qemu-de...@nongnu.org>; Hannes Reinecke <h...@suse.de>; Gabriel L. Somlo (GMail) <gso...@gmail.com>; Peter Jones <pjo...@redhat.com>; Peter Batard <p...@akeo.ie>; Gerd Hoffmann <kra...@redhat.com>; Co

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On 21/09/2015 10:46, Ingo Molnar wrote: > Or we could extend exception table entry encoding to include a 'warning bit', > to > not bloat the kernel. If the exception handler code encounters such an > exception > it would generate a one-time warning for that entry, but otherwise not crash >

Re: [Xen-devel] [PATCH v2 1/2] x86/msr: Carry on after a non-"safe" MSR access fails without !panic_on_oops

On 21/09/2015 19:43, Andy Lutomirski wrote: > And maybe the KVM user return notifier. No, not really. If anything, the place in KVM where it makes a difference is vmx_save_host_state, which is also only using always-present MSRs. But don't care about KVM. First clean it up, then we can add

[Xen-devel] [PATCH] KVM: x86: trap AMD MSRs for the TSeg base and mask

These have roughly the same purpose as the SMRR, which we do not need to implement in KVM. However, Linux accesses MSR_K8_TSEG_ADDR at boot, which causes problems when running a Xen dom0 under KVM. Just return 0, meaning that processor protection of SMRAM is not in effect. Signed-off-by: Paolo

Re: [Xen-devel] rdmsr_safe in Linux PV (under Xen) gets an #GP:Re: [Fedora-xen] Running fedora xen on top of KVM?

On 18/09/2015 15:54, Borislav Petkov wrote: > On Thu, Sep 17, 2015 at 01:23:31PM -0700, Andy Lutomirski wrote: >> > Cc: Borislav. Is TSEG guaranteed to exist? Can we defer that until > Why not? It is the tseg base address. > > I think this is kvm injecting a #GP as it is not ignoring this

Re: [Xen-devel] Regression: Xen guest with 5G of RAM on 32bit fail to boot

On 01/12/2015 18:53, Anthony PERARD wrote: > The problem is in qemu_ram_alloc_internal() where 'size' and 'maxsize' are > now been truncate to 32bit, due to 'qemu_host_page_size' been an uintptr_t > in the HOST_PAGE_ALIGN macro. Isn't it qemu_host_page_mask that causes the problem? This should

Re: [Xen-devel] Regression: Xen guest with 5G of RAM on 32bit fail to boot

On 02/12/2015 11:30, Paolo Bonzini wrote: > diff --git a/include/exec/cpu-all.h b/include/exec/cpu-all.h > index f9998b9..87a4145 100644 > --- a/include/exec/cpu-all.h > +++ b/include/exec/cpu-all.h > @@ -174,11 +174,10 @@ extern unsigned long reserved_va; > #defin

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

On 19/11/2015 09:40, Gerd Hoffmann wrote: >> > But this code should be >> > minor to be maintained in libvirt. > As far I know libvirt only needs to discover those devices. If they > look like sr/iov devices in sysfs this might work without any changes to > libvirt. I don't think they will

Re: [Xen-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

On 19/11/2015 16:32, Stefano Stabellini wrote: > > In addition to Kevin's replies, I have a high-level question: can VFIO > > be used by QEMU for both KVM and Xen? > > No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU > is owned by Xen. I don't think QEMU command line

Re: [Xen-devel] [PATCH v3] xen-hvm: ignore background I/O sections

- Original Message - > From: "Anthony PERARD" <anthony.per...@citrix.com> > To: "Paul Durrant" <paul.durr...@citrix.com> > Cc: qemu-de...@nongnu.org, xen-de...@lists.xenproject.org, "Stefano > Stabellini" <sstabell...@ke

Re: [Xen-devel] [PATCH] exec: Fix qemu_ram_block_from_host for Xen

> block = qemu_get_ram_block(ram_addr); > if (block) { > -*offset = (host - block->host); > +*offset = ram_addr - block->offset; > } > rcu_read_unlock(); > return block; > Acked-by: Paolo Bonzini <pbonz..

Re: [Xen-devel] qemu-upstream compile failure in intel_iommu.c:vtd_context_device_invalidate

On 27/01/2016 19:23, Olaf Hering wrote: > > xen.git/tools/qemu-xen-dir/hw/i386/intel_iommu.c: In function > ‘vtd_context_device_invalidate’: > xen.git/tools/qemu-xen-dir/hw/i386/intel_iommu.c:911:46: error: ‘mask’ may be > used uninitialized in this function [-Werror=maybe-uninitialized] >

Re: [Xen-devel] [PULL 10/11] Add Error **errp for xen_pt_config_init()

On 21/01/2016 18:01, Stefano Stabellini wrote: > -XEN_PT_LOG(>dev, "Failed to initialize %d/%ld reg > 0x%x in grp_type=0x%x (%d/%ld), rc=%d\n", > - j, > ARRAY_SIZE(xen_pt_emu_reg_grps[i].emu_regs), > -

Re: [Xen-devel] [PATCH v3 3/5] x86/paravirt: Add paravirt_{read, write}_msr

On 14/03/2016 18:02, Andy Lutomirski wrote: > On Mon, Mar 14, 2016 at 9:58 AM, Linus Torvalds > wrote: >> >> On Mar 14, 2016 9:53 AM, "Andy Lutomirski" wrote: >>> >>> Can you clarify? KVM uses the native version, and the native version >>>

Re: [Xen-devel] [PATCH v3 3/5] x86/paravirt: Add paravirt_{read, write}_msr

On 14/03/2016 17:53, Andy Lutomirski wrote: > > Please do the same for KVM. > > Can you clarify? KVM uses the native version, and the native version > only oopses with this series applied if panic_on_oops is set. Since you fixed the panic_on_oops thing, I'm okay with letting KVM use the unsafe

Re: [Xen-devel] [PATCH v3 3/5] x86/paravirt: Add paravirt_{read, write}_msr

On 11/03/2016 20:06, Andy Lutomirski wrote: > This adds paravirt hooks for unsafe MSR access. On native, they > call native_{read,write}_msr. On Xen, they use > xen_{read,write}_msr_safe. > > Nothing uses them yet for ease of bisection. The next patch will > use them in rdmsrl, wrmsrl, etc.

Re: [Xen-devel] Does __KERNEL_DS serve a purpose?

On 08/04/2016 18:00, Andy Lutomirski wrote: > But %ss can be loaded with 0 on 64-bit kernels. (I assume that > loading 0 into %ss sets SS.DPL to 0 if done at CPL0, but I'm vague on > this, since it only really matters to hypervisor code AFAIK.) It's even simpler, unless CPL=0 SS cannot be

Re: [Xen-devel] [PATCH] x86, locking: Remove ticket (spin)lock implementation

On 18/05/2016 21:34, Peter Zijlstra wrote: >> I don't know of any enterprise distro that is shipping anything >> > more modern than 4.1? > RHEL 7-- v3.10 > SLES 12 -- v3.12 > Debian Jessie -- v3.16 > Ubuntu 16.04 LTS -- v4.4 > > But

Re: [Xen-devel] Overlaped PIO with multiple ioreq_server (Xen4.6.1)

On 28/04/2016 13:25, Paul Durrant wrote: >> Maybe you are lucky, qemu is registered before your own demu >> emulator. > > I guess I was lucky. Yeah, QEMU has been doing that since 2013 (commit 3bb28b7, "memory: Provide separate handling of unassigned io ports accesses", 2013-09-05). >> I used

Re: [Xen-devel] Overlaped PIO with multiple ioreq_server (Xen4.6.1)

On 09/05/2016 18:14, Paul Durrant wrote: >> -Original Message- >> From: Paul Durrant >> Sent: 09 May 2016 17:02 >> To: Paul Durrant; Paolo Bonzini; Martin Cerveny >> Cc: xen-de...@lists.xensource.com; George Dunlap >> Subject: RE: [Xen-devel] Over

Re: [Xen-devel] [PATCH] xen-hvm: ignore background I/O sections

n_io_add/del so that sections with > memory-region ops pointing at 'unassigned_io_ops' are ignored. > > Signed-off-by: Paul Durrant <paul.durr...@citrix.com> > Cc: Stefano Stabellini <sstabell...@kernel.org> > Cc: Anthony Perard <anthony.per...@citrix.com> > Cc: Paolo Bo

Re: [Xen-devel] Regression with commit 095497ffc66b7f031

On 15/07/2016 10:47, Juergen Gross wrote: > Nothing scaring and no real difference between working and not working > variant. > > Meanwhile I've been digging a little bit deeper and found the reason: > libxenstore is setting up a reader thread which is waiting for the > watch to fire. With

Re: [Xen-devel] Regression with commit 095497ffc66b7f031

On 15/07/2016 12:12, Gerd Hoffmann wrote: > On Fr, 2016-07-15 at 12:02 +0200, Paolo Bonzini wrote: >> >> On 15/07/2016 10:47, Juergen Gross wrote: >>> Nothing scaring and no real difference between working and not working >>> variant. >>> >>&

Re: [Xen-devel] Regression with commit 095497ffc66b7f031

On 15/07/2016 12:41, Juergen Gross wrote: > On 15/07/16 12:35, Paolo Bonzini wrote: >> >> >> On 15/07/2016 12:12, Gerd Hoffmann wrote: >>> On Fr, 2016-07-15 at 12:02 +0200, Paolo Bonzini wrote: >>>> >>>> On 15/07/2016 10:47, Juergen Gro

Re: [Xen-devel] [PATCH v3 4/4] KVM: VMX: Simplify segment_base

> Paolo, how stable, non-rebasing are the KVM tree commits? Whatever ends in linux-next is stable. I have a separate rebasing branch, but it's not part of linux-next by design. > Or should we keep Andy's KVM patches together with the GDT patches? Either > workflow works for me - it's your call

Re: [Xen-devel] [PATCH v5 0/2] x86/kvm: Reduce vcpu_is_preempted() overhead

On 20/02/2017 20:54, Peter Zijlstra wrote: > On Mon, Feb 20, 2017 at 01:36:02PM -0500, Waiman Long wrote: >> Waiman Long (2): >> x86/paravirt: Change vcp_is_preempted() arg type to long >> x86/kvm: Provide optimized version of vcpu_is_preempted() for x86-64 >> >>

Re: [Xen-devel] [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

o init functions due to us > * using paravirt patching and jump labels patching and having to do > @@ -138,7 +136,7 @@ void __init xen_init_spinlocks(void) > pv_lock_ops.queued_spin_unlock = > PV_CALLEE_SAVE(__pv_queued_spin_unlock); > pv_lock_ops.wait = xen_qlock_wait; > pv_lock_ops.kick = xen_qlock_kick; > - pv_lock_ops.vcpu_is_preempted = PV_CALLEE_SAVE(xen_vcpu_stolen); > + pv_lock_ops.vcpu_is_preempted = xen_vcpu_stolen; > } > > static __init int xen_parse_nopvspin(char *arg) > Acked-by: Paolo Bonzini <pbonz...@redhat.com> Thank you very much! Paolo ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel

Re: [Xen-devel] [PATCH 0/2] Xen HVM unplug changes

On 01/09/2016 14:11, Olaf Hering wrote: > Update unplug in Xen HVM guests to cover more cases. > Please review. > > Olaf > > Olaf Hering (2): > xen_platform: unplug also SCSI disks > xen_platform: SUSE xenlinux unplug for emulated PCI > > hw/i386/xen/xen_platform.c | 36

Re: [Xen-devel] [PATCH 15/15] xen: Rename xen_be_frontend_changed

On 04/10/2016 08:43, Emil Condrea wrote: > xen_be_frontend_changed -> xen_fe_frontend_changed This is not correct. The front-end is implemented in the guest domain, while the back-end is implemented in the dom0 or stubdom. This function processes *in the backed* a notification that the

Re: [Xen-devel] [PATCH 15/15] xen: Rename xen_be_frontend_changed

On 04/10/2016 10:06, Paolo Bonzini wrote: > > > On 04/10/2016 08:43, Emil Condrea wrote: >> xen_be_frontend_changed -> xen_fe_frontend_changed > > This is not correct. The front-end is implemented in the guest domain, > while the back-end is impleme

Re: [Xen-devel] [PATCH v6 00/11] implement vcpu preempted check

On 28/10/2016 10:11, Pan Xinhui wrote: > change from v5: > spilt x86/kvm patch into guest/host part. > introduce kvm_write_guest_offset_cached. > fix some typos. > rebase patch onto 4.9.2 Acked-by: Paolo Bonzini <pbonz...@redhat.com> Thanks, Pa

Re: [Xen-devel] [PATCH 15/15] xen: Rename xen_be_frontend_changed

On 09/10/2016 21:50, Emil Condrea wrote: > On Tue, Oct 4, 2016 at 11:06 AM, Paolo Bonzini <pbonz...@redhat.com> wrote: >> >> >> On 04/10/2016 08:43, Emil Condrea wrote: >>> xen_be_frontend_changed -> xen_fe_frontend_changed >> >> This is not

Re: [Xen-devel] [PATCH 15/15] xen: Rename xen_be_frontend_changed

> So we are better leave it as is. Maybe we need to rename some functions in > that file. > __iirc__ adding xen_frontend.c is one of Stefano's comments in previous v6 > or v7.. I agree; it's quite possible that code can be shared between backend and frontend (renaming functions as needed), and

Re: [Xen-devel] [RFC 0/7] Move accel, KVM, Xen, qtest files to accel/ subdir

aybe a sysemu/ subdir? In that case, should we still create an > accel/ subdir, or move xen-*, kvm-* and friends to sysemu/ too? > > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: k...@vger.kernel.org > Cc: Christoffer Dall <christoffer.d...@linaro.org> > C

Re: [Xen-devel] [RFC 0/7] Move accel, KVM, Xen, qtest files to accel/ subdir

On 21/12/2016 15:15, Eduardo Habkost wrote: >> >> ifeq ($(CONFIG_SOFTMMU),y) >> obj-$(CONFIG_KVM) += kvm-all.c >> obj-$(call lnot, $(CONFIG_KVM)) += kvm-stub.c >> endif >> >> similar to what is done already in Makefile.objs? > I assume you mean: > > ifeq ($(CONFIG_SOFTMMU),y) >

Re: [Xen-devel] [RFC 0/7] Move accel, KVM, Xen, qtest files to accel/ subdir

On 21/12/2016 14:14, Eduardo Habkost wrote: > On Wed, Dec 21, 2016 at 12:21:44PM +0100, Paolo Bonzini wrote: >> >> >> On 20/12/2016 18:43, Eduardo Habkost wrote: >>> This moves the KVM and Xen files to the an accel/ subdir. >>> >>> Instead of mo

Re: [Xen-devel] [PATCH v4 1/8] xen: import ring.h from xen

On 29/03/2017 01:54, Stefano Stabellini wrote: >>> I understand your point of view, and honestly it wouldn't be a problem >>> doing it the way you suggested either. However, I think that going >>> forward it will be less of a maintenance pain to keep ring.h in sync, >>> compared to maintaining a

Re: [Xen-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

On 20/03/2017 03:40, Lan Tianyu wrote: >>> Xen only supports emulated I440 and so we enable vIOMMU with emulated >>> I440 chipset. This works on Linux and Windows guest. >> Any plans to change this? Why is Xen not able to use Q35 with Intel >> IOMMU, with only special hooks for interrupt

Re: [Xen-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

On 20/03/2017 15:17, Roger Pau Monné wrote: >>> Hi Paolo: >>> Thanks for review. For Xen side, we won't reuse Intel IOMMU device model >>> in Qemu and create counterpart in Xen hypervisor. The reasons are >>> 1) Avoid round trips between Qemu and Xen hypervisor >>> 2) Ease of integration with

Re: [Xen-devel] [PATCH v3 1/9] xen: do not build backends for targets that do not support xen

On 16/03/2017 21:01, Stefano Stabellini wrote: > Change Makefile.objs to use CONFIG_XEN instead of CONFIG_XEN_BACKEND, so > that the Xen backends are only built for targets that support Xen. > > Set CONFIG_XEN in the toplevel Makefile to ensure that files that are > built only once pick up Xen

Re: [Xen-devel] [RFC PATCH 0/4] Qemu: Add Xen vIOMMU support

On 17/03/2017 12:29, Lan Tianyu wrote: > This patchset is to add Xen vIOMMU device model and handle > irq remapping stuffs. Xen vIOMMU emulation is in the Xen hypervisor > and the new device module in Qemu works as hypercall wrappers to > create and destroy vIOMMU in hypervisor. > > Xen only

Re: [Xen-devel] [PATCH v2 1/9] configure: change CONFIG_XEN_BACKEND to be a target property

On 14/03/2017 21:23, Stefano Stabellini wrote: > On Tue, 14 Mar 2017, Stefano Stabellini wrote: >>> Then you add to Makefile: >>> >>> CONFIG_SOFTMMU := $(if $(filter %-softmmu,$(TARGET_DIRS)),y) >>> CONFIG_USER_ONLY := $(if $(filter %-user,$(TARGET_DIRS)),y) >>> +CONFIG_XEN :=

Re: [Xen-devel] [PATCH v2 1/9] configure: change CONFIG_XEN_BACKEND to be a target property

On 14/03/2017 00:55, Stefano Stabellini wrote: > CONFIG_XEN_BACKEND is currently set when the host supports Xen, > regardless of the chosen targets. As a consequence, Xen backends can be > enabled even on targets that don't support Xen. > > Fix the issue by setting CONFIG_XEN_BACKEND only for

Re: [Xen-devel] [Qemu-devel] [PATCH v2 2/6] qdict: Add convenience helpers for wrapped puts

again, Eric, are you using the scripts/cocci-macro-file.h? commit 6ad978e9f40d3edfd9f4a86b4a60e3523eff08fe Author: Paolo Bonzini <pbonz...@redhat.com> Date: Wed May 18 11:11:55 2016 +0200 coccinelle: add g_assert_cmp* to macro file This helps applying semantic patch

Re: [Xen-devel] [PATCH] x86: Skip check apic_id_limit for Xen

On 16/08/2017 02:22, Lan Tianyu wrote: > Xen vIOMMU device model will be in Xen hypervisor. Skip vIOMMU > check for Xen here when vcpu number is more than 255. I think you still need to do a check for vIOMMU being enabled. Paolo > Signed-off-by: Lan Tianyu > --- >

Re: [Xen-devel] [PATCH v2 0/3] Qemu: Add Xen vIOMMU interrupt remapping function support

On 09/08/2017 22:51, Lan Tianyu wrote: > This patchset is to deal with MSI interrupt remapping request when guest > updates MSI registers. > > Chao Gao (3): > i386/msi: Correct mask of destination ID in MSI address > xen-pt: bind/unbind interrupt remapping format MSI > msi: Handle

Re: [Xen-devel] QEMU commit 04bf2526ce breaks use of xen-mapcache

> Hi, > > Commits 04bf2526ce (exec: use qemu_ram_ptr_length to access guest ram) > start using qemu_ram_ptr_length() instead of qemu_map_ram_ptr(). > That result in calling xen_map_cache() with lock=true, but this mapping > is never invalidated. > So QEMU use more and more RAM until it stop

Re: [Xen-devel] QEMU commit 04bf2526ce breaks use of xen-mapcache

- Original Message - > From: "Stefano Stabellini" <sstabell...@kernel.org> > To: "Paolo Bonzini" <pbonz...@redhat.com> > Cc: "Anthony PERARD" <anthony.per...@citrix.com>, "Stefano Stabellini" > <sstabell...@kern

Re: [Xen-devel] QEMU commit 04bf2526ce breaks use of xen-mapcache

> > Thanks---however, after re-reading xen-mapcache.c, dma needs to be false > > for unlocked mappings. > > If there is a DMA operation already in progress, it means that we'll > already have a locked mapping for it. Yes, I only wanted to say that qemu_ram_ptr_length should pass dma=false when

Re: [Xen-devel] [PATCH] x86: Skip check apic_id_limit for Xen

On 18/08/2017 18:38, Eduardo Habkost wrote: >>> I think you still need to do a check for vIOMMU being enabled. >> >> Yes, this will be done in the Xen tool stack and Qemu doesn't have such >> knowledge. Operations of create, destroy Xen vIOMMU will be done in the >> Xen tool stack. > > Shouldn't

Re: [Xen-devel] [PATCH v2 2/3] Check the return value of fcntl in qemu_set_cloexec

On 09/05/2017 21:04, Stefano Stabellini wrote: > Assert that the return value is not an error. This issue was found by > Coverity. > > CID: 1374831 > > Signed-off-by: Stefano Stabellini > CC: gr...@kaod.org > CC: pbonz...@redhat.com > CC: Eric Blake

Re: [Xen-devel] [PATCH 3/3] xen-disk: use an IOThread per instance

On 20/06/2017 15:47, Paul Durrant wrote: > This patch allocates an IOThread object for each xen_disk instance and > sets the AIO context appropriately on connect. This allows processing > of I/O to proceed in parallel. > > The patch also adds tracepoints into xen_disk to make it possible to >

Re: [Xen-devel] [PATCH RFC] xen/mapcache: store dma information in revmapcache entries for debugging

tr are assumed to be [a], while > mappings created by address_space_map->qemu_ram_ptr_length are assumed > to be [b]. > > The goal of the patch is to make debugging and system understanding > easier. Sure, why not. Acked-by: Paolo Bonzini <pbonz...@redhat.com> Paolo > Signed-off-b

Re: [Xen-devel] [PATCH] x86: convert x86_platform_ops to timespec64

On 16/10/2017 10:11, Arnd Bergmann wrote: > Thanks! > > Since you've looked at it overall, do you have an opinion on the question > how to fix the PV interface to deal with the pvclock_wall_clock overflow? It has to be done separately for each hypervisor. In KVM, for example, it is probably

Re: [Xen-devel] [PATCH] x86: convert x86_platform_ops to timespec64

On 16/10/2017 14:16, Arnd Bergmann wrote: > On Mon, Oct 16, 2017 at 2:08 PM, Paolo Bonzini <pbonz...@redhat.com> wrote: >> On 16/10/2017 10:11, Arnd Bergmann wrote: >>> Thanks! >>> >>> Since you've looked at it overall, do you have an opinion on the questi

Re: [Xen-devel] [Qemu-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest

On 14/10/2017 00:46, Stefano Stabellini wrote: > On Fri, 13 Oct 2017, Jan Beulich wrote: > On 13.10.17 at 13:13, wrote: >>> To Jan, Andrew, Stefano and Anthony, >>> >>> what do you think about allowing QEMU to build the entire guest ACPI >>> and letting SeaBIOS to

Re: [Xen-devel] [Qemu-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest

On 12/10/2017 14:45, Haozhong Zhang wrote: > Basically, QEMU builds two ROMs for guest, /rom@etc/acpi/tables and > /rom@etc/table-loader. The former is unstructured to guest, and > contains all data of guest ACPI. The latter is a BIOSLinkerLoader > organized as a set of commands, which direct the

Re: [Xen-devel] KVM PV (was: Re: [PATCH v2 2/2] x86/lguest: remove lguest support)

- Lai Jiangshan <jiangshanlai+l...@gmail.com> ha scritto: > On Sat, Sep 30, 2017 at 12:39 AM, Paolo Bonzini <pbonz...@redhat.com> wrote: > > On 29/09/2017 17:47, Lai Jiangshan wrote: > >> Hello, all > >> > >> An interesting (at

Re: [Xen-devel] KVM PV

On 02/10/2017 12:36, George Dunlap wrote: >>> Although I'm not business man, I don't think the top cloud provider[s] >>> would allow nested virtualization, however mature nested virtualization >>> is. Even xen-pv is unable to be nested in the aws and azure. >> >> Check the contributors to KVM

Re: [Xen-devel] KVM PV (was: Re: [PATCH v2 2/2] x86/lguest: remove lguest support)

On 29/09/2017 17:47, Lai Jiangshan wrote: > Hello, all > > An interesting (at least to me) thinking came up to me when I found > that the lguest was removed. But I don't have enough knowledge > to find out the answer nor energy to implement it in some time. > > Is it possible to implement kvm-pv

Re: [Xen-devel] [PATCH v4 3/3] MAINTAINERS: xen, kvm: track pvclock-abi.h changes

ross <jgr...@suse.com> > > Reviewed-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com> Acked-by: Paolo Bonzini <pbonz...@redhat.com> >> --- >> In the end, I choose the originally posted because this is so far the >> only ABI shared between Xen/KVM.

Re: [Xen-devel] [Qemu-devel] [RFC QEMU PATCH v3 00/10] Implement vNVDIMM for Xen HVM guest

On 18/10/2017 10:32, Roger Pau Monné wrote: >> I'll have a try to check how much the differences would affect. If it >> would not take too much work, I'd like to adapt Xen NVDIMM enabling >> patches to the all QEMU built ACPI. Otherwise, I'll fall back to Paolo >> and MST's suggestions. > I don't

Re: [Xen-devel] [PATCH v2 2/2] x86: convert x86_platform_ops to timespec64

(version != wall_clock->version)); > > delta = pvclock_clocksource_read(vcpu_time);/* time since system > boot */ > - delta += now.tv_sec * (u64)NSEC_PER_SEC + now.tv_nsec; > + delta += now.tv_sec * NSEC_PER_SEC + now.tv_nsec; > > now.tv_nsec = do_div(delt

  1   2   >