On Wed, Apr 27, 2011 at 11:47:03AM +, KY Srinivasan wrote:
> On the host side, Windows emulates the standard PC hardware
> to permit hosting of fully virtualized operating systems.
> To enhance disk I/O performance, we support a virtual block driver.
> This block driver currently handles disks
On Wed, Apr 27, 2011 at 01:54:02AM +, KY Srinivasan wrote:
> I would prefer that we go through the review process. What is the process for
> this review? Is there a time window for people to respond. I am hoping I will
> be able
> to address all the review comments well in advance of the nex
Do you have a repository containing the current state of your patche
somewhere? There's been so much cleanup that it's hard to review these
patches against the current mainline codebase.
___
Virtualization mailing list
Virtualization@lists.linux-foundati
> @@ -882,7 +882,7 @@ static int blkvsc_drv_init(void)
>
> drv->driver.name = storvsc_drv_obj->base.name;
>
> - drv->driver.probe = blkvsc_probe;
> + drv->probe = blkvsc_probe;
> drv->driver.remove = blkvsc_remove;
> drv->driver.shutdown = blkvsc_shutdown;
Not new in
On Thu, Jan 27, 2011 at 05:32:21PM +0200, Michael S. Tsirkin wrote:
> This needs to be flushed on device removal, I think,
> otherwise the vdev pointer will go stale.
Indeed.
>
> > +}
> > +
> > +
>
> Two empty lines :)
I'll fix it up.
___
Virtualiz
On Fri, Jun 18, 2010 at 01:38:02PM -0500, Ryan Harper wrote:
> Create a new attribute for virtio-blk devices that will fetch the serial
> number
> of the block device. This attribute can be used by udev to create disk/by-id
> symlinks for devices that don't have a UUID (filesystem) associated wit
On Wed, May 05, 2010 at 10:52:53AM -0700, Stephen Hemminger wrote:
> Let me put it bluntly. Any design that allows external code to run
> in the kernel is not going to be accepted. Out of tree kernel modules are
> enough
> of a pain already, why do you expect the developers to add another
> inter
On Thu, May 06, 2010 at 11:04:11AM -0700, Pankaj Thakkar wrote:
> Plugin is x86 or x64 machine code. You write the plugin in C and compile it
> using gcc/ld to get the object file, we map the relevant sections only to the
> OS space.
Which is simply not supportable for a cross-platform operatin
On Wed, May 05, 2010 at 10:47:10AM -0700, Pankaj Thakkar wrote:
> > Forget about the licensing. Loading binary blobs written to a shim
> > layer is a complete pain in the ass and totally unsupportable, and
> > also uninteresting because of the overhead.
>
> [PT] Why do you think it is unsupportab
On Wed, May 05, 2010 at 10:35:28AM -0700, Dmitry Torokhov wrote:
> Yes, with the exception that the only body of code that will be
> accepted by the shell should be GPL-licensed and thus open and available
> for examining. This is not different from having a standard kernel
> module that is loaded
On Wed, May 05, 2010 at 10:29:40AM -0700, Dmitry Torokhov wrote:
> > We're not going to add any kind of loader for binry blobs into kernel
> > space, sorry. Don't even bother wasting your time on this.
> >
>
> It would not be a binary blob but software properly released under GPL.
> The current
On Tue, May 04, 2010 at 04:02:25PM -0700, Pankaj Thakkar wrote:
> The plugin image is provided by the IHVs along with the PF driver and is
> packaged in the hypervisor. The plugin image is OS agnostic and can be loaded
> either into a Linux VM or a Windows VM. The plugin is written against the
> S
On Tue, Apr 20, 2010 at 02:46:35AM +0100, Jamie Lokier wrote:
> Does this mean that virtio-blk supports all three combinations?
>
>1. FLUSH that isn't a barrier
>2. FLUSH that is also a barrier
>3. Barrier that is not a flush
>
> 1 is good for fsync-like operations;
> 2 is good for jo
On Fri, Feb 19, 2010 at 12:22:20AM +0200, Michael S. Tsirkin wrote:
> I took a stub at documenting CMD and FLUSH request types in virtio
> block. Christoph, could you look over this please?
>
> I note that the interface seems full of warts to me,
> this might be a first step to cleaning them.
Th
On Tue, May 04, 2010 at 02:08:24PM +0930, Rusty Russell wrote:
> On Fri, 19 Feb 2010 08:52:20 am Michael S. Tsirkin wrote:
> > I took a stub at documenting CMD and FLUSH request types in virtio
> > block. Christoph, could you look over this please?
> >
> > I note that the interface seems full of
On Tue, Jan 05, 2010 at 08:16:15PM +, Jamie Lokier wrote:
> It would be good if virtio relayed the backing device's basic topology
> hints, so:
>
> - If the backing dev is a real disk with 512-byte sectors,
> virtio should indicate 512-byte blocks to the guest.
>
> - If the back
On Mon, Jan 04, 2010 at 01:38:51PM +1030, Rusty Russell wrote:
> I thought this was what I was doing, but I have shown over and over that
> I have no idea about block devices.
>
> Our current driver treats BLK_SIZE as the logical and physical size (see
> blk_queue_logical_block_size).
>
> I have
On Thu, Oct 29, 2009 at 10:14:19AM -0500, Anthony Liguori wrote:
> Which patches are those?
http://repo.or.cz/w/qemu/kraxel.git?a=commitdiff;h=1ee5ee08e4427c3db7e1322d30cc0e58e5ca48b9
and
http://repo.or.cz/w/qemu/kraxel.git?a=commitdiff;h=a6e6178185786c582141f993272e00521d3f125a
___
On Thu, Oct 29, 2009 at 01:57:40PM +0100, Gerd Hoffmann wrote:
> Trying to go forward in review+bisect friendly baby steps. Here is what
> I have now:
>
> http://repo.or.cz/w/qemu/kraxel.git?a=shortlog;h=refs/heads/scsi.v1
>
> It is far from being completed, will continue tomorrow. Should give
On Wed, Oct 28, 2009 at 08:25:22PM +0100, Hannes Reinecke wrote:
> I don't think we really need two modes.
> My preferred interface here is to pass down scatter-gather lists down
> with every xfer; this way it'll be the responsibility of the driver to
> create the lists in the first place. If it ha
On Wed, Oct 28, 2009 at 09:11:29AM +0100, Hannes Reinecke wrote:
> The problem is I don't have any documentation for the LSI parallel
> SCSI controller. So I don't know if and in what shape I/O is passed
> down, nor anything else. And as the SCSI disk emulation is really
> tied into the LSI paralle
On Tue, Oct 27, 2009 at 04:28:59PM +0100, Hannes Reinecke wrote:
>
> Other drives might want to use SCSI command emulation without
> going through the SCSI disk abstraction, as this imposes too
> many limits on the emulation.
Might be a good idea to move something like this first into the series
On Wed, Sep 09, 2009 at 05:12:26PM -0500, Anthony Liguori wrote:
> Alok Kataria wrote:
>> I see your point, but the ring logic or the ABI that we use to
>> communicate between the hypervisor and guest is not shared between our
>> storage and network drivers. As a result, I don't see any benefit of
On Thu, Aug 06, 2009 at 12:45:50PM +0100, Alasdair G Kergon wrote:
> On Thu, Aug 06, 2009 at 12:14:17PM +0100, Mark McLoughlin wrote:
> > We should error all barriers, even empty barriers, on devices like
> > virtio_blk which don't support them.
>
> Have you considered whether or not virtio_blk a
On Thu, Mar 20, 2008 at 09:37:19PM +0100, Carsten Otte wrote:
> Christoph Hellwig wrote:
>> On Thu, Mar 20, 2008 at 05:25:26PM +0100, Carsten Otte wrote:
>>> @@ -143,6 +143,10 @@ static noinline __init void detect_machi
>>> /* Running on a P/390 ? */
>>
On Thu, Mar 20, 2008 at 05:25:26PM +0100, Carsten Otte wrote:
> @@ -143,6 +143,10 @@ static noinline __init void detect_machi
> /* Running on a P/390 ? */
> if (cpuinfo->cpu_id.machine == 0x7490)
> machine_flags |= 4;
> +
> + /* Running under KVM ? */
> + if (cpuin
On Mon, Jun 25, 2007 at 10:26:37AM -0500, Brian King wrote:
> 1. The add_inbuf interface passes an sg list. This causes problems for
>ibmveth since its rx buffers cannot be scatterlists.
> 2. The user of this API does not have access to the sk_buf. This causes
>issues for ibmveth since it n
On Fri, May 11, 2007 at 05:31:06PM +1000, Rusty Russell wrote:
> Well, without ioremap, the memory wouldn't normally be mapped. Is
> there something better to use?
Either use accessors or use your own lguest-specific remapping function that
doesn't return __iomem function
> > So instead of
On Fri, May 11, 2007 at 11:21:30AM +1000, Rusty Russell wrote:
> 1) send-dma and bind-dma hypercall wrappers for drivers to use,
> 2) formalization of the convention that devices can use the irq
>corresponding to their index on the lguest_bus.
> 3) ___force to shut up sparse: guests *can* use i
On Fri, May 11, 2007 at 11:17:26AM +1000, Rusty Russell wrote:
> - But the cost was high: lots of __force casts 8(
That sounds like something is very fishy.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linu
On Thu, May 10, 2007 at 01:14:55AM +1000, Rusty Russell wrote:
> > > + info->peer = (void *)ioremap(info->peer_phys, info->mapsize);
> >
> > check for NULL
>
> Erk, good catch!
Also the cast is bogus. ioremap already returns void already. Even
more importantly the lack of the __iomem annotatio
On Fri, May 04, 2007 at 04:21:16PM -0700, Jeremy Fitzhardinge wrote:
> +/*
> + * Mutually-exclusive module options to select receive data path:
> + * rx_copy : Packets are copied by network backend into local memory
> + * rx_flip : Page containing packet data is transferred to our ownership
> + *
> source "drivers/s390/block/Kconfig"
> +source "drivers/block/xen/Kconfig"
Please don't add a new subdirectory for a tiny new driver that
really should be only a single .c file.
> +config XEN_BLKDEV_FRONTEND
> + tristate "Block device frontend driver"
> + depends on XEN
> + default
On Sun, Apr 29, 2007 at 10:29:02AM -0700, Jeremy Fitzhardinge wrote:
> +#include
not needed.
> +#include
> +#include
> +#include
> +#ifdef CONFIG_XEN_BALLOON
> +#include
> +#endif
> +#include
Please don't try to put such a fucked up include hierachy in.
Just move everything under include/x
On Fri, Mar 16, 2007 at 10:26:55AM -0700, Jeremy Fitzhardinge wrote:
> +#ifdef CONFIG_HIGHPTE
> + .kmap_atomic_pte = native_kmap_atomic_pte,
> +#else
> + .kmap_atomic_pte = paravirt_nop,
> +#endif
This is ifdefing is quite ugly. Shouldn't native_kmap_atomic_pte
just be a noop in the !CONF
901 - 935 of 935 matches
Mail list logo
