qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Igor Mammedov <imammedo@redhat.com>
Cc: "Andreas Färber" <afaerber@suse.de>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 6/6] pc: limit 64 bit hole to 2G by default
Date: Sun, 28 Jul 2013 22:48:54 +0300	[thread overview]
Message-ID: <20130728194854.GA28008@redhat.com> (raw)
In-Reply-To: <20130728194032.457e52aa@thinkpad>

On Sun, Jul 28, 2013 at 07:40:32PM +0200, Igor Mammedov wrote:
> On Sun, 28 Jul 2013 12:17:47 +0200
> Andreas Färber <afaerber@suse.de> wrote:
> 
> > Am 28.07.2013 11:11, schrieb Michael S. Tsirkin:
> > > On Sun, Jul 28, 2013 at 10:21:56AM +0200, Igor Mammedov wrote:
> > >> On Sun, 28 Jul 2013 10:57:12 +0300
> > >> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >>
> > >>> On Sun, Jul 28, 2013 at 09:29:13AM +0200, Igor Mammedov wrote:
> > >>>>  
> > >>>>      info = g_malloc(sizeof *info);
> > >>>> -    info->w32_min = cpu_to_le64(guest_info->pci_info.w32.begin);
> > >>>> -    info->w32_max = cpu_to_le64(guest_info->pci_info.w32.end);
> > >>>> -    info->w64_min = cpu_to_le64(guest_info->pci_info.w64.begin);
> > >>>> -    info->w64_max = cpu_to_le64(guest_info->pci_info.w64.end);
> > >>>> +    info->w32_min = cpu_to_le64(object_property_get_int(pci_info,
> > >>>> +                                "pci_hole_start", NULL));
> > >>>> +    info->w32_max = cpu_to_le64(object_property_get_int(pci_info,
> > >>>> +                                "pci_hole_end", NULL));
> > >>>
> > >>> Looks wrong.
> > >>> object_property_get_int returns a signed int64.
> > >>> w32 is unsigned.
> > >>> Happens to work but I think we need an explicit API.
> > 
> > That's how QAPI works internally today for any uint64 visitor/property.
> > uint64_t is cast to int64_t and back in visitors.
> > 
> > So I'd hope something like
> > uint64_t val = (uint64_t) object_property_get_int()
> > would work equally well - CC'ing Michael.
> > 
> > >> I guess it's copy-past error s/cpu_to_le64/cpu_to_le32/
> > > 
> > > Not these are 64 bit values, but they need to be
> > > unsigned not signed.
> > > 
> > >> but not need for extra API, with fixed property definition
> > >> i.e. s/UINT64/UNIT32/ property set code will take care about limits.
> > > 
> > > If you replace these with UINT32 you won't be able to
> > > specify values >4G.
> > > 
> > >>> Property names are hard-coded string literals.
> > >>> Please add macros to set and get them
> > >>> so we can avoid duplicating code.
> > >>> E.g.
> > >> sure.
> > >>
> > >>>
> > >>> #define PCI_HOST_PROPS...
> > >>> static inline get_
> > [...]
> > >>>> @@ -629,6 +648,15 @@ static const char *i440fx_pcihost_root_bus_path(PCIHostState *host_bridge,
> > >>>>      return "0000";
> > >>>>  }
> > >>>>  
> > >>>> +static Property i440fx_props[] = {
> > >>>> +    DEFINE_PROP_UINT64("pci_hole64_start", I440FXState, pci_info.w64.begin, 0),
> > >>>> +    DEFINE_PROP_UINT64("pci_hole64_end", I440FXState, pci_info.w64.end, 0),
> > >>>> +    DEFINE_PROP_UINT64("pci_hole_start", I440FXState, pci_info.w32.begin, 0),
> > >>>> +    DEFINE_PROP_UINT64("pci_hole_end", I440FXState, pci_info.w32.end,
> > >>>> +                       IO_APIC_DEFAULT_ADDRESS),
> > >>>> +    DEFINE_PROP_END_OF_LIST(),
> > >>>> +};
> > >>>> +
> > >>>
> > >>> So we have 4 properties. One of them pci_hole64_end
> > >>> is supposed to be set to a value.
> > >>> Others should not be touched under any circuimstances.
> > >>> Of course if you query properties you have no way
> > >>> to know which is which and what are the legal values.
> > >>> Ouch.
> > >> read-only properties are possible but we would have to drop
> > >> usage DEFINE_PROP_UINT64 of and explicitly use only setter in PropertyInfo,
> > > 
> > > Or add DEFINE_PROP_UINT64_RO for this?
> > > 
> > >> user better not to touch these properties since they are mostly internal API.
> > >> but if we say it's internal properties then enforcing read-only might be
> > >> overkill.
> > >> For user friendly property "pci_hole64_size" would be nice to have.
> > > 
> > > So at the moment I do
> > > 
> > > qemu -device i440FX-pcihost,help
> > > 
> > > and this will get all properties.
> > > 
> > > If we add some properties that user can not set
> > > they should not appear in this output.
> > [snip]
> > 
> > Igor, you can simply use dynamic properties with NULL as setter argument
> > for object_property_add*() to achieve that effect.
> Yes, I can but it's more boiler plate code just for restricting single
> property. And if we have "pci_hole64_size"/default then user set
> "pci_hole64_end" would not have any effect, since "pci_hole64_size"
> would override it.

