On 07/30/2012 05:38 PM, Gleb Natapov wrote:
> Optimize "rep ins" by allowing emulator to write back more than one
> datum at a time. Introduce new operand type OP_MEM_STR which tells
> writeback() that dst contains pointer to an array that should be written
> back as opposite to just one data eleme
On 08/06/2012 11:58 AM, Gleb Natapov wrote:
> On Mon, Aug 06, 2012 at 11:50:20AM +0300, Avi Kivity wrote:
>> On 07/30/2012 05:38 PM, Gleb Natapov wrote:
>> > Optimize "rep ins" by allowing emulator to write back more than one
>> > datum at a time. Introduce ne
On 08/01/2012 11:59 AM, Takuya Yoshikawa wrote:
> This has been already discussed on other threads and the concept itself
> is not so controversial.
>
> But since I know that the last patch of this series conflicts with
> Paul's recent work, I want to find a way to synchronize with his work
> at t
On 07/24/2012 11:43 PM, Alex Williamson wrote:
> This new ioctl enables an eventfd to be triggered when an EOI is
> written for a specified irqchip pin. The first user of this will
> be external device assignment through VFIO, using a level irqfd
> for asserting a PCI INTx interrupt and this inter
On 08/06/2012 01:17 PM, Avi Kivity wrote:
>
>>
>> +4.77 KVM_EOIFD
>> +
>> +Capability: KVM_CAP_EOIFD
>> +Architectures: x86
>> +Type: vm ioctl
>> +Parameters: struct kvm_eoifd (in)
>> +Returns: 0 on success, < 0 on error
>> +
>>
On 08/06/2012 01:38 PM, Avi Kivity wrote:
> Regarding the implementation, instead of a linked list, would an array
> of counters parallel to the bitmap make it simpler?
Or even, replace the bitmap with an array of counters.
--
error compiling committee.c: too many arguments to function
On 08/06/2012 02:05 PM, Gleb Natapov wrote:
> On Mon, Aug 06, 2012 at 12:28:05PM +0300, Avi Kivity wrote:
>> On 08/06/2012 11:58 AM, Gleb Natapov wrote:
>> > On Mon, Aug 06, 2012 at 11:50:20AM +0300, Avi Kivity wrote:
>> >> On 07/30/2012 05:38 PM, Gleb Natapov wrote:
On 08/06/2012 02:49 PM, Gleb Natapov wrote:
> On Mon, Aug 06, 2012 at 02:39:52PM +0300, Avi Kivity wrote:
>> On 08/06/2012 02:05 PM, Gleb Natapov wrote:
>> > On Mon, Aug 06, 2012 at 12:28:05PM +0300, Avi Kivity wrote:
>> >> On 08/06/2012 11:58 AM, Gleb Natapov wrote
On 08/06/2012 11:46 AM, Stefan Priebe - Profihost AG wrote:
> But still i got the segfault and core dump - this is my main problem? I
> mean qemu-kvm master isn't declared as stable. So i don't care about the
> slowness here.
>
> What can we do about the core dump and crash?
Okay, I reproduced i
On 08/06/2012 03:12 PM, Avi Kivity wrote:
> On 08/06/2012 11:46 AM, Stefan Priebe - Profihost AG wrote:
>
>> But still i got the segfault and core dump - this is my main problem? I
>> mean qemu-kvm master isn't declared as stable. So i don't care about the
>> sl
On 08/06/2012 03:37 PM, Avi Kivity wrote:
> On 08/06/2012 03:12 PM, Avi Kivity wrote:
>> On 08/06/2012 11:46 AM, Stefan Priebe - Profihost AG wrote:
>>
>>> But still i got the segfault and core dump - this is my main problem? I
>>> mean qemu-kvm master isn'
On 08/03/2012 10:37 AM, Xiao Guangrong wrote:
> After that, the exported and un-inline function, get_fault_pfn,
> can be removed
>
>
> +#define KVM_PFN_ERR_FAULT(-EFAULT)
> +
IMO this symbol isn't needed, just use -EFAULT (and -EHWPOISON etc.)
directly. Just document it in hva_to_pfn(), sin
On 08/06/2012 04:01 PM, Avi Kivity wrote:
> On 08/03/2012 10:37 AM, Xiao Guangrong wrote:
>> After that, the exported and un-inline function, get_fault_pfn,
>> can be removed
>>
>>
>> +#define KVM_PFN_ERR_FAULT (-EFAULT)
>> +
>
> IMO this symbol i
On 08/03/2012 10:36 AM, Xiao Guangrong wrote:
> There are two bugs:
> - the 'error page' is forgot to be released
> [ it is unneeded after commit a2766325cf9f9, for backport, we
> still do kvm_release_pfn_clean for the error pfn ]
>
> - guest pages are always released regardless of the unmap
On 08/05/2012 03:58 PM, Gleb Natapov wrote:
> APIC code has a lot of checks for apic presence and apic HW/SW enable
> state. Most common configuration is when each vcpu has in kernel apic
> and it is fully enabled. This path series uses jump labels to turn checks
> to nops in the common case.
Ok
On 08/06/2012 11:25 PM, Scott Wood wrote:
> On 08/05/2012 04:00 AM, Avi Kivity wrote:
>> On 08/04/2012 01:32 AM, Benjamin Herrenschmidt wrote:
>>> On Fri, 2012-08-03 at 15:05 -0300, Marcelo Tosatti wrote:
>>>
>>>> See kvm_arch_process_async_events() call
On 08/07/2012 04:32 AM, David Gibson wrote:
> On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
>> On Mon, 2012-08-06 at 13:13 +1000, David Gibson wrote:
>> > So, I'm still trying to nut out the implications for H_CEDE, and think
>> > if there are any other hypercalls that mig
On 08/07/2012 03:14 PM, David Gibson wrote:
> On Tue, Aug 07, 2012 at 11:46:35AM +0300, Avi Kivity wrote:
>> On 08/07/2012 04:32 AM, David Gibson wrote:
>> > On Tue, Aug 07, 2012 at 06:57:57AM +1000, Benjamin Herrenschmidt wrote:
>> >> On Mon, 2012-08-06 at 1
On 08/07/2012 01:57 PM, Alexander Graf wrote:
> The e500 target has lived without mmu notifiers ever since it got
> introduced, but fails for the user space check on them with hugetlbfs.
>
> So in order to get that one working, implement mmu notifiers in a
> reasonably dumb fashion and be happy. O
On 08/07/2012 01:57 PM, Alexander Graf wrote:
> Some archs need to ensure that their icache is flushed when mapping a new
> page. Add a callback to the generic code for an arch to implement any cache
> flush logic it may need.
>
> Signed-off-by: Alexander Graf
> ---
> virt/kvm/kvm_main.c |6
On 08/07/2012 04:44 PM, Alexander Graf wrote:
>
>>
>> Is this the correct place? Who says the caller of hva_to_pfn() is going
>> to map it?
>
> I don't think anyone is. However, we need the struct page, and all the
> generic kvm mm code tries hard to hide it from its users. The alternative
>
On 08/06/2012 08:20 PM, Peter Maydell wrote:
> On 3 July 2012 10:01, Christoffer Dall wrote:
>> From: Christoffer Dall
>>
>> Userspace can inject IRQs and FIQs through the KVM_IRQ_LINE VM ioctl.
>> This ioctl is used since the sematics are in fact two lines that can be
>> either raised or lowered
On 08/07/2012 05:08 PM, Alexander Graf wrote:
>
>
> On 07.08.2012, at 15:58, Avi Kivity wrote:
>
>> On 08/07/2012 04:44 PM, Alexander Graf wrote:
>>>
>>>>
>>>> Is this the correct place? Who says the caller of hva_to_pfn() is going
>&g
On 08/07/2012 04:52 PM, Alexander Graf wrote:
>>>
>>> +/* MMU Notifiers */
>>> +
>>> +int kvm_unmap_hva(struct kvm *kvm, unsigned long hva)
>>> +{
>>> +/* Is this a guest page? */
>>> +if (!hva_to_memslot(kvm, hva))
>>> +return 0;
>>> +
>>> +/*
>>> +
On 08/07/2012 05:14 PM, Alexander Graf wrote:
>
>
> On 07.08.2012, at 16:10, Avi Kivity wrote:
>
>> On 08/07/2012 05:08 PM, Alexander Graf wrote:
>>>
>>>
>>> On 07.08.2012, at 15:58, Avi Kivity wrote:
>>>
>>>> On 08/07/2012
On 08/07/2012 05:12 PM, Peter Maydell wrote:
> On 7 August 2012 14:59, Avi Kivity wrote:
>> On 08/06/2012 08:20 PM, Peter Maydell wrote:
>>> On 3 July 2012 10:01, Christoffer Dall
>>> wrote:
>>>> From: Christoffer Dall
>>>>
>>>>
On 08/07/2012 05:24 PM, Alexander Graf wrote:
>>>
>>> Pre-map? How?
>>
>> In arch code before you install the page in a pte/tlbe.
>
> So how do I get to the struct page in there?
>
pfn_to_page()
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list:
On 08/08/2012 12:09 AM, Benjamin Herrenschmidt wrote:
> On Tue, 2012-08-07 at 16:13 +0300, Avi Kivity wrote:
>>
>
>> Peter has started to fix up this naming mess in qemu. I guess we should
>> do the same for the kernel (except for ABIs) and document it, because it
>&
On 08/08/2012 03:49 AM, David Gibson wrote:
>> > We never have irqchip in kernel (because we haven't written that yet)
>> > but we still sleep in-kernel for CEDE. I haven't spotted any problem
>> > with that, but now I'm wondering if there is one, since x86 don't do
>> > it in what seems like the
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> If out of global lock, we will be challenged by SMP in low level,
> so need atomic ops.
>
> This file is heavily copied from kernel. Currently, only x86 atomic ops
> included, and will be extended for other arch for future.
>
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> Collect unused object and release them at caller demand.
>
Please explain the motivation for this patch.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubs
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> Using mem_map_lock to protect among updaters. So we can get the intact
> snapshot of mem topology -- FlatView & radix-tree.
>
> Signed-off-by: Liu Ping Fan
> ---
> exec.c |3 +++
> memory.c | 22 ++
On 08/08/2012 12:07 PM, Paolo Bonzini wrote:
> Il 08/08/2012 11:05, Avi Kivity ha scritto:
>>> > From: Liu Ping Fan
>>> >
>>> > Collect unused object and release them at caller demand.
>>> >
>> Please explain the motivation for this patch
On 08/08/2012 12:05 PM, 陳韋任 (Wei-Ren Chen) wrote:
>> I propose we use gcc builtins. We get automatic architecture support,
>> and tuning for newer processors if the user so chooses.
>>
>> http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Atomic-Builtins.html
>>
>> In May 2031 we can switch to C11 atom
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> The types of referred object by MemoryRegion are variable, ex,
> another mr, DeviceState, or other struct defined by drivers.
> So the refer/unrefer may be different by drivers.
>
> Using this ops, we can mange the backend obje
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> Using refcnt for mr, so we can separate mr's life cycle management
> from refered object.
> When mr->ref 0->1, inc the refered object.
> When mr->ref 1->0, dec the refered object.
>
> The refered object can be DeviceStae, a
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> PhysMap contain the flatview and radix-tree view, they are snapshot
> of system topology and should be consistent. With PhysMap, we can
> swap the pointer when updating and achieve the atomic.
>
> Signed-off-by: Liu Ping Fan
>
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
> Flatview and radix view are all under the protection of pointer.
> And this make sure the change of them seem to be atomic!
>
> The mr accessed by radix-tree leaf or flatview will be reclaimed
> after the prev PhysMap not in us
On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
> From: Liu Ping Fan
>
Please explain the motivation. AFAICT, the big qemu lock is sufficient.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message
On 08/08/2012 12:52 PM, Paolo Bonzini wrote:
> Il 08/08/2012 08:25, Liu Ping Fan ha scritto:
>> +void qdev_unplug_complete(DeviceState *dev, Error **errp)
>> +{
>> +/* isolate from mem view */
>> +qdev_unmap(dev);
>> +qemu_lock_devtree();
>> +/* isolate from device tree */
>> +q
On 08/08/2012 12:23 AM, Marcelo Tosatti wrote:
>> @@ -281,8 +294,10 @@ struct x86_emulate_ctxt {
>> bool rip_relative;
>> unsigned long _eip;
>> struct operand memop;
>> +u32 regs_valid; /* bitmaps of registers in _regs[] that can be read */
>> +u32 regs_dirty; /* bitmaps o
On 08/08/2012 02:59 PM, David Gibson wrote:
>>
>> No, you're correct. HLT could have been emulated in userspace, it just
>> wasn't. The correct statement is that HLT was arbitrarily chosen to be
>> emulated in userspace with the synchronous model, but the asynchronous
>> model forced it into the
On 08/08/2012 04:49 PM, Paolo Bonzini wrote:
> Il 08/08/2012 15:32, Peter Maydell ha scritto:
>>> > 1. GCC atomics look ugly, :) do not provide rmb/wmb, and in some
>>> > versions of GCC mb is known to be (wrongly) a no-op.
>>> >
>>> > 2. glib atomics do not provide mb/rmb/wmb either, and
>>> > g_a
On 08/09/2012 10:49 AM, Paolo Bonzini wrote:
> Il 09/08/2012 09:33, liu ping fan ha scritto:
>> Yes, it is to defer destructors.
>> See 0009-memory-prepare-flatview-and-radix-tree-for-rcu-style.patch
>> When MemoryRegion is _del_subregion from mem in updater, it may be
>> still in use by reader --
On 08/09/2012 10:28 AM, liu ping fan wrote:
>>
>> Seems to me that nothing in memory.c can susceptible to races. It must
>> already be called under the big qemu lock, and with the exception of
>> mutators (memory_region_set_*), changes aren't directly visible.
>>
> Yes, what I want to do is "prepa
On 08/09/2012 10:27 AM, liu ping fan wrote:
> On Wed, Aug 8, 2012 at 5:42 PM, Avi Kivity wrote:
>> On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
>>> From: Liu Ping Fan
>>>
>>
>> Please explain the motivation. AFAICT, the big qemu lock is sufficient.
>&
On 08/09/2012 10:27 AM, liu ping fan wrote:
> On Wed, Aug 8, 2012 at 5:20 PM, Avi Kivity wrote:
>> On 08/08/2012 09:25 AM, Liu Ping Fan wrote:
>>> From: Liu Ping Fan
>>>
>>> Using refcnt for mr, so we can separate mr's life cycle management
>>>
On 08/09/2012 10:13 AM, Stefan Bader wrote:
> Avi, was the last version of the patch (only adding the flag to the nested
> MSRs)
> good for submitting to stable from your point of view?
>
Yes, it is correct. I forwarded it to stable, thanks.
--
error compiling committee.c: too many argument
On 08/08/2012 07:27 PM, David Ahern wrote:
> Not sure if KVM is the culprit, but it is the last line shown on the
> console. I have to power cycle the server to reboot.
Have you tried rmmoding the kvm modules before reboot?
Were any guests running during this?
--
error compiling committee.c: t
On 08/08/2012 03:24 PM, Gleb Natapov wrote:
> For apic_set_spiv() to track APIC SW state correctly it needs to see
> previous and next values of the spurious vector register, but currently
> memset() overwrite the old value before apic_set_spiv() get a chance to
> do tracking. Fix it by calling api
On 08/07/2012 05:52 PM, Cornelia Huck wrote:
> Running under a kvm host does not necessarily imply the presence of
> a page mapped above the main memory with the virtio information;
> however, the code includes a hard coded access to that page.
>
> Instead, check for the presence of the page and e
On 08/09/2012 01:34 PM, Takuya Yoshikawa wrote:
> On Tue, 7 Aug 2012 12:57:13 +0200
> Alexander Graf wrote:
>
>> +struct kvm_memory_slot *hva_to_memslot(struct kvm *kvm, hva_t hva)
>> +{
>> +struct kvm_memslots *slots = kvm_memslots(kvm);
>> +struct kvm_memory_slot *memslot;
>> +
>> +
On 08/09/2012 02:57 PM, Gerd Hoffmann wrote:
> Use kvmclock for tsc calibration when running on kvm. Without this the
> tsc frequency calibrated by seabios can be *way* off in case the virtual
> machine is booted on a loaded host. I've seen seabios calibrating 27
> instead of ca. 2800 MHz, result
On 08/08/2012 09:40 PM, Bruce Rogers wrote:
> A command line device probe using just -device "?" gets processed
> after qemu-kvm initializes the accelerator. If /dev/kvm is not
> present, the accelerator check will fail (kvm is defaulted to on),
> which causes libvirt to not be set up to handle qem
On 08/07/2012 06:11 PM, Peter Maydell wrote:
> On 2 August 2012 10:14, Jan Kiszka wrote:
>> On 2012-07-26 16:35, Peter Maydell wrote:
>>> This patch series removes all uses of kvm_irqchip_in_kernel()
>>> from architecture-independent code, by creating a set of more
>>> specific functions instead t
On 08/09/2012 05:01 PM, Avi Kivity wrote:
> On 08/09/2012 04:57 PM, Gerd Hoffmann wrote:
>> Hi,
>>
>>>> +u64 kvm_tsc_khz(void)
>>>> +{
>>>> +u32 eax, ebx, ecx, edx, msr;
>>>> +struct pvclock_vcpu_time_
On 08/09/2012 05:12 PM, Gerd Hoffmann wrote:
> Hi,
>
>>> er, the documentation says 4 bytes (so stack alignment works). I
>>> distinctly remember having a large alignment requirement so we don't
>>> cross a page or slot boundary... something's wrong here.
>>
>> case MSR_KVM_SYSTEM_TIME: {
On 08/09/2012 04:57 PM, Gerd Hoffmann wrote:
> Hi,
>
>>> +u64 kvm_tsc_khz(void)
>>> +{
>>> +u32 eax, ebx, ecx, edx, msr;
>>> +struct pvclock_vcpu_time_info time;
>>> +u32 addr = (u32)(&time);
>>> +u64 khz;
>>> +
>>> +/* check presence and figure msr number */
>>> +cpuid(K
On 08/09/2012 05:18 PM, Gerd Hoffmann wrote:
> Hi,
>
>>> So what do you suggest? The options I see are:
>>>
>>> (1) Use this patch (with alignment issue fixed of course).
>>> (2) Do a full kvmclock implementation. Feels a bit like overkill.
>>> (3) SeaBIOS can fallback to the PIT for tim
On 08/09/2012 06:13 PM, Paolo Bonzini wrote:
> Il 05/07/2012 12:29, Jason Wang ha scritto:
>> Sometimes, virtio device need to configure irq affiniry hint to maximize the
>> performance. Instead of just exposing the irq of a virtqueue, this patch
>> introduce an API to set the affinity for a virtqu
On 08/09/2012 10:26 PM, Alex Williamson wrote:
> On Mon, 2012-08-06 at 13:40 +0300, Avi Kivity wrote:
>> On 08/06/2012 01:38 PM, Avi Kivity wrote:
>>
>> > Regarding the implementation, instead of a linked list, would an array
>> > of counters parallel to the bitma
On 08/10/2012 09:44 AM, liu ping fan wrote:
>>> In the previous discussion, you have suggest add dev->ref++ in
>>> core_region_add. But I think, if we can move it to higher layer --
>>> memory_region_{add,del}_subregion, so we can avoid to duplicate do
>>> this in other xx_region_add.
>>
>> Why wo
On 08/11/2012 12:20 PM, Ren, Yongjie wrote:
> Hi folks,
> I did some basic testing on nested virtualization on Intel x86-64 platform.
> Will KVM support Xen as L1 guest in nested virtualization ?
>
> When I tried "Xen on KVM" mode, I found VMX can't be initialized in L1 Xen
> hypervisor.
> I trie
On 08/10/2012 11:10 AM, Gerd Hoffmann wrote:
> Hi,
>
>>> (1) Use this patch (with alignment issue fixed of course).
>>> (2) Do a full kvmclock implementation. Feels a bit like overkill.
>>> (3) SeaBIOS can fallback to the PIT for timing on machines which
>>> have
On 08/09/2012 09:59 PM, Marcelo Tosatti wrote:
>>
>> > +wrmsr(msr, 0);
>> > +if (time.version < 2 || time.tsc_to_system_mul == 0)
>> > +return 0;
>> > +
>> > +/* go figure tsc frequency */
>> > +khz = pvclock_tsc_khz(&time);
>> > +dprintf(1, "Using kvmclock, msr 0x%x, t
On 08/09/2012 08:02 PM, Alexander Graf wrote:
>
>
> On 09.08.2012, at 12:36, Avi Kivity wrote:
>
>> On 08/09/2012 01:34 PM, Takuya Yoshikawa wrote:
>>> On Tue, 7 Aug 2012 12:57:13 +0200
>>> Alexander Graf wrote:
>>>
>>>> +struct k
On 08/12/2012 12:41 PM, Ren, Yongjie wrote:
>> > #define CPU_BASED_RDTSC_EXITING 0x1000
>> > #define VM_EXIT_ACK_INTR_ON_EXIT0x8000
>> >
>> > Will KVM expose these two features in its vCPU ?
>>
>> Those are two bugs in kvm. The first is trivial to fix, the second is
On 08/09/2012 07:33 PM, Peter Maydell wrote:
> Enable KVM on ARM hosts, now that all the necessary components
> for it exist.
>
> esac
> case "$target_arch2" in
> - i386|x86_64|ppcemb|ppc|ppc64|s390x)
> + arm|i386|x86_64|ppcemb|ppc|ppc64|s390x)
> # Make sure the target and host cpus are c
On 08/09/2012 10:02 PM, Marcelo Tosatti wrote:
> On Thu, Aug 09, 2012 at 05:20:11PM +0300, Avi Kivity wrote:
>> On 08/09/2012 05:18 PM, Gerd Hoffmann wrote:
>> > Hi,
>> >
>> >>> So what do you suggest? The options I see are:
>> >>>
&
On 08/12/2012 02:03 PM, Alexander Graf wrote:
>
> Well, for now I just dropped the whole thing. In general, chances are pretty
> good that an HVA we get notified on with mmu notifiers is representing guest
> memory. And flushing a few times too often shouldn't hurt.
That is not the case, actual
On 08/12/2012 04:12 PM, Gleb Natapov wrote:
> MSR_IA32_DEBUGCTLMSR is zeroed on VMEXIT. Restore it to the correct
> value.
>
> @@ -6222,6 +6222,7 @@ static void atomic_switch_perf_msrs(struct vcpu_vmx
> *vmx)
> static void __noclone vmx_vcpu_run(struct kvm_vcpu *vcpu)
> {
> struct vcpu_vm
On 08/12/2012 04:25 PM, Gleb Natapov wrote:
>> How expensive is this? We may want a follow-on patch to cache it in a
>> per-cpu variable.
>>
> I have patches ready. I couldn't measure any overhead of the
> rdmsr(MSR_IA32_DEBUGCTLMSR).
>
Do you mean while running kvm? How about just running it
On 08/12/2012 08:28 PM, Gleb Natapov wrote:
> On Sun, Aug 12, 2012 at 04:40:48PM +0300, Avi Kivity wrote:
>> On 08/12/2012 04:25 PM, Gleb Natapov wrote:
>>
>> >> How expensive is this? We may want a follow-on patch to cache it in a
>> >> per-cpu variab
On 08/13/2012 12:16 PM, Gleb Natapov wrote:
> Signed-off-by: Gleb Natapov
>
> -int kvm_irq_delivery_to_apic(struct kvm *kvm, struct kvm_lapic *src,
> +int kvm_irq_delivery_to_apic(struct kvm_kernel_irq_routing_entry *e,
> + struct kvm *kvm, struct kvm_lapic *src,
> stru
On 08/13/2012 12:16 PM, Gleb Natapov wrote:
> Here is a quick prototype of what we discussed yesterday. This one
> caches only MSI interrupts for now. The obvious problem is that not
> all interrupts (namely IPIs and MSIs using KVM_CAP_SIGNAL_MSI) use irq
> routing table, so they cannot be cached.
On 08/13/2012 12:16 PM, Gleb Natapov wrote:
> Here is a quick prototype of what we discussed yesterday. This one
> caches only MSI interrupts for now. The obvious problem is that not
> all interrupts (namely IPIs and MSIs using KVM_CAP_SIGNAL_MSI) use irq
> routing table, so they cannot be cached.
On 08/13/2012 01:16 PM, Gleb Natapov wrote:
> On Mon, Aug 13, 2012 at 01:12:46PM +0300, Michael S. Tsirkin wrote:
>> On Mon, Aug 13, 2012 at 12:36:41PM +0300, Avi Kivity wrote:
>> > On 08/13/2012 12:16 PM, Gleb Natapov wrote:
>> > > Here is a quick prototype of wha
On 08/13/2012 01:24 PM, Gleb Natapov wrote:
> On Mon, Aug 13, 2012 at 01:21:33PM +0300, Avi Kivity wrote:
>> On 08/13/2012 01:16 PM, Gleb Natapov wrote:
>> > On Mon, Aug 13, 2012 at 01:12:46PM +0300, Michael S. Tsirkin wrote:
>> >> On Mon, Aug 13, 2012 at 12:3
On 08/13/2012 01:38 PM, Michael S. Tsirkin wrote:
> On Mon, Aug 13, 2012 at 01:31:36PM +0300, Avi Kivity wrote:
>> On 08/13/2012 01:24 PM, Gleb Natapov wrote:
>> > On Mon, Aug 13, 2012 at 01:21:33PM +0300, Avi Kivity wrote:
>> >> On 08/13/2012 01:16 PM, Gleb Natapov
On 08/13/2012 02:01 PM, Gleb Natapov wrote:
>>
>> Actually this is overkill. Suppose we do an apicid->vcpu translation
>> cache? Then we retain O(1) behaviour, no need for a huge cache.
>>
> Not sure I follow.
Unicast MSIs and IPIs can be speeded up by looking up the vcpu using the
apic id, us
On 08/13/2012 02:12 PM, Gleb Natapov wrote:
> On Mon, Aug 13, 2012 at 02:03:51PM +0300, Avi Kivity wrote:
>> On 08/13/2012 02:01 PM, Gleb Natapov wrote:
>> >>
>> >> Actually this is overkill. Suppose we do an apicid->vcpu translation
>> >> cach
On 08/13/2012 02:41 PM, Gleb Natapov wrote:
> On Mon, Aug 13, 2012 at 02:30:49PM +0300, Avi Kivity wrote:
>> On 08/13/2012 02:12 PM, Gleb Natapov wrote:
>> > On Mon, Aug 13, 2012 at 02:03:51PM +0300, Avi Kivity wrote:
>> >> On 08/13/2012 02:01 PM, Gleb Natapov wrot
On 08/13/2012 02:43 PM, Gleb Natapov wrote:
>> MSI does not have shorthand, so it is simpler but the code above does
>> work for APIC_DFR_CLUSTER as far as I can tell and it does not check
>> lowest prio, which is not multicast, but should bot be cached.
>>
> It also a little bit pessimistic for
All processors that support VMX have that feature, and guests (Xen) depend on
it. As we already implement it, advertize it to the guest.
Signed-off-by: Avi Kivity
---
arch/x86/kvm/vmx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
On 08/13/2012 04:27 PM, Anthony Liguori wrote:
> Thanks for pushing this forward! Hopefully this will finally kill off
> qemu-kvm.git for good.
No, it won't. vfio requires a 3.6 kernel, which we cannot assume anyone
has. We'll need the original device assignment code side-by-side.
--
error c
On 08/14/2012 10:33 AM, Jan Kiszka wrote:
>
> KVM_IRQ_LINE is old-style, deprecated, KVM_IRQ_LINE_STATUS (i.e
> injection with feedback to allow lost-tick compensation) is the current
> standard that other archs should pick up.
KVM_IRQ_LINE_STATUS may not make sense on all architectures.
I don't
On 08/12/2012 12:33 PM, Michael S. Tsirkin wrote:
>>
>> Michael, would the interface be more acceptable to you if we added
>> separate ioctls to allocate and free some representation of an irq
>> source ID, gsi pair? For instance, an ioctl might return an idr entry
>> for an irq source ID/gsi obj
On 08/14/2012 02:05 PM, Jan Kiszka wrote:
> On 2012-08-14 13:01, Avi Kivity wrote:
>> On 08/14/2012 10:33 AM, Jan Kiszka wrote:
>>>
>>> KVM_IRQ_LINE is old-style, deprecated, KVM_IRQ_LINE_STATUS (i.e
>>> injection with feedback to allow lost-tick compensati
On 08/10/2012 09:14 PM, Marcelo Tosatti wrote:
> On Tue, Aug 07, 2012 at 05:47:15PM +0800, Xiao Guangrong wrote:
>> Changelog:
>> - introduce KVM_PFN_ERR_RO_FAULT instead of dummy page
>> - introduce KVM_HVA_ERR_BAD and optimize error hva indicators
>>
>> The test case can be found at:
>> http://l
On 08/14/2012 05:00 PM, Jan Kiszka wrote:
>>> The host can prevent this by leaving disabling the guest pmu. But
>>> disabling jump labels for real-time kernels may be acceptable too. We
>>> can probably to it at run time by forcing the slow path at all times.
>> Yes, it is possible to add module
On 08/14/2012 08:27 AM, Alex Williamson wrote:
>> >
>> > Do we need this level of control? Open question I'm just wondering every
>> > time a new feature gets added together with --disable/--enable
>> > switches.
>>
>> I don't think so--it's easy enough for an administrator to disable vfio
>> for
On 08/13/2012 10:31 PM, Anthony Liguori wrote:
> Jan Kiszka writes:
>
>> On 2012-08-13 15:58, Avi Kivity wrote:
>>> On 08/13/2012 04:27 PM, Anthony Liguori wrote:
>>>
>>>> Thanks for pushing this forward! Hopefully this will finally kill off
>>
On 08/01/2012 08:18 AM, Alex Williamson wrote:
> This adds the core of the QEMU VFIO-based PCI device assignment driver.
> To make use of this driver, enable CONFIG_VFIO, CONFIG_VFIO_IOMMU_TYPE1,
> and CONFIG_VFIO_PCI in your host Linux kernel config. Load the vfio-pci
> module. To assign device
On 08/14/2012 05:58 PM, Jan Kiszka wrote:
>>>
>>> And regarding how common they are: Do standard OSes trigger any
>>> jump-label optimized switch during at least their boot-up? I thought so.
>>> In that case, if you co-locate RT and standard OSes on a shared host,
>>> you would have a conflict.
>>>
On 08/14/2012 07:38 PM, Jan Kiszka wrote:
> On 2012-08-14 18:21, Avi Kivity wrote:
>> On 08/14/2012 05:58 PM, Jan Kiszka wrote:
>>>>>
>>>>> And regarding how common they are: Do standard OSes trigger any
>>>>> jump-label optimized switch duri
On 08/14/2012 08:23 PM, Alex Williamson wrote:
>
>> Unrelated nit: memcmp() doesn't return a boolean or a count, so
>> !memcmp() is really unintuitive, at least to me.
>
> I figure we're all pretty used to it growing up on !strcmp though.
I hate that one too.
>> > +
>> > +/* XXX This should mov
On 08/13/2012 07:34 PM, Marcelo Tosatti wrote:
>
> Avi, Gleb, Alex, do you know why it is necessary to support change of
> GPA base again?
BAR moving around.
> Without taking into consideration backwards compatibility, userspace
> can first delete the slot and later create a new one.
Current
On 08/14/2012 01:04 AM, Marcelo Tosatti wrote:
> On Mon, Aug 13, 2012 at 01:34:11PM -0300, Marcelo Tosatti wrote:
>> On Sat, Aug 11, 2012 at 10:37:54AM +1000, Paul Mackerras wrote:
>> > On Fri, Aug 10, 2012 at 03:35:53PM -0300, Marcelo Tosatti wrote:
>> > > There's no plan. I just wanted to confirm
On 08/15/2012 02:04 AM, Alexander Graf wrote:
> From: Alan Cox
>
> Put the parameters the right way around
>
> Addresses https://bugzilla.kernel.org/show_bug.cgi?id=44031
>
Should this go to 3.6 (and backports etc.)?
--
error compiling committee.c: too many arguments to function
--
To unsu
On 08/15/2012 01:09 PM, Alexander Graf wrote:
>
> On 15.08.2012, at 12:07, Avi Kivity wrote:
>
>> On 08/15/2012 02:04 AM, Alexander Graf wrote:
>>> From: Alan Cox
>>>
>>> Put the parameters the right way around
>>>
>>>
201 - 300 of 1565 matches
Mail list logo