[PATCH 0 of 3] kvmctl code refactoring part 1

[PATCH 0 of 3] kvmctl code refactoring part 1

[Jerone Young]

These patches are the beginning of the refactoring  of the current kvmctl.
To begin the main focus is to refcator the x86 code to allow other
architectures to easily add support to kvmctl.

These will all be small for easy review and criticism. So please fire away :-)

Jerone Young <jyoung5-r/Jw6+rmf7EvE5x8rO2Teg@public.gmane.org>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[PATCH 1 of 3] Move x86 kvmcallback structure to kvmctl-x86.h header

[Jerone Young]

# HG changeset patch
# User Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
# Date 1193618330 18000
# Node ID 3bf072e498768885ab96b7ccb668b61c96db0e83
# Parent  a6f7c585fe76f9563fd061cfe3e772532ab27952
Move x86 kvmcallback structure to kvmctl-x86.h header.

This patch moves the kvmcallback structure that is currently in kvmctl.h
into an arch specific header.

Signed-off-by: Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

new file mode 100644

diff --git a/user/kvmctl-x86.h b/user/kvmctl-x86.h
new file mode 100644
--- /dev/null
+++ b/user/kvmctl-x86.h
@@ -0,0 +1,54 @@
+#ifndef KVMCTL_X86_H
+#define KVMCTL_X86_H
+
+/*!
+ * \brief KVM callbacks structure
+ *
+ * This structure holds pointers to various functions that KVM will call
+ * when it encounters something that cannot be virtualized, such as
+ * accessing hardware devices via MMIO or regular IO.
+ */
+struct kvm_callbacks {
+	/// For 8bit IO reads from the guest (Usually when executing 'inb')
+    int (*inb)(void *opaque, uint16_t addr, uint8_t *data);
+	/// For 16bit IO reads from the guest (Usually when executing 'inw')
+    int (*inw)(void *opaque, uint16_t addr, uint16_t *data);
+	/// For 32bit IO reads from the guest (Usually when executing 'inl')
+    int (*inl)(void *opaque, uint16_t addr, uint32_t *data);
+	/// For 8bit IO writes from the guest (Usually when executing 'outb')
+    int (*outb)(void *opaque, uint16_t addr, uint8_t data);
+	/// For 16bit IO writes from the guest (Usually when executing 'outw')
+    int (*outw)(void *opaque, uint16_t addr, uint16_t data);
+	/// For 32bit IO writes from the guest (Usually when executing 'outl')
+    int (*outl)(void *opaque, uint16_t addr, uint32_t data);
+	/// For 8bit memory reads from unmapped memory (For MMIO devices)
+    int (*readb)(void *opaque, uint64_t addr, uint8_t *data);
+	/// For 16bit memory reads from unmapped memory (For MMIO devices)
+    int (*readw)(void *opaque, uint64_t addr, uint16_t *data);
+	/// For 32bit memory reads from unmapped memory (For MMIO devices)
+    int (*readl)(void *opaque, uint64_t addr, uint32_t *data);
+	/// For 64bit memory reads from unmapped memory (For MMIO devices)
+    int (*readq)(void *opaque, uint64_t addr, uint64_t *data);
+	/// For 8bit memory writes to unmapped memory (For MMIO devices)
+    int (*writeb)(void *opaque, uint64_t addr, uint8_t data);
+	/// For 16bit memory writes to unmapped memory (For MMIO devices)
+    int (*writew)(void *opaque, uint64_t addr, uint16_t data);
+	/// For 32bit memory writes to unmapped memory (For MMIO devices)
+    int (*writel)(void *opaque, uint64_t addr, uint32_t data);
+	/// For 64bit memory writes to unmapped memory (For MMIO devices)
+    int (*writeq)(void *opaque, uint64_t addr, uint64_t data);
+    int (*debug)(void *opaque, int vcpu);
+	/*!
+	 * \brief Called when the VCPU issues an 'hlt' instruction.
+	 *
+	 * Typically, you should yeild here to prevent 100% CPU utilization
+	 * on the host CPU.
+	 */
+    int (*halt)(void *opaque, int vcpu);
+    int (*shutdown)(void *opaque, int vcpu);
+    int (*io_window)(void *opaque);
+    int (*try_push_interrupts)(void *opaque);
+    void (*post_kvm_run)(void *opaque, int vcpu);
+    int (*pre_kvm_run)(void *opaque, int vcpu);
+};
+#endif
diff --git a/user/kvmctl.h b/user/kvmctl.h
--- a/user/kvmctl.h
+++ b/user/kvmctl.h
@@ -27,56 +27,10 @@ struct kvm_context;
 
 typedef struct kvm_context *kvm_context_t;
 
