Re: [Qemu-devel] Re: [PATCH] Implement a virtio GPU transport
On 11/10/2010 11:22 AM, Ian Molton wrote: > Ping ? I think the best way forward is to post patches. To summarize what I was trying to express in the thread, I think this is not the right long term architecture but am not opposed to it as a short term solution. I think having a new virtio device is a bad design choice but am not totally opposed to it. My advice is that using virtio-serial + an external tool is probably the least amount of work to get something working and usable with QEMU. If you want to go for the path of integration, you're going to have to fix all of the coding style issues and make the code fit into QEMU. Dropping a bunch of junk into target-i386/ is not making the code fit into QEMU. If you post just what you have now in patch form, I can try to provide more concrete advice ignoring the coding style problems. Regards, Anthony Liguori ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [Qemu-devel] Re: [PATCH] Implement a virtio GPU transport
Ping ? On 05/11/10 18:05, Ian Molton wrote: > On 03/11/10 18:17, Anthony Liguori wrote: >> On 11/03/2010 01:03 PM, Ian Molton wrote: > >> Why is it better than using virtio-serial? > > For one thing, it enforces the PID in kernel so the guests processes > cant screw each other over by forging the PID passed to qemu. > >>> My current patch touches a tiny part of the qemu sources. It works >>> today. >> >> But it's not at all mergable in the current form. If you want to do the >> work of getting it into a mergable state (cleaning up the coding style, >> moving it to hw/, etc.) than I'm willing to consider it. But I don't >> think a custom virtio transport is the right thing to do here. > > Hm, I thought I'd indented everything in qemus odd way... Is there a > codingstyle document or a checkpatch-like tool for qemu? > > I'm happy to make the code meet qemus coding style. > >> However, if you want something that Just Works with the least amount of >> code possible, just split it into a separate process and we can stick it >> in a contrib/ directory or something. > > I dont see what splitting it into a seperate process buys us given we > still need the virtio-gl driver in order to enforce the PID. The virtio > driver is probably quite a bit more efficient at marshalling the data > too, given that it was designed alongside the userspace code. > I think we can consider integrating it into QEMU (or at least simplifying the execution of the backend) but integrating into QEMU is going to require an awful lot of the existing code to be rewritten. > > Why? aside from codingstyle, whats massively wrong with it thats going > to demand a total rewrite? > Keeping it separate has the advantage of allowing something to Just Work as an interim solution as we wait for proper support in Spice. > > Why does keeping it seperate make life easier? qemu is in a git repo. > when the time comes, if it reall is a total replacement, git-rm will > nuke it all. > >>> I dont know why you think integrating it into qemu is hard? I've >>> already done it. >> >> Adding a file that happens to compile as part of qemu even though it >> doesn't actually integrate with qemu in any meaningful way is not >> integrating. That's just build system manipulation. > > Uh? Either it compiles and works as part of qemu (which it does) or it > doesnt. How is that not integrated? I've added it to the configure > script too. > > -Ian > ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH 36/49] drivers/video: Use vzalloc
On Fri, Nov 5, 2010 at 11:08 AM, Joe Perches wrote: > Signed-off-by: Joe Perches > --- > drivers/video/arcfb.c | 5 ++--- > drivers/video/broadsheetfb.c | 4 +--- > drivers/video/hecubafb.c | 5 ++--- > drivers/video/metronomefb.c | 4 +--- > drivers/video/xen-fbfront.c | 3 +-- > 5 files changed, 7 insertions(+), 14 deletions(-) > > diff --git a/drivers/video/arcfb.c b/drivers/video/arcfb.c > index 3ec4923..86573e2 100644 > --- a/drivers/video/arcfb.c > +++ b/drivers/video/arcfb.c > @@ -515,11 +515,10 @@ static int __devinit arcfb_probe(struct platform_device > *dev) > > /* We need a flat backing store for the Arc's > less-flat actual paged framebuffer */ > - if (!(videomemory = vmalloc(videomemorysize))) > + videomemory = vmalloc(videomemorysize); typo? > + if (!videomemory) > return retval; > > - memset(videomemory, 0, videomemorysize); > - > info = framebuffer_alloc(sizeof(struct arcfb_par), &dev->dev); > if (!info) > goto err; > diff --git a/drivers/video/broadsheetfb.c b/drivers/video/broadsheetfb.c > index ebda687..377dde3 100644 > --- a/drivers/video/broadsheetfb.c > +++ b/drivers/video/broadsheetfb.c > @@ -1101,12 +1101,10 @@ static int __devinit broadsheetfb_probe(struct > platform_device *dev) > > videomemorysize = roundup((dpyw*dpyh), PAGE_SIZE); > > - videomemory = vmalloc(videomemorysize); > + videomemory = vzalloc(videomemorysize); > if (!videomemory) > goto err_fb_rel; > > - memset(videomemory, 0, videomemorysize); > - > info->screen_base = (char *)videomemory; > info->fbops = &broadsheetfb_ops; > > diff --git a/drivers/video/hecubafb.c b/drivers/video/hecubafb.c > index c77bcc6..a941e6f 100644 > --- a/drivers/video/hecubafb.c > +++ b/drivers/video/hecubafb.c > @@ -231,11 +231,10 @@ static int __devinit hecubafb_probe(struct > platform_device *dev) > > videomemorysize = (DPY_W*DPY_H)/8; > > - if (!(videomemory = vmalloc(videomemorysize))) > + videomemory = vzalloc(videomemorysize); > + if (!videomemory) > return retval; > > - memset(videomemory, 0, videomemorysize); > - > info = framebuffer_alloc(sizeof(struct hecubafb_par), &dev->dev); > if (!info) > goto err_fballoc; > diff --git a/drivers/video/metronomefb.c b/drivers/video/metronomefb.c > index 63ed3b7..c0c358c 100644 > --- a/drivers/video/metronomefb.c > +++ b/drivers/video/metronomefb.c > @@ -628,12 +628,10 @@ static int __devinit metronomefb_probe(struct > platform_device *dev) > /* we need to add a spare page because our csum caching scheme walks > * to the end of the page */ > videomemorysize = PAGE_SIZE + (fw * fh); > - videomemory = vmalloc(videomemorysize); > + videomemory = vzalloc(videomemorysize); > if (!videomemory) > goto err_fb_rel; > > - memset(videomemory, 0, videomemorysize); > - > info->screen_base = (char __force __iomem *)videomemory; > info->fbops = &metronomefb_ops; > > diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c > index 428d273..81fcaea 100644 > --- a/drivers/video/xen-fbfront.c > +++ b/drivers/video/xen-fbfront.c > @@ -395,10 +395,9 @@ static int __devinit xenfb_probe(struct xenbus_device > *dev, > spin_lock_init(&info->dirty_lock); > spin_lock_init(&info->resize_lock); > > - info->fb = vmalloc(fb_size); > + info->fb = vzalloc(fb_size); > if (info->fb == NULL) > goto error_nomem; > - memset(info->fb, 0, fb_size); > > info->nr_pages = (fb_size + PAGE_SIZE - 1) >> PAGE_SHIFT; > > -- > 1.7.3.1.g432b3.dirty > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Regards dave ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
Re: [PATCH] virtio: fix format of sysfs driver/vendor files
On Wed, 10 Nov 2010 04:50:29 pm Stephen Hemminger wrote: > The sysfs files for virtio produce the wrong format and are missing > the required newline. The output for virtio bus vendor/device should > have the same format as the corresponding entries for PCI devices. > > Although this technically changes the ABI for sysfs, these files were > broken to start with! Agreed, and I don't think anyone currently uses them. Applied, Rusty. ___ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
