On Fri, Aug 24, 2018 at 03:29:24PM +0200, Michal Privoznik wrote:
> On 08/24/2018 02:53 PM, Daniel P. Berrangé wrote:
>
> >
> > That sounds reasonable, so we don't need the _WAIT behaviour in
> > virtlockd itself, as everything will wait in the secdriver instead.
> > At least for now, until we mo
On 08/24/2018 02:53 PM, Daniel P. Berrangé wrote:
>
> That sounds reasonable, so we don't need the _WAIT behaviour in
> virtlockd itself, as everything will wait in the secdriver instead.
> At least for now, until we modularize the startup process with the
> shim. Guess that's just one more todo
On Fri, Aug 24, 2018 at 02:01:52PM +0200, Michal Privoznik wrote:
> On 08/23/2018 06:14 PM, Michal Privoznik wrote:
> > On 08/23/2018 05:51 PM, Daniel P. Berrangé wrote:
> >> On Thu, Aug 23, 2018 at 05:45:42PM +0200, Michal Privoznik wrote:
> >>> On 08/23/2018 05:01 PM, Daniel P. Berrangé wrote:
>
On 08/23/2018 06:14 PM, Michal Privoznik wrote:
> On 08/23/2018 05:51 PM, Daniel P. Berrangé wrote:
>> On Thu, Aug 23, 2018 at 05:45:42PM +0200, Michal Privoznik wrote:
>>> On 08/23/2018 05:01 PM, Daniel P. Berrangé wrote:
On Thu, Aug 23, 2018 at 04:54:01PM +0200, Michal Privoznik wrote:
>
On 08/23/2018 05:51 PM, Daniel P. Berrangé wrote:
> On Thu, Aug 23, 2018 at 05:45:42PM +0200, Michal Privoznik wrote:
>> On 08/23/2018 05:01 PM, Daniel P. Berrangé wrote:
>>> On Thu, Aug 23, 2018 at 04:54:01PM +0200, Michal Privoznik wrote:
On 08/20/2018 07:17 PM, Michal Prívozník wrote:
>
On Thu, Aug 23, 2018 at 05:45:42PM +0200, Michal Privoznik wrote:
> On 08/23/2018 05:01 PM, Daniel P. Berrangé wrote:
> > On Thu, Aug 23, 2018 at 04:54:01PM +0200, Michal Privoznik wrote:
> >> On 08/20/2018 07:17 PM, Michal Prívozník wrote:
> >>> On 08/20/2018 05:16 PM, Daniel P. Berrangé wrote:
>
On 08/23/2018 05:01 PM, Daniel P. Berrangé wrote:
> On Thu, Aug 23, 2018 at 04:54:01PM +0200, Michal Privoznik wrote:
>> On 08/20/2018 07:17 PM, Michal Prívozník wrote:
>>> On 08/20/2018 05:16 PM, Daniel P. Berrangé wrote:
On Tue, Aug 14, 2018 at 01:19:43PM +0200, Michal Privoznik wrote:
>
On Thu, Aug 23, 2018 at 04:54:01PM +0200, Michal Privoznik wrote:
> On 08/20/2018 07:17 PM, Michal Prívozník wrote:
> > On 08/20/2018 05:16 PM, Daniel P. Berrangé wrote:
> >> On Tue, Aug 14, 2018 at 01:19:43PM +0200, Michal Privoznik wrote:
> >>> Fortunately, we have qemu wrappers so it's sufficien
On 08/20/2018 07:17 PM, Michal Prívozník wrote:
> On 08/20/2018 05:16 PM, Daniel P. Berrangé wrote:
>> On Tue, Aug 14, 2018 at 01:19:43PM +0200, Michal Privoznik wrote:
>>> Fortunately, we have qemu wrappers so it's sufficient to put
>>> lock/unlock call only there.
>>>
>>> Signed-off-by: Michal Pr
On 08/20/2018 05:16 PM, Daniel P. Berrangé wrote:
> On Tue, Aug 14, 2018 at 01:19:43PM +0200, Michal Privoznik wrote:
>> Fortunately, we have qemu wrappers so it's sufficient to put
>> lock/unlock call only there.
>>
>> Signed-off-by: Michal Privoznik
>> ---
>> src/qemu/qemu_security.c | 107
>>
On Tue, Aug 14, 2018 at 01:19:43PM +0200, Michal Privoznik wrote:
> Fortunately, we have qemu wrappers so it's sufficient to put
> lock/unlock call only there.
>
> Signed-off-by: Michal Privoznik
> ---
> src/qemu/qemu_security.c | 107
> +++
> 1 file
On 08/17/2018 08:38 PM, John Ferlan wrote:
>
>
> On 08/14/2018 07:19 AM, Michal Privoznik wrote:
>> Fortunately, we have qemu wrappers so it's sufficient to put
>> lock/unlock call only there.
>>
>
> Kind of sparse... Maybe a few words related to what benefit locking the
> metadata provides. The
On 08/14/2018 07:19 AM, Michal Privoznik wrote:
> Fortunately, we have qemu wrappers so it's sufficient to put
> lock/unlock call only there.
>
Kind of sparse... Maybe a few words related to what benefit locking the
metadata provides. There is a danger in all this too if the unlock does
fail s
Fortunately, we have qemu wrappers so it's sufficient to put
lock/unlock call only there.
Signed-off-by: Michal Privoznik
---
src/qemu/qemu_security.c | 107 +++
1 file changed, 107 insertions(+)
diff --git a/src/qemu/qemu_security.c b/src/qemu/qemu_s
14 matches
Mail list logo
