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

[Anthony Liguori <anthony-rdkfGonbjUSkNkDKm+mE6A@public.gmane.org>]

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/