-/*!
- * \brief KVM callbacks structure
- *
- * This structure holds pointers to various functions that KVM will call
- * when it encounters something that cannot be virtualized, such as
- * accessing hardware devices via MMIO or regular IO.
- */
-struct kvm_callbacks {
-	/// For 8bit IO reads from the guest (Usually when executing 'inb')
-    int (*inb)(void *opaque, uint16_t addr, uint8_t *data);
-	/// For 16bit IO reads from the guest (Usually when executing 'inw')
-    int (*inw)(void *opaque, uint16_t addr, uint16_t *data);
-	/// For 32bit IO reads from the guest (Usually when executing 'inl')
-    int (*inl)(void *opaque, uint16_t addr, uint32_t *data);
-	/// For 8bit IO writes from the guest (Usually when executing 'outb')
-    int (*outb)(void *opaque, uint16_t addr, uint8_t data);
-	/// For 16bit IO writes from the guest (Usually when executing 'outw')
-    int (*outw)(void *opaque, uint16_t addr, uint16_t data);
-	/// For 32bit IO writes from the guest (Usually when executing 'outl')
-    int (*outl)(void *opaque, uint16_t addr, uint32_t data);
-	/// For 8bit memory reads from unmapped memory (For MMIO devices)
-    int (*readb)(void *opaque, uint64_t addr, uint8_t *data);
-	/// For 16bit memory reads from unmapped memory (For MMIO devices)
-    int (*readw)(void *opaque, uint64_t addr, uint16_t *data);
-	/// For 32bit memory reads from unmapped memory (For MMIO devices)
-    int (*readl)(void *opaque, uint64_t addr, uint32_t *data);
-	/// For 64bit memory reads from unmapped memory (For MMIO devices)
-    int (*readq)(void *opaque, uint64_t addr, uint64_t *data);
-	/// For 8bit memory writes to unmapped memory (For MMIO devices)
-    int (*writeb)(void *opaque, uint64_t addr, uint8_t data);
-	/// For 16bit memory writes to unmapped memory (For MMIO devices)
-    int (*writew)(void *opaque, uint64_t addr, uint16_t data);
-	/// For 32bit memory writes to unmapped memory (For MMIO devices)
-    int (*writel)(void *opaque, uint64_t addr, uint32_t data);
-	/// For 64bit memory writes to unmapped memory (For MMIO devices)
-    int (*writeq)(void *opaque, uint64_t addr, uint64_t data);
-    int (*debug)(void *opaque, int vcpu);
-	/*!
-	 * \brief Called when the VCPU issues an 'hlt' instruction.
-	 *
-	 * Typically, you should yeild here to prevent 100% CPU utilization
-	 * on the host CPU.
-	 */
-    int (*halt)(void *opaque, int vcpu);
-    int (*shutdown)(void *opaque, int vcpu);
-    int (*io_window)(void *opaque);
-    int (*try_push_interrupts)(void *opaque);
-    void (*post_kvm_run)(void *opaque, int vcpu);
-    int (*pre_kvm_run)(void *opaque, int vcpu);
-};
+/* Add info from arch specific header */
+#if defined(__x86_64__) || defined(__i386__)
+#include "kvmctl-x86.h"
+#endif
 
 /*!
  * \brief Create new KVM context

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [PATCH 1 of 3] Move x86 kvmcallback structure tokvmctl-x86.h header

[Zhang, Xiantao]

Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> # Date 1193618330 18000
> # Node ID 3bf072e498768885ab96b7ccb668b61c96db0e83
> # Parent  a6f7c585fe76f9563fd061cfe3e772532ab27952
> Move x86 kvmcallback structure to kvmctl-x86.h header.
> 
> This patch moves the kvmcallback structure that is currently in
> kvmctl.h into an arch specific header.
> 
> Signed-off-by: Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> 
> new file mode 100644
> 
> diff --git a/user/kvmctl-x86.h b/user/kvmctl-x86.h
> new file mode 100644
> --- /dev/null
> +++ b/user/kvmctl-x86.h
> @@ -0,0 +1,54 @@
> +#ifndef KVMCTL_X86_H
> +#define KVMCTL_X86_H
> +
> +/*!
> + * \brief KVM callbacks structure
> + *
> + * This structure holds pointers to various functions that KVM will
> call + * when it encounters something that cannot be virtualized,
> such as + * accessing hardware devices via MMIO or regular IO.
> + */
> +struct kvm_callbacks {
> +	/// For 8bit IO reads from the guest (Usually when executing
'inb')
> +    int (*inb)(void *opaque, uint16_t addr, uint8_t *data);
> +	/// For 16bit IO reads from the guest (Usually when executing
'inw')
> +    int (*inw)(void *opaque, uint16_t addr, uint16_t *data);

I don't know the privious story about this thread, but now I can't
understand the move. Why do we move all the structure to arch-specific ?
For IA64 side, almostly we can reuse them directly, and just see some
special fields as arch-specific. So, I think, we should keep common
fields in kvmctl.h.  

> 
>  /*!
>   * \brief Create new KVM context
> 
>
------------------------------------------------------------------------
-
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a
> browser. Download your FREE copy of Splunk now >>
> http://get.splunk.com/ _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure tokvmctl-x86.h header

[Hollis Blanchard]

On Mon, 2007-10-29 at 09:13 +0800, Zhang, Xiantao wrote:
> Jerone Young wrote:
> > # HG changeset patch
> > # User Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> > # Date 1193618330 18000
> > # Node ID 3bf072e498768885ab96b7ccb668b61c96db0e83
> > # Parent  a6f7c585fe76f9563fd061cfe3e772532ab27952
> > Move x86 kvmcallback structure to kvmctl-x86.h header.
> > 
> > This patch moves the kvmcallback structure that is currently in
> > kvmctl.h into an arch specific header.
> > 
> > Signed-off-by: Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> > 
> > new file mode 100644
> > 
> > diff --git a/user/kvmctl-x86.h b/user/kvmctl-x86.h
> > new file mode 100644
> > --- /dev/null
> > +++ b/user/kvmctl-x86.h
> > @@ -0,0 +1,54 @@
> > +#ifndef KVMCTL_X86_H
> > +#define KVMCTL_X86_H
> > +
> > +/*!
> > + * \brief KVM callbacks structure
> > + *
> > + * This structure holds pointers to various functions that KVM will
> > call + * when it encounters something that cannot be virtualized,
> > such as + * accessing hardware devices via MMIO or regular IO.
> > + */
> > +struct kvm_callbacks {
> > +	/// For 8bit IO reads from the guest (Usually when executing
> 'inb')
> > +    int (*inb)(void *opaque, uint16_t addr, uint8_t *data);
> > +	/// For 16bit IO reads from the guest (Usually when executing
> 'inw')
> > +    int (*inw)(void *opaque, uint16_t addr, uint16_t *data);
> 
> I don't know the privious story about this thread, but now I can't
> understand the move. Why do we move all the structure to arch-specific ?
> For IA64 side, almostly we can reuse them directly, and just see some
> special fields as arch-specific. So, I think, we should keep common
> fields in kvmctl.h.  

Are you suggesting that kvm_callbacks should be the union of all
callbacks used on all architectures, and for any given architecture only
a subset are actually used?

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure tokvmctl-x86.h header

[Anthony Liguori]

