On 6/27/07, Dong, Eddie <[EMAIL PROTECTED]> wrote:
>
> >> This exit reason is either NMI, or software interrupt or exception.
> >
> > Dong, could you explain a bit: in which case interrupt 1/3 cause NMI,
> > and in which case they cause exception?
>
> If you set the bitmap for INT 1/3 in EXCEPTION_
>> This exit reason is either NMI, or software interrupt or exception.
>
> Dong, could you explain a bit: in which case interrupt 1/3 cause NMI,
> and in which case they cause exception?
If you set the bitmap for INT 1/3 in EXCEPTION_BITMAP (refer
update_exception_bitmap), you will see
VM Exit f
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/27/07, Gregory Haskins <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-06-27 at 13:33 +0900, Jun Koi wrote:
> > On 6/27/07, Gregory Haskins <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2007-06-27 at 12:51 +0900, Jun Koi wrote:
> > > > BTW, I think that turning on debugger from qemu is a dangerous action
I don't see how I could have a broken compiler (unless building gcc3
with gcc4 breaks it) I'm using gcc-3.4.6-r2 in portage, and the only
c/cxxflags i'm using is -pipe... So I can say I have a working
compiler.
Also, compiling it with my gcc4 compiler (which is what I built my
entire system on) br
On Wed, 2007-06-27 at 13:33 +0900, Jun Koi wrote:
> On 6/27/07, Gregory Haskins <[EMAIL PROTECTED]> wrote:
> > On Wed, 2007-06-27 at 12:51 +0900, Jun Koi wrote:
> > > BTW, I think that turning on debugger from qemu is a dangerous action,
> > > from security point of view. Once the gdbserver is star
On 6/27/07, Gregory Haskins <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-06-27 at 12:51 +0900, Jun Koi wrote:
> > BTW, I think that turning on debugger from qemu is a dangerous action,
> > from security point of view. Once the gdbserver is started, anybody
> > can connect to it (with gdb) and modify V
On Wed, 2007-06-27 at 12:51 +0900, Jun Koi wrote:
> BTW, I think that turning on debugger from qemu is a dangerous action,
> from security point of view. Once the gdbserver is started, anybody
> can connect to it (with gdb) and modify VM memory in anyway he wants
> (like overwrite kernel with malic
BTW, I think that turning on debugger from qemu is a dangerous action,
from security point of view. Once the gdbserver is started, anybody
can connect to it (with gdb) and modify VM memory in anyway he wants
(like overwrite kernel with malicious code). The problem why this is
feasible is because th
Russell Harmon wrote:
> Also, now that I think about it, shouldn't this code be in #ifdef
> statements (or something) so it is not compiled in on an intel target?
>
No, but you could comment out kvm-amd in Kconfig to work around your
issue. You've got a broken compiler, this changeset is fine
Also, now that I think about it, shouldn't this code be in #ifdef
statements (or something) so it is not compiled in on an intel target?
On 6/26/07, Russell Harmon <[EMAIL PROTECTED]> wrote:
> are you doing it in the kernel tree, or the userspace tree. I forgot
> to mention that the offending file
are you doing it in the kernel tree, or the userspace tree. I forgot
to mention that the offending files are in the kernel tree. The output
of git show cfc329b216bc3e54fe1107e8f714c7b3bc133224 in the kernel
tree is as follows:
commit cfc329b216bc3e54fe1107e8f714c7b3bc133224
Author: Joerg Roedel <[
Dong, Eddie wrote:
> So I have 2 choices:
> 1: Port PIC to APIC patch which will use irqdevice abstraction layer and
> V09 irq injection path + bug fix mentioned above.
>
> 2: Port APIC to PIC patch (have above mentioned issue fixed) which
> eliminates irqdevice abstraction layer.
> We can discuss
Russell Harmon wrote:
> 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.
>
I don't have a cfc329b216bc3e54fe1107e8f714
There is a bug in the APIC V09 patch when porting Xen
find_highest_vector to find_highest_bit,
here is the prototype fix. (Not tested)
diff --git a/drivers/kvm/lapic.c b/drivers/kvm/lapic.c
index 602e94c..64264a0 100644
--- a/drivers/kvm/lapic.c
+++ b/drivers/kvm/lapic.c
@@ -62,12 +62,21 @@ stru
>>
>> If you make this
>>
>> + union {
>> + struct kvm_vmx_data vmx[1];
>> +struct kvm_svm_data svm[1];
>> + };
>>
>> then we can later change it to a zero-sized array with variable-size
>> allocation, with no additional code changes.
>>
>
> Why do we want to make
On Tue, 2007-06-26 at 00:36 -0700, Dor Laor wrote:
>
> Regarding merging it with mainline, if the AMD problems are over (as I
> think they are) we can do it.
Did someone figure out what was wrong with the svm.c changes? Cool! Is
the patch checked into the branch?
Jun Koi wrote:
> On 6/26/07, Dor Laor <[EMAIL PROTECTED]> wrote:
>> ...
>> +static __init struct kvm_paravirt_state *paravirt_alloc_state(void)
>> +{
>> + struct kvm_paravirt_state *state;
>> +
>> + state = (void *)get_zeroed_page(GFP_KERNEL);
>> + if (!state)
>> + g
Dor Laor wrote:
> ...
> +static __init struct kvm_paravirt_state *paravirt_alloc_state(void)
> +{
> + struct kvm_paravirt_state *state;
> +
> + state = (void *)get_zeroed_page(GFP_KERNEL);
> + if (!state)
> + goto err;
> +
> + state->vmca = (void *)get_zeroed_page(GFP_KE
On 6/26/07, Dor Laor <[EMAIL PROTECTED]> wrote:
> ...
> +static __init struct kvm_paravirt_state *paravirt_alloc_state(void)
> +{
> + struct kvm_paravirt_state *state;
> +
> + state = (void *)get_zeroed_page(GFP_KERNEL);
> + if (!state)
> + goto err;
> +
> + st
Dor Laor wrote:
>> 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).
>>> E
...
+static __init struct kvm_paravirt_state *paravirt_alloc_state(void)
+{
+ struct kvm_paravirt_state *state;
+
+ state = (void *)get_zeroed_page(GFP_KERNEL);
+ if (!state)
+ goto err;
+
+ state->vmca = (void *)get_zeroed_page(GFP_KERNEL);
+ if (!state-
>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 ce
23 matches
Mail list logo
