Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
On Fri, Apr 10, 2020 at 10:20:49AM -0600, Tamas K Lengyel wrote:
> On Fri, Apr 10, 2020 at 10:19 AM Wei Liu wrote:
> >
> > On Fri, Apr 10, 2020 at 10:05:50AM -0600, Tamas K Lengyel wrote:
> > > On Thu, Apr 9, 2020 at 11:30 AM Tamas K Lengyel
> > > wrote:
> > > >
> > > > On Thu, Apr 9, 2020 at 11:11 AM Wei Liu wrote:
> > > > >
> > > > > On Thu, Apr 09, 2020 at 10:59:55AM -0600, Tamas K Lengyel wrote:
> > > > > [...]
> > > > > > >
> > > > > > > >
> > > > > > > > > >
> > > > > > > > > > +/*
> > > > > > > > > > + * The parent domain is expected to be created with
> > > > > > > > > > default settings for
> > > > > > > > > > + * - max_evtch_port
> > > > > > > > > > + * - max_grant_frames
> > > > > > > > > > + * - max_maptrack_frames
> > > > > > > > > > + */
> > > > > > > > > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid,
> > > > > > > > > > uint32_t max_vcpus, uint32_t *domid)
> > > > > > > > > > +{
> > > > > > > > > > +int rc;
> > > > > > > > > > +struct xen_domctl_createdomain create = {0};
> > > > > > > > > > +create.flags |= XEN_DOMCTL_CDF_hvm;
> > > > > > > > > > +create.flags |= XEN_DOMCTL_CDF_hap;
> > > > > > > > > > +create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > > > > > > > > +create.arch.emulation_flags = (XEN_X86_EMU_ALL &
> > > > > > > > > > ~XEN_X86_EMU_VPCI);
> > > > > > > > > > +create.ssidref = SECINITSID_DOMU;
> > > > > > > > > > +create.max_vcpus = max_vcpus;
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Some questions:
> > > > > > > > >
> > > > > > > > > Why does the caller need to specify the number of vcpus?
> > > > > > > > >
> > > > > > > > > Since the parent (source) domain is around, can you retrieve
> > > > > > > > > its domain
> > > > > > > > > configuration such that you know its max_vcpus and other
> > > > > > > > > information
> > > > > > > > > including max_evtchn_port and maptrack frames?
> > > > > > > >
> > > > > > > > Because we want to avoid having to issue an extra hypercall for
> > > > > > > > these.
> > > > > > > > Normally these pieces of information will be available for the
> > > > > > > > user
> > > > > > > > and won't change, so we save time by not querying for it every
> > > > > > > > time a
> > > > > > > > fork is created. Remember, we might be creating thousands of
> > > > > > > > forks in
> > > > > > > > a very short time, so those extra hypercalls add up.
> > > > > > >
> > > > > > > I see. Speed is a big concern to you.
> > > > > > >
> > > > > > > What I was referring to doesn't require issuing hypercalls but
> > > > > > > requires
> > > > > > > calling libxl_retrieve_domain_configuration. That's likely to be
> > > > > > > even
> > > > > > > slower than making a hypercall.
> > > > > >
> > > > > > Right. We only want to parse the domain config if the device model
> > > > > > is
> > > > > > being launched.
> > > > > >
> > > > > > >
> > > > > > > I'm afraid the current incarnation of libxl_domain_fork_vm cannot
> > > > > > > become
> > > > > > > supported (as in Xen's support statement) going forward, because
> > > > > > > it is
> > > > > > > leaky.
> > > > > >
> > > > > > What do you mean by leaky?
> > > > >
> > > > > It requires the caller to specify the number of max_vcpus. The reason
> > > > > for doing that is because you want to avoid extra hypercall(s). There
> > > > > is
> > > > > nothing that stops someone from coming along in the future claiming
> > > > > some
> > > > > other parameters are required because of the same concern you have
> > > > > today. It is an optimisation, not a must-have in terms of
> > > > > functionality.
> > > > >
> > > > > To me the number shouldn't be specified by the caller in the first
> > > > > place. It is like forking a process somehow requires you to specify
> > > > > how
> > > > > many threads it will have.
> > > >
> > > > I agree. It's not how I wanted to have the interface work but
> > > > unfortunately this was the least "ugly" of the possible solutions
> > > > given the circumstances.
> > >
> > > By the way, it would be trivial to query the parent in case max_vcpus
> > > is not provided by the user. But I would still like to keep the option
> > > available to skip that step if the number is known already. Let me
> > > know if you would like me to add that.
> >
> > I'm still waiting for Ian and Anthony to chime in to see whether they
> > agree to keep this interface unstable.
> >
> > At the end of the day, if it is unstable, I don't really care that much.
> > I'm happy to let you (the developer and user) have more say in that
> > case. I will instead divert my (limited) time to code that your patch
> > touches which is also used by other stable functions.
>
> SGTM
Ian and Anthony, your opinions?
Wei.
Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
On Fri, Apr 10, 2020 at 10:19 AM Wei Liu wrote:
>
> On Fri, Apr 10, 2020 at 10:05:50AM -0600, Tamas K Lengyel wrote:
> > On Thu, Apr 9, 2020 at 11:30 AM Tamas K Lengyel
> > wrote:
> > >
> > > On Thu, Apr 9, 2020 at 11:11 AM Wei Liu wrote:
> > > >
> > > > On Thu, Apr 09, 2020 at 10:59:55AM -0600, Tamas K Lengyel wrote:
> > > > [...]
> > > > > >
> > > > > > >
> > > > > > > > >
> > > > > > > > > +/*
> > > > > > > > > + * The parent domain is expected to be created with default
> > > > > > > > > settings for
> > > > > > > > > + * - max_evtch_port
> > > > > > > > > + * - max_grant_frames
> > > > > > > > > + * - max_maptrack_frames
> > > > > > > > > + */
> > > > > > > > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid,
> > > > > > > > > uint32_t max_vcpus, uint32_t *domid)
> > > > > > > > > +{
> > > > > > > > > +int rc;
> > > > > > > > > +struct xen_domctl_createdomain create = {0};
> > > > > > > > > +create.flags |= XEN_DOMCTL_CDF_hvm;
> > > > > > > > > +create.flags |= XEN_DOMCTL_CDF_hap;
> > > > > > > > > +create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > > > > > > > +create.arch.emulation_flags = (XEN_X86_EMU_ALL &
> > > > > > > > > ~XEN_X86_EMU_VPCI);
> > > > > > > > > +create.ssidref = SECINITSID_DOMU;
> > > > > > > > > +create.max_vcpus = max_vcpus;
> > > > > > > >
> > > > > > > >
> > > > > > > > Some questions:
> > > > > > > >
> > > > > > > > Why does the caller need to specify the number of vcpus?
> > > > > > > >
> > > > > > > > Since the parent (source) domain is around, can you retrieve
> > > > > > > > its domain
> > > > > > > > configuration such that you know its max_vcpus and other
> > > > > > > > information
> > > > > > > > including max_evtchn_port and maptrack frames?
> > > > > > >
> > > > > > > Because we want to avoid having to issue an extra hypercall for
> > > > > > > these.
> > > > > > > Normally these pieces of information will be available for the
> > > > > > > user
> > > > > > > and won't change, so we save time by not querying for it every
> > > > > > > time a
> > > > > > > fork is created. Remember, we might be creating thousands of
> > > > > > > forks in
> > > > > > > a very short time, so those extra hypercalls add up.
> > > > > >
> > > > > > I see. Speed is a big concern to you.
> > > > > >
> > > > > > What I was referring to doesn't require issuing hypercalls but
> > > > > > requires
> > > > > > calling libxl_retrieve_domain_configuration. That's likely to be
> > > > > > even
> > > > > > slower than making a hypercall.
> > > > >
> > > > > Right. We only want to parse the domain config if the device model is
> > > > > being launched.
> > > > >
> > > > > >
> > > > > > I'm afraid the current incarnation of libxl_domain_fork_vm cannot
> > > > > > become
> > > > > > supported (as in Xen's support statement) going forward, because it
> > > > > > is
> > > > > > leaky.
> > > > >
> > > > > What do you mean by leaky?
> > > >
> > > > It requires the caller to specify the number of max_vcpus. The reason
> > > > for doing that is because you want to avoid extra hypercall(s). There is
> > > > nothing that stops someone from coming along in the future claiming some
> > > > other parameters are required because of the same concern you have
> > > > today. It is an optimisation, not a must-have in terms of functionality.
> > > >
> > > > To me the number shouldn't be specified by the caller in the first
> > > > place. It is like forking a process somehow requires you to specify how
> > > > many threads it will have.
> > >
> > > I agree. It's not how I wanted to have the interface work but
> > > unfortunately this was the least "ugly" of the possible solutions
> > > given the circumstances.
> >
> > By the way, it would be trivial to query the parent in case max_vcpus
> > is not provided by the user. But I would still like to keep the option
> > available to skip that step if the number is known already. Let me
> > know if you would like me to add that.
>
> I'm still waiting for Ian and Anthony to chime in to see whether they
> agree to keep this interface unstable.
>
> At the end of the day, if it is unstable, I don't really care that much.
> I'm happy to let you (the developer and user) have more say in that
> case. I will instead divert my (limited) time to code that your patch
> touches which is also used by other stable functions.
SGTM
Thanks,
Tamas
Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
On Fri, Apr 10, 2020 at 10:05:50AM -0600, Tamas K Lengyel wrote:
> On Thu, Apr 9, 2020 at 11:30 AM Tamas K Lengyel
> wrote:
> >
> > On Thu, Apr 9, 2020 at 11:11 AM Wei Liu wrote:
> > >
> > > On Thu, Apr 09, 2020 at 10:59:55AM -0600, Tamas K Lengyel wrote:
> > > [...]
> > > > >
> > > > > >
> > > > > > > >
> > > > > > > > +/*
> > > > > > > > + * The parent domain is expected to be created with default
> > > > > > > > settings for
> > > > > > > > + * - max_evtch_port
> > > > > > > > + * - max_grant_frames
> > > > > > > > + * - max_maptrack_frames
> > > > > > > > + */
> > > > > > > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid,
> > > > > > > > uint32_t max_vcpus, uint32_t *domid)
> > > > > > > > +{
> > > > > > > > +int rc;
> > > > > > > > +struct xen_domctl_createdomain create = {0};
> > > > > > > > +create.flags |= XEN_DOMCTL_CDF_hvm;
> > > > > > > > +create.flags |= XEN_DOMCTL_CDF_hap;
> > > > > > > > +create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > > > > > > +create.arch.emulation_flags = (XEN_X86_EMU_ALL &
> > > > > > > > ~XEN_X86_EMU_VPCI);
> > > > > > > > +create.ssidref = SECINITSID_DOMU;
> > > > > > > > +create.max_vcpus = max_vcpus;
> > > > > > >
> > > > > > >
> > > > > > > Some questions:
> > > > > > >
> > > > > > > Why does the caller need to specify the number of vcpus?
> > > > > > >
> > > > > > > Since the parent (source) domain is around, can you retrieve its
> > > > > > > domain
> > > > > > > configuration such that you know its max_vcpus and other
> > > > > > > information
> > > > > > > including max_evtchn_port and maptrack frames?
> > > > > >
> > > > > > Because we want to avoid having to issue an extra hypercall for
> > > > > > these.
> > > > > > Normally these pieces of information will be available for the user
> > > > > > and won't change, so we save time by not querying for it every time
> > > > > > a
> > > > > > fork is created. Remember, we might be creating thousands of forks
> > > > > > in
> > > > > > a very short time, so those extra hypercalls add up.
> > > > >
> > > > > I see. Speed is a big concern to you.
> > > > >
> > > > > What I was referring to doesn't require issuing hypercalls but
> > > > > requires
> > > > > calling libxl_retrieve_domain_configuration. That's likely to be even
> > > > > slower than making a hypercall.
> > > >
> > > > Right. We only want to parse the domain config if the device model is
> > > > being launched.
> > > >
> > > > >
> > > > > I'm afraid the current incarnation of libxl_domain_fork_vm cannot
> > > > > become
> > > > > supported (as in Xen's support statement) going forward, because it is
> > > > > leaky.
> > > >
> > > > What do you mean by leaky?
> > >
> > > It requires the caller to specify the number of max_vcpus. The reason
> > > for doing that is because you want to avoid extra hypercall(s). There is
> > > nothing that stops someone from coming along in the future claiming some
> > > other parameters are required because of the same concern you have
> > > today. It is an optimisation, not a must-have in terms of functionality.
> > >
> > > To me the number shouldn't be specified by the caller in the first
> > > place. It is like forking a process somehow requires you to specify how
> > > many threads it will have.
> >
> > I agree. It's not how I wanted to have the interface work but
> > unfortunately this was the least "ugly" of the possible solutions
> > given the circumstances.
>
> By the way, it would be trivial to query the parent in case max_vcpus
> is not provided by the user. But I would still like to keep the option
> available to skip that step if the number is known already. Let me
> know if you would like me to add that.
I'm still waiting for Ian and Anthony to chime in to see whether they
agree to keep this interface unstable.
At the end of the day, if it is unstable, I don't really care that much.
I'm happy to let you (the developer and user) have more say in that
case. I will instead divert my (limited) time to code that your patch
touches which is also used by other stable functions.
Wei.
>
> Thanks,
> Tamas
Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
On Thu, Apr 9, 2020 at 11:30 AM Tamas K Lengyel
wrote:
>
> On Thu, Apr 9, 2020 at 11:11 AM Wei Liu wrote:
> >
> > On Thu, Apr 09, 2020 at 10:59:55AM -0600, Tamas K Lengyel wrote:
> > [...]
> > > >
> > > > >
> > > > > > >
> > > > > > > +/*
> > > > > > > + * The parent domain is expected to be created with default
> > > > > > > settings for
> > > > > > > + * - max_evtch_port
> > > > > > > + * - max_grant_frames
> > > > > > > + * - max_maptrack_frames
> > > > > > > + */
> > > > > > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid,
> > > > > > > uint32_t max_vcpus, uint32_t *domid)
> > > > > > > +{
> > > > > > > +int rc;
> > > > > > > +struct xen_domctl_createdomain create = {0};
> > > > > > > +create.flags |= XEN_DOMCTL_CDF_hvm;
> > > > > > > +create.flags |= XEN_DOMCTL_CDF_hap;
> > > > > > > +create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > > > > > +create.arch.emulation_flags = (XEN_X86_EMU_ALL &
> > > > > > > ~XEN_X86_EMU_VPCI);
> > > > > > > +create.ssidref = SECINITSID_DOMU;
> > > > > > > +create.max_vcpus = max_vcpus;
> > > > > >
> > > > > >
> > > > > > Some questions:
> > > > > >
> > > > > > Why does the caller need to specify the number of vcpus?
> > > > > >
> > > > > > Since the parent (source) domain is around, can you retrieve its
> > > > > > domain
> > > > > > configuration such that you know its max_vcpus and other information
> > > > > > including max_evtchn_port and maptrack frames?
> > > > >
> > > > > Because we want to avoid having to issue an extra hypercall for these.
> > > > > Normally these pieces of information will be available for the user
> > > > > and won't change, so we save time by not querying for it every time a
> > > > > fork is created. Remember, we might be creating thousands of forks in
> > > > > a very short time, so those extra hypercalls add up.
> > > >
> > > > I see. Speed is a big concern to you.
> > > >
> > > > What I was referring to doesn't require issuing hypercalls but requires
> > > > calling libxl_retrieve_domain_configuration. That's likely to be even
> > > > slower than making a hypercall.
> > >
> > > Right. We only want to parse the domain config if the device model is
> > > being launched.
> > >
> > > >
> > > > I'm afraid the current incarnation of libxl_domain_fork_vm cannot become
> > > > supported (as in Xen's support statement) going forward, because it is
> > > > leaky.
> > >
> > > What do you mean by leaky?
> >
> > It requires the caller to specify the number of max_vcpus. The reason
> > for doing that is because you want to avoid extra hypercall(s). There is
> > nothing that stops someone from coming along in the future claiming some
> > other parameters are required because of the same concern you have
> > today. It is an optimisation, not a must-have in terms of functionality.
> >
> > To me the number shouldn't be specified by the caller in the first
> > place. It is like forking a process somehow requires you to specify how
> > many threads it will have.
>
> I agree. It's not how I wanted to have the interface work but
> unfortunately this was the least "ugly" of the possible solutions
> given the circumstances.
By the way, it would be trivial to query the parent in case max_vcpus
is not provided by the user. But I would still like to keep the option
available to skip that step if the number is known already. Let me
know if you would like me to add that.
Thanks,
Tamas
Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
On Thu, Apr 9, 2020 at 11:11 AM Wei Liu wrote:
>
> On Thu, Apr 09, 2020 at 10:59:55AM -0600, Tamas K Lengyel wrote:
> [...]
> > >
> > > >
> > > > > >
> > > > > > +/*
> > > > > > + * The parent domain is expected to be created with default
> > > > > > settings for
> > > > > > + * - max_evtch_port
> > > > > > + * - max_grant_frames
> > > > > > + * - max_maptrack_frames
> > > > > > + */
> > > > > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t
> > > > > > max_vcpus, uint32_t *domid)
> > > > > > +{
> > > > > > +int rc;
> > > > > > +struct xen_domctl_createdomain create = {0};
> > > > > > +create.flags |= XEN_DOMCTL_CDF_hvm;
> > > > > > +create.flags |= XEN_DOMCTL_CDF_hap;
> > > > > > +create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > > > > +create.arch.emulation_flags = (XEN_X86_EMU_ALL &
> > > > > > ~XEN_X86_EMU_VPCI);
> > > > > > +create.ssidref = SECINITSID_DOMU;
> > > > > > +create.max_vcpus = max_vcpus;
> > > > >
> > > > >
> > > > > Some questions:
> > > > >
> > > > > Why does the caller need to specify the number of vcpus?
> > > > >
> > > > > Since the parent (source) domain is around, can you retrieve its
> > > > > domain
> > > > > configuration such that you know its max_vcpus and other information
> > > > > including max_evtchn_port and maptrack frames?
> > > >
> > > > Because we want to avoid having to issue an extra hypercall for these.
> > > > Normally these pieces of information will be available for the user
> > > > and won't change, so we save time by not querying for it every time a
> > > > fork is created. Remember, we might be creating thousands of forks in
> > > > a very short time, so those extra hypercalls add up.
> > >
> > > I see. Speed is a big concern to you.
> > >
> > > What I was referring to doesn't require issuing hypercalls but requires
> > > calling libxl_retrieve_domain_configuration. That's likely to be even
> > > slower than making a hypercall.
> >
> > Right. We only want to parse the domain config if the device model is
> > being launched.
> >
> > >
> > > I'm afraid the current incarnation of libxl_domain_fork_vm cannot become
> > > supported (as in Xen's support statement) going forward, because it is
> > > leaky.
> >
> > What do you mean by leaky?
>
> It requires the caller to specify the number of max_vcpus. The reason
> for doing that is because you want to avoid extra hypercall(s). There is
> nothing that stops someone from coming along in the future claiming some
> other parameters are required because of the same concern you have
> today. It is an optimisation, not a must-have in terms of functionality.
>
> To me the number shouldn't be specified by the caller in the first
> place. It is like forking a process somehow requires you to specify how
> many threads it will have.
I agree. It's not how I wanted to have the interface work but
unfortunately this was the least "ugly" of the possible solutions
given the circumstances.
> >
> > >
> > > I can see two solutions: 1. batch forking to reduce the number of
> > > queries needed; 2. make a proper domctl which duplicates the source
> > > domain structure inside Xen.
> >
> > I've attempted to do that by extending the domain create hypercall so
> > that this information can be copied in the hypervisor. That approach
> > was very unpopular.
> >
>
> Sigh. Sorry I haven't had the chance to read previous discussions.
> -ETIME.
Sigh indeed.
Tamas
Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
On Thu, Apr 09, 2020 at 10:59:55AM -0600, Tamas K Lengyel wrote:
[...]
> >
> > >
> > > > >
> > > > > +/*
> > > > > + * The parent domain is expected to be created with default settings
> > > > > for
> > > > > + * - max_evtch_port
> > > > > + * - max_grant_frames
> > > > > + * - max_maptrack_frames
> > > > > + */
> > > > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t
> > > > > max_vcpus, uint32_t *domid)
> > > > > +{
> > > > > +int rc;
> > > > > +struct xen_domctl_createdomain create = {0};
> > > > > +create.flags |= XEN_DOMCTL_CDF_hvm;
> > > > > +create.flags |= XEN_DOMCTL_CDF_hap;
> > > > > +create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > > > +create.arch.emulation_flags = (XEN_X86_EMU_ALL &
> > > > > ~XEN_X86_EMU_VPCI);
> > > > > +create.ssidref = SECINITSID_DOMU;
> > > > > +create.max_vcpus = max_vcpus;
> > > >
> > > >
> > > > Some questions:
> > > >
> > > > Why does the caller need to specify the number of vcpus?
> > > >
> > > > Since the parent (source) domain is around, can you retrieve its domain
> > > > configuration such that you know its max_vcpus and other information
> > > > including max_evtchn_port and maptrack frames?
> > >
> > > Because we want to avoid having to issue an extra hypercall for these.
> > > Normally these pieces of information will be available for the user
> > > and won't change, so we save time by not querying for it every time a
> > > fork is created. Remember, we might be creating thousands of forks in
> > > a very short time, so those extra hypercalls add up.
> >
> > I see. Speed is a big concern to you.
> >
> > What I was referring to doesn't require issuing hypercalls but requires
> > calling libxl_retrieve_domain_configuration. That's likely to be even
> > slower than making a hypercall.
>
> Right. We only want to parse the domain config if the device model is
> being launched.
>
> >
> > I'm afraid the current incarnation of libxl_domain_fork_vm cannot become
> > supported (as in Xen's support statement) going forward, because it is
> > leaky.
>
> What do you mean by leaky?
It requires the caller to specify the number of max_vcpus. The reason
for doing that is because you want to avoid extra hypercall(s). There is
nothing that stops someone from coming along in the future claiming some
other parameters are required because of the same concern you have
today. It is an optimisation, not a must-have in terms of functionality.
To me the number shouldn't be specified by the caller in the first
place. It is like forking a process somehow requires you to specify how
many threads it will have.
>
> >
> > I can see two solutions: 1. batch forking to reduce the number of
> > queries needed; 2. make a proper domctl which duplicates the source
> > domain structure inside Xen.
>
> I've attempted to do that by extending the domain create hypercall so
> that this information can be copied in the hypervisor. That approach
> was very unpopular.
>
Sigh. Sorry I haven't had the chance to read previous discussions.
-ETIME.
Wei.
Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
On Thu, Apr 9, 2020 at 10:22 AM Wei Liu wrote:
>
> On Thu, Apr 09, 2020 at 09:51:35AM -0600, Tamas K Lengyel wrote:
> > On Thu, Apr 9, 2020 at 9:43 AM Wei Liu wrote:
> > >
> > > On Mon, Apr 06, 2020 at 08:20:05AM -0700, Tamas K Lengyel wrote:
> > > > Add necessary bits to implement "xl fork-vm" commands. The command
> > > > allows the
> > > > user to specify how to launch the device model allowing for a
> > > > late-launch model
> > > > in which the user can execute the fork without the device model and
> > > > decide to
> > > > only later launch it.
> > > >
> > > > Signed-off-by: Tamas K Lengyel
> > > > ---
> > > [...]
> > > >
> > > > +int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
> > > > + libxl__domain_build_state *state,
> > > > + uint32_t *domid, bool soft_reset)
> > >
> > > It would have been nice if you could split the refactoring out to a
> > > separate patch.
> >
> > I found the toolstack to be way harder to work with then the
> > hypervisor code-base. Splitting the patches would have been nice but I
> > don't even know how to begin that since it's all such a spaghetti.
>
> In this case you've split out some code from a function to make a new
> function. That is a self-contained task, which can be in its own patch.
>
> >
> > >
> > > > static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
> > > > libxl_domain_build_info *b_info)
> > > > {
> > > > @@ -1191,16 +1207,32 @@ static void initiate_domain_create(libxl__egc
> > > > *egc,
> > > > ret = libxl__domain_config_setdefault(gc,d_config,domid);
> > > > if (ret) goto error_out;
> > > >
> > > > -ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> > > > - dcs->soft_reset);
> > > > -if (ret) {
> > > > -LOGD(ERROR, domid, "cannot make domain: %d", ret);
> > > > +if ( !d_config->dm_restore_file )
> > > > +{
> > > > +ret = libxl__domain_make(gc, d_config, &dcs->build_state,
> > > > &domid,
> > > > + dcs->soft_reset);
> > > > dcs->guest_domid = domid;
> > > > +
> > > > +if (ret) {
> > > > +LOGD(ERROR, domid, "cannot make domain: %d", ret);
> > > > +ret = ERROR_FAIL;
> > > > +goto error_out;
> > > > +}
> > > > +} else if ( dcs->guest_domid != INVALID_DOMID ) {
> > >
> > > Coding style issue here.
> > >
> > > There are quite a few of them. I won't point them out one by one
> > > though. Let's focus on the interface first.
> >
> > Do we have an automatic formatter we could just run on this code-base?
> > I don't know what style issue you are referring to and given that the
> > coding style here is different here compared to the hypervisor I find
> > it very hard to figure it out what other issues you spotted. Please
> > report them because I won't be able to spot them manually. To me it
> > all looks fine as-is.
>
> I feel your pain. There was work in progress to provide a style checker,
> but we're not there yet.
>
> Xen and libxc share one coding style while libxl and xl share another.
> There is a CODING_STYLE file under libxl directory. The problem here is
> you should not have spaces inside ().
>
> Generally I think pointing out coding style issues tend to distract
> people from discussing more important things, so I would leave them last
> to fix.
I agree. I would highly prefer if we would get to a spot where they
wouldn't even have to be pointed out other then "run this command to
fix up the style". I submitted an astyle template already for Xen,
others prefer clang to do it, yet it's been like a year and doesn't
look like we will go anywhere with either. Just a waste of time IMHO.
>
> >
> > > >
> > > > +/*
> > > > + * The parent domain is expected to be created with default settings
> > > > for
> > > > + * - max_evtch_port
> > > > + * - max_grant_frames
> > > > + * - max_maptrack_frames
> > > > + */
> > > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t
> > > > max_vcpus, uint32_t *domid)
> > > > +{
> > > > +int rc;
> > > > +struct xen_domctl_createdomain create = {0};
> > > > +create.flags |= XEN_DOMCTL_CDF_hvm;
> > > > +create.flags |= XEN_DOMCTL_CDF_hap;
> > > > +create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > > +create.arch.emulation_flags = (XEN_X86_EMU_ALL &
> > > > ~XEN_X86_EMU_VPCI);
> > > > +create.ssidref = SECINITSID_DOMU;
> > > > +create.max_vcpus = max_vcpus;
> > >
> > >
> > > Some questions:
> > >
> > > Why does the caller need to specify the number of vcpus?
> > >
> > > Since the parent (source) domain is around, can you retrieve its domain
> > > configuration such that you know its max_vcpus and other information
> > > including max_evtchn_port and maptrack frames?
> >
> > Because we want to avoid having to issue an extra hypercall for these.
> > Normally these pieces of information will b
Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
On Thu, Apr 09, 2020 at 09:51:35AM -0600, Tamas K Lengyel wrote:
> On Thu, Apr 9, 2020 at 9:43 AM Wei Liu wrote:
> >
> > On Mon, Apr 06, 2020 at 08:20:05AM -0700, Tamas K Lengyel wrote:
> > > Add necessary bits to implement "xl fork-vm" commands. The command allows
> > > the
> > > user to specify how to launch the device model allowing for a late-launch
> > > model
> > > in which the user can execute the fork without the device model and
> > > decide to
> > > only later launch it.
> > >
> > > Signed-off-by: Tamas K Lengyel
> > > ---
> > [...]
> > >
> > > +int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
> > > + libxl__domain_build_state *state,
> > > + uint32_t *domid, bool soft_reset)
> >
> > It would have been nice if you could split the refactoring out to a
> > separate patch.
>
> I found the toolstack to be way harder to work with then the
> hypervisor code-base. Splitting the patches would have been nice but I
> don't even know how to begin that since it's all such a spaghetti.
In this case you've split out some code from a function to make a new
function. That is a self-contained task, which can be in its own patch.
>
> >
> > > static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
> > > libxl_domain_build_info *b_info)
> > > {
> > > @@ -1191,16 +1207,32 @@ static void initiate_domain_create(libxl__egc
> > > *egc,
> > > ret = libxl__domain_config_setdefault(gc,d_config,domid);
> > > if (ret) goto error_out;
> > >
> > > -ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> > > - dcs->soft_reset);
> > > -if (ret) {
> > > -LOGD(ERROR, domid, "cannot make domain: %d", ret);
> > > +if ( !d_config->dm_restore_file )
> > > +{
> > > +ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> > > + dcs->soft_reset);
> > > dcs->guest_domid = domid;
> > > +
> > > +if (ret) {
> > > +LOGD(ERROR, domid, "cannot make domain: %d", ret);
> > > +ret = ERROR_FAIL;
> > > +goto error_out;
> > > +}
> > > +} else if ( dcs->guest_domid != INVALID_DOMID ) {
> >
> > Coding style issue here.
> >
> > There are quite a few of them. I won't point them out one by one
> > though. Let's focus on the interface first.
>
> Do we have an automatic formatter we could just run on this code-base?
> I don't know what style issue you are referring to and given that the
> coding style here is different here compared to the hypervisor I find
> it very hard to figure it out what other issues you spotted. Please
> report them because I won't be able to spot them manually. To me it
> all looks fine as-is.
I feel your pain. There was work in progress to provide a style checker,
but we're not there yet.
Xen and libxc share one coding style while libxl and xl share another.
There is a CODING_STYLE file under libxl directory. The problem here is
you should not have spaces inside ().
Generally I think pointing out coding style issues tend to distract
people from discussing more important things, so I would leave them last
to fix.
>
> > >
> > > +/*
> > > + * The parent domain is expected to be created with default settings for
> > > + * - max_evtch_port
> > > + * - max_grant_frames
> > > + * - max_maptrack_frames
> > > + */
> > > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t
> > > max_vcpus, uint32_t *domid)
> > > +{
> > > +int rc;
> > > +struct xen_domctl_createdomain create = {0};
> > > +create.flags |= XEN_DOMCTL_CDF_hvm;
> > > +create.flags |= XEN_DOMCTL_CDF_hap;
> > > +create.flags |= XEN_DOMCTL_CDF_oos_off;
> > > +create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> > > +create.ssidref = SECINITSID_DOMU;
> > > +create.max_vcpus = max_vcpus;
> >
> >
> > Some questions:
> >
> > Why does the caller need to specify the number of vcpus?
> >
> > Since the parent (source) domain is around, can you retrieve its domain
> > configuration such that you know its max_vcpus and other information
> > including max_evtchn_port and maptrack frames?
>
> Because we want to avoid having to issue an extra hypercall for these.
> Normally these pieces of information will be available for the user
> and won't change, so we save time by not querying for it every time a
> fork is created. Remember, we might be creating thousands of forks in
> a very short time, so those extra hypercalls add up.
I see. Speed is a big concern to you.
What I was referring to doesn't require issuing hypercalls but requires
calling libxl_retrieve_domain_configuration. That's likely to be even
slower than making a hypercall.
I'm afraid the current incarnation of libxl_domain_fork_vm cannot become
supported (as in Xen's support statement) going forward, because it is
leaky.
I can see two solutions: 1. batch forking
Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
On Thu, Apr 9, 2020 at 9:43 AM Wei Liu wrote:
>
> On Mon, Apr 06, 2020 at 08:20:05AM -0700, Tamas K Lengyel wrote:
> > Add necessary bits to implement "xl fork-vm" commands. The command allows
> > the
> > user to specify how to launch the device model allowing for a late-launch
> > model
> > in which the user can execute the fork without the device model and decide
> > to
> > only later launch it.
> >
> > Signed-off-by: Tamas K Lengyel
> > ---
> [...]
> >
> > +int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
> > + libxl__domain_build_state *state,
> > + uint32_t *domid, bool soft_reset)
>
> It would have been nice if you could split the refactoring out to a
> separate patch.
I found the toolstack to be way harder to work with then the
hypervisor code-base. Splitting the patches would have been nice but I
don't even know how to begin that since it's all such a spaghetti.
>
> > static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
> > libxl_domain_build_info *b_info)
> > {
> > @@ -1191,16 +1207,32 @@ static void initiate_domain_create(libxl__egc *egc,
> > ret = libxl__domain_config_setdefault(gc,d_config,domid);
> > if (ret) goto error_out;
> >
> > -ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> > - dcs->soft_reset);
> > -if (ret) {
> > -LOGD(ERROR, domid, "cannot make domain: %d", ret);
> > +if ( !d_config->dm_restore_file )
> > +{
> > +ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> > + dcs->soft_reset);
> > dcs->guest_domid = domid;
> > +
> > +if (ret) {
> > +LOGD(ERROR, domid, "cannot make domain: %d", ret);
> > +ret = ERROR_FAIL;
> > +goto error_out;
> > +}
> > +} else if ( dcs->guest_domid != INVALID_DOMID ) {
>
> Coding style issue here.
>
> There are quite a few of them. I won't point them out one by one
> though. Let's focus on the interface first.
Do we have an automatic formatter we could just run on this code-base?
I don't know what style issue you are referring to and given that the
coding style here is different here compared to the hypervisor I find
it very hard to figure it out what other issues you spotted. Please
report them because I won't be able to spot them manually. To me it
all looks fine as-is.
> >
> > +/*
> > + * The parent domain is expected to be created with default settings for
> > + * - max_evtch_port
> > + * - max_grant_frames
> > + * - max_maptrack_frames
> > + */
> > +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t
> > max_vcpus, uint32_t *domid)
> > +{
> > +int rc;
> > +struct xen_domctl_createdomain create = {0};
> > +create.flags |= XEN_DOMCTL_CDF_hvm;
> > +create.flags |= XEN_DOMCTL_CDF_hap;
> > +create.flags |= XEN_DOMCTL_CDF_oos_off;
> > +create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> > +create.ssidref = SECINITSID_DOMU;
> > +create.max_vcpus = max_vcpus;
>
>
> Some questions:
>
> Why does the caller need to specify the number of vcpus?
>
> Since the parent (source) domain is around, can you retrieve its domain
> configuration such that you know its max_vcpus and other information
> including max_evtchn_port and maptrack frames?
Because we want to avoid having to issue an extra hypercall for these.
Normally these pieces of information will be available for the user
and won't change, so we save time by not querying for it every time a
fork is created. Remember, we might be creating thousands of forks in
a very short time, so those extra hypercalls add up.
Tamas
Re: [PATCH v14 3/3] xen/tools: VM forking toolstack side
On Mon, Apr 06, 2020 at 08:20:05AM -0700, Tamas K Lengyel wrote:
> Add necessary bits to implement "xl fork-vm" commands. The command allows the
> user to specify how to launch the device model allowing for a late-launch
> model
> in which the user can execute the fork without the device model and decide to
> only later launch it.
>
> Signed-off-by: Tamas K Lengyel
> ---
[...]
>
> +int libxl__domain_make(libxl__gc *gc, libxl_domain_config *d_config,
> + libxl__domain_build_state *state,
> + uint32_t *domid, bool soft_reset)
It would have been nice if you could split the refactoring out to a
separate patch.
> static int store_libxl_entry(libxl__gc *gc, uint32_t domid,
> libxl_domain_build_info *b_info)
> {
> @@ -1191,16 +1207,32 @@ static void initiate_domain_create(libxl__egc *egc,
> ret = libxl__domain_config_setdefault(gc,d_config,domid);
> if (ret) goto error_out;
>
> -ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> - dcs->soft_reset);
> -if (ret) {
> -LOGD(ERROR, domid, "cannot make domain: %d", ret);
> +if ( !d_config->dm_restore_file )
> +{
> +ret = libxl__domain_make(gc, d_config, &dcs->build_state, &domid,
> + dcs->soft_reset);
> dcs->guest_domid = domid;
> +
> +if (ret) {
> +LOGD(ERROR, domid, "cannot make domain: %d", ret);
> +ret = ERROR_FAIL;
> +goto error_out;
> +}
> +} else if ( dcs->guest_domid != INVALID_DOMID ) {
Coding style issue here.
There are quite a few of them. I won't point them out one by one
though. Let's focus on the interface first.
>
> +/*
> + * The parent domain is expected to be created with default settings for
> + * - max_evtch_port
> + * - max_grant_frames
> + * - max_maptrack_frames
> + */
> +int libxl_domain_fork_vm(libxl_ctx *ctx, uint32_t pdomid, uint32_t
> max_vcpus, uint32_t *domid)
> +{
> +int rc;
> +struct xen_domctl_createdomain create = {0};
> +create.flags |= XEN_DOMCTL_CDF_hvm;
> +create.flags |= XEN_DOMCTL_CDF_hap;
> +create.flags |= XEN_DOMCTL_CDF_oos_off;
> +create.arch.emulation_flags = (XEN_X86_EMU_ALL & ~XEN_X86_EMU_VPCI);
> +create.ssidref = SECINITSID_DOMU;
> +create.max_vcpus = max_vcpus;
Some questions:
Why does the caller need to specify the number of vcpus?
Since the parent (source) domain is around, can you retrieve its domain
configuration such that you know its max_vcpus and other information
including max_evtchn_port and maptrack frames?
Wei.
[PATCH v14 3/3] xen/tools: VM forking toolstack side
Add necessary bits to implement "xl fork-vm" commands. The command allows the
user to specify how to launch the device model allowing for a late-launch model
in which the user can execute the fork without the device model and decide to
only later launch it.
Signed-off-by: Tamas K Lengyel
---
docs/man/xl.1.pod.in | 44 +
tools/libxc/include/xenctrl.h | 13 ++
tools/libxc/xc_memshr.c | 22 +++
tools/libxl/libxl.h | 11 ++
tools/libxl/libxl_create.c| 361 +++---
tools/libxl/libxl_dm.c| 2 +-
tools/libxl/libxl_dom.c | 43 +++-
tools/libxl/libxl_internal.h | 7 +
tools/libxl/libxl_types.idl | 1 +
tools/libxl/libxl_x86.c | 41
tools/xl/Makefile | 2 +-
tools/xl/xl.h | 5 +
tools/xl/xl_cmdtable.c| 15 ++
tools/xl/xl_forkvm.c | 144 ++
tools/xl/xl_vmcontrol.c | 14 ++
15 files changed, 559 insertions(+), 166 deletions(-)
create mode 100644 tools/xl/xl_forkvm.c
diff --git a/docs/man/xl.1.pod.in b/docs/man/xl.1.pod.in
index 09339282e6..59c03c6427 100644
--- a/docs/man/xl.1.pod.in
+++ b/docs/man/xl.1.pod.in
@@ -708,6 +708,50 @@ above).
=back
+=item B [I] I
+
+Create a fork of a running VM. The domain will be paused after the operation
+and remains paused while forks of it exist. Experimental and x86 only.
+Forks can only be made of domains with HAP enabled and on Intel hardware. The
+parent domain must be created with the xl toolstack and its configuration must
+not manually define max_grant_frames, max_maptrack_frames or
max_event_channels.
+
+B
+
+=over 4
+
+=item B<-p>
+
+Leave the fork paused after creating it.
+
+=item B<--launch-dm>
+
+Specify whether the device model (QEMU) should be launched for the fork. Late
+launch allows to start the device model for an already running fork.
+
+=item B<-C>
+
+The config file to use when launching the device model. Currently required
when
+launching the device model. Most config settings MUST match the parent domain
+exactly, only change VM name, disk path and network configurations.
+
+=item B<-Q>
+
+The path to the qemu save file to use when launching the device model.
Currently
+required when launching the device model.
+
+=item B<--fork-reset>
+
+Perform a reset operation of an already running fork. Note that resetting may
+be less performant then creating a new fork depending on how much memory the
+fork has deduplicated during its runtime.
+
+=item B<--max-vcpus>
+
+Specify the max-vcpus matching the parent domain when not launching the dm.
+
+=back
+
=item B [I]
Display the number of shared pages for a specified domain. If no domain is
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 58fa931de1..631750a242 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2225,6 +2225,19 @@ int xc_memshr_range_share(xc_interface *xch,
uint64_t first_gfn,
uint64_t last_gfn);
+int xc_memshr_fork(xc_interface *xch,
+ uint32_t source_domain,
+ uint32_t client_domain);
+
+/*
+ * Note: this function is only intended to be used on short-lived forks that
+ * haven't yet aquired a lot of memory. In case the fork has a lot of memory
+ * it is likely more performant to create a new fork with xc_memshr_fork.
+ *
+ * With VMs that have a lot of memory this call may block for a long time.
+ */
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t forked_domain);
+
/* Debug calls: return the number of pages referencing the shared frame backing
* the input argument. Should be one or greater.
*
diff --git a/tools/libxc/xc_memshr.c b/tools/libxc/xc_memshr.c
index 97e2e6a8d9..d0e4ee225b 100644
--- a/tools/libxc/xc_memshr.c
+++ b/tools/libxc/xc_memshr.c
@@ -239,6 +239,28 @@ int xc_memshr_debug_gref(xc_interface *xch,
return xc_memshr_memop(xch, domid, &mso);
}
+int xc_memshr_fork(xc_interface *xch, uint32_t pdomid, uint32_t domid)
+{
+xen_mem_sharing_op_t mso;
+
+memset(&mso, 0, sizeof(mso));
+
+mso.op = XENMEM_sharing_op_fork;
+mso.u.fork.parent_domain = pdomid;
+
+return xc_memshr_memop(xch, domid, &mso);
+}
+
+int xc_memshr_fork_reset(xc_interface *xch, uint32_t domid)
+{
+xen_mem_sharing_op_t mso;
+
+memset(&mso, 0, sizeof(mso));
+mso.op = XENMEM_sharing_op_fork_reset;
+
+return xc_memshr_memop(xch, domid, &mso);
+}
+
int xc_memshr_audit(xc_interface *xch)
{
xen_mem_sharing_op_t mso;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index 71709dc585..088e81c78b 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -2666,6 +2666,17 @@ int libxl_psr_get_hw_info(libxl_ctx *ctx,
libxl_psr_feat_type type,
unsigned int lvl, unsigned int *nr,
libxl_psr_hw_info **info);
void libxl_psr_hw_info_list_free(libxl_psr_hw_info *list, unsigned in
