[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 1/1] Add mmio_hole_size



On Tue, Sep 30, 2014 at 2:27 AM, Boris Ostrovsky
<boris.ostrovsky@xxxxxxxxxx> wrote:
>> +    if ( mmio_hole_size )
>> +    {
>> +        uint64_t max_ram_below_4g = (1ULL << 32) - mmio_hole_size;
>> +
>> +        if ( max_ram_below_4g > HVM_BELOW_4G_MMIO_START )
>> +        {
>> +            printf("max_ram_below_4g=0x"PRIllx
>> +                   " too big for mmio_hole_size=0x"PRIllx
>> +                   " has been ignored.\n",
>> +                   PRIllx_arg(max_ram_below_4g),
>> +                   PRIllx_arg(mmio_hole_size));
>> +        }
>
>
> Do you need to check whether the hole is too large?
>
> Here and in the toolstack.

How large is too large?  I've seen real machines with a 3GiB memory hole...

>> "0";
>> +        if (info->u.hvm.mmio_hole_size) {
>> +            uint64_t max_ram_below_4g =
>> +                (1ULL << 32) - info->u.hvm.mmio_hole_size;
>> +
>> +            if (max_ram_below_4g <= HVM_BELOW_4G_MMIO_START) {
>
>
> You seem to be making various checks on hole size in multiple places ---
> here, in libxl__build_device_model_args_new() and in parse_config_data().
> (And, to some degree, in xc_hvm_build_with_hole()). Are they all necessary?

I think we should get rid of xc_hvm_build_with_hole() entirely, but I
think we want a check everywhere else.  The key question is when the
failure is going to happen ideally.  You absolutely have to check it
at the bottom level (hvmloader).  But you don't want to go through all
the hassle of setting up the domain and starting to boot it only to
find that some silly parameter is messed up, so it should also be
checked in libxl (since many people will be going through only libxl).
But if you're using xl and get an error at the libxl layer, the error
message is often a bit cryptic.  So it makes sense to have it at the
parsing level too.

 -George

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.