From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: "Andreas Färber" <afaerber@suse.de>,
"Michael S. Tsirkin" <mst@redhat.com>,
"Igor Mammedov" <imammedo@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 6/6] pc: limit 64 bit hole to 2G by default
Date: Tue, 30 Jul 2013 16:34:07 -0500 [thread overview]
Message-ID: <20130730213407.14585.11429@loki> (raw)
In-Reply-To: <51F4EFCB.4050401@suse.de>
Quoting Andreas Färber (2013-07-28 05:17:47)
> 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.
It actually depends on the 'wire'/'serialized' encoding of the underlying
visitor implementation. In this case we're 'serializing' into a QObject
via QmpOutputVisitor, where all integers are actually stored as a
QInt/int64 anyway, so this cast is unavoidable in this case regardless
of what QAPI interface we use: we'll always end up storing as an int64,
requiring us to re-cast to get back to original value. Best we can
achieve is burying the cast deeper (or significantly re-working how
QObject/QInt works)
There is additional bounds checking performed prior to serialization
if the serialized type is less than 64 bits though, so we'd probably
want to add fixed-width accessors if we found ourselves in a situation
where we needed to cast to a smaller datatype than the original.
It's also worth noting that visiting uint64 types using int64 visitor
interfaces isn't universally guaranteed to work: for certain visitor
implementations the serialized encodings may not be compatible with
one another. But in this case we should be good.
>
> >> 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.
>
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2013-07-30 21:34 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
2013-07-30 21:34 ` Michael Roth [this message]
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=20130730213407.14585.11429@loki \
--to=mdroth@linux.vnet.ibm.com \
--cc=afaerber@suse.de \
--cc=imammedo@redhat.com \
--cc=mst@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.