Re: KVM Block Device Driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Wolfgang,

  Thanks so much for the response.  It turns out that wasn't handling the
QEMUIOVector properly.  When I first implemented it, I saw that the iovec
was a pointer and assumed that there would only ever be one.  Given the
lack of documentation and my lack of understanding this went undetected
for a while.  everything now seems to work just fine.  :-)  See below for
the portion of code that threw me off.  Thanks again!

 - Chad


Proposed change to qemu-common.h (:

typedef struct QEMUIOVector {
    struct iovec *iov;
    int niov;
    int nalloc;
    size_t size;
} QEMUIOVector;

changed to:

// Array of I/O vectors

typedef struct QEMUIOVector {
struct iovec iov[];
int niov;
int nalloc;
size_t size;
} QEMUIOVector;





-- 
Chad S. Spensky

MIT Lincoln Laboratory
Group 59 (Cyber Systems Assessment)
Ph: (781) 981-4173





On 8/14/13 11:49 AM, "Wolfgang Richter" <wolf@xxxxxxxxxx> wrote:

>Read through the kvm thread (I'm not on that mailing just just for
>reference; thanks for the CC).
>
>I saw you're hooking a different function than me (not sure it
>matters).  I hook bdrv_co_writev and I operate on the passed in
>iovector datastructure there writing out its contents and a short
>header to stderr where my introspection tools interpret it.  I don't
>maintain a full shadow copy of the disk, but it conceptually shouldn't
>matter.
>
>Are you working on the iovec data structure as well?  Also, is your
>disk format raw?  I don't think it should matter, but I was just
>wondering.
>
>--
>Wolf
>
>On Wed, Aug 14, 2013 at 11:02 AM, Wolfgang Richter <wolf@xxxxxxxxxx>
>wrote:
>> On Wed, Aug 14, 2013 at 10:43 AM, Spensky, Chad - 0559 - MITLL
>> <chad.spensky@xxxxxxxxxx> wrote:
>>> Wolf,
>>>
>>>   We're able to get all of the meta data just fine.
>>
>> I assume by meta-data you mean (essentially) "function" call
>> parameters within QEMU as to the (1) location of the write on disk,
>> and (2) the amount of data being written out (in bytes).
>>
>>> However it seems that
>>> the actual content of the read/write seems to be wrong some of the
>>>time.
>>
>> That's very odd, I'm pretty sure I never had that bug (although I
>> might silently have it!).
>>
>> I did occasionally observe a kernel accidentally writing out kernel
>> buffers that hadn't been cleared to disk (guest kernel) :-)
>>
>>> The first 2 sectors seem to always be correct, however on some writes,
>>>the
>>> data that we traced does not match up with the data we are actually
>>>seeing
>>> in the .img file for the guest on disk.
>>
>> Are you certain you're getting every write?  Sometimes things might be
>> written to rapidly in succession?
>>
>> How are you obtaining the shadow copy of the write stream (maybe there
>> was earlier stuff in this thread I should read up on)?
>>
>> --
>> Wolf
>
>
>
>-- 
>Wolf

Attachment: smime.p7s
Description: S/MIME cryptographic signature


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux