Re: KVM Block Device Driver

["Spensky, Chad - 0559 - MITLL" <chad.spensky@ll.mit.edu>]

[-- Attachment #1: Type: text/plain, Size: 2811 bytes --]

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@cs.cmu.edu> 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@cs.cmu.edu>
>wrote:
>> On Wed, Aug 14, 2013 at 10:43 AM, Spensky, Chad - 0559 - MITLL
>> <chad.spensky@ll.mit.edu> 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 #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5142 bytes --]