From: Arnd Bergmann <arnd@arndb.de>
To: Avi Kivity <avi@qumranet.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/13] KVM: virtualization infrastructure
Date: Mon, 23 Oct 2006 21:35:02 +0200 [thread overview]
Message-ID: <200610232135.02684.arnd@arndb.de> (raw)
In-Reply-To: <20061023133026.92C9F250143@cleopatra.q>
On Monday 23 October 2006 15:30, Avi Kivity wrote:
> - ioctl()
> - mmap()
> - vcpu context management (vcpu_load/vcpu_put)
> - some control register logic
Let me comment on coding style for now, I might come back with
contents when I understand more of the code.
> +static struct dentry *debugfs_dir;
> +static struct dentry *debugfs_pf_fixed;
> +static struct dentry *debugfs_pf_guest;
> +static struct dentry *debugfs_tlb_flush;
> +static struct dentry *debugfs_invlpg;
> +static struct dentry *debugfs_exits;
> +static struct dentry *debugfs_io_exits;
> +static struct dentry *debugfs_mmio_exits;
> +static struct dentry *debugfs_signal_exits;
> +static struct dentry *debugfs_irq_exits;
How about making these an array?
> +static int rmode_tss_base(struct kvm* kvm);
> +static void set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0);
> +static void __set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0);
> +static void lmsw(struct kvm_vcpu *vcpu, unsigned long msw);
> +static void set_cr3(struct kvm_vcpu *vcpu, unsigned long cr0);
> +static void set_cr4(struct kvm_vcpu *vcpu, unsigned long cr0);
> +static void __set_cr4(struct kvm_vcpu *vcpu, unsigned long cr4);
> +#ifdef __x86_64__
> +static void __set_efer(struct kvm_vcpu *vcpu, u64 efer);
> +#endif
In general, you should try to avoid forward declarations for
static functions. The expected reading order is that static
functions are called only from other functions below them
in the same file, or through callbacks.
> +struct descriptor_table {
> + u16 limit;
> + unsigned long base;
> +} __attribute__((packed));
Is this a hardware structure? If not, packing it only
make accesses rather inefficient.
> +static void get_gdt(struct descriptor_table *table)
> +{
> + asm ( "sgdt %0" : "=m"(*table) );
> +}
Spacing:
asm ("sgdt %0" : "=m" (*table));
> +static void load_fs(u16 sel)
> +{
> + asm ( "mov %0, %%fs\n" : : "g"(sel) );
> +}
> +
> +static void load_gs(u16 sel)
> +{
> + asm ( "mov %0, %%gs\n" : : "g"(sel) );
> +}
Remove the '\n'.
> +struct segment_descriptor {
> + u16 limit_low;
> + u16 base_low;
> + u8 base_mid;
> + u8 type : 4;
> + u8 system : 1;
> + u8 dpl : 2;
> + u8 present : 1;
> + u8 limit_high : 4;
> + u8 avl : 1;
> + u8 long_mode : 1;
> + u8 default_op : 1;
> + u8 granularity : 1;
> + u8 base_high;
> +} __attribute__((packed));
Bitfields are generally frowned upon. It's better to define
constants for each of these and use a u64.
> +
> +#ifdef __x86_64__
> +// LDT or TSS descriptor in the GDT. 16 bytes.
> +struct segment_descriptor_64 {
> + struct segment_descriptor s;
> + u32 base_higher;
> + u32 pad_zero;
> +} __attribute__((packed));
> +#endif
No need for packing this.
> +
> +DEFINE_PER_CPU(struct vmcs *, vmxarea);
> +DEFINE_PER_CPU(struct vmcs *, current_vmcs);
If you make these
DEFINE_PER_CPU(struct vmcs, vmxarea);
DEFINE_PER_CPU(struct vmcs, current_vmcs);
you no longer need to handle allocation of the structures
yourself. Also, they should be 'static DEFINE_PER_CPU' if
possible.
> +static void set_cr0(struct kvm_vcpu *vcpu, unsigned long cr0)
> +{
> + if (cr0 & CR0_RESEVED_BITS) {
> + printk("set_cr0: 0x%lx #GP, reserved bits (0x%lx)\n", cr0, guest_cr0());
> + inject_gp(vcpu);
> + return;
> + }
> +
> + if ((cr0 & CR0_NW_MASK) && !(cr0 & CR0_CD_MASK)) {
> + printk("set_cr0: #GP, CD == 0 && NW == 1\n");
> + inject_gp(vcpu);
> + return;
> + }
> +
> + if ((cr0 & CR0_PG_MASK) && !(cr0 & CR0_PE_MASK)) {
> + printk("set_cr0: #GP, set PG flag and a clear PE flag\n");
> + inject_gp(vcpu);
> + return;
> + }
> +
> + if (is_paging()) {
> +#ifdef __x86_64__
> + if (!(cr0 & CR0_PG_MASK)) {
> + vcpu->shadow_efer &= ~EFER_LMA;
> + vmcs_write32(VM_ENTRY_CONTROLS,
> + vmcs_read32(VM_ENTRY_CONTROLS) &
> + ~VM_ENTRY_CONTROLS_IA32E_MASK);
> + }
> +#endif
> + } else if ((cr0 & CR0_PG_MASK)) {
> +#ifdef __x86_64__
> + if ((vcpu->shadow_efer & EFER_LME)) {
> + u32 guest_cs_ar;
> + u32 guest_tr_ar;
> + if (!is_pae()) {
> + printk("set_cr0: #GP, start paging in "
> + "long mode while PAE is disabled\n");
> + inject_gp(vcpu);
> + return;
> + }
> + guest_cs_ar = vmcs_read32(GUEST_CS_AR_BYTES);
> + if (guest_cs_ar & SEGMENT_AR_L_MASK) {
> + printk("set_cr0: #GP, start paging in "
> + "long mode while CS.L == 1\n");
> + inject_gp(vcpu);
> + return;
> +
> + }
> + guest_tr_ar = vmcs_read32(GUEST_TR_AR_BYTES);
> + if ((guest_tr_ar & AR_TYPE_MASK) != AR_TYPE_BUSY_64_TSS) {
> + printk("%s: tss fixup for long mode. \n",
> + __FUNCTION__);
> + vmcs_write32(GUEST_TR_AR_BYTES,
> + (guest_tr_ar & ~AR_TYPE_MASK) |
> + AR_TYPE_BUSY_64_TSS);
> + }
> + vcpu->shadow_efer |= EFER_LMA;
> + find_msr_entry(vcpu, MSR_EFER)->data |=
> + EFER_LMA | EFER_LME;
> + vmcs_write32(VM_ENTRY_CONTROLS,
> + vmcs_read32(VM_ENTRY_CONTROLS) |
> + VM_ENTRY_CONTROLS_IA32E_MASK);
> +
> + } else
> +#endif
> + if (is_pae() &&
> + pdptrs_have_reserved_bits_set(vcpu, vcpu->cr3)) {
> + printk("set_cr0: #GP, pdptrs reserved bits\n");
> + inject_gp(vcpu);
> + return;
> + }
> +
> + }
> +
> + __set_cr0(vcpu, cr0);
> + kvm_mmu_reset_context(vcpu);
> + return;
> +}
This function is a little too complex to read. Can you split it up
into smaller functions?
> + } else
> + printk("lmsw: unexpected\n");
Make sure that all printk have KERN_* level in them.
> +
> + #define LMSW_GUEST_MASK 0x0eULL
Don't indent macro definition. Normally, these should to the top of your
file.
> +static long kvm_dev_ioctl(struct file *filp,
> + unsigned int ioctl, unsigned long arg)
> +{
> + struct kvm *kvm = filp->private_data;
> + int r = -EINVAL;
> +
> + switch (ioctl) {
> + default:
> + ;
> + }
> +out:
> + return r;
> +}
Huh? Just leave out stuff like this. If the ioctl function is introduced
in a later patch, you can still add the whole function there.
Arnd <><
next prev parent reply other threads:[~2006-10-23 19:35 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-23 13:28 [PATCH 0/7] KVM: Kernel-based Virtual Machine (v2) Avi Kivity
2006-10-23 13:29 ` [PATCH 1/13] KVM: userspace interface Avi Kivity
2006-10-24 12:51 ` Muli Ben-Yehuda
2006-10-24 12:56 ` Avi Kivity
2006-10-24 12:59 ` Muli Ben-Yehuda
2006-10-23 13:29 ` [PATCH 2/13] KVM: Intel virtual mode extensions definitions Avi Kivity
2006-10-23 13:30 ` [PATCH 3/13] KVM: kvm data structures Avi Kivity
2006-10-23 13:30 ` [PATCH 4/13] KVM: random accessors and constants Avi Kivity
2006-10-23 13:30 ` [PATCH 5/13] KVM: virtualization infrastructure Avi Kivity
2006-10-23 19:35 ` Arnd Bergmann [this message]
2006-10-23 20:28 ` Avi Kivity
2006-10-23 20:35 ` Arnd Bergmann
2006-10-23 20:39 ` Avi Kivity
2006-10-24 12:03 ` Avi Kivity
2006-10-24 5:19 ` Andi Kleen
2006-10-24 13:43 ` [PATCH] x86: Extract segment descriptor definitions for use outside of x86_64 Avi Kivity
2006-10-24 14:10 ` Andi Kleen
2006-10-23 13:30 ` [PATCH 6/13] KVM: memory slot management Avi Kivity
2006-10-23 13:30 ` [PATCH 7/13] KVM: vcpu creation and maintenance Avi Kivity
2006-10-23 13:30 ` [PATCH 8/13] KVM: vcpu execution loop Avi Kivity
[not found] ` <200610232141.45802.arnd@arndb.de>
2006-10-23 20:16 ` Avi Kivity
2006-10-23 20:29 ` Arnd Bergmann
2006-10-23 20:37 ` Avi Kivity
2006-10-23 21:02 ` Antonio Vargas
2006-10-23 21:11 ` Avi Kivity
2006-10-23 22:08 ` Antonio Vargas
2006-10-23 22:18 ` Arnd Bergmann
2006-10-23 13:31 ` [PATCH 9/13] KVM: define exit handlers Avi Kivity
2006-10-24 1:05 ` Anthony Liguori
2006-10-24 7:23 ` Avi Kivity
2006-10-23 13:31 ` [PATCH 10/13] KVM: less common " Avi Kivity
2006-10-23 13:31 ` [PATCH 11/13] KVM: mmu Avi Kivity
2006-10-23 13:31 ` [PATCH 12/13] KVM: x86 emulator Avi Kivity
2006-10-23 13:31 ` [PATCH 13/13] KVM: plumbing Avi Kivity
2006-10-23 13:44 ` [PATCH 0/7] KVM: Kernel-based Virtual Machine (v2) Avi Kivity
2006-10-23 15:38 ` [PATCH 0/13] KVM: qemu patch Avi Kivity
-- strict thread matches above, loose matches on Subject: below --
2006-10-26 17:19 [PATCH 0/13] KVM: Kernel-based Virtual Machine (v3) Avi Kivity
2006-10-26 17:26 ` [PATCH 5/13] KVM: virtualization infrastructure Avi Kivity
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200610232135.02684.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=avi@qumranet.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox