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" <w...@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 <w...@cs.cmu.edu>
>wrote:
>> On Wed, Aug 14, 2013 at 10:43 AM, Spensky, Chad - 0559 - MITLL
>> <chad.spen...@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
smime.p7s
Description: S/MIME cryptographic signature