I don't think we want user to control low level properties such and
_start and _end.  _size might be unavoidable but let's limit
it to that.


> > Andreas
> > 
> > -- 
> > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
> 
> 
> -- 
> Regards,
>   Igor

  reply	other threads:[~2013-07-28 19:47 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-28  7:29 [Qemu-devel] [PATCH 0/6 v2 for-1.6] pc: limit 64 bit hole to 2G by default Igor Mammedov
2013-07-28  7:29 ` [Qemu-devel] [PATCH 1/6] pc: move IO_APIC_DEFAULT_ADDRESS to include/hw/i386/ioapic.h Igor Mammedov
2013-07-28  9:54   ` Andreas Färber
2013-07-28 17:19     ` Igor Mammedov
2013-07-28 17:37       ` Andreas Färber
2013-07-28  7:29 ` [Qemu-devel] [PATCH 2/6] pc: add I440FX QOM cast macro Igor Mammedov
2013-07-28  9:57   ` Andreas Färber
2013-07-28 17:21     ` Igor Mammedov
2013-07-28 17:24       ` Andreas Färber
2013-07-28 18:05         ` Igor Mammedov
2013-07-28  7:29 ` [Qemu-devel] [PATCH 3/6] utils: add range_size() wrapper Igor Mammedov
2013-07-28  7:29 ` [Qemu-devel] [PATCH 4/6] pc: replace i440fx_common_init() with i440fx_init() as it isn't used by anywhere else Igor Mammedov
2013-07-28 10:07   ` Andreas Färber
2013-07-28  7:29 ` [Qemu-devel] [PATCH 5/6] pc: add Q35 to QOM composition tree under /machine Igor Mammedov
2013-07-28 10:08   ` Andreas Färber
2013-07-28  7:29 ` [Qemu-devel] [PATCH 6/6] pc: limit 64 bit hole to 2G by default Igor Mammedov
2013-07-28  7:57   ` Michael S. Tsirkin
2013-07-28  8:21     ` Igor Mammedov
2013-07-28  9:11       ` Michael S. Tsirkin
2013-07-28 10:17         ` Andreas Färber
2013-07-28 17:40           ` Igor Mammedov
2013-07-28 19:48             ` Michael S. Tsirkin [this message]
2013-07-30 21:34           ` Michael Roth
2013-07-28 17:33         ` Igor Mammedov
2013-07-28 19:51           ` Michael S. Tsirkin
2013-07-29  7:55             ` Igor Mammedov
2013-07-29  8:16               ` Michael S. Tsirkin
2013-07-28  9:13       ` Michael S. Tsirkin
2013-07-28 17:34         ` Igor Mammedov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130728194854.GA28008@redhat.com \
    --to=mst@redhat.com \
    --cc=afaerber@suse.de \
    --cc=imammedo@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).