request processing state from block.c?
I did very little scaling testing on virtio-blk, it was more a demo case
for conversion than anything else. So probably not of much use to what
you are looking for...
--
Jens Axboe
require a thread for
handling completions, but you could easily just use a single completion
thread for all devices for this as it would not need to do any real
work.
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org
may have to ensure 1k/4k alignment.
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
like CDROM_SEND_PACKET or SG_IO. Or the CDROMREADAUDIO ioctl,
which is the easiest to use since it doesn't require an understanding of
the command set.
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman
.
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
WIN_FLUSH_CACHE:
+case WIN_FLUSH_CACHE_EXT:
s-status = READY_STAT;
ide_set_irq(s);
break;
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
On Fri, Dec 30 2005, Fabrice Bellard wrote:
Jens Axboe wrote:
Saw the posts on this the other day and had a few spare hours to play
with this. Works for me, with and without DMA (didn't test mult mode,
but that should work fine too).
Test with caution though, it's changing the ide code so
On Fri, Dec 30 2005, Fabrice Bellard wrote:
Jens Axboe wrote:
Saw the posts on this the other day and had a few spare hours to play
with this. Works for me, with and without DMA (didn't test mult mode,
but that should work fine too).
Test with caution though, it's changing the ide code so
;
+ }
default:
goto abort_cmd;
}
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Hi,
Here's the set of 3 patches I currently have for the qemu ide/block
code.
1/3: The ide id updates
2/3: lba48 support
3/3: Proper support of the flush cache command
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http
On Wed, Jan 04 2006, Johannes Schindelin wrote:
Hi,
On Wed, 4 Jan 2006, Jens Axboe wrote:
1.0.GIT
Using git for QEmu development? Welcome to the club. ;-)
Yes I just imported the repo into git, cvs isn't really my cup of tea
and it isn't very handy for patch series. git isn't very
On Thu, Jan 05 2006, Jens Axboe wrote:
Are you using a persistent git repo for qemu (ie continually importing
new changes)? I've considered setting one up :-)
I set up such a gateway, should be updated every night from Fabrices cvs
repository. The web interface is here:
http://brick.kernel.dk
On Wed, Feb 01 2006, Fabrice Bellard wrote:
Jens Axboe wrote:
Subject: [PATCH] Add lba48 support to ide
From: Jens Axboe [EMAIL PROTECTED]
Date: 1136376117 +0100
Add lba48 support for the ide code. Read back of hob registers isn't
there yet, though.
Do you have a more recent patch
a nsector_internal to fixup this internally in the
read/write path so all register correctly reflect what was actually
written by the OS.
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
broken (or
incomplete)?
lba48 support is not committed yet, read the linux messasge - it says it
cannot use lba48, because the drive (qemu) doesn't support it. Find my
latest posting on this list, it should get you going.
--
Jens Axboe
___
Qemu
On Mon, Mar 13 2006, Mario Goppold wrote:
Am Samstag, 11. März 2006 13:31 schrieb Jens Axboe:
On Fri, Mar 10 2006, Mario Goppold wrote:
Hi,
I try to install SuSE92-64 on an 400G HD but it fails:
hda: max request size: 128KiB
hda: cannot use LBA48 - full capacity 838860800
is at mwait_idle+0x2f/0x41
I don't think qemu supports PNI, which includes the monitor/mwait
additions. I wonder why Linux detects that. You can probably get around
it for now by either passing idle=poll as a boot parameter, or compile
your kernel for plain i586 for instance.
--
Jens Axboe
the last two
suceed, the others still not. This CPU has sse2.
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
On Tue, Jun 20 2006, Jens Axboe wrote:
On Tue, Jun 20 2006, malc wrote:
On Tue, 20 Jun 2006, Sylvain Petreolle wrote:
--- Julian Seward [EMAIL PROTECTED] a ?crit :
The SSE2 instructions cvttps2dq, movdq2q, movq2dq do not behave
correctly, as shown by the attached program. It should
not emulate.
Until that gets fixed up, you can boot with idle=halt.
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
version, since that'll for sure perform the
best on Linux. But a posixaio version might be saner, as that should
work on other operating systems as well.
Fabrice, can you let people know what you would prefer?
--
Jens Axboe
___
Qemu-devel mailing
On Tue, Jul 25 2006, Fabrice Bellard wrote:
Jens Axboe wrote:
On Tue, Jul 25 2006, Sven Köhler wrote:
So the current thread-based async dma patch is really just the
wrong long term solution. A more long term solution is likely in
the works. It requires quite a bit of code modification
not know that queueing was fully implemented there yet!
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
On Wed, Jul 26 2006, Paul Brook wrote:
On Wednesday 26 July 2006 13:23, Jens Axboe wrote:
On Wed, Jul 26 2006, Paul Brook wrote:
Sounds good, so at least it's on its way :-)
It's on of those big items left on the TODO, so will be good to see go
in. Then one should implement an ahci
OS out there.
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
for
flushing data out, like using barriers on the file system and
propagating fsync() properly down.
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
on the app, if the io workload is parallel then you should see a
nice speedup as well (as QEMU is then no longer the serializing bottle
neck).
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
supposed to, QEMU can't
help you. And, in fact, running your app on the same host OS with write
back caching would screw you as well. The timing window will probably be
larger with QEMU, but the problem is essentially the same.
--
Jens Axboe
___
Qemu-devel
On Mon, Jul 31 2006, Jonas Maebe wrote:
On 31 jul 2006, at 09:08, Jens Axboe wrote:
Applications running on the host can count on fsync doing the
right thing, meaning that if they call fsync, the data *will*
have made it to disk. Applications running inside a guest have
no guarantees
they are arrogantly ignored.
Send a patch, I'm pretty sure nobody would disagree :-)
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
/barriers on Linux does this.
Random write tricks are worthless, as you cannot make any assumptions
about what the drive firmware will do.
--
Jens Axboe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu
On Tue, Aug 01 2006, Jamie Lokier wrote:
Jens Axboe wrote:
On Tue, Aug 01 2006, Jamie Lokier wrote:
Of course, guessing the disk drive write buffer size and trying not to
kill
system I/O performance with all these writes is another question
entirely
... sigh
be a good cleanup to get rid
of that an turn nsector into a proper uint8_t.
It appears to use 16k bits in some cases. I won't fiddle with it myself
16bits, or 64k, that is.
Yeah, it's for larger requests. It would be nice to track elsewhere,
though. I'll take a look at it.
--
Jens Axboe
the flush approach is really workable. Even just strict
ordering of requests could only be supported on SCSI, and even there the
kernel still lacks proper guarantees on error handling to prevent
reordering there.
--
Jens Axboe
as well, I have been hoping for some more adoption
of this. I have mptsas and mpt2sas patches pending as well.
I have not done enough and fully exhaustive weight analysis, so note me
down for wanting such an analysis on virtio_blk as well.
--
Jens Axboe
, or subversion. But cvs isn't really set up for this sort of
thing...
git clone git://git.kernel.dk/data/git/qemu.git
and bisect on that then. It's a continued git import of the cvs repo,
gets updated every night.
--
Jens Axboe
On Sun, Jun 24 2007, Rob Landley wrote:
On Saturday 23 June 2007 07:00:03 Jens Axboe wrote:
I realize releases are a bit out of fashion, but is there any way to go
through cvs to track down which checkin broke this stuff? I can do it in
git, mercurial, or subversion. But cvs isn't
))
+ buf[2] = 0x70;
+ else
+ buf[2] = 0;
buf[3] = 0;
buf[4] = 0;
buf[5] = 0;
--
Jens Axboe
is clearly too
anal.
--
Jens Axboe
] __blockdev_direct_IO_newtrunc+0x986/0x1270
RSP 88011a11ba48
---[ end trace 73be5dcaf8939399 ]---
Kernel panic - not syncing: Fatal exception
That code isn't even in mainline, as far as I can tell...
--
Jens Axboe
On 11/26/2014 01:51 PM, Mike Snitzer wrote:
On Wed, Nov 26 2014 at 2:48pm -0500,
Jens Axboe ax...@kernel.dk wrote:
On 11/21/2014 08:49 AM, Mike Snitzer wrote:
On Fri, Nov 21 2014 at 4:54am -0500,
Christoph Hellwig h...@infradead.org wrote:
On Thu, Nov 20, 2014 at 02:00:59PM -0500, Mike
On 11/26/2014 02:51 PM, Mike Snitzer wrote:
On Wed, Nov 26 2014 at 3:54pm -0500,
Jens Axboe ax...@kernel.dk wrote:
On 11/26/2014 01:51 PM, Mike Snitzer wrote:
On Wed, Nov 26 2014 at 2:48pm -0500,
Jens Axboe ax...@kernel.dk wrote:
That code isn't even in mainline, as far as I can tell
reat if you could try 5.4.71 and see if that helps for your
issue.
--
Jens Axboe
On 10/17/20 8:29 AM, Ju Hyung Park wrote:
> Hi Jens.
>
> On Sat, Oct 17, 2020 at 3:07 AM Jens Axboe wrote:
>>
>> Would be great if you could try 5.4.71 and see if that helps for your
>> issue.
>>
>
> Oh wow, yeah it did fix the issue.
>
> I'm able t
ing mailing list to clarify:
> 1. Are short IORING_OP_READV reads possible on files/block devices?
> 2. Are short IORING_OP_WRITEV writes possible on files/block devices?
In general we try very hard to avoid them, but if eg we get a short read
or write from blocking context (eg io-wq), then io_uring does return
that. There's really not much we can do here, it seems futile to retry
IO which was issued just like it would've been from a normal blocking
syscall yet it is still short.
--
Jens Axboe
45 matches
Mail list logo
