> -----Original Message----- > From: Greg KH [mailto:gregkh@xxxxxxxxxxxxxxxxxxx] > Sent: Wednesday, November 28, 2012 7:05 PM > To: KY Srinivasan > Cc: linux-kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx > 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 > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