Hollis Blanchard wrote:
>> I don't know the privious story about this thread, but now I can't
>> understand the move. Why do we move all the structure to arch-specific ?
>> For IA64 side, almostly we can reuse them directly, and just see some
>> special fields as arch-specific. So, I think, we should keep common
>> fields in kvmctl.h.  
>>     
>
> Are you suggesting that kvm_callbacks should be the union of all
> callbacks used on all architectures, and for any given architecture only
> a subset are actually used?
>   

I think two separate callback structures would make more sense.

Quite a few of the callbacks should have common implementations.  For 
instance, all of the io callbacks and the io_window callback should be 
the same.  I would expect most architectures have a concept of a "halt" 
so that should probably be the same too.  That pretty much covers the 
majority of the callbacks structure :-)

Regards,

Anthony Liguori


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure tokvmctl-x86.h header

[Zhang, Xiantao]

Anthony Liguori wrote:
> Hollis Blanchard wrote:
>>> I don't know the privious story about this thread, but now I can't
>>> understand the move. Why do we move all the structure to
>>> arch-specific ? For IA64 side, almostly we can reuse them directly,
>>> and just see some special fields as arch-specific. So, I think, we
>>> should keep common fields in kvmctl.h. 
>>> 
>> 
>> Are you suggesting that kvm_callbacks should be the union of all
>> callbacks used on all architectures, and for any given architecture
>> only a subset are actually used? 
>> 
> 
> I think two separate callback structures would make more sense.
> 
> Quite a few of the callbacks should have common implementations.  For
> instance, all of the io callbacks and the io_window callback should be
> the same.  I would expect most architectures have a concept of a
> "halt" so that should probably be the same too.  That pretty much
> covers the majority of the callbacks structure :-)

Agree. 

> Regards,
> 
> Anthony Liguori

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure tokvmctl-x86.h header

[Hollis Blanchard]

On Mon, 2007-10-29 at 10:41 +0800, Zhang, Xiantao wrote:
> Anthony Liguori wrote:
> > Hollis Blanchard wrote:
> >>> I don't know the privious story about this thread, but now I can't
> >>> understand the move. Why do we move all the structure to
> >>> arch-specific ? For IA64 side, almostly we can reuse them directly,
> >>> and just see some special fields as arch-specific. So, I think, we
> >>> should keep common fields in kvmctl.h. 
> >>> 
> >> 
> >> Are you suggesting that kvm_callbacks should be the union of all
> >> callbacks used on all architectures, and for any given architecture
> >> only a subset are actually used? 
> >> 
> > 
> > I think two separate callback structures would make more sense.
> > 
> > Quite a few of the callbacks should have common implementations.  For
> > instance, all of the io callbacks and the io_window callback should be
> > the same.  I would expect most architectures have a concept of a
> > "halt" so that should probably be the same too.  That pretty much
> > covers the majority of the callbacks structure :-)
> 
> Agree. 

OK, are you changing your position then? Anthony is saying there should
be multiple callback data structure definitions, but that the
*implementations* of some of those callbacks should be shared. For
example:

ia64.h:
        struct kvm_callbacks {
                ...
                .inb = pio_inb,
        };

x86.h:
        struct kvm_callbacks {
                ...
                .inb = pio_inb,
        };

pio.c (built only for ia64 and x86):
        int pio_inb(port) {
                ...
        }

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure tokvmctl-x86.h header

[Anthony Liguori]

Hollis Blanchard wrote:
> On Mon, 2007-10-29 at 10:41 +0800, Zhang, Xiantao wrote:
>   
>> Anthony Liguori wrote:
>>     
>>> Hollis Blanchard wrote:
>>>       
>>>>> I don't know the privious story about this thread, but now I can't
>>>>> understand the move. Why do we move all the structure to
>>>>> arch-specific ? For IA64 side, almostly we can reuse them directly,
>>>>> and just see some special fields as arch-specific. So, I think, we
>>>>> should keep common fields in kvmctl.h. 
>>>>>
>>>>>           
>>>> Are you suggesting that kvm_callbacks should be the union of all
>>>> callbacks used on all architectures, and for any given architecture
>>>> only a subset are actually used? 
>>>>
>>>>         
>>> I think two separate callback structures would make more sense.
>>>
>>> Quite a few of the callbacks should have common implementations.  For
>>> instance, all of the io callbacks and the io_window callback should be
>>> the same.  I would expect most architectures have a concept of a
>>> "halt" so that should probably be the same too.  That pretty much
>>> covers the majority of the callbacks structure :-)
>>>       
>> Agree. 
>>     
>
> OK, are you changing your position then? Anthony is saying there should
> be multiple callback data structure definitions, but that the
> *implementations* of some of those callbacks should be shared. For
> example:
>
> ia64.h:
>         struct kvm_callbacks {
>                 ...
>                 .inb = pio_inb,
>         };
>
> x86.h:
>         struct kvm_callbacks {
>                 ...
>                 .inb = pio_inb,
>         };
>
> pio.c (built only for ia64 and x86):
>         int pio_inb(port) {
>                 ...
>         }
>   

I was actually advocating splitting the kvm_callbacks structure into two 
separate structures, one being architecture specific.  But I don't think 
it's *that* important.

Regards,

Anthony Liguori



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [kvm-ppc-devel] [PATCH 1 of 3] Move x86kvmcallback structure tokvmctl-x86.h header

[Zhang, Xiantao]

>>> call + * when it encounters something that cannot be virtualized,
>>> such as + * accessing hardware devices via MMIO or regular IO. + */
>>> +struct kvm_callbacks {
>>> +	/// For 8bit IO reads from the guest (Usually when executing
>>> 'inb') +    int (*inb)(void *opaque, uint16_t addr, uint8_t *data);
>>> +	/// For 16bit IO reads from the guest (Usually when executing
>>> 'inw') +    int (*inw)(void *opaque, uint16_t addr, uint16_t *data);
>> 
>> I don't know the privious story about this thread, but now I can't
>> understand the move. Why do we move all the structure to
>> arch-specific ? For IA64 side, almostly we can reuse them directly,
>> and just see some special fields as arch-specific. So, I think, we
>> should keep common fields in kvmctl.h.
> 
> Are you suggesting that kvm_callbacks should be the union of all
> callbacks used on all architectures, and for any given architecture
> only a subset are actually used?

No, not a union. I think we should keep some common fields for all
archs.  At least, io_callbacks should be same for all archs. 
So, we need to split them into two parts, one common and the other one
is arch-specific.  Maybe we should add an filed, such as arch to hold
arch-specific fields, instead of moving them all to kvmctl-x86.h 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [kvm-ppc-devel] [PATCH 1 of 3] Move x86kvmcallback structure tokvmctl-x86.h header

[Hollis Blanchard]

On Mon, 2007-10-29 at 10:41 +0800, Zhang, Xiantao wrote:
> >>> call + * when it encounters something that cannot be virtualized,
> >>> such as + * accessing hardware devices via MMIO or regular IO. + */
> >>> +struct kvm_callbacks {
> >>> +	/// For 8bit IO reads from the guest (Usually when executing
> >>> 'inb') +    int (*inb)(void *opaque, uint16_t addr, uint8_t *data);
> >>> +	/// For 16bit IO reads from the guest (Usually when executing
> >>> 'inw') +    int (*inw)(void *opaque, uint16_t addr, uint16_t *data);
> >> 
> >> I don't know the privious story about this thread, but now I can't
> >> understand the move. Why do we move all the structure to
> >> arch-specific ? For IA64 side, almostly we can reuse them directly,
> >> and just see some special fields as arch-specific. So, I think, we
> >> should keep common fields in kvmctl.h.
> > 
> > Are you suggesting that kvm_callbacks should be the union of all
> > callbacks used on all architectures, and for any given architecture
> > only a subset are actually used?
> 
> No, not a union. I think we should keep some common fields for all
> archs.  At least, io_callbacks should be same for all archs. 

Really? The *PIO* callbacks are the same? (PowerPC doesn't do PIO at
all, and I'm almost positive that S390 doesn't either.)

> So, we need to split them into two parts, one common and the other one
> is arch-specific.  Maybe we should add an filed, such as arch to hold
> arch-specific fields, instead of moving them all to kvmctl-x86.h 

Arch-specific code must handle the kernel->user returns anyways, so
having a common/arch-specific data structure split buys us nothing. The
reason we will have that split in the general KVM code (e.g. ioctl
handling) is that there is common *code*, and so it needs to work with
common data structures. That is not the case here.

If your arch has PIO, you're welcome to create PIO callbacks, and you
can even share the implementation of those callbacks by building a
shared pio.c. This can and should be done with completely arch-specific
callback structures.

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [PATCH 1 of 3] Move x86 kvmcallback structure to kvmctl-x86.h header

