[Intel-gfx] [PATCH v3 1/8] drm/i915: Introduce a PV INFO page structure for Intel GVT-g.

[Tian, Kevin]

> From: Yu, Zhang
> Sent: Wednesday, December 17, 2014 10:50 AM
> >>>> +    /*
> >>>> +     *  Data structure to describe the balooning info of resources.
> >>>> +     *  Each VM can only have one portion of continuous area for
> now.
> >>>> +     *  (May support scattered resource in future)
> >>>> +     *  (starting from offset 0x40)
> >>>> +     */
> >>>> +    struct {
> >>>> +        /* Aperture register balooning */
> >>>> +        struct {
> >>>> +            uint32_t my_base;
> >>>> +            uint32_t my_size;
> >>>> +        } low_gmadr;    /* aperture */
> >>>> +        /* GMADR register balooning */
> >>>> +        struct {
> >>>> +            uint32_t my_base;
> >>>> +            uint32_t my_size;
> >>>> +        } high_gmadr;    /* non aperture */
> >>>> +        /* allowed fence registers */
> >>>> +        uint32_t fence_num;
> >>>> +        uint32_t rsv2[3];
> >>>> +    } avail_rs;        /* available/assigned resource */
> >>>
> >>> I didn't figure out yet why the concept is to pass in two ranges to mark
> >>> as reserved, instead of one usable/allowed range and then implicitly all
> >>> the rest as reserved?
> >>>
> >> Like you said in 2/3 comments, this 2 part is for mappable and
> >> non-mapplable respectively. :)
> >
> > Are high and low memory as terms known in the i915 space so far as
> > synonyms for mappable and non-mappable?
> >
> Well, I'm not sure.
> Daniel, do you think the "low gmadr/high gmadr" will cause any
> misunderstanding?

for i915 possibly mappable and non-mappable are more intuitive, but
for end user they finally need to know mappable is actually in low end
and non-mappable is in high end, so low/high would be simpler to 
them. since this is the information used between host and guest, we're
open to whatever meaningful to i915, and our host vgt driver can still
keep low/high notations to user.

Thanks
Kevin