On Mon, Feb 9, 2015 at 7:08 AM, Anthony PERARD
wrote:
> On Mon, Feb 09, 2015 at 09:07:13AM +, Ian Campbell wrote:
>> On Fri, 2015-02-06 at 17:23 +, Stefano Stabellini wrote:
>> > >
>> > > One of the main issues outstanding from when Anthony originally posted
>> > > his patches is how we wa
On Mon, Feb 09, 2015 at 09:07:13AM +, Ian Campbell wrote:
> On Fri, 2015-02-06 at 17:23 +, Stefano Stabellini wrote:
> > >
> > > One of the main issues outstanding from when Anthony originally posted
> > > his patches is how we want to go about building this? I honestly do
> > > not know
On Mon, 9 Feb 2015, Ian Campbell wrote:
> On Fri, 2015-02-06 at 17:23 +, Stefano Stabellini wrote:
> > >
> > > One of the main issues outstanding from when Anthony originally posted
> > > his patches is how we want to go about building this? I honestly do
> > > not know how well the current d
On Fri, 2015-02-06 at 17:23 +, Stefano Stabellini wrote:
> >
> > One of the main issues outstanding from when Anthony originally posted
> > his patches is how we want to go about building this? I honestly do
> > not know how well the current dracut-based approach to building the
> > root imag
On Fri, 6 Feb 2015, Eric Shelton wrote:
> On Fri, Feb 6, 2015 at 10:36 AM, Stefano Stabellini
> wrote:
> > On Fri, 6 Feb 2015, Wei Liu wrote:
>
> >> ISTR our policy is upstream first. That is, though we maintain our own
> >> qemu tree those changesets are all upstream changesets. Arguably there
>
On Fri, Feb 6, 2015 at 10:36 AM, Stefano Stabellini
wrote:
> On Fri, 6 Feb 2015, Wei Liu wrote:
>> ISTR our policy is upstream first. That is, though we maintain our own
>> qemu tree those changesets are all upstream changesets. Arguably there
>> might be some bandaid changesets that are not upst
On Fri, Feb 06, 2015 at 10:46:15AM -0500, Eric Shelton wrote:
> On Fri, Feb 6, 2015 at 9:59 AM, Wei Liu wrote:
> > On Fri, Feb 06, 2015 at 08:56:40AM -0500, Eric Shelton wrote:
> >> On Fri, Feb 6, 2015 at 6:16 AM, Wei Liu wrote:
> >>
> >> I simply used the code already present in the QEMU upstrea
On Fri, Feb 6, 2015 at 9:59 AM, Wei Liu wrote:
> On Fri, Feb 06, 2015 at 08:56:40AM -0500, Eric Shelton wrote:
>> On Fri, Feb 6, 2015 at 6:16 AM, Wei Liu wrote:
>>
>> I simply used the code already present in the QEMU upstream code,
>> which is writing to that particular ath to indicate "running.
On Fri, 6 Feb 2015, Wei Liu wrote:
> > > Unfortunately this problem can't be solved without putting in
> > > significant effort and time (involves redesign of protocol and handle
> > > all the compatibility issues). We can't say for sure when the solution
> > > is going to land.
> >
> > I noticed
On Fri, Feb 06, 2015 at 08:56:40AM -0500, Eric Shelton wrote:
> On Fri, Feb 6, 2015 at 6:16 AM, Wei Liu wrote:
> > Thanks for posting.
> >
> > ...
> >
> > FWIW we are now experiencing problem with this startup protocol (not
> > Linux stubdom specific) -- that path that libxl waiting for is wrong.
On Fri, Feb 6, 2015 at 6:16 AM, Wei Liu wrote:
> Thanks for posting.
>
> ...
>
> FWIW we are now experiencing problem with this startup protocol (not
> Linux stubdom specific) -- that path that libxl waiting for is wrong.
I simply used the code already present in the QEMU upstream code,
which is
Thanks for posting.
On Tue, Feb 03, 2015 at 11:06:15PM -0500, Eric Shelton wrote:
[...]
> @@ -1368,12 +1401,24 @@ static void stubdom_pvqemu_cb(libxl__egc *egc,
> libxl__stub_dm_spawn_state *sdss = CONTAINER_OF(multidev, *sdss,
> multidev);
> STATE_AO_GC(sdss->dm.spawn.ao);
> uint3
To ensure the QEMU instance in a stubdomain is running before we unpause
an HVM guest that relies on it for a device model, we do a xenstore wait
on QEMU's indiction that it is running.
Signed-off-by: Eric Shelton
---
tools/libxl/libxl_dm.c | 46 +-
1
13 matches
Mail list logo