[Anthony Liguori]

Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> # Date 1193618330 18000
> # Node ID 3bf072e498768885ab96b7ccb668b61c96db0e83
> # Parent  a6f7c585fe76f9563fd061cfe3e772532ab27952
> Move x86 kvmcallback structure to kvmctl-x86.h header.
>
> This patch moves the kvmcallback structure that is currently in kvmctl.h
> into an arch specific header.
>
> Signed-off-by: Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> new file mode 100644
>
> diff --git a/user/kvmctl-x86.h b/user/kvmctl-x86.h
> new file mode 100644
> --- /dev/null
> +++ b/user/kvmctl-x86.h
> @@ -0,0 +1,54 @@
> +#ifndef KVMCTL_X86_H
> +#define KVMCTL_X86_H
> +
> +/*!
> + * \brief KVM callbacks structure
> + *
> + * This structure holds pointers to various functions that KVM will call
> + * when it encounters something that cannot be virtualized, such as
> + * accessing hardware devices via MMIO or regular IO.
> + */
> +struct kvm_callbacks {
> +	/// For 8bit IO reads from the guest (Usually when executing 'inb')
> +    int (*inb)(void *opaque, uint16_t addr, uint8_t *data);
> +	/// For 16bit IO reads from the guest (Usually when executing 'inw')
> +    int (*inw)(void *opaque, uint16_t addr, uint16_t *data);
> +	/// For 32bit IO reads from the guest (Usually when executing 'inl')
> +    int (*inl)(void *opaque, uint16_t addr, uint32_t *data);
> +	/// For 8bit IO writes from the guest (Usually when executing 'outb')
> +    int (*outb)(void *opaque, uint16_t addr, uint8_t data);
> +	/// For 16bit IO writes from the guest (Usually when executing 'outw')
> +    int (*outw)(void *opaque, uint16_t addr, uint16_t data);
> +	/// For 32bit IO writes from the guest (Usually when executing 'outl')
> +    int (*outl)(void *opaque, uint16_t addr, uint32_t data);
> +	/// For 8bit memory reads from unmapped memory (For MMIO devices)
> +    int (*readb)(void *opaque, uint64_t addr, uint8_t *data);
> +	/// For 16bit memory reads from unmapped memory (For MMIO devices)
> +    int (*readw)(void *opaque, uint64_t addr, uint16_t *data);
> +	/// For 32bit memory reads from unmapped memory (For MMIO devices)
> +    int (*readl)(void *opaque, uint64_t addr, uint32_t *data);
> +	/// For 64bit memory reads from unmapped memory (For MMIO devices)
> +    int (*readq)(void *opaque, uint64_t addr, uint64_t *data);
> +	/// For 8bit memory writes to unmapped memory (For MMIO devices)
> +    int (*writeb)(void *opaque, uint64_t addr, uint8_t data);
> +	/// For 16bit memory writes to unmapped memory (For MMIO devices)
> +    int (*writew)(void *opaque, uint64_t addr, uint16_t data);
> +	/// For 32bit memory writes to unmapped memory (For MMIO devices)
> +    int (*writel)(void *opaque, uint64_t addr, uint32_t data);
> +	/// For 64bit memory writes to unmapped memory (For MMIO devices)
> +    int (*writeq)(void *opaque, uint64_t addr, uint64_t data);
> +    int (*debug)(void *opaque, int vcpu);
> +	/*!
> +	 * \brief Called when the VCPU issues an 'hlt' instruction.
> +	 *
> +	 * Typically, you should yeild here to prevent 100% CPU utilization
> +	 * on the host CPU.
> +	 */
> +    int (*halt)(void *opaque, int vcpu);
> +    int (*shutdown)(void *opaque, int vcpu);
> +    int (*io_window)(void *opaque);
> +    int (*try_push_interrupts)(void *opaque);
> +    void (*post_kvm_run)(void *opaque, int vcpu);
> +    int (*pre_kvm_run)(void *opaque, int vcpu);
> +};
> +#endif
> diff --git a/user/kvmctl.h b/user/kvmctl.h
> --- a/user/kvmctl.h
> +++ b/user/kvmctl.h
> @@ -27,56 +27,10 @@ struct kvm_context;
>  
>  typedef struct kvm_context *kvm_context_t;
>  
> -/*!
> - * \brief KVM callbacks structure
> - *
> - * This structure holds pointers to various functions that KVM will call
> - * when it encounters something that cannot be virtualized, such as
> - * accessing hardware devices via MMIO or regular IO.
> - */
> -struct kvm_callbacks {
> -	/// For 8bit IO reads from the guest (Usually when executing 'inb')
> -    int (*inb)(void *opaque, uint16_t addr, uint8_t *data);
> -	/// For 16bit IO reads from the guest (Usually when executing 'inw')
> -    int (*inw)(void *opaque, uint16_t addr, uint16_t *data);
> -	/// For 32bit IO reads from the guest (Usually when executing 'inl')
> -    int (*inl)(void *opaque, uint16_t addr, uint32_t *data);
> -	/// For 8bit IO writes from the guest (Usually when executing 'outb')
> -    int (*outb)(void *opaque, uint16_t addr, uint8_t data);
> -	/// For 16bit IO writes from the guest (Usually when executing 'outw')
> -    int (*outw)(void *opaque, uint16_t addr, uint16_t data);
> -	/// For 32bit IO writes from the guest (Usually when executing 'outl')
> -    int (*outl)(void *opaque, uint16_t addr, uint32_t data);
> -	/// For 8bit memory reads from unmapped memory (For MMIO devices)
> -    int (*readb)(void *opaque, uint64_t addr, uint8_t *data);
> -	/// For 16bit memory reads from unmapped memory (For MMIO devices)
> -    int (*readw)(void *opaque, uint64_t addr, uint16_t *data);
> -	/// For 32bit memory reads from unmapped memory (For MMIO devices)
> -    int (*readl)(void *opaque, uint64_t addr, uint32_t *data);
> -	/// For 64bit memory reads from unmapped memory (For MMIO devices)
> -    int (*readq)(void *opaque, uint64_t addr, uint64_t *data);
> -	/// For 8bit memory writes to unmapped memory (For MMIO devices)
> -    int (*writeb)(void *opaque, uint64_t addr, uint8_t data);
> -	/// For 16bit memory writes to unmapped memory (For MMIO devices)
> -    int (*writew)(void *opaque, uint64_t addr, uint16_t data);
> -	/// For 32bit memory writes to unmapped memory (For MMIO devices)
> -    int (*writel)(void *opaque, uint64_t addr, uint32_t data);
> -	/// For 64bit memory writes to unmapped memory (For MMIO devices)
> -    int (*writeq)(void *opaque, uint64_t addr, uint64_t data);
>   

With a little refactoring, this can be made into something sharable for 
all architectures.  I'd recommend converting to something like:

int (*io_write)(void *opaque, int as, uint64_t addr, uint64_t data, int 
size);

Where as is a #define representing the address space (on x86, there is 
the PIO and MMIO address spaces, on PPC, there is just MMIO).

Since the ioctl() interface has a single handler for all pio 
operations/mmio operations, I think this is more natural too.

Regards,

Anthony Liguori

