Re: [PATCH v2 3/7] virt: geniezone: Introduce GenieZone hypervisor support

[Trilok Soni]

Hi Marc,

> [...]
>
> > +/**
> > + * gzvm_gfn_to_pfn_memslot() - Translate gfn (guest ipa) to pfn (host 
> > pa),
> > + *                   result is in @pfn
> > + *
> > + * Leverage KVM's gfn_to_pfn_memslot(). Because gfn_to_pfn_memslot() 
> > needs
> > + * kvm_memory_slot as parameter, this function populates necessary 
> > fileds
> > + * for calling gfn_to_pfn_memslot().
> > + *
> > + * Return:
> > + * * 0            - Succeed
> > + * * -EFAULT        - Failed to convert
> > + */
> > +static int gzvm_gfn_to_pfn_memslot(struct gzvm_memslot *memslot, u64
> > gfn, u64 *pfn)
> > +{
> > +    hfn_t __pfn;
> > +    struct kvm_memory_slot kvm_slot = {0};
> > +
> > +    kvm_slot.base_gfn = memslot->base_gfn;
> > +    kvm_slot.npages = memslot->npages;
> > +    kvm_slot.dirty_bitmap = NULL;
> > +    kvm_slot.userspace_addr = memslot->userspace_addr;
> > +    kvm_slot.flags = memslot->flags;
> > +    kvm_slot.id = memslot->slot_id;
> > +    kvm_slot.as_id = 0;
> > +
> > +    __pfn = gfn_to_pfn_memslot(&kvm_slot, gfn);
>
> Again, I absolutely oppose this horror. This is internal to KVM,
> and we want to be able to change this without having to mess
> with your own code that we cannot test anyway.
>
> What if we start using the extra fields that you don't populate
> as they mean nothing to you? Or add a backpointer to the kvm
> structure to do fancy accounting?
>
> You have your own hypervisor, that's well and good. Since your
> main argument is that it is supposed to be standalone, make it
> *really* standalone and don't use KVM as a prop.


Agreed, same comments were made earlier too. I would prefer that 
GenieZone have its own identify rather than sharing the 
APIs/data-structures here.

---Trilok Soni