linux-kernel - Re: drivres/hv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 28 Nov 2012 16:04:34 -0800
From:	Greg KH <gregkh@...uxfoundation.org>
To:	KY Srinivasan <kys@...rosoft.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devel@...uxdriverproject.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?

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.

If not, that seems really strange, but hey, it's hyper-v, it wouldn't be
the first time :)

good luck,

greg k-h
--
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/