libxc: remove stale error check for domain size in xc_sr_save_x86_hvm.c
PATCH 1/1 libxc: remove stale error check for domain size in xc_sr_save_x86_hvm.c
Long ago domains to be saved were limited to 1TB size due to the migration stream v1 limitations which used a 32 bit value for the PFN and the frame type (4 bits) leaving only 28 bits for the PFN.
Migration stream V2 uses a 64 bit value for this purpose, so there is no need to refuse saving (or migrating) domains larger than 1 TB.
Remove the related test in xc_sr_save_x86_hvm.c
---
I know we have code freeze. Nevertheless I'd like to request an exception and get this into 4.10, as the impact of the patch is very local and of low risk.
--- tools/libxc/xc_sr_save_x86_hvm.c | 6 ------ 1 file changed, 6 deletions(-)
tools/libxc/xc_sr_save_x86_hvm.c +0 -6
@@ -148,12 +148,6 @@ static int x86_hvm_setup(struct xc_sr_context *ctx)PERROR ("Unable to obtain the guest p2m size" );return -1 ; } -if ( nr_pfns > ~XEN_DOMCTL_PFINFO_LTAB_MASK ) - { - errno =E2BIG ; -PERROR ("Cannot save this big a guest" ); -return -1 ; - } ctx->save.p2m_size = nr_pfns;
Signature · 7 lines
2.12.3 _______________________________________________ Xen-devel mailing list [email protected] https://lists.xen.org/xen-devel
Quoted 10 lines · Juergen Gross
Long ago domains to be saved were limited to 1TB size due to the migration stream v1 limitations which used a 32 bit value for the PFN and the frame type (4 bits) leaving only 28 bits for the PFN.
Migration stream V2 uses a 64 bit value for this purpose, so there is no need to refuse saving (or migrating) domains larger than 1 TB.
Remove the related test in
xc_sr_save_x86_hvm.cSigned-off-by Juergen Gross <[email protected]>
Sorry, but this still serves a very real purpose. Without it, you will crash a 32bit toolstack trying to migrate a large domain, due to virtual address space exhaustion.
Things are hopefully better now that we don't unconditionally map the m2p, but iirc, 1.2T domains were the tipping point last time I tried.
I didn't come up with any more clever way of limiting the size, which is why this check persisted from the legacy code.
~Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 8 lines · Andrew Cooper
Quoted 7 lines · Juergen Gross
Long ago domains to be saved were limited to 1TB size due to the migration stream v1 limitations which used a 32 bit value for the PFN and the frame type (4 bits) leaving only 28 bits for the PFN.
Migration stream V2 uses a 64 bit value for this purpose, so there is no need to refuse saving (or migrating) domains larger than 1 TB.
Quoted 7 lines
Quoted 3 lines
Remove the related test in
xc_sr_save_x86_hvm.cSigned-off-by Juergen Gross <[email protected]>Sorry, but this still serves a very real purpose. Without it, you will crash a 32bit toolstack trying to migrate a large domain, due to virtual address space exhaustion.
So would you be fine with doing the check for 32 bit toolstack only?
Eventually on the receiver side, too?
Juergen
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel
Quoted 16 lines · Andrew Cooper
Quoted 10 lines · Juergen Gross
Long ago domains to be saved were limited to 1TB size due to the migration stream v1 limitations which used a 32 bit value for the PFN and the frame type (4 bits) leaving only 28 bits for the PFN.
Migration stream V2 uses a 64 bit value for this purpose, so there is no need to refuse saving (or migrating) domains larger than 1 TB.
Remove the related test in
xc_sr_save_x86_hvm.cSigned-off-by Juergen Gross <[email protected]>Sorry, but this still serves a very real purpose. Without it, you will crash a 32bit toolstack trying to migrate a large domain, due to virtual address space exhaustion.
Quoted 5 lines
Things are hopefully better now that we don't unconditionally map the m2p, but iirc, 1.2T domains were the tipping point last time I tried.
I didn't come up with any more clever way of limiting the size, which is why this check persisted from the legacy code.
BTW: this test is really confusing!
You don't want to limit the pfns to 28 bits due to the type mask, but you just want to limit the domain size due to a (potential) lack of host resources.
So the least to do would be a test for the size without using XEN_DOMCTL_PFINFO_LTAB_MASK together with a comment _why_ the test is needed.
Juergen
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xen.org/xen-devel