> -    int (*debug)(void *opaque, int vcpu);
> -	/*!
> -	 * \brief Called when the VCPU issues an 'hlt' instruction.
> -	 *
> -	 * Typically, you should yeild here to prevent 100% CPU utilization
> -	 * on the host CPU.
> -	 */
> -    int (*halt)(void *opaque, int vcpu);
> -    int (*shutdown)(void *opaque, int vcpu);
> -    int (*io_window)(void *opaque);
> -    int (*try_push_interrupts)(void *opaque);
> -    void (*post_kvm_run)(void *opaque, int vcpu);
> -    int (*pre_kvm_run)(void *opaque, int vcpu);
> -};
> +/* Add info from arch specific header */
> +#if defined(__x86_64__) || defined(__i386__)
> +#include "kvmctl-x86.h"
> +#endif
>  
>  /*!
>   * \brief Create new KVM context
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure to kvmctl-x86.h header

[Hollis Blanchard]

On Sun, 2007-10-28 at 21:11 -0500, Anthony Liguori wrote:
> 
> int (*io_write)(void *opaque, int as, uint64_t addr, uint64_t data,
> int size);
> 
> Where as is a #define representing the address space (on x86, there is
> the PIO and MMIO address spaces, on PPC, there is just MMIO).

So the implementation would look something like this:

int io_write(void *opaque, int as, uint64_t addr, uint64_t data, int
size) {
        io_handler_t cb;
        
        switch (as) {
        case MMIO:
                cb = io_table_lookup(&mmio_table, ...)
                break;
#ifdef HAS_PIO
        case PIO:
                cb = io_table_lookup(&pio_table, ...)
                break;
#endif
#ifdef HAS_DCR
        case DCR:
                cb = io_table_lookup(&dcr_table, ...)
                break;
#endif
        default:
                cb = NULL;
        }
        
        if (cb)
                return cb(...);
        
        printk("error");
        return -EINVAL;
}

Sounds fine to me.

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure to kvmctl-x86.h header

[Anthony Liguori]

Hollis Blanchard wrote:
> On Sun, 2007-10-28 at 21:11 -0500, Anthony Liguori wrote:
>   
>> int (*io_write)(void *opaque, int as, uint64_t addr, uint64_t data,
>> int size);
>>
>> Where as is a #define representing the address space (on x86, there is
>> the PIO and MMIO address spaces, on PPC, there is just MMIO).
>>     
>
> So the implementation would look something like this:
>
> int io_write(void *opaque, int as, uint64_t addr, uint64_t data, int
> size) {
>         io_handler_t cb;
>         
>         switch (as) {
>         case MMIO:
>                 cb = io_table_lookup(&mmio_table, ...)
>                 break;
> #ifdef HAS_PIO
>         case PIO:
>                 cb = io_table_lookup(&pio_table, ...)
>                 break;
> #endif
> #ifdef HAS_DCR
>         case DCR:
>                 cb = io_table_lookup(&dcr_table, ...)
>                 break;
> #endif
>         default:
>                 cb = NULL;
>         }
>         
>         if (cb)
>                 return cb(...);
>         
>         printk("error");
>         return -EINVAL;
> }
>
> Sounds fine to me.
>   

You could certainly get even more clever and have the arch backend 
register the appropriate tables based on the as type but that's merely 
an implementation detail.  The key observation, that I believe is 
correct, is that all architectures have one or more IO "address spaces" 
that have at max a 64-bit address space and support at max 64-bit 
input/output operations.  Once that assumption is made, almost all IO 
code becomes common.

Regards,

Anthony Liguori



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure to kvmctl-x86.h header

[Hollis Blanchard]

On Sun, 2007-10-28 at 22:50 -0500, Anthony Liguori wrote:
> 
> You could certainly get even more clever and have the arch backend 
> register the appropriate tables based on the as type but that's merely
> an implementation detail.  The key observation, that I believe is
> correct, is that all architectures have one or more IO "address
> spaces" that have at max a 64-bit address space and support at max
> 64-bit input/output operations.  Once that assumption is made, almost
> all IO code becomes common.

Just FYI, some PowerPC have "load/store quad", which are 128-bit memory
accesses. For that matter, I suppose one could do IO loads into Altivec
registers (which are also 128 bits), though that sounds like an extreme
case. I wonder if the same is true for x86 vector registers.

Also, can't x86 "rep" instructions go beyond 64 bits? I guess that must
be handled in the arch-specific caller of io_write(), which would call
it multiple times.

-- 
Hollis Blanchard
IBM Linux Technology Center


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure to kvmctl-x86.h header

[Anthony Liguori]

Hollis Blanchard wrote:
> On Sun, 2007-10-28 at 22:50 -0500, Anthony Liguori wrote:
>   
>> You could certainly get even more clever and have the arch backend 
>> register the appropriate tables based on the as type but that's merely
>> an implementation detail.  The key observation, that I believe is
>> correct, is that all architectures have one or more IO "address
>> spaces" that have at max a 64-bit address space and support at max
>> 64-bit input/output operations.  Once that assumption is made, almost
>> all IO code becomes common.
>>     
>
> Just FYI, some PowerPC have "load/store quad", which are 128-bit memory
> accesses.

Can you do MMIO with these instructions though?  I'm not really sure 
what would happen on x86 if you did MMIO with a 128-bit instruction.

Regards,

Anthony Liguori

>  For that matter, I suppose one could do IO loads into Altivec
> registers (which are also 128 bits), though that sounds like an extreme
> case. I wonder if the same is true for x86 vector registers.
>
> Also, can't x86 "rep" instructions go beyond 64 bits? I guess that must
> be handled in the arch-specific caller of io_write(), which would call
> it multiple times.
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [kvm-ppc-devel] [PATCH 1 of 3] Move x86 kvmcallback structure to kvmctl-x86.h header

[Avi Kivity]

Hollis Blanchard wrote:
> Also, can't x86 "rep" instructions go beyond 64 bits? I guess that must
> be handled in the arch-specific caller of io_write(), which would call
> it multiple times.
>   
'rep' has special support in the ABI (it's N accesses of M bits, not an 
NxM bit access).

-- 
Any sufficiently difficult bug is indistinguishable from a feature.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[PATCH 2 of 3] Move kvm_context structure to kvmctl.h header

[Jerone Young]

# HG changeset patch
# User Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
# Date 1193618330 18000
# Node ID 8bf5e4e6a4c9d2dab89062a0ab24a2ae5d144a02
# Parent  3bf072e498768885ab96b7ccb668b61c96db0e83
Move kvm_context structure to kvmctl.h header

This patch moves the kvm_context sturcture declaration to the kvmctl.h
header. This way other files are able to identify variables associated
with the structure. Also moved are definitions MAX_VCPU &
KVM_MAX_NUM_MEM_REGIONS  to the kvmctl-x86.h since these are arch specific.

Signed-off-by: Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

diff --git a/user/kvmctl-x86.h b/user/kvmctl-x86.h
--- a/user/kvmctl-x86.h
+++ b/user/kvmctl-x86.h
@@ -1,5 +1,8 @@
 #ifndef KVMCTL_X86_H
 #define KVMCTL_X86_H
+
+#define KVM_MAX_NUM_MEM_REGIONS 8u
+#define MAX_VCPUS 4
 
 /*!
  * \brief KVM callbacks structure
diff --git a/user/kvmctl.c b/user/kvmctl.c
--- a/user/kvmctl.c
+++ b/user/kvmctl.c
@@ -44,36 +44,8 @@ static int kvm_abi = EXPECTED_KVM_API_VE
 
 /* FIXME: share this number with kvm */
 /* FIXME: or dynamically alloc/realloc regions */
-#define KVM_MAX_NUM_MEM_REGIONS 8u
 int free_slots[KVM_MAX_NUM_MEM_REGIONS];
 unsigned long phys_addr_slots[KVM_MAX_NUM_MEM_REGIONS];
