Re: [PATCH v3 0/6] KVM: MMU: fast invalidate all mmio sptes
On Thu, 13 Jun 2013 21:08:21 -0300 Marcelo Tosatti wrote: > On Fri, Jun 07, 2013 at 04:51:22PM +0800, Xiao Guangrong wrote: > - Where is the generation number increased? Looks like when a new slot is installed in update_memslots() because it's based on slots->generation. This is not restricted to "create" and "move". > - Should use spinlock breakable code in kvm_mmu_zap_mmio_sptes() > (picture guest with 512GB of RAM, even walking all those pages is > expensive) (ah, patch to remove kvm_mmu_zap_mmio_sptes does that). > - Is -13 enough to test wraparound? Its highly likely the guest has > not began executing by the time 13 kvm_set_memory_calls are made > (so no sptes around). Perhaps -2000 is more sensible (should confirm > though). In the future, after we've tested enough, we should change the testing code to be executed only for some debugging configs. Especially, if we change zap_mmio_sptes() to zap_all_shadows(), very common guests, even without huge memory like 512GB, can see the effect induced by sudden page faults unnecessarily. If necessary, developers can test the wraparound code by lowering the max_gen itself anyway. > - Why remove "if (change == KVM_MR_CREATE) || (change > == KVM_MR_MOVE)" from kvm_arch_commit_memory_region? > Its instructive. There may be a chance that we miss generation wraparounds if we don't check other cases: seems unlikely, but theoretically possible. In short, all memory slot changes make mmio sptes stored in shadow pages obsolete, or zapped for wraparounds, in the new way -- am I right? Takuya -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[kvm-unit-test PATCH] kvmclock: serialize RDTSC
Serialize RDTSC so its executed inside kvmclock_read
section.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=922285
Signed-off-by: Marcelo Tosatti
diff --git a/x86/kvmclock.c b/x86/kvmclock.c
index 0624da3..5b831c5 100644
--- a/x86/kvmclock.c
+++ b/x86/kvmclock.c
@@ -177,10 +177,10 @@ cycle_t pvclock_clocksource_read(struct
pvclock_vcpu_time_info *src)
do {
version = pvclock_get_time_values(&shadow, src);
- barrier();
+ mb();
offset = pvclock_get_nsec_offset(&shadow);
ret = shadow.system_timestamp + offset;
- barrier();
+ mb();
} while (version != src->version);
if ((valid_flags & PVCLOCK_RAW_CYCLE_BIT) ||
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: perf kvm top --callgraph not showing callgraph
[added kvm devel list and Xiao who implemented the original perf-kvm as
I recall]
On 6/14/13 5:11 PM, Cody P Schafer wrote:
I am under the impression the limitations are these 2 snippets in
>arch/x86/kernel/cpu/perf_event.c:
Yep, that's disabling the in-kernel callchain generation (the in-perf
callchain code should still be an option without this). I wonder if
one could use perf_callchain_user() to find the callchain of the guest
kernel.
Does anyone know the particular changes that need to be done to
support kvm backtraces/the reasons it is specifically disabled?
It's going to require some KVM changes I would think. e.g., for the IP:
unsigned long perf_instruction_pointer(struct pt_regs *regs)
{
if (perf_guest_cbs && perf_guest_cbs->is_in_guest())
return perf_guest_cbs->get_guest_ip();
return regs->ip + code_segment_base(regs);
}
get_guest_ip comes from arch/x86/kvm/x86.c.
callchain walking starts in perf_callchain, kernel/events/callchain.c
For more context:
perf_prepare_sample()
data->callchain = perf_callchain(event, regs);
For guests you'll want regs from the guest which will need to be
supplied by kvm.
David
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 14/31] mips/kvm: Add thread_info flag to indicate operation in MIPS VZ Guest Mode.
Acked-by: Ralf Baechle Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/31] mips/kvm: Add accessors for MIPS VZ registers.
Acked-by: Ralf Baechle Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/31] MIPS: Add instruction format information for WAIT, MTC0, MFC0, et al.
On Fri, Jun 07, 2013 at 04:03:16PM -0700, David Daney wrote: > To: linux-m...@linux-mips.org, r...@linux-mips.org, kvm@vger.kernel.org, > Sanjay Lal > Cc: linux-ker...@vger.kernel.org, David Daney > Subject: [PATCH 12/31] MIPS: Add instruction format information for WAIT, > MTC0, MFC0, et al. Looks good. Acked-by: Ralf Baechle I wonder if somebody could throw in microMIPS equivalent to this patch? Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/31] MIPS: Rearrange branch.c so it can be used by kvm code.
Acked-by: Ralf Baechle Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/31] mips/kvm: Implement ioctls to get and set FPU registers.
On Fri, Jun 07, 2013 at 04:03:14PM -0700, David Daney wrote: > From: David Daney > > The current implementation does nothing with them, but future MIPSVZ > work need them. Also add the asm-offsets accessors for the fields. Just as a note, older MIPS FPUs only have fcr0 and fcr31. Acked-by: Ralf Baechle Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pci: Enable overrides for missing ACS capabilities
Bump. Comments?
On Thu, 2013-05-30 at 12:40 -0600, Alex Williamson wrote:
> PCIe ACS (Access Control Services) is the PCIe 2.0+ feature that
> allows us to control whether transactions are allowed to be redirected
> in various subnodes of a PCIe topology. For instance, if two
> endpoints are below a root port or downsteam switch port, the
> downstream port may optionally redirect transactions between the
> devices, bypassing upstream devices. The same can happen internally
> on multifunction devices. The transaction may never be visible to the
> upstream devices.
>
> One upstream device that we particularly care about is the IOMMU. If
> a redirection occurs in the topology below the IOMMU, then the IOMMU
> cannot provide isolation between devices. This is why the PCIe spec
> encourages topologies to include ACS support. Without it, we have to
> assume peer-to-peer DMA within a hierarchy can bypass IOMMU isolation.
>
> Unfortunately, far too many topologies do not support ACS to make this
> a steadfast requirement. Even the latest chipsets from Intel are only
> sporadically supporting ACS. We have trouble getting interconnect
> vendors to include the PCIe spec required PCIe capability, let alone
> suggested features.
>
> Therefore, we need to add some flexibility. The pcie_acs_override=
> boot option lets users opt-in specific devices or sets of devices to
> assume ACS support. The "downstream" option assumes full ACS support
> on root ports and downstream switch ports. The "multifunction"
> option assumes the subset of ACS features available on multifunction
> endpoints and upstream switch ports are supported. The "id::"
> option enables ACS support on devices matching the provided vendor
> and device IDs, allowing more strategic ACS overrides. These options
> may be combined in any order. A maximum of 16 id specific overrides
> are available. It's suggested to use the most limited set of options
> necessary to avoid completely disabling ACS across the topology.
>
> Note to hardware vendors, we have facilities to permanently quirk
> specific devices which enforce isolation but not provide an ACS
> capability. Please contact me to have your devices added and save
> your customers the hassle of this boot option.
>
> Signed-off-by: Alex Williamson
> ---
> Documentation/kernel-parameters.txt | 10 +++
> drivers/pci/quirks.c| 102
> +++
> 2 files changed, 112 insertions(+)
>
> diff --git a/Documentation/kernel-parameters.txt
> b/Documentation/kernel-parameters.txt
> index 47bb23c..a60e6ad 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2349,6 +2349,16 @@ bytes respectively. Such letter suffixes can also be
> entirely omitted.
> nomsi Do not use MSI for native PCIe PME signaling (this makes
> all PCIe root ports use INTx for all services).
>
> + pcie_acs_override =
> + [PCIE] Override missing PCIe ACS support for:
> + downstream
> + All downstream ports - full ACS capabilties
> + multifunction
> + All multifunction devices - multifunction ACS subset
> + id::
> + Specfic device - full ACS capabilities
> + Specified as vid:did (vendor/device ID) in hex
> +
> pcmv= [HW,PCMCIA] BadgePAD 4
>
> pd. [PARIDE]
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 0369fb6..c7609f6 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3292,11 +3292,113 @@ struct pci_dev *pci_get_dma_source(struct pci_dev
> *dev)
> return pci_dev_get(dev);
> }
>
> +static bool acs_on_downstream;
> +static bool acs_on_multifunction;
> +
> +#define NUM_ACS_IDS 16
> +struct acs_on_id {
> + unsigned short vendor;
> + unsigned short device;
> +};
> +static struct acs_on_id acs_on_ids[NUM_ACS_IDS];
> +static u8 max_acs_id;
> +
> +static __init int pcie_acs_override_setup(char *p)
> +{
> + if (!p)
> + return -EINVAL;
> +
> + while (*p) {
> + if (!strncmp(p, "downstream", 10))
> + acs_on_downstream = true;
> + if (!strncmp(p, "multifunction", 13))
> + acs_on_multifunction = true;
> + if (!strncmp(p, "id:", 3)) {
> + char opt[5];
> + int ret;
> + long val;
> +
> + if (max_acs_id >= NUM_ACS_IDS - 1) {
> + pr_warn("Out of PCIe ACS override slots (%d)\n",
> + NUM_ACS_IDS);
> + goto next;
> + }
> +
> + p += 3;
> + snprintf(opt, 5, "%s", p);
> + ret = kstrtol(opt, 16, &val);
> + if (ret)
Re: [PATCH 03/31] mips/kvm: Fix 32-bitisms in kvm_locore.S
Hello. On 14-06-2013 17:09, Ralf Baechle wrote: diff --git a/arch/mips/kvm/kvm_locore.S b/arch/mips/kvm/kvm_locore.S index dca2aa6..e86fa2a 100644 --- a/arch/mips/kvm/kvm_locore.S +++ b/arch/mips/kvm/kvm_locore.S @@ -310,7 +310,7 @@ NESTED (MIPSX(GuestException), CALLFRAME_SIZ, ra) LONG_S t0, VCPU_R26(k1) /* Get GUEST k1 and save it in VCPU */ -la t1, ~0x2ff + PTR_LI t1, ~0x2ff mfc0t0, CP0_EBASE and t0, t0, t1 LONG_L t0, 0x3000(t0) @@ -384,14 +384,14 @@ NESTED (MIPSX(GuestException), CALLFRAME_SIZ, ra) mtc0k0, CP0_DDATA_LO /* Restore RDHWR access */ -la k0, 0x200F + PTR_LI k0, 0x200F mtc0k0, CP0_HWRENA /* Jump to handler */ FEXPORT(__kvm_mips_jump_to_handler) /* XXXKYMA: not sure if this is safe, how large is the stack?? */ /* Now jump to the kvm_mips_handle_exit() to see if we can deal with this in the kernel */ -la t9,kvm_mips_handle_exit + PTR_LA t9, kvm_mips_handle_exit jalr.hb t9 addiu sp,sp, -CALLFRAME_SIZ /* BD Slot */ @@ -566,7 +566,7 @@ __kvm_mips_return_to_host: mtlok0 /* Restore RDHWR access */ -la k0, 0x200F + PTR_LI k0, 0x200F mtc0k0, CP0_HWRENA Technically ok, there's only a formatting issue because you indent the changed lines with tabs while the existing file uses tab characters. I hope you meant the space characters? :-) I suggest you insert an extra cleanup patch to properly re-indent the entire file into the series before this one? So with that sorted: Acked-by: Ralf Baechle Ralf WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/31] mips/kvm: Factor trap-and-emulate support into a pluggable implementation.
Acked-by: Ralf Baechle Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/31] mips/kvm: Fix code formatting in arch/mips/kvm/kvm_locore.S
Ah, here's you're taking care of my eariler complaint about the formatting of kvm_locore.S. I'd have done things in a different order to avoid the inconsistent formatting - even if that was only a temporary state. But anyway, Acked-by: Ralf Baechle Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/31] mips/kvm: Rename VCPU_registername to KVM_VCPU_ARCH_registername
Acked-by: Ralf Baechle Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/31] mips/kvm: Rename kvm_vcpu_arch.pc to kvm_vcpu_arch.epc
Acked-by: Ralf Baechle Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/31] mips/kvm: Use generic cache flushing functions.
On Fri, Jun 07, 2013 at 04:03:09PM -0700, David Daney wrote:
> From: David Daney
>
> We don't know if we have the r4k specific functions available, so use
> universally available __flush_cache_all() instead. This takes longer
> as it flushes both i-cache and d-cache, but is available for all CPUs.
>
> Signed-off-by: David Daney
> ---
> arch/mips/kvm/kvm_mips_emul.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/mips/kvm/kvm_mips_emul.c b/arch/mips/kvm/kvm_mips_emul.c
> index af9a661..a2c6687 100644
> --- a/arch/mips/kvm/kvm_mips_emul.c
> +++ b/arch/mips/kvm/kvm_mips_emul.c
> @@ -916,8 +916,6 @@ kvm_mips_emulate_cache(uint32_t inst, uint32_t *opc,
> uint32_t cause,
> struct kvm_run *run, struct kvm_vcpu *vcpu)
> {
> struct mips_coproc *cop0 = vcpu->arch.cop0;
> - extern void (*r4k_blast_dcache) (void);
> - extern void (*r4k_blast_icache) (void);
> enum emulation_result er = EMULATE_DONE;
> int32_t offset, cache, op_inst, op, base;
> struct kvm_vcpu_arch *arch = &vcpu->arch;
> @@ -954,9 +952,9 @@ kvm_mips_emulate_cache(uint32_t inst, uint32_t *opc,
> uint32_t cause,
>arch->gprs[base], offset);
>
> if (cache == MIPS_CACHE_DCACHE)
> - r4k_blast_dcache();
Only nukes the D-cache.
> + __flush_cache_all();
This is also going to blow away the I-cache, so will be slower.
> else if (cache == MIPS_CACHE_ICACHE)
> - r4k_blast_icache();
Only nukes the I-cache.
> + __flush_cache_all();
This is also going to blow away the D-cache, so will be slower.
Ralf
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/31] mips/kvm: Add casts to avoid pointer width mismatch build failures.
Cast are always a bit ugly, in particular the one double casts - but a necessary evil here. Acked-by: Ralf Baechle http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/31] MIPS: Move allocate_kscratch to cpu-probe.c and make it public.
On Fri, Jun 14, 2013 at 01:41:18PM +0200, Ralf Baechle wrote: > Date: Fri, 14 Jun 2013 13:41:18 +0200 > From: Ralf Baechle > To: James Hogan > Cc: linux-m...@linux-mips.org, kvm@vger.kernel.org, Sanjay Lal > , linux-ker...@vger.kernel.org, David Daney > > Subject: Re: [PATCH 01/31] MIPS: Move allocate_kscratch to cpu-probe.c and > make it public. > Content-Type: text/plain; charset=us-ascii > > On Fri, Jun 07, 2013 at 04:03:05PM -0700, David Daney wrote: > > Date: Fri, 7 Jun 2013 16:03:05 -0700 > > From: David Daney > > To: linux-m...@linux-mips.org, r...@linux-mips.org, kvm@vger.kernel.org, > > Sanjay Lal > > Cc: linux-ker...@vger.kernel.org, David Daney > > Subject: [PATCH 01/31] MIPS: Move allocate_kscratch to cpu-probe.c and make > > it public. > > > > From: David Daney > > I'd just like to add a note about compatibility. Code optimized for > LL/SC-less CPUs has made use of the fact that exception handlers will > clobber k0/k1 to a non-zero value. On a MIPS II or better CPU a branch > likely instruction could be used to atomically test k0/k1 and depending > on the test, execute a store instruction like: > > .setnoreorder > beqzl $k0, ok > sw $reg, offset($reg) > /* if we get here, our SC emulation has failed */ > ok: ... > > In particular Sony had elected to do this for the R5900 (after I explained > the concept to somebody and told it'd be a _bad_ idea for compatibility > reasons). Bad ideas are infectious so I'm sure others have used it, too. > > I don't think this should stop your patch nor should we unless this turns > out to be an actual problem add any kludges to support such cowboy style > hacks. But I wanted to mention and document the issue; maybe this should > be mentioned in the log message of the next version of this patch. > > Acked-by: Ralf Baechle Bleh. I fatfingered mutt. This of course was the reply intended for "[PATCH 02/31] MIPS: Save and restore K0/K1 when CONFIG_KVM_MIPSVZ". As for 1/31: Acked-by: Ralf Baechle Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/31] mips/kvm: Fix 32-bitisms in kvm_locore.S
On Fri, Jun 07, 2013 at 04:03:07PM -0700, David Daney wrote: > diff --git a/arch/mips/kvm/kvm_locore.S b/arch/mips/kvm/kvm_locore.S > index dca2aa6..e86fa2a 100644 > --- a/arch/mips/kvm/kvm_locore.S > +++ b/arch/mips/kvm/kvm_locore.S > @@ -310,7 +310,7 @@ NESTED (MIPSX(GuestException), CALLFRAME_SIZ, ra) > LONG_S t0, VCPU_R26(k1) > > /* Get GUEST k1 and save it in VCPU */ > -la t1, ~0x2ff > + PTR_LI t1, ~0x2ff > mfc0t0, CP0_EBASE > and t0, t0, t1 > LONG_L t0, 0x3000(t0) > @@ -384,14 +384,14 @@ NESTED (MIPSX(GuestException), CALLFRAME_SIZ, ra) > mtc0k0, CP0_DDATA_LO > > /* Restore RDHWR access */ > -la k0, 0x200F > + PTR_LI k0, 0x200F > mtc0k0, CP0_HWRENA > > /* Jump to handler */ > FEXPORT(__kvm_mips_jump_to_handler) > /* XXXKYMA: not sure if this is safe, how large is the stack?? */ > /* Now jump to the kvm_mips_handle_exit() to see if we can deal with > this in the kernel */ > -la t9,kvm_mips_handle_exit > + PTR_LA t9, kvm_mips_handle_exit > jalr.hb t9 > addiu sp,sp, -CALLFRAME_SIZ /* BD Slot */ > > @@ -566,7 +566,7 @@ __kvm_mips_return_to_host: > mtlok0 > > /* Restore RDHWR access */ > -la k0, 0x200F > + PTR_LI k0, 0x200F > mtc0k0, CP0_HWRENA Technically ok, there's only a formatting issue because you indent the changed lines with tabs while the existing file uses tab characters. I suggest you insert an extra cleanup patch to properly re-indent the entire file into the series before this one? So with that sorted: Acked-by: Ralf Baechle Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM Forum 2013 Call for Participation
= KVM Forum 2013: Call For Participation October 21-23, 2013 - Edinburgh International Conference Centre - Edinburgh, UK (All submissions must be received before midnight July 21, 2013) = KVM is an industry leading open source hypervisor that provides an ideal platform for datacenter virtualization, virtual desktop infrastructure, and cloud computing. Once again, it's time to bring together the community of developers and users that define the KVM ecosystem for our annual technical conference. We will discuss the current state of affairs and plan for the future of KVM, its surrounding infrastructure, and management tools. The oVirt Workshop will run in parallel with the KVM Forum again, bringing in a community focused on enterprise datacenter virtualization management built on KVM. For topics which overlap we will have shared sessions. So mark your calendar and join us in advancing KVM. http://events.linuxfoundation.org/events/kvm-forum/ Once again we are colocated with The Linux Foundation's LinuxCon Europe. KVM Forum attendees will be able to attend oVirt Workshop sessions and are eligible to attend LinuxCon Europe for a discounted rate. http://events.linuxfoundation.org/events/kvm-forum/register We invite you to lead part of the discussion by submitting a speaking proposal for KVM Forum 2013. http://events.linuxfoundation.org/cfp Suggested topics: KVM/Kernel - Scaling and performance - Nested virtualization - I/O improvements - VFIO, device assignment, SR-IOV - Driver domains - Time keeping - Resource management (cpu, memory, i/o) - Memory management (page sharing, swapping, huge pages, etc) - Network virtualization - Security - Architecture ports QEMU - Device model improvements - New devices and chipsets - Scaling and performance - Desktop virtualization - Spice - Increasing robustness and hardening - Security model - Management interfaces - QMP protocol and implementation - Image formats - Firmware (SeaBIOS, OVMF, UEFI, etc) - Live migration - Live snapshots and merging - Fault tolerance, high availability, continuous backup - Real-time guest support Virtio - Speeding up existing devices - Alternatives - Virtio on non-Linux or non-virtualized Management infrastructure - oVirt (shared track w/ oVirt Workshop) - Libvirt - KVM autotest - OpenStack - Network virtualization management - Enterprise storage management Cloud computing - Scalable storage - Virtual networking - Security - Provisioning SUBMISSION REQUIREMENTS Abstracts due: July 21, 2013 Notification: August 1, 2013 Please submit a short abstract (~150 words) describing your presentation proposal. In your submission please note how long your talk will take. Slots vary in length up to 45 minutes. Also include in your proposal the proposal type -- one of: - technical talk - end-user talk - birds of a feather (BOF) session Submit your proposal here: http://events.linuxfoundation.org/cfp You will receive a notification whether or not your presentation proposal was accepted by Aug 1st. END-USER COLLABORATION One of the big challenges as developers is to know what, where and how people actually use our software. We will reserve a few slots for end users talking about their deployment challenges and achievements. If you are using KVM in production you are encouraged submit a speaking proposal. Simply mark it as an end-user collaboration proposal. As an end user, this is a unique opportunity to get your input to developers. BOF SESSION We will reserve some slots in the evening after the main conference tracks, for birds of a feather (BOF) sessions. These sessions will be less formal than presentation tracks and targetted for people who would like to discuss specific issues with other developers and/or users. If you are interested in getting developers and/or uses together to discuss a specific problem, please submit a BOF proposal. HOTEL / TRAVEL The KVM Forum 2013 will be held in Edinburgh, UK at the Edinburgh International Conference Centre. http://events.linuxfoundation.org/events/kvm-forum/hotel Thank you for your interest in KVM. We're looking forward to your submissions and seeing you at the KVM Forum 2013 in October! Thanks, -your KVM Forum 2013 Program Committee Please contact us with any questions or comments. kvm-forum-2013...@redhat.com -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/31] MIPS: Move allocate_kscratch to cpu-probe.c and make it public.
On Fri, Jun 07, 2013 at 04:03:05PM -0700, David Daney wrote: > Date: Fri, 7 Jun 2013 16:03:05 -0700 > From: David Daney > To: linux-m...@linux-mips.org, r...@linux-mips.org, kvm@vger.kernel.org, > Sanjay Lal > Cc: linux-ker...@vger.kernel.org, David Daney > Subject: [PATCH 01/31] MIPS: Move allocate_kscratch to cpu-probe.c and make > it public. > > From: David Daney I'd just like to add a note about compatibility. Code optimized for LL/SC-less CPUs has made use of the fact that exception handlers will clobber k0/k1 to a non-zero value. On a MIPS II or better CPU a branch likely instruction could be used to atomically test k0/k1 and depending on the test, execute a store instruction like: .setnoreorder beqzl $k0, ok sw $reg, offset($reg) /* if we get here, our SC emulation has failed */ ok: ... In particular Sony had elected to do this for the R5900 (after I explained the concept to somebody and told it'd be a _bad_ idea for compatibility reasons). Bad ideas are infectious so I'm sure others have used it, too. I don't think this should stop your patch nor should we unless this turns out to be an actual problem add any kludges to support such cowboy style hacks. But I wanted to mention and document the issue; maybe this should be mentioned in the log message of the next version of this patch. Acked-by: Ralf Baechle Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 17/31] MIPS: Quit exposing Kconfig symbols in uapi headers.
So this one can be dropped. Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/31] KVM/MIPS: Implement hardware virtualization via the MIPS-VZ extensions.
On Fri, Jun 07, 2013 at 04:03:04PM -0700, David Daney wrote: > Subject: [PATCH 00/31] KVM/MIPS: Implement hardware virtualization via the > MIPS-VZ extensions. > > From: David Daney > > These patches take a somewhat different approach to MIPS > virtualization via the MIPS-VZ extensions than the patches previously > sent by Sanjay Lal. > > Several facts about the code: > > o Existing exception handlers are modified to hook in to KVM instead > of intercepting all exceptions via the EBase register, and then > chaining to real exception handlers. > > o Able to boot 64-bit SMP guests that use the FPU (I have booted 4-way > SMP 64-bit MIPS/Linux). > > o Additional overhead on every exception even when *no* vCPU is running. > > o Lower interrupt overhead, than the EBase interception method, when > vCPU *is* running. > > o This code is somewhat smaller than the existing trap/emulate > implementation (about 2100 lines vs. about 5300 lines) > > o Currently probably only usable on the OCTEON III CPU model, as some > MIPS-VZ implementation-defined behaviors were assumed to have the > OCTEON III behavior. > > Note: I think Ralf already has the 17/31 (MIPS: Quit exposing Kconfig > symbols in uapi headers.) queued, but I also include it here. Yes; as the references to CONFIG_* symbols in UAPI were a bug, I've already merged this patch for 3.10 as 8f657933a3c2086d4731350c98f91a990783c0d3 [MIPS: Quit exposing Kconfig symbols in uapi headers.] Ralf -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cache write back & barriers
On Thu, Jun 13, 2013 at 10:47:32AM +0200, folkert wrote: > Hi, > > > > In virt-manager I saw that there's the option for cache writeback for > > > storage devices. > > > I'm wondering: does this also make kvm to ignore write barriers invoked > > > by the virtual machine? > > > > No, that would be unsafe. When the guest issues a flush then QEMU will > > ensure that data reaches the disk with -drive cache=writeback. > > Aha so the writeback behaves like the consume harddisks with write-cache > on them. > In that case maybe an extra note could be added to the virt-manager > (excellent software by the way!) that if the client vm supports > barriers, that write-back in that case then is safe. Agree? CCed virt-manager mailing list so they can see your request. Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: x86: remove vcpu's CPL check in host invoked vcpu's xcr set process
__kvm_set_xcr function does the CPL check when set xcr. __kvm_set_xcr is called
in two flows,
one is invoked by guest, call stack shown as below,
handle_xsetbv(or xsetbv_interception)
kvm_set_xcr
__kvm_set_xcr
the other one is invoked by host(QEMU), call stack shown as below,
kvm_arch_vcpu_ioctl
kvm_vcpu_ioctl_x86_set_xcrs
__kvm_set_xcr
The former does need the CPL check, but the latter does not.
Signed-off-by: Zhang Haoyu
---
arch/x86/kvm/x86.c|5 +-
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 094b5d9..16ff44e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -582,8 +582,6 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr)
if (index != XCR_XFEATURE_ENABLED_MASK)
return 1;
xcr0 = xcr;
-if (kvm_x86_ops->get_cpl(vcpu) != 0)
-return 1;
if (!(xcr0 & XSTATE_FP))
return 1;
if ((xcr0 & XSTATE_YMM) && !(xcr0 & XSTATE_SSE))
@@ -597,7 +595,8 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr)
int kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr)
{
-if (__kvm_set_xcr(vcpu, index, xcr)) {
+if ((kvm_x86_ops->get_cpl(vcpu) != 0) ||
+ __kvm_set_xcr(vcpu, index, xcr)) {
kvm_inject_gp(vcpu, 0);
return 1;
}
1.7.3.1.msysgit.0
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
