Message-ID: <426367E2313C2449837CD2DE46E7EAF930E5E599@SN2PRD0310MB382.namprd03.prod.outlook.com>
Date:	Thu, 29 Nov 2012 00:35:00 +0000
From:	KY Srinivasan <kys@...rosoft.com>
To:	Greg KH <gregkh@...uxfoundation.org>
CC:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>
Subject: RE: drivres/hv



> -----Original Message-----
> From: Greg KH [mailto:gregkh@...uxfoundation.org]
> Sent: Wednesday, November 28, 2012 7:05 PM
> To: KY Srinivasan
> Cc: linux-kernel@...r.kernel.org; devel@...uxdriverproject.org
> Subject: Re: drivres/hv
> 
> On Wed, Nov 28, 2012 at 11:32:52PM +0000, KY Srinivasan wrote:
> > > > I recently discovered that the Hyper-V host allocates mmio
> > > > memory for some synthetic devices like the virtual framebuffer.
> > > > We are currently in the process of implementing this virtual
> > > > framebuffer device. As part of the offer message from the host
> > > > we are given the mmio region size that needs to be allocatted to
> > > > the device. I am told in the current implementation of the firmware,
> > > > this mmio resource shows up in the PCI space. What is the best way to
> > > > allocate this mmio space for this driver.
> > >
> > > I don't understand, does the guest os think this really is mmio memory
> > > and the host just set up up?  Or is the memory being used to pass data
> > > back and forth?  Or something else?
> >
> > From what I understand, the host is allocating this memory and presenting
> > this to the guest. This memory is to be used for framebuffer. The guest is
> > expected to setup appropriate mappings to this region and use that as the
> > framebuffer.
> 
> What type of framebuffer?  Linux supports a ton of different ones, have
> you looked at drivers/video/ to see if one of the ones there will "just
> work" with what hyperv is passing to the guest?

We are writing a diver for this device. The existing Linux drivers can (and do)
work for the emulated VGA device. What we are implementing is a synthetic
framebuffer driver that will communicate over the vmbus to the host.
 
> 
> If not, you'll have to write a new driver for this, look at the examples
> of other framebuffer drivers in that directory for examples.  Also, I
> bet the code there will answer your memory questions.
> 
> > > And what do you mean "firmware"?  That usually means UEFI/BIOS to me,
> > > not a hyperv host.
> >
> > Hyper-V host presents the firmware to the guest (Hyper-V like KVM supports
> > full virtualization with selective para-virtualization - PV drivers). As part of the
> > BIOS presented to the guest this mmio region is allocated.
> >
> > >
> > > And finally, what does the guest os see as far as the PCI resource space
> > > shows it?  Shouldn't it just think it is a normal PCI device and access
> > > it properly that way?
> >
> > This is the crux of the problem. Vmbus and other vmbus based devices are not
> > PCI  devices. I have implemented vmbus as an ACPI driver since vmbus is an
> ACPI
> > enumerated device. I have the size information of the mmio region that is to be
> > allocated to the framebuffer device. I am looking at a way to allocate this mmio
> > region.
> 
> Do you have any "hints" as to where it is, if it even is present, or
> anything else?  If so, use them and create a new framebuffer device with
> that information.

All I know is that it is present and its size is known. If I have a way of knowing
what range of mmio memory is unclaimed; I could grab that perhaps using
the request_mem_region() call, I know the size that is reserved for this device.
So, is there a way to query the system for the first unclaimed address in the mmio
range.

Thanks,

K. Y
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists