Hi,
I am wondering how KVM handles debug and breakpoint interrupt? Does it
process them like normal NMI interrupt, or is there any special
processing?
Thanks,
Jun
-
This SF.net email is sponsored by DB2 Express
Download DB2
On 6/25/07, Dor Laor <[EMAIL PROTECTED]> wrote:
> >I am wondering how KVM handles debug and breakpoint interrupt? Does it
> >process them like normal NMI interrupt, or is there any special
> >processing?
> >
>
> I haven't use it but KVM does support qemu'd gdbstub. Both single step
> and breakpoint
[EMAIL PROTECTED] wrote:
> Hi,
>
> I am wondering how KVM handles debug and breakpoint interrupt? Does it
> process them like normal NMI interrupt, or is there any special
> processing?
>
Do u mean int 1/3 handling? Or DR virtualization?
Eddie
--
>I am wondering how KVM handles debug and breakpoint interrupt? Does it
>process them like normal NMI interrupt, or is there any special
>processing?
>
I haven't use it but KVM does support qemu'd gdbstub. Both single step
and breakpoint are possible. From the source code (vmx.c) it seems like
han
Hi Dong,
On 6/25/07, Dong, Eddie <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > I am wondering how KVM handles debug and breakpoint interrupt? Does it
> > process them like normal NMI interrupt, or is there any special
> > processing?
> >
> Do u mean int 1/3 handling? Or DR
[EMAIL PROTECTED] wrote:
> On 6/25/07, Dor Laor <[EMAIL PROTECTED]> wrote:
>>> I am wondering how KVM handles debug and breakpoint interrupt? Does
>>> it process them like normal NMI interrupt, or is there any special
>>> processing?
>>>
>>
>> I haven't use it but KVM does support qemu'd gdbstub
On 6/25/07, Dong, Eddie <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > On 6/25/07, Dor Laor <[EMAIL PROTECTED]> wrote:
> >>> I am wondering how KVM handles debug and breakpoint interrupt? Does
> >>> it process them like normal NMI interrupt, or is there any special
> >>> processing?
> >>
Dor Laor wrote:
Are you sure? the kvm_vmx_exit_handlers function pointer arrays has
the index named EXIT_REASON_EXCEPTION_NMI, so it must be handled as
NMI to me.
>>> This exit reason is either NMI, or software interrupt or exception.
>>>
>>> Refer update_exception_bitm
>On 6/25/07, Dong, Eddie <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>> > On 6/25/07, Dor Laor <[EMAIL PROTECTED]> wrote:
>> >>> I am wondering how KVM handles debug and breakpoint interrupt?
Does
>> >>> it process them like normal NMI interrupt, or is there any
special
>> >>> processing
On 6/25/07, Dor Laor <[EMAIL PROTECTED]> wrote:
> >On 6/25/07, Dong, Eddie <[EMAIL PROTECTED]> wrote:
> >> [EMAIL PROTECTED] wrote:
> >> > On 6/25/07, Dor Laor <[EMAIL PROTECTED]> wrote:
> >> >>> I am wondering how KVM handles debug and breakpoint interrupt?
> Does
> >> >>> it process them like nor
Hello list,
in the past two days I experienced some weird problems with mouse inside
VM guests. Specifically, whenever I started a guest and clicked on its
SDL window, the mouse cursor would get stuck in one of the corners and
not move away from there. What was strange is that everything worked
From: Paul Turner <[EMAIL PROTECTED]>
This just separates vmx/svm specific fields off kvm_vcpu into kvm_vmx_data
and kvm_svm_data fields respectively. Ideally these should be compiled
out depending on target architecture, at least the waste is organized now.
I didn't notice any svm specific fi
From: Paul Turner <[EMAIL PROTECTED]>
Update vmx/emulate to use vmx structure as appropriate.
- Paul
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index b909b54..7af8f34 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -31,7 +31,7 @@ #include "segment_descriptor.h"
MODULE_AUTHOR(
Jun Koi wrote:
> On 6/25/07, Dor Laor <[EMAIL PROTECTED]> wrote:
>>> On 6/25/07, Dong, Eddie <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] wrote:
> On 6/25/07, Dor Laor <[EMAIL PROTECTED]> wrote:
>>> I am wondering how KVM handles debug and breakpoint interrupt?
>>> Does it process
On Sat, 2007-06-23 at 20:41 +0300, Avi Kivity wrote:
> Dong, Eddie wrote:
> > 3: IOAPIC position
> > Though it looks like neutral to have this one in user or kernel
> > space,
> > but I'd like to suggest we only support one model. Considering future
> > VT-d
> > case, hypervisor need to inject
On Mon, 2007-06-25 at 09:45 +0800, Dong, Eddie wrote:
> Sure. Question:
> Should we check the extension API basis or feature sets list?
> I.e. Each API (KVM_CREATE_PIC, KVM_SET_ISA_IRQ_LEVEL) or feature sets:
> KVM_KERNEL_IRQCHIP.
Actually, I have that same question. I currently implemente
On Sun, 2007-06-24 at 23:28 -0400, Avi Kivity wrote:
> Dong, Eddie wrote:
> >> Need to add a way to detect if this functionality is available, via
> >> KVM_CHECK_EXTENSION.
> >>
> >
> > Sure. Question:
> > Should we check the extension API basis or feature sets list?
> > I.e. Each API (KV
On Mon, 2007-06-25 at 11:32 +0800, Dong, Eddie wrote:
> Avi Kivity wrote:
> > Dong, Eddie wrote:
> > We'll add it as soon as it becomes necessary. But isn't it
> > just a memory
> > write?
On real HW, yes. The Intel guys can correct me if I am wrong, but I
think we can actually simplify this in t
>-Original Message-
>From: Gregory Haskins [mailto:[EMAIL PROTECTED]
>Sent: 2007年6月25日 21:43
>To: [EMAIL PROTECTED]
>Cc: Dong, Eddie; kvm-devel@lists.sourceforge.net
>Subject: Re: [kvm-devel] In kernel PIC support: kernel patch
>
>On Sat, 2007-06-23 at 20:41 +0300, Avi Kivity wrote:
>>
On Sat, 2007-06-23 at 10:53 +0300, Avi Kivity wrote:
> Gregory Haskins wrote:
> >
> > In fact, my own implementation puts the ISA-userint model as hanging off
> > the kvm structure as well (which would be replaced with a similar PIC
> > model for layer-2 mode in the future).
> >
> >
>
> The PIC
On Mon, 2007-06-25 at 21:54 +0800, Dong, Eddie wrote:
>
> >-Original Message-
> >From: Gregory Haskins [mailto:[EMAIL PROTECTED]
> >Sent: 2007年6月25日 21:43
> >To: [EMAIL PROTECTED]
> >Cc: Dong, Eddie; kvm-devel@lists.sourceforge.net
> >Subject: Re: [kvm-devel] In kernel PIC support: kerne
I've started to look at these patches to figure out how easily I
could convert the ibmveth driver to use this new infrastructure
and have ran into a few issues. So far the two biggest issues I've
encountered are:
1. The add_inbuf interface passes an sg list. This causes problems for
ibmveth sin
On Mon, Jun 25, 2007 at 10:26:37AM -0500, Brian King wrote:
> 1. The add_inbuf interface passes an sg list. This causes problems for
>ibmveth since its rx buffers cannot be scatterlists.
> 2. The user of this API does not have access to the sk_buf. This causes
>issues for ibmveth since it n
Paul Turner wrote:
> From: Paul Turner <[EMAIL PROTECTED]>
>
> This just separates vmx/svm specific fields off kvm_vcpu into
> kvm_vmx_data and kvm_svm_data fields respectively. Ideally these
> should be compiled out depending on target architecture, at least the
> waste is organized now. I did
Paul Turner wrote:
> From: Paul Turner <[EMAIL PROTECTED]>
>
> Update vmx/emulate to use vmx structure as appropriate.
This must be part of the first patch, otherwise compilation breaks
during a bisect.
-
This SF.net email
>>
>> It can, but a little bit more complicated, and probably unable to
live
>> migration between KVM and Qemu since Qemu only has one IOAPIC.
>
>Good point, but is that a design requirement?
>
Migration between KVM and qemu is not a requirement and I don't see
important value there. When many PV
Christoph Hellwig wrote:
> On Mon, Jun 25, 2007 at 10:26:37AM -0500, Brian King wrote:
>
>> 1. The add_inbuf interface passes an sg list. This causes problems for
>>ibmveth since its rx buffers cannot be scatterlists.
>>
I'm probably missing something. What is wrong with a scatterlist
Dor Laor wrote:
>>> It can, but a little bit more complicated, and probably unable to
>>>
> live
>
>>> migration between KVM and Qemu since Qemu only has one IOAPIC.
>>>
>> Good point, but is that a design requirement?
>>
>>
>
> Migration between KVM and qemu is not a requirem
Gregory Haskins wrote:
>> n paravirt device drivers will want to inject IRQs via the ioapic
>> (when the guest is not paravirt_ops enabled, like older Linux and
>> Windows).
>>
>
> Note that its probably not a requirement to do so. The IOAPIC
> essentially provides a standard mechanism to
Avi Kivity wrote:
> Christoph Hellwig wrote:
>> On Mon, Jun 25, 2007 at 10:26:37AM -0500, Brian King wrote:
>>
>>> 1. The add_inbuf interface passes an sg list. This causes problems for
>>>ibmveth since its rx buffers cannot be scatterlists.
>>>
>
> I'm probably missing something. Wha
Gregory Haskins wrote:
> On Sat, 2007-06-23 at 10:53 +0300, Avi Kivity wrote:
>
>> Gregory Haskins wrote:
>>
>>> In fact, my own implementation puts the ISA-userint model as hanging off
>>> the kvm structure as well (which would be replaced with a similar PIC
>>> model for layer-2 mode in t
Brian King wrote:
>> I'm probably missing something. What is wrong with a scatterlist of
>> length 1?
>>
>
> Absolutely nothing, as long as the interface guarantees I don't see a larger
> scatterlist. With the current implementation it looks to me like this is
> always true, but if we
On Mon, 2007-06-25 at 18:08 -0400, Avi Kivity wrote:
> There's a slight issue that Windows with the ACPI HAL
> is dog slow when virtulalized, but maybe we can find another HAL that
> supports ACPI but doesn't use the APIC.
Is this in reference to the frequent TPR updates, or is there something
e
Gregory Haskins wrote:
> On Mon, 2007-06-25 at 18:08 -0400, Avi Kivity wrote:
>
>> There's a slight issue that Windows with the ACPI HAL
>> is dog slow when virtulalized, but maybe we can find another HAL that
>> supports ACPI but doesn't use the APIC.
>>
>
> Is this in reference to the f
On Mon, 2007-06-25 at 18:25 -0400, Avi Kivity wrote:
> Gregory Haskins wrote:
> > On Mon, 2007-06-25 at 18:08 -0400, Avi Kivity wrote:
> >
> >> There's a slight issue that Windows with the ACPI HAL
> >> is dog slow when virtulalized, but maybe we can find another HAL that
> >> supports ACPI bu
>>
>> MSI is also a good solution; but do all semi-modern guest
>OSes support it?
Linux support MSI from 2.6.18, Vista has full support. But XP doesn't.
>
>I can't say for sure, but I would guess "yes" because IIUC PCI-Express
>only uses MSI (or at least heavily prefers it).
>
>
>>
>> I was ta
Hi, in vmx_vcpu_setup() is this code:
vmcs_writel(GUEST_IDTR_BASE, 0);
vmcs_write32(GUEST_IDTR_LIMIT, 0x);
But if you use SIDT on a real processor, after boot-up, you will see the
real-mode base is in fact 0, but the limit is 0x3ff. That is, in fact,
the base an limit you ar
On 6/26/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> Paul Turner wrote:
> > From: Paul Turner <[EMAIL PROTECTED]>
> >
> > This just separates vmx/svm specific fields off kvm_vcpu into
> > kvm_vmx_data and kvm_svm_data fields respectively. Ideally these
> > should be compiled out depending on target
Greg/Dor:
When thinking to merge APIC device model with PIC, a curious
question: Where does the code base come from? Xen or Qemu? I found there
are many diff from Xen (even excluding name difference).
Eddie
-
This SF.
On Tue, 2007-06-26 at 11:02 +0800, Dong, Eddie wrote:
> Greg/Dor:
> When thinking to merge APIC device model with PIC, a curious
> question: Where does the code base come from? Xen or Qemu? I found there
> are many diff from Xen (even excluding name difference).
> Eddie
I am fairly certain
I'm trying to build the external module and userspace utils from git
sources, but i'm getting the following errors:
[EMAIL PROTECTED] ~/src/kvm/git $ sudo ./makekvm --prefix=/usr/local/kvm
Password:
Already up-to-date.
Already up-to-date.
Install prefix/usr/local/kvm
BIOS directory/usr/loc
Ok, I figured out the problem. It seems to compile fine when I remove
the changes made to svm.c in commit
cfc329b216bc3e54fe1107e8f714c7b3bc133224. I am using my laptop which
is an intel centrino duo processor with vmx.
On 6/26/07, Russell Harmon <[EMAIL PROTECTED]> wrote:
> I'm trying to build th
Because zero sizing then 'over allocating' the struct on intel lets
you save space on svm, same extends obviously for other architectures
in future.
- Paul
On 6/25/07, Jun Koi <[EMAIL PROTECTED]> wrote:
> On 6/26/07, Avi Kivity <[EMAIL PROTECTED]> wrote:
> > Paul Turner wrote:
> > > From: Paul Tu
43 matches
Mail list logo
