> From: Marcelo Tosatti
> Sent: Tuesday, August 23, 2011 6:47 PM
>
> > >+ if (!apic->lapic_timer.tscdeadline)
> > >+ return;
> > >+
> > >+ tsc_target = kvm_x86_ops->
> > >+ guest_to_host_tsc(apic->lapic_timer.tscdeadline);
> > >+ rdtscll
Hi, Avi,
Here comes the patch:
KVM: APIC: avoid instruction emulation for EOI writes
Instruction emulation for EOI writes can be skipped, since sane
guest simply uses MOV instead of string operations. This is a nice
improvement when guest doesn't support x2apic or hyper-V EOI
On 08/29/2011 01:14 AM, Kevin O'Connor wrote:
On Sun, Aug 28, 2011 at 10:42:49PM +0200, Jan Kiszka wrote:
> On 2011-08-28 20:54, Alexander Graf wrote:
> >
> > On 28.08.2011, at 02:42, Avi Kivity wrote:
> >
> >> On 08/26/2011 08:32 AM, ya su wrote:
> >>> hi,Avi:
> >>>
> >>> I met t
On Sun, Aug 28, 2011 at 10:34:45AM +0300, Avi Kivity wrote:
> On 08/26/2011 01:03 AM, David Evensky wrote:
> >I need to specify the physical address because I need to ioremap the
> >memory during boot.
>
> Did you consider pci_ioremap_bar()?
No, the code needs a physical memory address, not a PCI
On Sun, Aug 28, 2011 at 10:42:49PM +0200, Jan Kiszka wrote:
> On 2011-08-28 20:54, Alexander Graf wrote:
> >
> > On 28.08.2011, at 02:42, Avi Kivity wrote:
> >
> >> On 08/26/2011 08:32 AM, ya su wrote:
> >>> hi,Avi:
> >>>
> >>> I met the same problem, tons of hpet vm_exits(vector 209, fault
>
On 2011-08-28 20:54, Alexander Graf wrote:
>
> On 28.08.2011, at 02:42, Avi Kivity wrote:
>
>> On 08/26/2011 08:32 AM, ya su wrote:
>>> hi,Avi:
>>>
>>> I met the same problem, tons of hpet vm_exits(vector 209, fault
>>> address is in the guest vm's hpet mmio range), even I disable hpet
>>> de
On 28.08.2011, at 02:42, Avi Kivity wrote:
> On 08/26/2011 08:32 AM, ya su wrote:
>> hi,Avi:
>>
>> I met the same problem, tons of hpet vm_exits(vector 209, fault
>> address is in the guest vm's hpet mmio range), even I disable hpet
>> device in win7 guest vm, it still produce a larget amoun
On 08/28/2011 04:56 PM, Joerg Roedel wrote:
On Sun, Aug 28, 2011 at 04:14:00PM +0300, Avi Kivity wrote:
> On 08/26/2011 12:24 PM, Roedel, Joerg wrote:
>> The biggest problem with this approach is that it has to happen in the
>> context of the given process. Linux can't really modify an mm whi
On Sun, Aug 28, 2011 at 04:14:00PM +0300, Avi Kivity wrote:
> On 08/26/2011 12:24 PM, Roedel, Joerg wrote:
>> The biggest problem with this approach is that it has to happen in the
>> context of the given process. Linux can't really modify an mm which
>> which belong to another context in a safe w
On 08/26/2011 12:24 PM, Roedel, Joerg wrote:
>
> As I see it there are two options: (a) make subsequent accesses from
> userspace or the guest result in either a SIGBUS that userspace must
> either deal with or die, or (b) replace the mapping with a dummy RO
> mapping containing 0xff, with an
On 08/23/2011 05:10 PM, Jan Kiszka wrote:
On 2011-08-23 16:02, Anthony Liguori wrote:
> On 08/23/2011 08:02 AM, Jan Kiszka wrote:
>> On 2011-08-23 14:40, Anthony Liguori wrote:
>>> You should be able to just use an eventfd or pipe.
>>>
>>> Better yet, we should look at using GThreadPool to re
On 08/26/2011 08:32 AM, ya su wrote:
hi,Avi:
I met the same problem, tons of hpet vm_exits(vector 209, fault
address is in the guest vm's hpet mmio range), even I disable hpet
device in win7 guest vm, it still produce a larget amount of vm_exits
when trace-cmd ; I add -no-hpet to start the
On 08/26/2011 01:03 AM, David Evensky wrote:
I need to specify the physical address because I need to ioremap the
memory during boot.
Did you consider pci_ioremap_bar()?
The production issue I think is a memory limitation. We certainly do
use QEMU a lot; but for this the kvm tool is a better
13 matches
Mail list logo
