Bugs item #1689684, was opened at 2007-03-28 10:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1689684&group_id=180599
Please note that this message will contain a full copy
Bugs item #1689688, was opened at 2007-03-28 10:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1689688&group_id=180599
Please note that this message will contain a full copy
Bugs item #1689714, was opened at 2007-03-28 10:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1689714&group_id=180599
Please note that this message will contain a full copy
On Tue, 2007-03-27 at 08:57 +0200, Avi Kivity wrote:
> Hollis Blanchard wrote:
> > Hi Avi, I was wondering what you think is the right abstraction layer to
> > target for porting KVM to non-x86 architectures? To me it looks like
> > libkvm is the answer.
> >
> > The kernel/userland interface is hea
On Wednesday 28 March 2007, Hollis Blanchard wrote:
> > I don't see a big difference between the ioctl layer and libkvm. In
> > general, a libkvm function is an ioctl, and kvm_callback members are a
> > decoding of kvm_run fields. If you edit kvm_run to suit your needs, you
> > can probably re
Avi,
On Tue, Mar 27, 2007 at 07:10:58PM +0200, Avi Kivity wrote:
> >>
> >
> >The Performance counters (PMU) cannot be fully virtualized, they need to
> >run on the actual MSR registers. The PMU interrupt is controlled by the
> >local APIC. To get overflow-based sampling to work in a guest, we
Hollis Blanchard wrote:
> On Tue, 2007-03-27 at 08:57 +0200, Avi Kivity wrote:
>
>> Hollis Blanchard wrote:
>>
>>> Hi Avi, I was wondering what you think is the right abstraction layer to
>>> target for porting KVM to non-x86 architectures? To me it looks like
>>> libkvm is the answer.
>>>
Stephane Eranian wrote:
>
>> As I'd rather not do that, perhaps we can program the apic to issue an
>> nmi instead of an interrupt while in guest mode. On receipt of nmi, we
>> can call the host perfmon handler directly to interpret the performance
>> counters.
>>
>>
> Yes, but that wou
I was messing around with using the perf counters a couple weeks ago
as a way to get deterministic exits in the instruction stream of the
guest. I used the h/w msr save/restore area to disable the counters
and save the values on guest exit and restore them on entry. I also
set up the LVT to deliver
Attached is a patch that fixes problems with 32-bit guests on 64-bit
hosts. For example, I got damn small linux 0.4.10 to boot with this;
previously it segfaulted during init.
If you have issues with 32-bit guests, please test with this patch and
report. Even if you don't have any issues, te
On Wed, 2007-03-28 at 17:48 +0200, Avi Kivity wrote:
> Hollis Blanchard wrote:
> > On Tue, 2007-03-27 at 08:57 +0200, Avi Kivity wrote:
> >>
> >> I don't think we should be aiming at full source portability.
> >> Virtualization is inherently nonportable, and as it is mostly done in
> >> hardware
>Avi Kivity wrote:
>> Gregory Haskins wrote:
>>> Hi Avi,
>>> You make good points. I will convert to a nest lock design and
>>> resubmit. Should I use two mutexes, or a mutex and spinlock?
>>>
>>> Also, do you have any suggestions on the signum I should use to IPI
>>> the running guest? Shoul
Avi Kivity <[EMAIL PROTECTED]> writes:
>
> Can you run qemu under strace -ttT? Be prepared for a long log.
>
> Also, checking with the -no-kvm option is worthwhile.
Avi:
Can't run under strace. XP starts to boot then blue screens complaining of an
infinite loop in the cirrus driver. I have a
Leslie Mann wrote:
> Avi Kivity <[EMAIL PROTECTED]> writes:
>
>
>> Can you run qemu under strace -ttT? Be prepared for a long log.
>>
>> Also, checking with the -no-kvm option is worthwhile.
>>
>
> Avi:
>
> Can't run under strace. XP starts to boot then blue screens complaining of an
> in
Hollis Blanchard wrote:
>> No, I'm saying that some #ifdeffery in both libkvm and the ioctl
>> interface is unavoidable.
>>
>
> If by #ifdeffery you mean having per-architecture definitions of
> structures like kvm_regs, absolutely. If you mean literal #ifdefs in the
> middle a header file, I
15 matches
Mail list logo
