On Sun, 2025-05-18 at 22:32 -0700, Christoph Hellwig wrote:
> On Fri, May 16, 2025 at 12:06:21PM -0400, Benjamin Marzinski wrote:
> > I've run into SCSI arrays that always act like they were called
> > with the
> > ALL_TG_PT flag set (or perhaps they were just configured that way,
> > I
> > never c
On Mon, May 19, 2025 at 07:33:50PM +0200, Martin Wilck wrote:
> I still don't get what this buys us.
You get one layer to deal with instead of polking into a leak
abstraction. Qemu sees a block devices, checks if it supports
persistent reservations and everything is taken care underneath
instead
On Sun, May 18, 2025 at 10:32:17PM -0700, Christoph Hellwig wrote:
> On Fri, May 16, 2025 at 12:06:21PM -0400, Benjamin Marzinski wrote:
> > I've run into SCSI arrays that always act like they were called with the
> > ALL_TG_PT flag set (or perhaps they were just configured that way, I
> > never co
On Thu, 2025-05-15 at 23:00 -0700, Christoph Hellwig wrote:
> On Thu, May 15, 2025 at 12:11:49PM +0200, Kevin Wolf wrote:
> > If you're talking about SG_IO in dm-mpath, then PRIN/PROUT commands
> > are
> > actually the one thing that we don't need. libmpathpersist sends
> > the
> > commands to the
Am 16.05.2025 um 08:00 hat Christoph Hellwig geschrieben:
> On Thu, May 15, 2025 at 12:11:49PM +0200, Kevin Wolf wrote:
> > If you're talking about SG_IO in dm-mpath, then PRIN/PROUT commands are
> > actually the one thing that we don't need. libmpathpersist sends the
> > commands to the individual
On Fri, May 16, 2025 at 12:06:21PM -0400, Benjamin Marzinski wrote:
> I've run into SCSI arrays that always act like they were called with the
> ALL_TG_PT flag set (or perhaps they were just configured that way, I
> never could get a straight answer about that).
Hmm, that's pretty strange.
> libm
On Thu, May 15, 2025 at 11:00:17PM -0700, Christoph Hellwig wrote:
> On Thu, May 15, 2025 at 12:11:49PM +0200, Kevin Wolf wrote:
> > If you're talking about SG_IO in dm-mpath, then PRIN/PROUT commands are
> > actually the one thing that we don't need. libmpathpersist sends the
> > commands to the i
On Thu, May 15, 2025 at 12:11:49PM +0200, Kevin Wolf wrote:
> If you're talking about SG_IO in dm-mpath, then PRIN/PROUT commands are
> actually the one thing that we don't need. libmpathpersist sends the
> commands to the individual path devices, so dm-mpath will never see
> those. It's mostly abo
On Thu, May 15, 2025 at 05:00:41PM +0200, Martin Wilck wrote:
> I didn't mean it this way. I was rather musing about the question
> whether doing SG_IO on multipath devices by forwarding them to the
> current path makes sense.
It doesn't, and that's the core of the problem. Someone back in the
da
On Tue, May 13, 2025 at 12:29:51PM -0400, Benjamin Marzinski wrote:
> On Mon, May 12, 2025 at 11:49:19PM -0700, Christoph Hellwig wrote:
> > On Tue, May 13, 2025 at 08:32:12AM +0200, Hannes Reinecke wrote:
> > > Reservations and stuff.
> >
> > They should use the kernel persistent reservation API.
On Thu, 2025-05-15 at 13:09 +0200, Paolo Bonzini wrote:
> However, EBADE handling dates back to 2011 (commit 63583cca745f,
> "[SCSI]
> Add detailed SCSI I/O errors", 2011-02-12) and yet the Windows tests
> for
> PR were failing before QEMU switched to SG_IO for reads and writes.
> I
> guess I
On Thu, 2025-05-15 at 12:11 +0200, Kevin Wolf wrote:
> Am 14.05.2025 um 23:21 hat Martin Wilck geschrieben:
>
> > In the long term, we should evaluate alternatives. If my conjecture
> > in
> > my previous post is correct we need only PRIN/PROUT commands, there
> > might be a better solution than
On Thu, 2025-05-15 at 10:29 -0400, Benjamin Marzinski wrote:
> On Thu, May 15, 2025 at 12:34:13PM +0200, Martin Wilck wrote:
> >
> > However, I suppose that depends on the permissions with which the
> > qemu
> > process is started, no? Wouldn't qemu need CAP_SYS_RAWIO for PCI
> > passthrough as we
On Thu, 2025-05-15 at 12:51 +0200, Paolo Bonzini wrote:
> On Thu, May 15, 2025 at 12:34 PM Martin Wilck
> >
> > Thanks for mentioning this. However, I suppose that depends on the
> > permissions with which the qemu process is started, no? Wouldn't
> > qemu need CAP_SYS_RAWIO for PCI passthrough
On Thu, May 15, 2025 at 12:34:13PM +0200, Martin Wilck wrote:
> On Thu, 2025-05-15 at 04:53 +0200, Paolo Bonzini wrote:
> > Il mer 14 mag 2025, 13:37 Martin Wilck ha scritto:
> > >
> > > I'd go one step further. Christoph is right to say that what we're
> > > currently doing in qemu – passing thr
On 5/14/25 06:53, Christoph Hellwig wrote:
And no, passing the SCSI devices to the VM and doing multipath in the
the guest doesn't work. The transport layer isn't properly emulated
(bluntly speaking, we have no FC emulation).
Then fix that. Because without it you will be in never ending pain
d
On Thu, May 15, 2025 at 12:34 PM Martin Wilck wrote:
> On Thu, 2025-05-15 at 04:53 +0200, Paolo Bonzini wrote:
> > Il mer 14 mag 2025, 13:37 Martin Wilck ha scritto:
> > Yes, as usual things are a bit more complicated. First, a handful of
> > commands are special (REQUEST SENSE would be for HBAs
On 5/15/25 12:11, Kevin Wolf wrote:
The thing that we need to make sure, though, is that the emulated status
we can expose to the guest is actually good enough. That Paolo said that
the problem with reservation conflicts was mostly because -EBADE wasn't
a thing yet gives me some hope that at leas
On Thu, 2025-05-15 at 04:53 +0200, Paolo Bonzini wrote:
> Il mer 14 mag 2025, 13:37 Martin Wilck ha scritto:
> >
> > I'd go one step further. Christoph is right to say that what we're
> > currently doing in qemu – passing through every command except the
> > PRIN/PROUT to a multipath device – is
Am 14.05.2025 um 23:21 hat Martin Wilck geschrieben:
> On Tue, 2025-05-13 at 10:00 +0200, Martin Wilck wrote:
> > > If you think it does, is there another reason why you didn't try
> > > this
> > > before?
> >
> > It didn't occur to me back then that we could fail paths without
> > retrying in the
Il mer 14 mag 2025, 13:37 Martin Wilck ha scritto:
>
> I'd go one step further. Christoph is right to say that what we're
> currently doing in qemu – passing through every command except the
> PRIN/PROUT to a multipath device – is a dangerous thing to do.
>
> Passthrough from a dm-multipath device
On Tue, 2025-05-13 at 10:00 +0200, Martin Wilck wrote:
>
> > If you think it does, is there another reason why you didn't try
> > this
> > before?
>
> It didn't occur to me back then that we could fail paths without
> retrying in the kernel.
>
> Perhaps we could have the sg driver pass the blk
Hello Ben, hello Christoph,
On Wed, 2025-05-14 at 12:23 -0400, Benjamin Marzinski wrote:
> On Tue, May 13, 2025 at 09:57:51PM -0700, Christoph Hellwig wrote:
> >
> > SG_IO is fine and the only way for SCSI passthrough. But doing
> > SCSI passthrough through md-multipath just doesn't work. SCSI
On Tue, May 13, 2025 at 09:57:51PM -0700, Christoph Hellwig wrote:
> On Tue, May 13, 2025 at 11:29:09AM +0200, Kevin Wolf wrote:
> > Am 13.05.2025 um 07:55 hat Christoph Hellwig geschrieben:
> > > On Mon, May 12, 2025 at 05:18:43PM +0200, Kevin Wolf wrote:
> > > > Yes, it's a bit unfortunate, but w
On Wed, May 14, 2025 at 08:39:25AM +0200, Hannes Reinecke wrote:
> On 5/13/25 18:29, Benjamin Marzinski wrote:
> > On Mon, May 12, 2025 at 11:49:19PM -0700, Christoph Hellwig wrote:
> > > On Tue, May 13, 2025 at 08:32:12AM +0200, Hannes Reinecke wrote:
> > > > Reservations and stuff.
> > >
> > > T
On 5/13/25 18:29, Benjamin Marzinski wrote:
On Mon, May 12, 2025 at 11:49:19PM -0700, Christoph Hellwig wrote:
On Tue, May 13, 2025 at 08:32:12AM +0200, Hannes Reinecke wrote:
Reservations and stuff.
They should use the kernel persistent reservation API.
Currently QEMU isn't sending Persist
On Tue, May 13, 2025 at 11:29:09AM +0200, Kevin Wolf wrote:
> Am 13.05.2025 um 07:55 hat Christoph Hellwig geschrieben:
> > On Mon, May 12, 2025 at 05:18:43PM +0200, Kevin Wolf wrote:
> > > Yes, it's a bit unfortunate, but we have to work with what we have. QEMU
> > > doesn't even necessarily know
On Tue, May 13, 2025 at 12:29:51PM -0400, Benjamin Marzinski wrote:
> Without reading that sense and status information in kernel, the
> multipath target can't know if it needs to fail a path and retry the
> ioctl down a different path. QEMU can read this information, but it
> doesn't know what pat
On Tue, May 13, 2025 at 10:17:58AM +0200, Martin Wilck wrote:
> If we emulate a SCSI device to a VM, the device should support commands
> like persistent reservations properly.
Then point it to an actual SCSI device, and not a multipath-device.
Trying to split responsibility for handling the init
On Tue, May 13, 2025 at 08:30:55AM +0200, Hannes Reinecke wrote:
> On 5/12/25 17:18, Kevin Wolf wrote:
> > Am 08.05.2025 um 15:51 hat Martin Wilck geschrieben:
> > > Hello Kevin,
> > >
> > > [I'm sorry for the previous email. It seems that I clicked "send" in
> > > the wrong window].
> > >
> > >
On Mon, May 12, 2025 at 11:49:19PM -0700, Christoph Hellwig wrote:
> On Tue, May 13, 2025 at 08:32:12AM +0200, Hannes Reinecke wrote:
> > Reservations and stuff.
>
> They should use the kernel persistent reservation API.
Currently QEMU isn't sending Persistent Reservation requests to
multipath de
Il mar 13 mag 2025, 11:29 Kevin Wolf ha scritto:
> QEMU's scsi-block device actually started off using normal I/O for reads
> and writes and using SG_IO only for things that aren't covered by normal
> I/O. But then those had to be changed to SG_IO, too, so that the guest
> would actually see the f
On Tue, 2025-05-13 at 10:00 +0200, Martin Wilck wrote:
> On Mon, 2025-05-12 at 17:18 +0200, Kevin Wolf wrote:
>
> >
> > Ben already fixed up the missing check.
>
> I missed that.
Saw it now.
Martin
Am 13.05.2025 um 07:55 hat Christoph Hellwig geschrieben:
> On Mon, May 12, 2025 at 05:18:43PM +0200, Kevin Wolf wrote:
> > Yes, it's a bit unfortunate, but we have to work with what we have. QEMU
> > doesn't even necessarily know that it's dealing with a multipath device,
> > so it just has to bli
On Mon, 2025-05-12 at 23:49 -0700, Christoph Hellwig wrote:
> On Tue, May 13, 2025 at 08:32:12AM +0200, Hannes Reinecke wrote:
> > Reservations and stuff.
>
> They should use the kernel persistent reservation API.
>
> > There are customer who use GPFS ...
>
> Supporting illegal binary only modul
Hi Kevin,
On Mon, 2025-05-12 at 17:18 +0200, Kevin Wolf wrote:
> Am 08.05.2025 um 15:51 hat Martin Wilck geschrieben:
> > Hello Kevin,
> >
> > [I'm sorry for the previous email. It seems that I clicked "send"
> > in
> > the wrong window].
> >
> > On Tue, 2025-04-29 at 18:50 +0200, Kevin Wolf wro
Hello Mikulas,
On Mon, 2025-05-12 at 15:46 +0200, Mikulas Patocka wrote:
> Hi
>
>
> On Thu, 8 May 2025, Martin Wilck wrote:
>
> > Hello Kevin,
> >
> > [I'm sorry for the previous email. It seems that I clicked "send"
> > in
> > the wrong window].
> >
> > On Tue, 2025-04-29 at 18:50 +0200, Kev
On Tue, May 13, 2025 at 08:09:45AM +0200, Hannes Reinecke wrote:
> On 5/13/25 07:55, Christoph Hellwig wrote:
> > On Mon, May 12, 2025 at 05:18:43PM +0200, Kevin Wolf wrote:
> > > Yes, it's a bit unfortunate, but we have to work with what we have. QEMU
> > > doesn't even necessarily know that it's
On Tue, May 13, 2025 at 08:32:12AM +0200, Hannes Reinecke wrote:
> Reservations and stuff.
They should use the kernel persistent reservation API.
> There are customer who use GPFS ...
Supporting illegal binary only modules that is already enough of a
reason to NAK this.
On 5/13/25 08:14, Christoph Hellwig wrote:
On Tue, May 13, 2025 at 08:09:45AM +0200, Hannes Reinecke wrote:
On 5/13/25 07:55, Christoph Hellwig wrote:
On Mon, May 12, 2025 at 05:18:43PM +0200, Kevin Wolf wrote:
Yes, it's a bit unfortunate, but we have to work with what we have. QEMU
doesn't ev
On 5/12/25 17:18, Kevin Wolf wrote:
Am 08.05.2025 um 15:51 hat Martin Wilck geschrieben:
Hello Kevin,
[I'm sorry for the previous email. It seems that I clicked "send" in
the wrong window].
On Tue, 2025-04-29 at 18:50 +0200, Kevin Wolf wrote:
Multipath cannot directly provide failover for ioc
On 5/13/25 07:55, Christoph Hellwig wrote:
On Mon, May 12, 2025 at 05:18:43PM +0200, Kevin Wolf wrote:
Yes, it's a bit unfortunate, but we have to work with what we have. QEMU
doesn't even necessarily know that it's dealing with a multipath device,
so it just has to blindly try the ioctl and see
On Mon, May 12, 2025 at 05:18:43PM +0200, Kevin Wolf wrote:
> Yes, it's a bit unfortunate, but we have to work with what we have. QEMU
> doesn't even necessarily know that it's dealing with a multipath device,
> so it just has to blindly try the ioctl and see if it works.
Why is qemu even using SG
Am 08.05.2025 um 15:51 hat Martin Wilck geschrieben:
> Hello Kevin,
>
> [I'm sorry for the previous email. It seems that I clicked "send" in
> the wrong window].
>
> On Tue, 2025-04-29 at 18:50 +0200, Kevin Wolf wrote:
> > Multipath cannot directly provide failover for ioctls in the kernel
> > be
Hi
On Thu, 8 May 2025, Martin Wilck wrote:
> Hello Kevin,
>
> [I'm sorry for the previous email. It seems that I clicked "send" in
> the wrong window].
>
> On Tue, 2025-04-29 at 18:50 +0200, Kevin Wolf wrote:
> > Multipath cannot directly provide failover for ioctls in the kernel
> > because i
Hello Kevin,
[I'm sorry for the previous email. It seems that I clicked "send" in
the wrong window].
On Tue, 2025-04-29 at 18:50 +0200, Kevin Wolf wrote:
> Multipath cannot directly provide failover for ioctls in the kernel
> because it doesn't know what each ioctl means and which result could
>
Multipath cannot directly provide failover for ioctls in the kernel
because it doesn't know what each ioctl means and which result could
indicate a path error. Userspace generally knows what the ioctl it
issued means and if it might be a path error, but neither does it know
which path the ioctl too
47 matches
Mail list logo
