On 10/12/2010 08:16 AM, Stefan Hajnoczi wrote:
Well, the protocol is currently encoded in the file name, separated by a
colon. Of course, we want to get rid of that, but we still don't know
what we want instead. It's completely unrelated to the backing file
format, though, it's about the format
On Tue, Oct 12, 2010 at 10:07:53AM +0200, Kevin Wolf wrote:
> Am 11.10.2010 19:14, schrieb Anthony Liguori:
> > On 10/11/2010 11:18 AM, Anthony Liguori wrote:
> >> On 10/11/2010 10:46 AM, Stefan Hajnoczi wrote:
> >>> On Mon, Oct 11, 2010 at 05:39:01PM +0200, Avi Kivity wrote:
> On 10/11/2010
On 10/11/2010 06:10 PM, Anthony Liguori wrote:
On 10/11/2010 11:02 AM, Avi Kivity wrote:
On 10/11/2010 05:49 PM, Anthony Liguori wrote:
On 10/11/2010 09:58 AM, Avi Kivity wrote:
A leak is unacceptable. It means an image can grow to an
unbounded size. If you are a server provider offering
Am 11.10.2010 19:14, schrieb Anthony Liguori:
> On 10/11/2010 11:18 AM, Anthony Liguori wrote:
>> On 10/11/2010 10:46 AM, Stefan Hajnoczi wrote:
>>> On Mon, Oct 11, 2010 at 05:39:01PM +0200, Avi Kivity wrote:
On 10/11/2010 05:30 PM, Stefan Hajnoczi wrote:
>> It was discussed before, bu
On 10/11/2010 03:42 PM, Stefan Hajnoczi wrote:
>
> A leak is acceptable (it won't grow; it's just an unused, incorrect
> freelist), but data corruption is not.
The alternative is for the freelist to be a non-compat feature bit.
That means older QEMU binaries cannot use a QED image that has en
On 10/11/2010 11:18 AM, Anthony Liguori wrote:
On 10/11/2010 10:46 AM, Stefan Hajnoczi wrote:
On Mon, Oct 11, 2010 at 05:39:01PM +0200, Avi Kivity wrote:
On 10/11/2010 05:30 PM, Stefan Hajnoczi wrote:
It was discussed before, but I don't think we came to a
conclusion. Are
there any circ
On 10/11/2010 11:02 AM, Avi Kivity wrote:
On 10/11/2010 05:49 PM, Anthony Liguori wrote:
On 10/11/2010 09:58 AM, Avi Kivity wrote:
A leak is unacceptable. It means an image can grow to an unbounded
size. If you are a server provider offering multitenancy, then a
malicious guest can potentia
On 10/11/2010 04:06 PM, Stefan Hajnoczi wrote:
On Mon, Oct 11, 2010 at 03:44:38PM +0200, Avi Kivity wrote:
> On 10/11/2010 03:42 PM, Stefan Hajnoczi wrote:
> >>
> >> A leak is acceptable (it won't grow; it's just an unused, incorrect
> >> freelist), but data corruption is not.
> >
> >
Am 11.10.2010 17:30, schrieb Stefan Hajnoczi:
> On Mon, Oct 11, 2010 at 03:58:07PM +0200, Kevin Wolf wrote:
>> Am 08.10.2010 17:48, schrieb Stefan Hajnoczi:
>>> Signed-off-by: Stefan Hajnoczi
>>> ---
>>> docs/specs/qed_spec.txt | 94
>>> +++
>>> 1 fi
On 10/11/2010 10:46 AM, Stefan Hajnoczi wrote:
On Mon, Oct 11, 2010 at 05:39:01PM +0200, Avi Kivity wrote:
On 10/11/2010 05:30 PM, Stefan Hajnoczi wrote:
It was discussed before, but I don't think we came to a conclusion. Are
there any circumstances under which you don't want to
On 10/11/2010 05:41 PM, Anthony Liguori wrote:
On 10/11/2010 10:24 AM, Avi Kivity wrote:
On 10/11/2010 05:02 PM, Anthony Liguori wrote:
On 10/11/2010 08:44 AM, Avi Kivity wrote:
On 10/11/2010 03:42 PM, Stefan Hajnoczi wrote:
>
> A leak is acceptable (it won't grow; it's just an unused,
i
On 10/11/2010 10:24 AM, Avi Kivity wrote:
On 10/11/2010 05:02 PM, Anthony Liguori wrote:
On 10/11/2010 08:44 AM, Avi Kivity wrote:
On 10/11/2010 03:42 PM, Stefan Hajnoczi wrote:
>
> A leak is acceptable (it won't grow; it's just an unused, incorrect
> freelist), but data corruption is not.
On 10/11/2010 05:49 PM, Anthony Liguori wrote:
On 10/11/2010 09:58 AM, Avi Kivity wrote:
A leak is unacceptable. It means an image can grow to an unbounded
size. If you are a server provider offering multitenancy, then a
malicious guest can potentially grow the image beyond it's allotted
si
Am 08.10.2010 17:48, schrieb Stefan Hajnoczi:
> Signed-off-by: Stefan Hajnoczi
> ---
> docs/specs/qed_spec.txt | 94
> +++
> 1 files changed, 94 insertions(+), 0 deletions(-)
> create mode 100644 docs/specs/qed_spec.txt
>
> diff --git a/docs/specs/
On 10/11/2010 05:30 PM, Stefan Hajnoczi wrote:
>
> It was discussed before, but I don't think we came to a conclusion. Are
> there any circumstances under which you don't want to set the
> QED_CF_BACKING_FORMAT flag?
I suggest the following:
QED_CF_BACKING_FORMAT_RAW = 0x1
When set, the ba
On Mon, Oct 11, 2010 at 03:58:07PM +0200, Kevin Wolf wrote:
> Am 08.10.2010 17:48, schrieb Stefan Hajnoczi:
> > Signed-off-by: Stefan Hajnoczi
> > ---
> > docs/specs/qed_spec.txt | 94
> > +++
> > 1 files changed, 94 insertions(+), 0 deletions(-)
> >
On Mon, Oct 11, 2010 at 03:44:38PM +0200, Avi Kivity wrote:
> On 10/11/2010 03:42 PM, Stefan Hajnoczi wrote:
> >>
> >> A leak is acceptable (it won't grow; it's just an unused, incorrect
> >> freelist), but data corruption is not.
> >
> >The alternative is for the freelist to be a non-compat fea
On 10/11/2010 09:58 AM, Avi Kivity wrote:
A leak is unacceptable. It means an image can grow to an unbounded
size. If you are a server provider offering multitenancy, then a
malicious guest can potentially grow the image beyond it's allotted
size causing a Denial of Service attack against ano
On Mon, Oct 11, 2010 at 05:39:01PM +0200, Avi Kivity wrote:
> On 10/11/2010 05:30 PM, Stefan Hajnoczi wrote:
> >>
> >> It was discussed before, but I don't think we came to a conclusion. Are
> >> there any circumstances under which you don't want to set the
> >> QED_CF_BACKING_FORMAT flag?
> >
On 10/11/2010 08:04 AM, Avi Kivity wrote:
On 10/11/2010 12:09 PM, Stefan Hajnoczi wrote:
On Sun, Oct 10, 2010 at 11:20:09AM +0200, Avi Kivity wrote:
> On 10/08/2010 05:48 PM, Stefan Hajnoczi wrote:
> >Signed-off-by: Stefan Hajnoczi
> >---
> > docs/specs/qed_spec.txt | 94
On 10/11/2010 08:44 AM, Avi Kivity wrote:
On 10/11/2010 03:42 PM, Stefan Hajnoczi wrote:
>
> A leak is acceptable (it won't grow; it's just an unused, incorrect
> freelist), but data corruption is not.
The alternative is for the freelist to be a non-compat feature bit.
That means older QEMU
On 10/11/2010 04:54 PM, Anthony Liguori wrote:
On 10/11/2010 08:04 AM, Avi Kivity wrote:
On 10/11/2010 12:09 PM, Stefan Hajnoczi wrote:
On Sun, Oct 10, 2010 at 11:20:09AM +0200, Avi Kivity wrote:
> On 10/08/2010 05:48 PM, Stefan Hajnoczi wrote:
> >Signed-off-by: Stefan Hajnoczi
> >---
> >
On 10/11/2010 05:02 PM, Anthony Liguori wrote:
On 10/11/2010 08:44 AM, Avi Kivity wrote:
On 10/11/2010 03:42 PM, Stefan Hajnoczi wrote:
>
> A leak is acceptable (it won't grow; it's just an unused, incorrect
> freelist), but data corruption is not.
The alternative is for the freelist to be
On Mon, Oct 11, 2010 at 03:04:03PM +0200, Avi Kivity wrote:
> On 10/11/2010 12:09 PM, Stefan Hajnoczi wrote:
> >On Sun, Oct 10, 2010 at 11:20:09AM +0200, Avi Kivity wrote:
> >> On 10/08/2010 05:48 PM, Stefan Hajnoczi wrote:
> >> >Signed-off-by: Stefan Hajnoczi
> >> >---
> >> > docs/specs/qe
On 10/11/2010 12:09 PM, Stefan Hajnoczi wrote:
On Sun, Oct 10, 2010 at 11:20:09AM +0200, Avi Kivity wrote:
> On 10/08/2010 05:48 PM, Stefan Hajnoczi wrote:
> >Signed-off-by: Stefan Hajnoczi
> >---
> > docs/specs/qed_spec.txt | 94
+++
> > 1
On Sun, Oct 10, 2010 at 11:20:09AM +0200, Avi Kivity wrote:
> On 10/08/2010 05:48 PM, Stefan Hajnoczi wrote:
> >Signed-off-by: Stefan Hajnoczi
> >---
> > docs/specs/qed_spec.txt | 94
> > +++
> > 1 files changed, 94 insertions(+), 0 deletions(-)
> >
On 10/08/2010 05:48 PM, Stefan Hajnoczi wrote:
Signed-off-by: Stefan Hajnoczi
---
docs/specs/qed_spec.txt | 94 +++
1 files changed, 94 insertions(+), 0 deletions(-)
+Feature bits:
+* QED_F_BACKING_FILE = 0x01. The image uses a backing file.
+*
27 matches
Mail list logo
