On Sun, Apr 29, 2007 at 10:29:02AM -0700, Jeremy Fitzhardinge wrote:
+#include linux/version.h
not needed.
+#include xen/xenbus.h
+#include xen/interface/io/netif.h
+#include xen/interface/memory.h
+#ifdef CONFIG_XEN_BALLOON
+#include xen/balloon.h
+#endif
+#include
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 y
Please
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
+ * For
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 annotations shows
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
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 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
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 ? */
if (cpuinfo-cpu_id.machine == 0x7490
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 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
and
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 parallel
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 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 no
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 backing
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 warts to
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
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: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 unsupportable? How
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
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.
___
Virtualization
@@ -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 this patch,
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
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 next
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 Fri, Apr 29, 2011 at 04:32:35PM +, KY Srinivasan wrote:
On the host-side, as part of configuring a guest you can specify block
devices
as being under an IDE controller or under a
SCSI controller. Those are the only options you have. Devices configured under
the IDE controller cannot
On Fri, Apr 29, 2011 at 09:40:25AM -0700, Greg KH wrote:
Are you sure the libata core can't see this ide controller and connect
to it? That way you would use the scsi system if you do that and you
would need a much smaller ide driver, perhaps being able to merge it
with your scsi driver.
On Sun, May 01, 2011 at 03:46:23PM +, KY Srinivasan wrote:
What is the issue here? This is no different than what is done in other
Virtualization platforms. For instance, the Xen blkfront driver is no
different - if you specify the block device to be presented to the guest
as an ide
On Sun, May 01, 2011 at 06:56:58PM +, KY Srinivasan wrote:
Yeah, it seems to me that no matter how the user specifies the disk
type for the guest configuration, we should use the same Linux driver,
with the same naming scheme for both ways.
As Christoph points out, it's just a
On Sun, May 01, 2011 at 06:08:37PM +, KY Srinivasan wrote:
Could you elaborate on the problems/issues when the block driver registers
for the
IDE majors. On the Qemu side, we have a mechanism to disable the emulation
when
PV drivers load. I don't think there is an equivalent mechanism
On Mon, May 02, 2011 at 07:48:38PM +, KY Srinivasan wrote:
By setting up appropriate modprobe rules, this can be addressed.
That assumes libata is a module, which it is not for many popular
distributions.
___
Virtualization mailing list
On Mon, May 02, 2011 at 09:16:36PM +, KY Srinivasan wrote:
That assumes libata is a module, which it is not for many popular
distributions.
As long as you can prevent ata_piix from loading, it should be fine.
Again, this might very well be built in, e.g. take a look at:
On Wed, May 04, 2011 at 11:51:45AM -0700, K. Y. Srinivasan wrote:
config HYPERV
tristate Microsoft Hyper-V client drivers
- depends on X86 m
+ depends on X86 ACPI PCI m
I can't see anything preventing this driver from beeing built-in,
so the depends on m should probably go
On Fri, May 06, 2011 at 01:10:38PM +, KY Srinivasan wrote:
I audited the block and the net drivers. As part of their exit routine,
they invoke vmbus_child_driver_unregister() after properly cleaning
up all the devices they are managing. Do you still see an issue with
regards to module
On Mon, May 09, 2011 at 02:56:52PM +, KY Srinivasan wrote:
I will address this. Greg had a concern about module reference counting
and looking at the current code, it did not appear to be an issue. The
change you are suggesting will not affect the vmbus core which is what I want
to focus
- ret = storvsc_drv-on_io_request(blkdev-device_ctx,
+ ret = storvsc_do_io(blkdev-device_ctx,
blkvsc_req-request);
ret = storvsc_do_io(blkdev-device_ctx, blkvsc_req-request);
___
- net_device-wait_condition = 0;
ret = vmbus_sendpacket(device-channel, init_packet,
sizeof(struct nvsp_message),
(unsigned long)init_packet,
@@ -272,10 +272,8 @@ static int netvsc_init_recv_buf(struct hv_device *device)
On Mon, May 09, 2011 at 02:56:51PM -0700, K. Y. Srinivasan wrote:
The subject line says it all.
Is there any good reason to not support a 32-bit sector_t?
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
I must be missing something here. As I look at the block driver (and
this is indicative of other drivers as well); the exit routine -
blkvsc_drv_exit, first iterates through all the devices it manages
and invokes device_unregister() on each of the devices and then
invokes
On Thu, May 19, 2011 at 03:06:25PM -0700, K. Y. Srinivasan wrote:
A few days ago you applied all the outstanding patches for the Hyper-V
drivers. With these patches, I have addressed all of the known review
comments for the vmbus driver (and a lot of comments/issues in other
drivers as
On Fri, May 20, 2011 at 01:12:32PM +, KY Srinivasan wrote:
Well, the util driver that implements a range of other services such as KVP,
time synch, heartbeat etc. is also a client of the vmbus driver (perhaps not
in the
The KVP driver is a different module as far as I can see. But it
I see maintainers for each of the clocksource drivers and I see John Stultz
and
Thomas Gleixner listed as the maintainers for Timekeeping. Who should
sign-off
on the Hyper-V clocksource.
just send it to both of the with linux-kernel in Cc, and either of them
will probably put it in.
On Mon, Jun 06, 2011 at 03:49:36PM -0700, K. Y. Srinivasan wrote:
To support auto-loading the storvsc driver, add a DMI signature.
The storvsc driver is not a DMI driver, but a vmbus driver. As such it
should have a vmbus table that is used for autoloading, not a dmi one.
On Mon, Jun 06, 2011 at 03:49:48PM -0700, K. Y. Srinivasan wrote:
Now, get rid of the unused wrapper - vmbus_onchannel_event().
I'd merge this into the previous patch. In general your patch split
seem a little too fine grained to me in general. When you remove a
wrapper you can inline it into
On Mon, Jun 06, 2011 at 03:49:50PM -0700, K. Y. Srinivasan wrote:
Since tis is not used anymore, get rid of the poll timer in the channel
state.
This would be more useful together with the patch that removes the use
of the timer.
___
Virtualization
On Sun, Jun 19, 2011 at 10:48:41AM +0300, Michael S. Tsirkin wrote:
diff --git a/block/blk-core.c b/block/blk-core.c
index 4ce953f..a8672ec 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -433,6 +433,8 @@ void blk_run_queue(struct request_queue *q)
On Tue, Jun 14, 2011 at 05:30:24PM +0200, Hannes Reinecke wrote:
Which is exactly the problem I was referring to.
When using more than one channel the request ordering
_as seen by the initiator_ has to be preserved.
This is quite hard to do from a device's perspective;
it might be able to
On Sun, Jun 12, 2011 at 10:51:41AM +0300, Michael S. Tsirkin wrote:
For example, if the driver is crazy enough to put
all write requests on one queue and all barriers
on another one, how is the device supposed to ensure
ordering?
There is no such things as barriers in SCSI. The thing that
On Wed, Jun 29, 2011 at 10:23:26AM +0200, Paolo Bonzini wrote:
I agree here, in fact I misread Hannes's comment as if a driver
uses more than one queue it is responsibility of the driver to
ensure strict request ordering. If you send requests to different
queues, you know that those requests
On Wed, Jun 29, 2011 at 10:39:42AM +0100, Stefan Hajnoczi wrote:
I think we're missing a level of addressing. We need the ability to
talk to multiple target ports in order for list target ports to make
sense. Right now there is one implicit target that handles all
commands. That means there
On Wed, Jun 29, 2011 at 07:38:21AM -0700, K. Y. Srinivasan wrote:
Further cleanup of the hv drivers:
1) Cleanup the reference counting mess for both stor and net devices.
I really don't understand the need for reference counting on the storage
side, especially now that you only have a
+/*
+ * We want to manage the IDE devices using standard Linux SCSI drivers
+ * using the storvsc driver.
+ * Define special channels to support this.
+ */
+
+#define HV_MAX_IDE_DEVICES 4
+#define HV_IDE_BASE_CHANNEL 10
+#define HV_IDE0_DEV1 HV_IDE_BASE_CHANNEL
+#define
On Wed, Jun 29, 2011 at 07:39:21AM -0700, K. Y. Srinivasan wrote:
We use the channel number to distinguish an IDE device managed by the
storvsc driver from scsi devices. Add code to get the correct
device pointer based on the channel number.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
I think all this would be a lot simpler if you simply used one scsi
host per ide device as mentioned before.
Also it would be nice if you could sent patches 23 to 28 as one patch
in the next round, as that allows reviewing the whole IDE related code
in one go, which is useful given that it's all
On Wed, Jun 29, 2011 at 07:39:32AM -0700, K. Y. Srinivasan wrote:
Make storvsc_dev_add() a static function.
Making all pending functions static should be fine in a single patch.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
On Wed, Jun 29, 2011 at 07:39:31AM -0700, K. Y. Srinivasan wrote:
Add the contents of hyperv_storage.h to storvsc_drv.c and cleanup
storvsc_drv.c.n
I'd at least leave the first half of the header that defines the
protocol around.
___
Virtualization
On Wed, Jun 29, 2011 at 07:39:35AM -0700, K. Y. Srinivasan wrote:
The current handler on the Windows Host does not correctly handle
INQUIRY and MODE_SENSE commands with some options. Fixup srb_status
in these cases since the failure is not fatal.
+ /*
+ * The current SCSI handling
On Thu, Jun 30, 2011 at 07:59:28PM +, KY Srinivasan wrote:
The reason I did this was so that I could key off on real failures
indicated by
srb_status == 0x4 to off-line the device.
Ok. Please document what your doing in detail in the code, though.
On Thu, Jun 30, 2011 at 08:13:51PM +, KY Srinivasan wrote:
Add the contents of hyperv_storage.h to storvsc_drv.c and cleanup
storvsc_drv.c.n
I'd at least leave the first half of the header that defines the
protocol around.
I only got rid of the block comment at the start of
On Thu, Jun 30, 2011 at 09:15:54PM +, KY Srinivasan wrote:
That is what I did initially. Then looking at the way we were handling scsi
devices
where each scsi controller configured for the guest results in an emulated HBA
(scsi host) in the guest and all the block devices under a given
On Thu, Jun 30, 2011 at 09:38:34PM +, KY Srinivasan wrote:
+#define HV_MAX_IDE_DEVICES 4
+#define HV_IDE_BASE_CHANNEL 10
+#define HV_IDE0_DEV1 HV_IDE_BASE_CHANNEL
+#define HV_IDE0_DEV2 (HV_IDE_BASE_CHANNEL + 1)
+#define HV_IDE1_DEV1
On Thu, Jun 30, 2011 at 11:28:27PM +, KY Srinivasan wrote:
On Wed, Jun 29, 2011 at 07:38:21AM -0700, K. Y. Srinivasan wrote:
Further cleanup of the hv drivers:
1) Cleanup the reference counting mess for both stor and net devices.
I really don't understand the need for
On Fri, Jul 01, 2011 at 01:01:43PM +, KY Srinivasan wrote:
Nothing I could see from whatever testing I did. However, the guest will have
Scsi hosts that the user did not configure. This is certainly the case in
both
approaches - just the numbers are different!
If the IDE drivers were
On Fri, Jul 15, 2011 at 10:46:08AM -0700, K. Y. Srinivasan wrote:
+static bool is_not_null_guid(const __u8 *guid)
+{
+ int i;
+
+ for (i = 0; i (sizeof(struct hv_vmbus_device_id)); i++)
+ if (guid[i] != 0)
+ return true;
+ return false;
+}
Thanks, this looks much cleaner than the initial variant.
+ if (dev_is_ide) {
+ storvsc_get_ide_info(device, target, path);
+ host_dev-path = device_info.path_id;
+ host_dev-target = device_info.target_id;
+ } else {
+ host_dev-path =
On Fri, Jul 15, 2011 at 10:47:26AM -0700, K. Y. Srinivasan wrote:
Now, enable handling of all IDE devices by extending the storvsc
device id table to handle IDE guid. As part of this cleanup Kconfig
and Hyper-V Makefile to not build the IDE driver (blkvsc).
I think this should be part of the
On Sat, Jul 16, 2011 at 12:54:46PM +, KY Srinivasan wrote:
would be nice to add uuid_{le,be}_is_nil helpers to uuid.h. I also
think simply using a memcpy might be more efficient than the hand-rolled
loop.
Having a helper function would be great. With regards to the efficiency of
this
On Sat, Jul 16, 2011 at 04:01:39PM +0300, Sasha Levin wrote:
Is think that what Christoph meant was simplifying it to:
if (dev_is_ide)
storvsc_get_ide_info(device, target, path);
host_dev-path = device_info.path_id;
host_dev-target =
Any progress on these patches?
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
On Thu, Nov 03, 2011 at 06:12:49PM +1030, Rusty Russell wrote:
The old documentation is left over from when we used a structure with
strategy pointers.
Looks good,
Reviewed-by: Christoph Hellwig h...@lst.de
___
Virtualization mailing list
On Thu, Nov 03, 2011 at 06:12:50PM +1030, Rusty Russell wrote:
Remove wrapper functions. This makes the allocation type explicit in
all callers; I used GPF_KERNEL where it seemed obvious, left it at
GFP_ATOMIC otherwise.
Looks good,
Reviewed-by: Christoph Hellwig h...@lst.de
On Thu, Nov 03, 2011 at 06:12:51PM +1030, Rusty Russell wrote:
Based on patch by Christoph for virtio_blk speedup:
Please credit it to Stefan - he also sent a pointer to his original
version in reply to the previous thread.
Also shouldn't virtqueue_kick have kerneldoc comments?
I also notices
Please send a version that does direct block I/O similar to xen-blkback
for now. If we get proper in-kernel aio support one day you can add
back file backend support.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
On Wed, Jul 18, 2012 at 08:42:21AM -0500, Anthony Liguori wrote:
If you add support for a new command, you need to provide userspace
a way to disable this command. If you change what gets reported for
VPD, you need to provide userspace a way to make VPD look like what
it did in a previous
On Mon, Jul 30, 2012 at 09:31:06AM +0200, Paolo Bonzini wrote:
You only need to add REQ_FLUSH support. The virtio-blk protocol does
not support REQ_FUA, because there's no easy way to do it in userspace.
A bio-based driver needs to handle both REQ_FLUSH and REQ_FUA as it does
not get the
On Mon, Jul 30, 2012 at 12:43:12PM +0800, Asias He wrote:
I think we can add REQ_FLUSH REQ_FUA support to bio path and that
deserves another patch.
Adding it is a requirement for merging the code.
___
Virtualization mailing list
On Thu, Aug 02, 2012 at 02:25:56PM +0800, Asias He wrote:
We need to support both REQ_FLUSH and REQ_FUA for bio based path since
it does not get the sequencing of REQ_FUA into REQ_FLUSH that request
based drivers can request.
REQ_FLUSH is emulated by:
1. Send VIRTIO_BLK_T_FLUSH to device
On Thu, Aug 02, 2012 at 02:43:04PM +0800, Asias He wrote:
Even if it has a payload waiting is highly suboptimal and it should
use a non-blocking sequencing like it is done in the request layer.
So, for REQ_FLUSH, what we need is that send out the VIRTIO_BLK_T_FLUSH and
not to wait.
If it's
At least after review is done I really think this patch sopuld be folded
into the previous one.
Some more comments below:
@@ -58,6 +58,12 @@ struct virtblk_req
struct bio *bio;
struct virtio_blk_outhdr out_hdr;
struct virtio_scsi_inhdr in_hdr;
+ struct work_struct
On Tue, Aug 07, 2012 at 04:47:13PM +0800, Asias He wrote:
1) Ramdisk device
With bio-based IO path, sequential read/write, random read/write
IOPS boost : 28%, 24%, 21%, 16%
Latency improvement: 32%, 17%, 21%, 16%
2) Fusion IO device
With bio-based IO path,
+static int vhost_blk_req_submit(struct vhost_blk_req *req, struct file *file)
+{
+
+ struct inode *inode = file-f_mapping-host;
+ struct block_device *bdev = inode-i_bdev;
+ int ret;
Please just pass the block_device directly instead of a file struct.
+
+ ret =
On Fri, Mar 14, 2014 at 11:34:31PM -0400, Theodore Ts'o wrote:
The current virtio block sets a queue depth of 64, which is
insufficient for very fast devices. It has been demonstrated that
with a high IOPS device, using a queue depth of 256 can double the
IOPS which can be sustained.
As
On Sun, Jun 29, 2014 at 11:26:37AM +0300, Michael S. Tsirkin wrote:
On Fri, Jun 27, 2014 at 07:57:38AM -0400, Josh Boyer wrote:
Hi All,
We've had a report[1] of the virt_blk driver causing a lot of spew
because it's calling a sleeping function from an invalid context. The
backtrace is
On Mon, Jun 30, 2014 at 09:01:07PM -0600, Jens Axboe wrote:
I appreciate very much that one of you may queue these two
patches into your tree so that userspace work can be kicked off,
since Michael has acked both patches and all comments have
been addressed already.
Given that Michael also
the
behavior optional, but didn't update the existing drivers to keep their
previous behavior.
Signed-off-by: Christoph Hellwig h...@lst.de
---
drivers/block/virtio_blk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index
On Sun, Sep 07, 2014 at 02:41:53PM +0300, Michael S. Tsirkin wrote:
Signed-off-by: Christoph Hellwig h...@lst.de
OK so this is an optimization patch right?
What kind of performance gain is observed with it?
None. I actually wrote it when the block layer had a bug when dm was
used on top
On Mon, Sep 08, 2014 at 11:18:30AM +0300, Michael S. Tsirkin wrote:
Could you respond to Ming Lei's mail, who benchmarked the patch, please?
I don't really have any additional data or disagreement, not sure what
I should respond there.
___
On Thu, Nov 19, 2015 at 04:21:03PM -0800, Ming Lin wrote:
> #define NVMET_SUBSYS_NAME_LEN256
> charsubsys_name[NVMET_SUBSYS_NAME_LEN];
> +
> + void*opaque;
> + void(*start)(void *);
> };
Why can't vhost
Thanks Ming,
from a first quick view this looks great. I'll look over it in a bit
more detail once I get a bit more time.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
On Tue, Jun 28, 2016 at 10:39:15AM +0800, Fam Zheng wrote:
> Userspace listens to the KOBJ_ADD uevent generated in add_disk. At that
> point we haven't created the serial attribute file, therefore depending
> on how fast udev reacts, the /dev/disk/by-id/ entry doesn't always get
> created.
>
>
On Fri, Jan 29, 2016 at 11:01:00AM +, David Woodhouse wrote:
> Also, wasn't Christoph looking at making per-device DMA ops more
> generic instead of an 'archdata' thing on basically every platform? Or
> did I just imagine that part?
What I've done for 4.5 is to switch all architectures to use
On Tue, Jul 19, 2016 at 05:38:23AM +0300, Michael S. Tsirkin wrote:
>
> On other systems, including SPARC and PPC64, virtio-pci devices are
> enumerated as though they are behind an IOMMU, but the virtio host
> ignores the IOMMU, so we must either pretend that the IOMMU isn't
> there or somehow
Again, this is still the wrong way around. A "noiommu" feature is a
quirk and should not be the default.
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Thu, Jun 30, 2016 at 02:35:54PM +0800, Fam Zheng wrote:
> also more code and less flexible IMO. For example, we need at least two
> variants, for attribute_group and device_attribute separately, right?
Yes, or maybe just a calling convention that just passes both.
On Fri, Feb 03, 2017 at 03:54:36PM +0800, Jason Wang wrote:
>> +list_for_each_entry(vq, _dev->vdev.vqs, list) {
>> +if (vq->callback && vring_interrupt(irq, vq) == IRQ_HANDLED)
>
> The check of vq->callback seems redundant, we will check it soon in
> vring_interrupt().
Good point
On Fri, Feb 03, 2017 at 03:54:54PM +0800, Jason Wang wrote:
> On 2017年01月27日 16:16, Christoph Hellwig wrote:
>> +snprintf(vp_dev->msix_names[i + 1],
>> + sizeof(*vp_dev->msix_names), "%s-%s",
>>
On Tue, Feb 07, 2017 at 03:17:02PM +0800, Jason Wang wrote:
> The check is still there.
Meh, I could swear I fixed it up. Here is an updated version:
---
>From bf5e3b7fd272aea32388570503f00d0ab592fc2a Mon Sep 17 00:00:00 2001
From: Christoph Hellwig <h...@lst.de>
Date: Wed, 25 Jan 2
This basically passed up the pci_irq_get_affinity information through
virtio through an optional get_vq_affinity method. It is only implemented
by the PCI backend for now, and only when we use per-virtqueue IRQs.
Signed-off-by: Christoph Hellwig <h...@lst.de>
Reviewed-by: Jason Wang
Signed-off-by: Christoph Hellwig <h...@lst.de>
Reviewed-by: Jason Wang <jasow...@redhat.com>
---
drivers/virtio/virtio_pci_common.c | 5 ++---
drivers/virtio/virtio_pci_common.h | 2 --
drivers/virtio/virtio_pci_legacy.c | 2 +-
drivers/virtio/virtio_pci_modern.c | 2 +-
includ
semantics
- we can use a simple array to look up the MSI-X vec if needed.
- That simple array now also duoble serves to replace the per_vq_vectors
flag
Signed-off-by: Christoph Hellwig <h...@lst.de>
---
drivers/virtio/virtio_pci_common.c | 117 +++--
d
Hi Michael, hi Jason,
This patches applies a few cleanups to the virtio PCI interrupt handling
code, and then converts the virtio PCI code to use the automatic MSI-X
vectors spreading, as well as using the information in virtio-blk
and virtio-scsi to automatically align the blk-mq queues to the
1 - 100 of 910 matches
Mail list logo