-#define MAX_VCPUS 4
-
-/**
- * \brief The KVM context
- *
- * The verbose KVM context
- */
-struct kvm_context {
-	/// Filedescriptor to /dev/kvm
-	int fd;
-	int vm_fd;
-	int vcpu_fd[MAX_VCPUS];
-	struct kvm_run *run[MAX_VCPUS];
-	/// Callbacks that KVM uses to emulate various unvirtualizable functionality
-	struct kvm_callbacks *callbacks;
-	void *opaque;
-	/// A pointer to the memory used as the physical memory for the guest
-	void *physical_memory;
-	/// is dirty pages logging enabled for all regions or not
-	int dirty_pages_log_all;
-	/// memory regions parameters
-	struct kvm_memory_region mem_regions[KVM_MAX_NUM_MEM_REGIONS];
-	/// do not create in-kernel irqchip if set
-	int no_irqchip_creation;
-	/// in-kernel irqchip status
-	int irqchip_in_kernel;
-};
 
 static void init_slots()
 {
diff --git a/user/kvmctl.h b/user/kvmctl.h
--- a/user/kvmctl.h
+++ b/user/kvmctl.h
@@ -31,6 +31,36 @@ typedef struct kvm_context *kvm_context_
 #if defined(__x86_64__) || defined(__i386__)
 #include "kvmctl-x86.h"
 #endif
+
+
+/**
+ * \brief The KVM context
+ *
+ * The verbose KVM context
+ */
+
+struct kvm_context {
+	/// Filedescriptor to /dev/kvm
+	int fd;
+	int vm_fd;
+	int vcpu_fd[MAX_VCPUS];
+	struct kvm_run *run[MAX_VCPUS];
+	/// Callbacks that KVM uses to emulate various unvirtualizable functionality
+	struct kvm_callbacks *callbacks;
+	void *opaque;
+	/// A pointer to the memory used as the physical memory for the guest
+	void *physical_memory;
+	/// is dirty pages logging enabled for all regions or not
+	int dirty_pages_log_all;
+	/// memory regions parameters
+	struct kvm_memory_region mem_regions[KVM_MAX_NUM_MEM_REGIONS];
+	/// do not create in-kernel irqchip if set
+	int no_irqchip_creation;
+	/// in-kernel irqchip status
+	int irqchip_in_kernel;
+};
+
+
 
 /*!
  * \brief Create new KVM context

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [PATCH 2 of 3] Move kvm_context structure to kvmctl.hheader

[Zhang, Xiantao]

Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> # Date 1193618330 18000
> # Node ID 8bf5e4e6a4c9d2dab89062a0ab24a2ae5d144a02
> # Parent  3bf072e498768885ab96b7ccb668b61c96db0e83
> Move kvm_context structure to kvmctl.h header
> 
> This patch moves the kvm_context sturcture declaration to the kvmctl.h
> header. This way other files are able to identify variables associated
> with the structure. Also moved are definitions MAX_VCPU &
> KVM_MAX_NUM_MEM_REGIONS  to the kvmctl-x86.h since these are arch
> specific. 

Just see these two definitions here, I remembered kernel space also
defines two similar macros for the purpose . How to sync with them
direclty?   Define them in linux/kvm.h instead of defining them twice ?


> - */
> -struct kvm_context {
> -	/// Filedescriptor to /dev/kvm
> -	int fd;
> -	int vm_fd;
> -	int vcpu_fd[MAX_VCPUS];
> -	struct kvm_run *run[MAX_VCPUS];
> -	/// Callbacks that KVM uses to emulate various unvirtualizable
> functionality 
> -	struct kvm_callbacks *callbacks;
> -	void *opaque;
> -	/// A pointer to the memory used as the physical memory for the
> guest 
> -	void *physical_memory;
> -	/// is dirty pages logging enabled for all regions or not
> -	int dirty_pages_log_all;
> -	/// memory regions parameters
> -	struct kvm_memory_region mem_regions[KVM_MAX_NUM_MEM_REGIONS];
> -	/// do not create in-kernel irqchip if set
> -	int no_irqchip_creation;
> -	/// in-kernel irqchip status
> -	int irqchip_in_kernel;
> -};
> 

Maybe we should put them in kvmctl.h, and just move some arch-specific
fields to kvmctl-x86.h. 

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [PATCH 2 of 3] Move kvm_context structure to kvmctl.h header

[Anthony Liguori]

Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> # Date 1193618330 18000
> # Node ID 8bf5e4e6a4c9d2dab89062a0ab24a2ae5d144a02
> # Parent  3bf072e498768885ab96b7ccb668b61c96db0e83
> Move kvm_context structure to kvmctl.h header
>
> This patch moves the kvm_context sturcture declaration to the kvmctl.h
> header. This way other files are able to identify variables associated
> with the structure. Also moved are definitions MAX_VCPU &
> KVM_MAX_NUM_MEM_REGIONS  to the kvmctl-x86.h since these are arch specific.
>   

I think just moving the declaration of kvm_context to an x86 specific 
file is the wrong direction to take.

I think a better first step would be to split up the architecture 
specific portions of kvm_context into an architecture specific structure 
and then have the common kvm_context be a part of the architecture 
specific structure (just like is done in the kernel code).

Regards,

Anthony Liguori

> Signed-off-by: Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
>
> diff --git a/user/kvmctl-x86.h b/user/kvmctl-x86.h
> --- a/user/kvmctl-x86.h
> +++ b/user/kvmctl-x86.h
> @@ -1,5 +1,8 @@
>  #ifndef KVMCTL_X86_H
>  #define KVMCTL_X86_H
> +
> +#define KVM_MAX_NUM_MEM_REGIONS 8u
> +#define MAX_VCPUS 4
>  
>  /*!
>   * \brief KVM callbacks structure
> diff --git a/user/kvmctl.c b/user/kvmctl.c
> --- a/user/kvmctl.c
> +++ b/user/kvmctl.c
> @@ -44,36 +44,8 @@ static int kvm_abi = EXPECTED_KVM_API_VE
>  
>  /* FIXME: share this number with kvm */
>  /* FIXME: or dynamically alloc/realloc regions */
> -#define KVM_MAX_NUM_MEM_REGIONS 8u
>  int free_slots[KVM_MAX_NUM_MEM_REGIONS];
>  unsigned long phys_addr_slots[KVM_MAX_NUM_MEM_REGIONS];
> -#define MAX_VCPUS 4
> -
> -/**
> - * \brief The KVM context
> - *
> - * The verbose KVM context
> - */
> -struct kvm_context {
> -	/// Filedescriptor to /dev/kvm
> -	int fd;
> -	int vm_fd;
> -	int vcpu_fd[MAX_VCPUS];
> -	struct kvm_run *run[MAX_VCPUS];
> -	/// Callbacks that KVM uses to emulate various unvirtualizable functionality
> -	struct kvm_callbacks *callbacks;
> -	void *opaque;
> -	/// A pointer to the memory used as the physical memory for the guest
> -	void *physical_memory;
> -	/// is dirty pages logging enabled for all regions or not
> -	int dirty_pages_log_all;
> -	/// memory regions parameters
> -	struct kvm_memory_region mem_regions[KVM_MAX_NUM_MEM_REGIONS];
> -	/// do not create in-kernel irqchip if set
> -	int no_irqchip_creation;
> -	/// in-kernel irqchip status
> -	int irqchip_in_kernel;
> -};
>  
>  static void init_slots()
>  {
> diff --git a/user/kvmctl.h b/user/kvmctl.h
> --- a/user/kvmctl.h
> +++ b/user/kvmctl.h
> @@ -31,6 +31,36 @@ typedef struct kvm_context *kvm_context_
>  #if defined(__x86_64__) || defined(__i386__)
>  #include "kvmctl-x86.h"
>  #endif
> +
> +
> +/**
> + * \brief The KVM context
> + *
> + * The verbose KVM context
> + */
> +
> +struct kvm_context {
> +	/// Filedescriptor to /dev/kvm
> +	int fd;
> +	int vm_fd;
> +	int vcpu_fd[MAX_VCPUS];
> +	struct kvm_run *run[MAX_VCPUS];
> +	/// Callbacks that KVM uses to emulate various unvirtualizable functionality
> +	struct kvm_callbacks *callbacks;
> +	void *opaque;
> +	/// A pointer to the memory used as the physical memory for the guest
> +	void *physical_memory;
> +	/// is dirty pages logging enabled for all regions or not
> +	int dirty_pages_log_all;
> +	/// memory regions parameters
> +	struct kvm_memory_region mem_regions[KVM_MAX_NUM_MEM_REGIONS];
> +	/// do not create in-kernel irqchip if set
> +	int no_irqchip_creation;
> +	/// in-kernel irqchip status
> +	int irqchip_in_kernel;
> +};
> +
> +
>  
>  /*!
>   * \brief Create new KVM context
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Re: [PATCH 2 of 3] Move kvm_context structure to kvmctl.h header

[Izik Eidus]

On Sun, 2007-10-28 at 19:42 -0500, Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
> # Date 1193618330 18000
> # Node ID 8bf5e4e6a4c9d2dab89062a0ab24a2ae5d144a02
> # Parent  3bf072e498768885ab96b7ccb668b61c96db0e83
> Move kvm_context structure to kvmctl.h header
> 
> This patch moves the kvm_context sturcture declaration to the kvmctl.h
> header. This way other files are able to identify variables associated
> with the structure. Also moved are definitions MAX_VCPU &
> KVM_MAX_NUM_MEM_REGIONS  to the kvmctl-x86.h since these are arch specific.

this KVM_MAX_NUM_MEM_REGIONS should have never be defined from kvmctl.h,
(nothing wrong with what you did)
but i think this define should move to include/linux/kvm.h
so userspace and kernel share this number



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

[PATCH 3 of 3] Move x86 specific properties of kvm_init to own file

[Jerone Young]

# HG changeset patch
# User Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
# Date 1193618393 18000
# Node ID 64de4ce84d745217a7001dd5ba8c871aa9ad533a
# Parent  8bf5e4e6a4c9d2dab89062a0ab24a2ae5d144a02
Move x86 specific properties of kvm_init to own file.

This patch breaks out x86 specific properties for kvm_init initialization
into it's own function, into a architecture specific file.

Signed-off-by: Jerone Young <jyoung5-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>

diff --git a/user/config-x86-common.mak b/user/config-x86-common.mak
--- a/user/config-x86-common.mak
+++ b/user/config-x86-common.mak
@@ -2,9 +2,9 @@
 
 all: kvmctl libkvm.a test_cases
 
-kvmctl_objs=kvmctl.o main.o
+kvmctl_objs=kvmctl-x86.o kvmctl.o main.o
 
-libkvm_objs=kvmctl.o
+libkvm_objs=kvmctl-x86.o kvmctl.o
 
 balloon_ctl: balloon_ctl.o
 
diff --git a/user/kvmctl-x86.c b/user/kvmctl-x86.c
new file mode 100644
--- /dev/null
+++ b/user/kvmctl-x86.c
@@ -0,0 +1,9 @@
+#include "kvmctl.h"
+#include <string.h>
+
+void arch_kvm_init(kvm_context_t kvm)
+{
+	kvm->dirty_pages_log_all = 0;
+	kvm->no_irqchip_creation = 0;
+	memset(&kvm->mem_regions, 0, sizeof(kvm->mem_regions));
+}
diff --git a/user/kvmctl-x86.h b/user/kvmctl-x86.h
--- a/user/kvmctl-x86.h
+++ b/user/kvmctl-x86.h
@@ -54,4 +54,11 @@ struct kvm_callbacks {
     void (*post_kvm_run)(void *opaque, int vcpu);
     int (*pre_kvm_run)(void *opaque, int vcpu);
 };
+
+/*
+ * \brief  Arch specific initialization for KVM context
+ */  
+void arch_kvm_init(kvm_context_t kvm);
+
+
 #endif
diff --git a/user/kvmctl.c b/user/kvmctl.c
--- a/user/kvmctl.c
+++ b/user/kvmctl.c
@@ -231,10 +231,9 @@ kvm_context_t kvm_init(struct kvm_callba
 	kvm->vm_fd = -1;
 	kvm->callbacks = callbacks;
 	kvm->opaque = opaque;
-	kvm->dirty_pages_log_all = 0;
-	kvm->no_irqchip_creation = 0;
-	memset(&kvm->mem_regions, 0, sizeof(kvm->mem_regions));
-
+
+	arch_kvm_init(kvm);
+	
 	return kvm;
  out_close:
 	close(fd);

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/