[MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[Ian Campbell]

This was the rescheduled 8 July call, on the topic of PVH and related work

= Attendees =

 * Ian Campbell
 * David Vrabel
 * Stefano Stabellini
 * Boris Ostrovsky
 * Elena Ufimtseva
 * Wei Liu
 * George Dunlap
 * Konrad Rzeszutek Wilk
 * Jan Beulich
 * Daniel Kiper
 * Andrew Cooper 
 * Roger Pau Monne

Apologies:

 * Ian Jackson

= Current Status =

Note on naming: Eventually we will end up with a thing called PVH. At
the moment there are two options for who we get there. For the
purposes of this discussion we need to distinguish the two
approaches. So we call them "PVH classic" (the approach following the
path start by Mukesh) and "no-dm" (the approach which Roger has
proposed patches for).

== PVH (classic) ==

Boris: Most important lack is 32-bit, AMD and migration support. To
get the code to support the first two features doesn't require major
additional code but doesn't get us where we wanted to go.

George: Does it work with shadow? Answer: No.

Andy: Also doesn't work with AMD.

Andy: What is wrong with migration?
Boris: It may be a trivial fix but it doesn't work in practice
Andy: Thought Roger had fixed
Roger: Fixed migration using PVH dom0, but not of a PVH guest.

Stefano: Also missing PCI passthrough

Jan: MMIO handling for dom0 is a problem with the current code,
e.g. MSI related issues.

Boris: 32-bit patches only support domU
Roger: Not sure of the point of 32-bit dom0 PVH

Someone/several: Should be no restriction on the mode of a PVH guest.

== PVH (no-dm/HVMlite) ==

Roger:

Picked up libxc and noticed that the PV vs HVM builders are very
different and the HVM one is not very good. Currently patches move the
builder for HVM to use the same code as the PV builder code. Not too
complicated, lots of hooks in place already. Adds another type of
guest with e.g. different hooks for populating memory, special pages.

Has been able to unify the way we build the two guest types, to the
point of one function in libxl being the decision point.

Can now choose a container type and then load whatever kernel,
hvmload, PV kernel, pv grub etc etc.

Remaining work is to disable emulated devices in Xen.

Start a no-dm guest as an HVM guest, 32-bit flat, same as with HVM
today with the entry point.

= Ongoing work =

(we sort of drifted into this)

Needs a kernel with a suitable 32-bit flat entry point, which may be
Xen specific or may be possible to share with native (depends on the
guest). Other than entry point doesn't need much other than PVH.

Konrad: Another entry point without page tables might be an issue in
terms of upstreaming to Linux. Going from the Xen entry point to the
Linux generic entry point is similar to the x86/PV.

Roger: The physical entry point should use a different ELF note, could
also check for 32 vs 64 but would prefer not to, i.e. would prefer to
have the guest take care of the mode starting from a common mode.

Konrad: The issue is that it expects a bootloader stub (internal to
Linux).

David: Can we use EFI firmware (replacing hvmloader) which provides a
known entry protocol etc and boots using the UEFI interfaces.

George: Need to think about microkernels too

David: EFI just for Linux, but microkernels do not have to use it.

Roger: dom0 is a problem for UEFI

David: Just use it as another multiboot module

Jan: Using OVMF/EFI as the basis, is: Is OVMF Xen aware.

Andy: it is aware of PV drivers

Jan: But not using all of the PV infra is the bigger part.

David: PV entry point is a non-starter. If the entry point for no-dm
is not the native entry point then it is not viable and won't be
accepted. Maybe not the full UEFI firmware, but some sort of firmware.

Ian: Do we mean the 32- or 16-bit real entry point?

David: Needs to see a more concrete proposal. It is fine to have a
stub to build a set of 64-bit page tables and enter at the 64-bit
entry point.

Konrad: Would need per OS stubs.

David: Doesn't see a problem with that.

Konrad: This path wouldn't enable the pvops hooks

David: Those hooks already exists.

Roger: But where can you set those hooks?

Konrad: Much later. What happens between early boot up stage and when
we can set those hooks.

David: Something which needs to get looked at.

Andy: Could move the native entry points per-hypervisor checks
earlier.

Konrad: This means working with the x86 maintainers.

David: Doesn't see any issue with that.

Andy: Also benefits other hypervisors not just us.

Summary:

  - Want boot up path to be as no-dm (flat 32-bit, no paging), with
    different per-OS stubs depending on the OS, which setup whatever
    is needed for the given OS.

Roger: Where does the stub live, in Xen or in guest OS?

David: Stub could live in the guest OS. Self contained, independent of
other x86 code. Just needs to go from Xen entry point to the native
entry point.

Roger: Needs to be bundled with Linux

Stefano: Similar model to the EFI stub.

Ian: Need some way to find the Xen entry point.

Konrad: Who is going to write that code.

Boris: Was planning to do for Linux as Roger did for BSD.

Roger: Was ~200 lines of code for BSD.

Konrad: Need to setup Linux bootparams code.

David: Bigger concern is the early stuff which assumes ACPI tables and
so on in the native path. A certain amount of chasing these cases down
and removing assumptions.

Konrad: Bring up of secondary processors, how do to.

Roger: It has to use the PV interface

Andy: Should just expose that to HVM guests.

Roger: Baremetal way requires a local APIC, so PV is the only way.

Andy: Eventually want to expose a local APIC to PVH guests when
Post-Interrupts are available. To start with lets disable, but
eventually may want to allow emulated local APIC.

Ian: As we do on ARM. But lets leave this for a future discussion.

= Next steps =

General agreement to go to the no-dm approach to PVH.

Boris: What about the short term?

David: Lets not worry short term and stop working on PVH classic. Lets
focus on doing it right.

Konrad: PVH classic useful for e.g. testing

George: No point testing PVH classic on AMD and then doing it again on
no-dm. Just do it once.

Konrad: So should stop work on AMD support, but keep going with
secondary processor setup (which is the same in both approaches).

David: The initial list of features are things which (hopefully) just
work if you use no-dm.

Konrad: PCI passthrough is the exception

Andy: PCI passthrough (and dom0) can be exluded from the initial set.

Summary: Will go with the no-dm approach, stopping work on anything in
classic which cannot be reused for no-dm.

Boris: Would prefer to see 32-bit stuff go in as it is a very small
amount of code, bit of not would continue with no-dm.

Jan: It could in principal subject to the freeze. Post freeze does it
make sense to commit something which we are committed to replacing?
Worst case need to remove a little bit extra, not a big deal.

David: Similarly for the Linux side.

Andy: Roger, do you think it is reasonable to plan for ~January to
have: plain domU no-dm style work, no frills, no passthrough, no
dom0. With a stable interface.

Roger: The series seems in good shape, but hasn't had lots of comments
due to the freeze. Is a good cleanup in any case, the rest shouldn't
be that intrusive and is mostly cleanup of things we already
have. Very likely to make 4.7. Was hoping to even do dom0.

David: To declare the ABI stable need 2 guests to use it. i.e. add
Linux to the existing BSD.

Roger: ABI is as HVM today plus some hypercalls one for memory map and
three to do secondary CPU setup, all that is needed for simple no-dm
approach. More needed for passthrough.

Boris and Roger will do most of this, Boris is planning to do the
Linux entry point.

Re: [MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[Ian Campbell]

On Wed, 2015-07-22 at 18:07 +0100, Ian Campbell wrote:
> This was the rescheduled 8 July call, on the topic of PVH and related 
> work

CCing people who were on the call this time.

Perhaps a summary of what we discussed/agreed (AIUI) would be easier to
(dis)agree with than the raw minutes:

      * Going forward we will switch to using the hvmlite/no-dm
        approach to PV, rather than the existing "classic PVH"
        approach.
      * Any work which is specific to classic PVH may as well stop, but
        anything which is common to both approaches could continue
              * Boris' classic-PVH 32-bit domU support is basically
                ready and there were no strong objections to putting it
                in (after the 4.6 freeze, of course).
      * The entry point shall be a flat 32-bit, paging disabled, entry
        point (same as hvmloader today)
              * Discovery of the Xen entrypoint will be via an ELF note
              * For Linux:
                      * The Xen entrypoint shall point to a "stub" in
                        the same vein of the UEFI stub.
                      * The stub will set up a basic initial set of
                        page tables, fills in bootinfo and then jump to
                        the native 32- or 64-bit entry point as
                        appropriate. 
                      * The stub can/should live in linux.git
                        (presumably arch/x86/xen) but should be self
                        -contained and isolated from the main body of
                        Linux code. It does setup to impedance match
                        the Xen entry point to the Linux native entry
                        point.
                      * Other things (e.g. lack of ACPI) should be
                        addressed by fixing the native Linux entry path
                        to be able to cope without them. Likewise
                        installing PV hooks may need hypervisor
                        detection to be moved earlier in the native
                        boot path.
              * For BSD:
                      * I suppose Roger is on the case wrt agreeing
                        things with the BSD maintainers. I think model
                        is not dissimilar to that described for Linux.
      * In Xen device models will be made optional and disabled.
      * Secondary CPU bring up will be done using the PV paths
      * Priority is to declare a stable API for basic domU use
        excluding dom0, PCI passthrough and migration in the short
        term. We are aiming to have this by ~January.

Boris and Roger will be the primary people working on this. Roger will
be looking at the no-dm loader side and then disabling Xen device
models, Boris will be looking at the Linux stub aspect.

There was talk about other things (e.g. VLAPIC using h/w support, UEFI
firmware) but those are future considerations.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[Roger Pau Monné]

El 23/07/15 a les 11.08, Ian Campbell ha escrit:
> On Wed, 2015-07-22 at 18:07 +0100, Ian Campbell wrote:
>> This was the rescheduled 8 July call, on the topic of PVH and related 
>> work
> 
> CCing people who were on the call this time.
> 
> Perhaps a summary of what we discussed/agreed (AIUI) would be easier to
> (dis)agree with than the raw minutes:

Thanks, this is a really good summary/plan of action IMHO.

>       * Going forward we will switch to using the hvmlite/no-dm
>         approach to PV, rather than the existing "classic PVH"
>         approach.
>       * Any work which is specific to classic PVH may as well stop, but
>         anything which is common to both approaches could continue
>               * Boris' classic-PVH 32-bit domU support is basically
>                 ready and there were no strong objections to putting it
>                 in (after the 4.6 freeze, of course).
>       * The entry point shall be a flat 32-bit, paging disabled, entry
>         point (same as hvmloader today)
>               * Discovery of the Xen entrypoint will be via an ELF note
>               * For Linux:
>                       * The Xen entrypoint shall point to a "stub" in
>                         the same vein of the UEFI stub.
>                       * The stub will set up a basic initial set of
>                         page tables, fills in bootinfo and then jump to
>                         the native 32- or 64-bit entry point as
>                         appropriate. 
>                       * The stub can/should live in linux.git
>                         (presumably arch/x86/xen) but should be self
>                         -contained and isolated from the main body of
>                         Linux code. It does setup to impedance match
>                         the Xen entry point to the Linux native entry
>                         point.
>                       * Other things (e.g. lack of ACPI) should be
>                         addressed by fixing the native Linux entry path
>                         to be able to cope without them. Likewise
>                         installing PV hooks may need hypervisor
>                         detection to be moved earlier in the native
>                         boot path.
>               * For BSD:
>                       * I suppose Roger is on the case wrt agreeing
>                         things with the BSD maintainers. I think model
>                         is not dissimilar to that described for Linux.

Just FYI, this is what I had planned for FreeBSD:

 - Entry point is a code32 section that setups page tables and jumps
into long mode. The page tables setup by the asm stub are exactly the
same as the ones that are created by the native FreeBSD loader (the low
1GiB of physical memory is mapped using 2MiB pages).
 - The asm stub calls into a Xen specific function that setups all the
necessary PV hooks, then the native FreeBSD early boot function is called.

>       * In Xen device models will be made optional and disabled.
>       * Secondary CPU bring up will be done using the PV paths
>       * Priority is to declare a stable API for basic domU use
>         excluding dom0, PCI passthrough and migration in the short
>         term. We are aiming to have this by ~January.
> 
> Boris and Roger will be the primary people working on this. Roger will
> be looking at the no-dm loader side and then disabling Xen device
> models, Boris will be looking at the Linux stub aspect.

I will also update the design document about the boot protocol, and
possibly merge it into the PVH specification that's already committed to
Xen.

Roger.

Re: [MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[Andrew Cooper]

On 23/07/15 10:08, Ian Campbell wrote:
> On Wed, 2015-07-22 at 18:07 +0100, Ian Campbell wrote:
>> This was the rescheduled 8 July call, on the topic of PVH and related 
>> work
> CCing people who were on the call this time.
>
> Perhaps a summary of what we discussed/agreed (AIUI) would be easier to
> (dis)agree with than the raw minutes:
>
>       * Going forward we will switch to using the hvmlite/no-dm
>         approach to PV, rather than the existing "classic PVH"
>         approach.
>       * Any work which is specific to classic PVH may as well stop, but
>         anything which is common to both approaches could continue
>               * Boris' classic-PVH 32-bit domU support is basically
>                 ready and there were no strong objections to putting it
>                 in (after the 4.6 freeze, of course).
>       * The entry point shall be a flat 32-bit, paging disabled, entry
>         point (same as hvmloader today)
>               * Discovery of the Xen entrypoint will be via an ELF note
>               * For Linux:
>                       * The Xen entrypoint shall point to a "stub" in
>                         the same vein of the UEFI stub.
>                       * The stub will set up a basic initial set of
>                         page tables, fills in bootinfo and then jump to
>                         the native 32- or 64-bit entry point as
>                         appropriate. 
>                       * The stub can/should live in linux.git
>                         (presumably arch/x86/xen) but should be self
>                         -contained and isolated from the main body of
>                         Linux code. It does setup to impedance match
>                         the Xen entry point to the Linux native entry
>                         point.
>                       * Other things (e.g. lack of ACPI) should be
>                         addressed by fixing the native Linux entry path
>                         to be able to cope without them. Likewise
>                         installing PV hooks may need hypervisor
>                         detection to be moved earlier in the native
>                         boot path.
>               * For BSD:
>                       * I suppose Roger is on the case wrt agreeing
>                         things with the BSD maintainers. I think model
>                         is not dissimilar to that described for Linux.
>       * In Xen device models will be made optional and disabled.
>       * Secondary CPU bring up will be done using the PV paths
>       * Priority is to declare a stable API for basic domU use
>         excluding dom0, PCI passthrough and migration in the short
>         term. We are aiming to have this by ~January.

I would not exclude migration from the basic domU use.  Migration is a
key feature of virtualisation, and being HVM-lite, means that the
existing HVM migration path should JustWork.

~Andrew

Re: [MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[Ian Campbell]

On Thu, 2015-07-23 at 10:35 +0100, Andrew Cooper wrote:
> On 23/07/15 10:08, Ian Campbell wrote:
> > On Wed, 2015-07-22 at 18:07 +0100, Ian Campbell wrote:
> > > This was the rescheduled 8 July call, on the topic of PVH and 
> > > related 
> > > work
> > CCing people who were on the call this time.
> > 
> > Perhaps a summary of what we discussed/agreed (AIUI) would be 
> > easier to
> > (dis)agree with than the raw minutes:
> > 
> >       * Going forward we will switch to using the hvmlite/no-dm
> >         approach to PV, rather than the existing "classic PVH"
> >         approach.
> >       * Any work which is specific to classic PVH may as well stop, 
> > but
> >         anything which is common to both approaches could continue
> >               * Boris' classic-PVH 32-bit domU support is basically
> >                 ready and there were no strong objections to 
> > putting it
> >                 in (after the 4.6 freeze, of course).
> >       * The entry point shall be a flat 32-bit, paging disabled, 
> > entry
> >         point (same as hvmloader today)
> >               * Discovery of the Xen entrypoint will be via an ELF 
> > note
> >               * For Linux:
> >                       * The Xen entrypoint shall point to a "stub" 
> > in
> >                         the same vein of the UEFI stub.
> >                       * The stub will set up a basic initial set of
> >                         page tables, fills in bootinfo and then 
> > jump to
> >                         the native 32- or 64-bit entry point as
> >                         appropriate. 
> >                       * The stub can/should live in linux.git
> >                         (presumably arch/x86/xen) but should be 
> > self
> >                         -contained and isolated from the main body 
> > of
> >                         Linux code. It does setup to impedance 
> > match
> >                         the Xen entry point to the Linux native 
> > entry
> >                         point.
> >                       * Other things (e.g. lack of ACPI) should be
> >                         addressed by fixing the native Linux entry 
> > path
> >                         to be able to cope without them. Likewise
> >                         installing PV hooks may need hypervisor
> >                         detection to be moved earlier in the native
> >                         boot path.
> >               * For BSD:
> >                       * I suppose Roger is on the case wrt agreeing
> >                         things with the BSD maintainers. I think 
> > model
> >                         is not dissimilar to that described for 
> > Linux.
> >       * In Xen device models will be made optional and disabled.
> >       * Secondary CPU bring up will be done using the PV paths
> >       * Priority is to declare a stable API for basic domU use
> >         excluding dom0, PCI passthrough and migration in the short
> >         term. We are aiming to have this by ~January.
> 
> I would not exclude migration from the basic domU use.  Migration is a
> key feature of virtualisation, and being HVM-lite, means that the
> existing HVM migration path should JustWork.

OK.

Re: [MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[Konrad Rzeszutek Wilk]

On July 23, 2015 5:08:46 AM EDT, Ian Campbell <ian.campbell@citrix.com> wrote:
>On Wed, 2015-07-22 at 18:07 +0100, Ian Campbell wrote:
>> This was the rescheduled 8 July call, on the topic of PVH and related
>
>> work
>
>CCing people who were on the call this time.
>
>Perhaps a summary of what we discussed/agreed (AIUI) would be easier to
>(dis)agree with than the raw minutes:
>
>      * Going forward we will switch to using the hvmlite/no-dm
>        approach to PV, rather than the existing "classic PVH"
>        approach.
>      * Any work which is specific to classic PVH may as well stop, but
>        anything which is common to both approaches could continue
>              * Boris' classic-PVH 32-bit domU support is basically
>                ready and there were no strong objections to putting it
>                in (after the 4.6 freeze, of course).
>      * The entry point shall be a flat 32-bit, paging disabled, entry
>        point (same as hvmloader today)
>              * Discovery of the Xen entrypoint will be via an ELF note
>              * For Linux:
>                      * The Xen entrypoint shall point to a "stub" in
>                        the same vein of the UEFI stub.
>                      * The stub will set up a basic initial set of
>                        page tables, fills in bootinfo and then jump to
>                        the native 32- or 64-bit entry point as
>                        appropriate. 
>                      * The stub can/should live in linux.git
>                        (presumably arch/x86/xen) but should be self
>                        -contained and isolated from the main body of
>                        Linux code. It does setup to impedance match
>                        the Xen entry point to the Linux native entry
>                        point.
>                      * Other things (e.g. lack of ACPI) should be
>                        addressed by fixing the native Linux entry path
>                        to be able to cope without them. Likewise
>                        installing PV hooks may need hypervisor
>                        detection to be moved earlier in the native
>                        boot path.
>              * For BSD:
>                      * I suppose Roger is on the case wrt agreeing
>                        things with the BSD maintainers. I think model
>                        is not dissimilar to that described for Linux.
>      * In Xen device models will be made optional and disabled.
>      * Secondary CPU bring up will be done using the PV paths
>      * Priority is to declare a stable API for basic domU use
>        excluding dom0, PCI passthrough and migration in the short
>        term. We are aiming to have this by ~January.
>
>Boris and Roger will be the primary people working on this. Roger will
>be looking at the no-dm loader side and then disabling Xen device
>models, Boris will be looking at the Linux stub aspect.
>
>There was talk about other things (e.g. VLAPIC using h/w support, UEFI
>firmware) but those are future considerations.

We forgot to speak about dom0. This work outlined will lay out how to do it - but the pieces for dom0 are not implemented and would need work (which actually may be following most of the is_pvh in the hypervisor).

>
>Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[Roger Pau Monné]

El 23/07/15 a les 12.59, Konrad Rzeszutek Wilk ha escrit:
[...]
> We forgot to speak about dom0. This work outlined will lay out how to do it - but the pieces for dom0 are not implemented and would need work (which actually may be following most of the is_pvh in the hypervisor).

Let's do that once we have DomU nailed down and the guest ABI marked as
stable.

Some work will indeed be needed for Dom0, for example I would like to
avoid using the current Dom0 builder (construct_dom0, that is suited for
PV, but all the PVH hacks just make it almost impossible to understand)
and start from scratch with a more sane approach.

Roger.

Re: [MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[Andrew Cooper]

On 23/07/15 12:17, Roger Pau Monné wrote:
> El 23/07/15 a les 12.59, Konrad Rzeszutek Wilk ha escrit:
> [...]
>> We forgot to speak about dom0. This work outlined will lay out how to do it - but the pieces for dom0 are not implemented and would need work (which actually may be following most of the is_pvh in the hypervisor).
> Let's do that once we have DomU nailed down and the guest ABI marked as
> stable.
>
> Some work will indeed be needed for Dom0, for example I would like to
> avoid using the current Dom0 builder (construct_dom0, that is suited for
> PV, but all the PVH hacks just make it almost impossible to understand)
> and start from scratch with a more sane approach.

+1 on both points.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[Ian Campbell]

On Thu, 2015-07-23 at 13:17 +0200, Roger Pau Monné wrote:
> El 23/07/15 a les 12.59, Konrad Rzeszutek Wilk ha escrit:
> [...]
> > We forgot to speak about dom0. This work outlined will lay out how 
> > to do it - but the pieces for dom0 are not implemented and would 
> > need work (which actually may be following most of the is_pvh in 
> > the hypervisor).
> 
> Let's do that once we have DomU nailed down and the guest ABI marked 
> as stable.

IIRC someone on the call pointed out that one large piece of the Dom0
work would be very similar to the PCI passthrough work, so it makes
sense to defer them together.

> 
> Some work will indeed be needed for Dom0, for example I would like to
> avoid using the current Dom0 builder (construct_dom0, that is suited for
> PV, but all the PVH hacks just make it almost impossible to understand)
> and start from scratch with a more sane approach.
> 
> Roger.
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: [MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[David Vrabel]

On 23/07/15 10:08, Ian Campbell wrote:
> 
>               * For Linux:
>                       * The Xen entrypoint shall point to a "stub" in
>                         the same vein of the UEFI stub.
>                       * The stub will set up a basic initial set of
>                         page tables, fills in bootinfo and then jump to
>                         the native 32- or 64-bit entry point as
>                         appropriate. 
>                       * The stub can/should live in linux.git
>                         (presumably arch/x86/xen) but should be self
>                         -contained and isolated from the main body of
>                         Linux code. It does setup to impedance match
>                         the Xen entry point to the Linux native entry
>                         point.
>                       * Other things (e.g. lack of ACPI) should be
>                         addressed by fixing the native Linux entry path
>                         to be able to cope without them. Likewise
>                         installing PV hooks may need hypervisor
>                         detection to be moved earlier in the native
>                         boot path.

Agreed.

The goal here is to use as much of the native code paths as possible to
reduce the chance of Xen support being broken by x86 changes.

David

Re: [MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[Konrad Rzeszutek Wilk]

On Thu, Jul 23, 2015 at 01:17:45PM +0200, Roger Pau Monné wrote:
> El 23/07/15 a les 12.59, Konrad Rzeszutek Wilk ha escrit:
> [...]
> > We forgot to speak about dom0. This work outlined will lay out how to do it - but the pieces for dom0 are not implemented and would need work (which actually may be following most of the is_pvh in the hypervisor).
> 
> Let's do that once we have DomU nailed down and the guest ABI marked as
> stable.
> 
> Some work will indeed be needed for Dom0, for example I would like to
> avoid using the current Dom0 builder (construct_dom0, that is suited for
> PV, but all the PVH hacks just make it almost impossible to understand)
> and start from scratch with a more sane approach.

Well construct_dom0 is huge already. Doing surgery on that beast
would be most welcome.

The other issues that I think we will still encounter - which Elena
was looking for AMD - is the handling of decoding of operations
on AMD without qemu-dm involvment. Which meant that we could not
use any of the mmio_handlers - that I believe will still be an
outstanding issue.

So will the setting of various states that the toolstack does right now
but had never been done in the hypervisor - such as the tsc_scaling
for AMD.

Lastly the E820 setup and poking/re-organizing the P2M to match it.

> 
> Roger.
> 

Re: [MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[Konrad Rzeszutek Wilk]

On Thu, Jul 23, 2015 at 12:26:20PM +0100, Ian Campbell wrote:
> On Thu, 2015-07-23 at 13:17 +0200, Roger Pau Monné wrote:
> > El 23/07/15 a les 12.59, Konrad Rzeszutek Wilk ha escrit:
> > [...]
> > > We forgot to speak about dom0. This work outlined will lay out how 
> > > to do it - but the pieces for dom0 are not implemented and would 
> > > need work (which actually may be following most of the is_pvh in 
> > > the hypervisor).
> > 
> > Let's do that once we have DomU nailed down and the guest ABI marked 
> > as stable.
> 
> IIRC someone on the call pointed out that one large piece of the Dom0
> work would be very similar to the PCI passthrough work, so it makes
> sense to defer them together.
> 

I don't recall that?
 
I think that the aim in January would be for domU. I don't know if dom0
work could also be done in that time-frame.
> > 
> > Some work will indeed be needed for Dom0, for example I would like to
> > avoid using the current Dom0 builder (construct_dom0, that is suited for
> > PV, but all the PVH hacks just make it almost impossible to understand)
> > and start from scratch with a more sane approach.
> > 
> > Roger.
> > 

Re: [MINUTES] Monthly Xen.org Technical Call (2015-07-22)

[Ian Campbell]

On Thu, 2015-07-23 at 13:44 -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Jul 23, 2015 at 12:26:20PM +0100, Ian Campbell wrote:
> > On Thu, 2015-07-23 at 13:17 +0200, Roger Pau Monné wrote:
> > > El 23/07/15 a les 12.59, Konrad Rzeszutek Wilk ha escrit:
> > > [...]
> > > > We forgot to speak about dom0. This work outlined will lay out 
> > > > how 
> > > > to do it - but the pieces for dom0 are not implemented and 
> > > > would 
> > > > need work (which actually may be following most of the is_pvh 
> > > > in 
> > > > the hypervisor).
> > > 
> > > Let's do that once we have DomU nailed down and the guest ABI 
> > > marked 
> > > as stable.
> > 
> > IIRC someone on the call pointed out that one large piece of the 
> > Dom0
> > work would be very similar to the PCI passthrough work, so it makes
> > sense to defer them together.
> > 
> 
> I don't recall that?

Maybe I misheard/misremembered.

> I think that the aim in January would be for domU.

Right, that's what I said in my summary.

>  I don't know if dom0
> work could also be done in that time-frame.

If it happens it happens I guess, but the goal stated was just to get
to a stable domU API by then.

> > > 
> > > Some work will indeed be needed for Dom0, for example I would 
> > > like to
> > > avoid using the current Dom0 builder (construct_dom0, that is 
> > > suited for
> > > PV, but all the PVH hacks just make it almost impossible to 
> > > understand)
> > > and start from scratch with a more sane approach.
> > > 
> > > Roger.
> > > 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel