Re: [Qemu-devel] KVM call minutes for Feb 8
On Tue, Feb 15, 2011 at 05:07:07PM -0600, Anthony Liguori wrote:
On 02/15/2011 11:11 AM, Blue Swirl wrote:
On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
Any device we expose to the user through -device needs to maintain a
compatible interface forever. For our own sanity, I think we should try to
expose as little as possible.
Restricting the users from adding arbitrary devices is a different
issue. Dropping qdev support to prevent user from adding the device
seems draconian, what's wrong with no_user flag?
I think you're missing my point.
It should be possible to make a device qdev without exposing it
via a factory interface. Today it's all or nothing and that's the
part I dislike.
I think you are mixing too different thing here. The purpose of qdev (or
other device tree implementation) should be 1. to provide factory
interface. 2 to keep track on how devices are interconnected (or in
other words to keep track of device tree). But you are constantly
talking about how qdev should be object oriented way to build devices
themselves and I think this shouldn't be part of qdev at all.
no_user is a hack. We can do better.
A good example of a device that we should model through qdev but not expose
via -device is actually SerialState.
You wouldn't want users to add any serial ports? What should be do
with serial ports then, always enable a full set of ports? How would
the user use them?
No, users should be able to create ISASerialDevice,
MMIOSerialDevice, but not UART16650A. Here's what I'm talking
about:
class ISASerialDevice : public ISADevice
{
UART16650A uart;
};
class MMIOSerialDevice : public PlatformDevice
{
UART16650A uart;
};
There should be factory interfaces for ISASeriaDevice and
MMIOSerialDevice but not UART16650A.
This is OK and I do not disagree with this, but this is not what qdev
should be about. Qdev should be about allowing user to specify how and
which classes (read devices) should be instantiated at how they should
be interconnected. Taking yous example above qdev should allow to say: I
want to instantiate ISASerialDevice on bus object isabus0 (which was
instantiated before). It should claim resources A, B and C from that
bus. I also what instantiate MMIOSerialDevice on bus object systembus
claiming resource Z.
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguori anth...@codemonkey.ws wrote: On 02/14/2011 03:25 PM, Blue Swirl wrote: I'd still like to have the inline wrapper over the factory interface, probably with similar signature to isa_serial_new. Then there would be two functions, one going through qdev and the other bypassing it. I don't see how that would be useful. The callers of the direct interface would force linkage between them and so it would be impossible to build QEMU with that device. We don't need that flexibility for every device though, but I don't see any advantages for using the direct interface either. Why shouldn't we want all devices to be exposed to the user? For example, there are still devices which don't show up in 'info qtree', which is a shame. Showing up in info qtree is goodness, but I'm talking about allowing a user to directly instantiate a device. Any device we expose to the user through -device needs to maintain a compatible interface forever. For our own sanity, I think we should try to expose as little as possible. Restricting the users from adding arbitrary devices is a different issue. Dropping qdev support to prevent user from adding the device seems draconian, what's wrong with no_user flag? A good example of a device that we should model through qdev but not expose via -device is actually SerialState. You wouldn't want users to add any serial ports? What should be do with serial ports then, always enable a full set of ports? How would the user use them? Today, we have ISASerialState which embeds SerialState. We can also create a MMIO version of SerialState although there's no direct structure that wraps that. Ideally, SerialState would be a proper qdev device that is embedded in both ISASerialState and MMIOSerialState (or pick a better name). info qtree should show a has-a relationship for these devices. I think the devices shown in qtree should always have some relationship to real devices. If ICH10 contains all possible onboard devices, including for example HPET, e1000 and SATA, that could use a has-a relationship to show the composition but otherwise I fear this would only increase complexity with no gain. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/15/2011 11:11 AM, Blue Swirl wrote:
On Mon, Feb 14, 2011 at 11:47 PM, Anthony Liguorianth...@codemonkey.ws wrote:
Any device we expose to the user through -device needs to maintain a
compatible interface forever. For our own sanity, I think we should try to
expose as little as possible.
Restricting the users from adding arbitrary devices is a different
issue. Dropping qdev support to prevent user from adding the device
seems draconian, what's wrong with no_user flag?
I think you're missing my point.
It should be possible to make a device qdev without exposing it via a
factory interface. Today it's all or nothing and that's the part I dislike.
no_user is a hack. We can do better.
A good example of a device that we should model through qdev but not expose
via -device is actually SerialState.
You wouldn't want users to add any serial ports? What should be do
with serial ports then, always enable a full set of ports? How would
the user use them?
No, users should be able to create ISASerialDevice, MMIOSerialDevice,
but not UART16650A. Here's what I'm talking about:
class ISASerialDevice : public ISADevice
{
UART16650A uart;
};
class MMIOSerialDevice : public PlatformDevice
{
UART16650A uart;
};
There should be factory interfaces for ISASeriaDevice and
MMIOSerialDevice but not UART16650A.
Today, we have ISASerialState which embeds SerialState. We can also create
a MMIO version of SerialState although there's no direct structure that
wraps that.
Ideally, SerialState would be a proper qdev device that is embedded in both
ISASerialState and MMIOSerialState (or pick a better name). info qtree
should show a has-a relationship for these devices.
I think the devices shown in qtree should always have some
relationship to real devices. If ICH10 contains all possible onboard
devices, including for example HPET, e1000 and SATA, that could use a
has-a relationship to show the composition
Yeah, I'm not disagreeing at all.
Ignoring the fact that modern uarts are implemented in a super i/o chip,
it's same chip whether it's soldered directly on a board with direct
connections to a CPU bus or whether it's exposed on the ISA bus.
Regards,
Anthony Liguori
but otherwise I fear this
would only increase complexity with no gain.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/13/2011 08:57 PM, Anthony Liguori wrote: It shouldn't be able to dead lock if the locking is designed right. As an aside, one advantage of the qemuthread wrappers is that we can add lockdep mechanisms. (It's true that these could be added to glib as well, but getting stuff into glib is a pain). Paolo -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Sun, Feb 13, 2011 at 01:38:12PM -0600, Anthony Liguori wrote: On 02/13/2011 12:08 PM, Gleb Natapov wrote: On Sun, Feb 13, 2011 at 10:56:30AM -0600, Anthony Liguori wrote: qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device ioapic,id=ioapic,chipset=sb -device cpu,ioapic=ioapic,northbridge=nb Is not all that unreasonable and presents a fully functioning PC. Sure. And -M blah is a shortcut. Exactly. Or better yet, blah is a config file that contains [device nb] driver=i440fx You are trying to model how particular (very ancient) HW looked like, instead of emulating guest visible functionality, but is dead end since things are changing constantly. Northbridge functionality moves onto cpu for instance. What CPU i440fx was designed for? Pentium? What if user runs QEMU with emulated CPU that in real life has internal memory controller? Does you config have sense for such setup? Should we allow to specify only Pentium CPU since this is how real HW worked? Yes, how we structure the device tree will change over time. If users have to specify this stuff, we've already failed to start with. And nevertheless this is what you propose here. User should be able to specify what devices he wants in a stable format (FDT for instance) and qemu should create the machine from it. How it is done internally is different question, but if FDT cannot be reproduced from internal state we are doing something wrong. The important thing is: we should model how different parts of HW work together, not how chips are interconnected. Look at FDTs of real machines. They may contain a lot of devices, but in reality most of them are sitting in the same chip as CPU. The i440fx is definitely guest visible. And yes, a guest could look at freak out that an i440fx is in use with a non-Pentium class CPU. We cheat here, and it works just fine. And not modeling PIIX3 exactly as in real life (by dropping IDE or USB or even adding ACPI from PIIX4) works just fine (we checked it here too). And yes, a guest could look into details and freak out too. But guests don't do that (otherwise they would have to support each chipset in existence). The state that i440fx expose to a guest is of any interest only to firmware and luckily we have our own firmware to take care of the details. PIIX3 is not mush more visible to a guest. This is just marketing name for collection of HW put in one chip. Remove USB and you get PIIX2, add ACPI and you get PIIX4. Why would you want to govern qemu design from such insignificant details? [device sb] driver=piix3 And piix3 refers to piix3.cfg which describe devices that present on the chipset. I disagree in this case that it's the best thing to do, but in general, yeah, we should provide a mechanism to have essentially device tree macros such that one high level device represents a larger tree of devices. This would be a good mechanism to support the concept of machines. But I don't think we should rely on having this tomorrow as doing this well is going to be challenging. That is what we (almost) have now. If going your direction makes it challenging we shouldn't go there. chipset=nb [device ioapic] driver=ioapic chipset=sb Here, for instance, IOAPIC is included in a chipset for a long time now. Why user should care that piix3 didn't have it. How this detail changes qemu functionality? If it doesn't why should we expose it? Yeah, I'd be inclined to push the ioapic into the chipset here except it may be useful to have multiple ioapics at some point down the road. When machine has multiple ioapic I am almost sure all of them are present on a chipset, not as stand alone chips. Since having multiple IOAPIC affects also firmware I am not sure it is useful to support different number of IOAPICs in qemu. Yes, we're exposing gory details of the device model. No, I don't have a problem with that. [device cpu] driver=cpu ioapic=ioapic Why ioapic here? Doesn't cpu talks to ioapic via northbridge? The i440fx is the northbridge. For the i440fx, the I/O apic is a separate chip. But it is connected to i440fx, not CPU like in your theoretical config. Northbridge, southbridge are just names that do not have any architectural significance. Like other said in this thread on other architectures there is no such naming at all. No wonder, since on most embedded archs (that I know of) all functionality was included on the same chip as CPU. On x86 PCs historically motherboard had three main chips (cpu, ram + pic controller, common hw), so they got those names. Now in Intel Sandy Bridge all of the functions of the northbridge reside on the chip itself for instance and I am sure there will be Atoms with all HW on the same chip. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Mon, Feb 14, 2011 at 12:42 AM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/13/2011 03:00 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
On 02/13/2011 01:37 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
qdev doesn't expose any state today. qdev properties are
construction-only
properties that happen to be stored in each device state.
What we really need is a full property framework that includes
properties
with hookable getters and setters along with the ability to mark
properties
as construct-only, read-only, or read-write.
But I think it's reasonable to expose construct-only properties as just
an
initfn argument.
Sounds OK. About read-write properties, what happens if we one day
have extensive threading, and locks are pushed to device level? I can
imagine a deadlock involving one thread running in IO thread for a
device and another trying to access that device's properties. Maybe
that is not different from function call version.
You need hookable setters/getters that can acquire a lock and do the
right
thing. It shouldn't be able to dead lock if the locking is designed
right.
Yes, but qemu_irq is very restricted as it only models a signal bit of
information and doesn't really have a mechanism to attach/detach in any
generic way.
Basic signals are already very useful for many purposes, since they
match digital logic signals in real HW. In theory, whole machines
could be constructed with just qemu_irq and NAND gate emulator. ;-)
It's not just in theory. In the C++ port of QEMU that I wrote, I
implemented an AND, OR, and XOR gate and implemented a full 32-bit adder
by
just using a device config file.
If done correctly, using referencing can be extremely powerful. A full
adder is a good example. The gates really don't have any concept of bus
and
the relationship between gates is definitely not a tree.
In the message passing IRQ discussion earlier, it was IIRC decided
that the one bit version would not be changed but a separate message
passing version would be created if ever needed.
C already has a message passing interface that supports type safety
called
function pointers :-)
An object that implements multiple interfaces where the interface becomes
the message passing interface is exactly what I've been saying we need.
It's flexible and the compiler helps us enforce typing.
Any interfaces of a base class should make sense even for derived
classes.
That means if the base class is going to expose essentially a pin-out
interface, that if I have a PCIDevice and cast it to Device, I should
be
able to interact with the GPIO interface to interact with the PCI
device.
Presumably, that means interfacing at the PCI signalling level.
That's
insane to model in QEMU :-)
This would be doable, if we built buses from a bunch of signals, like
in VHDL or Verilog. It would simplify aliased MMIO addresses nicely,
the undecoded address pins would be ignored. I don't think it would be
useful, but a separate interface could be added for connecting to
PCIBus with just qemu_irqs.
Yeah, it's possible, but I don't want to spend my time doing this.
In reality, GPIO only makes sense for a small class of simple devices
where
modelling the pin-out interface makes sense (like a 7-segment LCD).
That
suggests that GPIO should not be in the DeviceState interface but
instead
should be in a SimpleDevice subclass or something like that.
Could you point to examples of SystemBus overuse?
anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
73
anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
56
SystemBus has become a catch-all for shallow qdev conversions. We've
got
Northbridges, RAM, and network devices sitting on the same bus...
On Sparc32 I have not bothered to create a SBus bus. Now it would be
useful to get bootindex corrected. Most devices (even on-board IO)
should use SBus.
The only other bus (MBus) would exist between CPU, IOMMU and memory.
But SysBus fitted the need until recently.
A good way to judge where a device is using a bus interface correct: does
all of it's interactions with any other part of the guest state involve
method calls to the bus?
Right now, the answer is no for just about every device in QEMU. This is
the problem that qdev really was meant to solve and we're not really any
further along solving it unfortunately.
I'm not arguing against a generic factory interface, I'm arguing that
it
should be separate.
IOW:
SerialState *serial_create(int iobase, int irq, ...);
static DeviceState *qdev_serial_create(QemuOpts *opts);
static void serial_init(void)
{
qdev_register(serial, qdev_serial_create);
}
The key point is that when we create devices internally, we should have
a
C-friendly, type-safe interface
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/14/2011 11:31 AM, Blue Swirl wrote:
I don't understand. The caller just does
if (isa_serial_init()) {
error();
}
or
if (serial_init()) {
error();
}
If you mean inside isa_serial_init() vs. serial_init(), that may be
true since isa_serial_init has to check for qdev failures, but the to
the caller both should be identical.
The problem with qdev is there's too much boiler plate code which makes
it hard to give examples :-) Here's precisely what I'm talking about:
static int serial_isa_initfn(ISADevice *dev)
{
static int index;
ISASerialState *isa = DO_UPCAST(ISASerialState, dev, dev);
SerialState *s = isa-state;
if (isa-index == -1)
isa-index = index;
if (isa-index = MAX_SERIAL_PORTS)
return -1;
if (isa-iobase == -1)
isa-iobase = isa_serial_io[isa-index];
if (isa-isairq == -1)
isa-isairq = isa_serial_irq[isa-index];
index++;
s-baudbase = 115200;
isa_init_irq(dev, s-irq, isa-isairq);
serial_init_core(s);
qdev_set_legacy_instance_id(dev-qdev, isa-iobase, 3);
register_ioport_write(isa-iobase, 8, 1, serial_ioport_write, s);
register_ioport_read(isa-iobase, 8, 1, serial_ioport_read, s);
isa_init_ioport_range(dev, isa-iobase, 8);
return 0;
}
SerialState *serial_init(int base, qemu_irq irq, int baudbase,
CharDriverState *chr)
{
SerialState *s;
s = qemu_mallocz(sizeof(SerialState));
s-irq = irq;
s-baudbase = baudbase;
s-chr = chr;
serial_init_core(s);
vmstate_register(NULL, base, vmstate_serial, s);
register_ioport_write(base, 8, 1, serial_ioport_write, s);
register_ioport_read(base, 8, 1, serial_ioport_read, s);
return s;
}
static ISADeviceInfo serial_isa_info = {
.qdev.name = isa-serial,
.qdev.size = sizeof(ISASerialState),
.qdev.vmsd = vmstate_isa_serial,
.init = serial_isa_initfn,
.qdev.props = (Property[]) {
DEFINE_PROP_UINT32(index, ISASerialState, index, -1),
DEFINE_PROP_HEX32(iobase, ISASerialState, iobase, -1),
DEFINE_PROP_UINT32(irq, ISASerialState, isairq, -1),
DEFINE_PROP_CHR(chardev, ISASerialState, state.chr),
DEFINE_PROP_END_OF_LIST(),
},
};
static void serial_register_devices(void)
{
isa_qdev_register(serial_isa_info);
}
device_init(serial_register_devices)
To create a device, I need to do:
{
ISADevice *dev;
dev = isa_create(isa-serial);
if (dev == NULL) {
return error;
}
if (qdev_set_uint32(dev-qdev, index, index)) {
goto err;
}
if (qdev_set_uint32(dev-qdev, iobase, iobase)) {
goto err;
}
if (qdev_set_uint32(dev-qdev, irq, irq)) {
goto err;
}
if (qdev_set_chr(dev-qdev, chardev, chr)) {
goto err;
}
if (qdev_init(dev-qdev)) {
goto err;
}
return 0;
err:
qdev_destroy(dev-qdev);
return -1;
}
This is simply not a reasonable API to use to create devices. There are
two ways we can make this more managable. The first is gobject-style
vararg constructor coupled with a type safe wrapper. So...
ISASerialDevice *isa_serial_device_new(uint32_t index, uint32_t iobase,
uint32_t irq, CharDriverState *chr)
{
return isa_device_create_va(isa-seral, index, index,
iobase, iobase, irq, irq, chardev, chr, NULL);
}
Now this can be used in a reasonable fashion. However, we can do even
better if we change the way qdev is done. Consider the following:
SerialState *serial_init(int base, qemu_irq irq, int baudbase,
CharDriverState *chr)
{
SerialState *s;
s = qemu_mallocz(sizeof(SerialState));
s-irq = irq;
s-baudbase = baudbase;
s-chr = chr;
serial_init_core(s);
vmstate_register(NULL, base, vmstate_serial, s);
register_ioport_write(base, 8, 1, serial_ioport_write, s);
register_ioport_read(base, 8, 1, serial_ioport_read, s);
return s;
}
ISASerialDevice *isa_serial_new(uint32_t index, uint32_t iobase,
uint32_t irq, CharDriverState *chr)
{
static int index;
ISADevice *dev = isa_create(isa-serial);
ISASerialState *isa = DO_UPCAST(ISASerialState, dev, dev);
SerialState *s = isa-state;
if (index == -1)
index = index;
if (index = MAX_SERIAL_PORTS)
return NULL;
if (iobase == -1)
iobase = isa_serial_io[index];
if (isairq == -1)
isairq = isa_serial_irq[index];
index++;
s-baudbase = 115200;
isa_init_irq(dev, s-irq, isairq);
serial_init_core(s);
qdev_set_legacy_instance_id(dev-qdev, isa-iobase, 3);
register_ioport_write(isa-iobase, 8, 1, serial_ioport_write, s);
register_ioport_read(isa-iobase, 8, 1, serial_ioport_read, s);
isa_init_ioport_range(dev, isa-iobase, 8);
return isa;
}
static ISADevice *isa_seral_init_qdev(QemuOpts *opts)
{
uint32_t index = qemu_opt_get_uint32(opts, index, -1);
uint32_t irq =
Re: [Qemu-devel] KVM call minutes for Feb 8
On Mon, Feb 14, 2011 at 10:53 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/14/2011 11:31 AM, Blue Swirl wrote:
I don't understand. The caller just does
if (isa_serial_init()) {
error();
}
or
if (serial_init()) {
error();
}
If you mean inside isa_serial_init() vs. serial_init(), that may be
true since isa_serial_init has to check for qdev failures, but the to
the caller both should be identical.
The problem with qdev is there's too much boiler plate code which makes it
hard to give examples :-) Here's precisely what I'm talking about:
static int serial_isa_initfn(ISADevice *dev)
{
static int index;
ISASerialState *isa = DO_UPCAST(ISASerialState, dev, dev);
SerialState *s = isa-state;
if (isa-index == -1)
isa-index = index;
if (isa-index = MAX_SERIAL_PORTS)
return -1;
if (isa-iobase == -1)
isa-iobase = isa_serial_io[isa-index];
if (isa-isairq == -1)
isa-isairq = isa_serial_irq[isa-index];
index++;
s-baudbase = 115200;
isa_init_irq(dev, s-irq, isa-isairq);
serial_init_core(s);
qdev_set_legacy_instance_id(dev-qdev, isa-iobase, 3);
register_ioport_write(isa-iobase, 8, 1, serial_ioport_write, s);
register_ioport_read(isa-iobase, 8, 1, serial_ioport_read, s);
isa_init_ioport_range(dev, isa-iobase, 8);
return 0;
}
SerialState *serial_init(int base, qemu_irq irq, int baudbase,
CharDriverState *chr)
{
SerialState *s;
s = qemu_mallocz(sizeof(SerialState));
s-irq = irq;
s-baudbase = baudbase;
s-chr = chr;
serial_init_core(s);
vmstate_register(NULL, base, vmstate_serial, s);
register_ioport_write(base, 8, 1, serial_ioport_write, s);
register_ioport_read(base, 8, 1, serial_ioport_read, s);
return s;
}
static ISADeviceInfo serial_isa_info = {
.qdev.name = isa-serial,
.qdev.size = sizeof(ISASerialState),
.qdev.vmsd = vmstate_isa_serial,
.init = serial_isa_initfn,
.qdev.props = (Property[]) {
DEFINE_PROP_UINT32(index, ISASerialState, index, -1),
DEFINE_PROP_HEX32(iobase, ISASerialState, iobase, -1),
DEFINE_PROP_UINT32(irq, ISASerialState, isairq, -1),
DEFINE_PROP_CHR(chardev, ISASerialState, state.chr),
DEFINE_PROP_END_OF_LIST(),
},
};
static void serial_register_devices(void)
{
isa_qdev_register(serial_isa_info);
}
device_init(serial_register_devices)
To create a device, I need to do:
{
ISADevice *dev;
dev = isa_create(isa-serial);
if (dev == NULL) {
return error;
}
if (qdev_set_uint32(dev-qdev, index, index)) {
goto err;
}
if (qdev_set_uint32(dev-qdev, iobase, iobase)) {
goto err;
}
if (qdev_set_uint32(dev-qdev, irq, irq)) {
goto err;
}
if (qdev_set_chr(dev-qdev, chardev, chr)) {
goto err;
}
if (qdev_init(dev-qdev)) {
goto err;
}
return 0;
err:
qdev_destroy(dev-qdev);
return -1;
}
This is simply not a reasonable API to use to create devices.
This can be wrapped in a static inline function, with similar
signature to what you propose:
static inline ISADevice *serial_init(int base, qemu_irq irq, int
baudbase, CharDriverState *chr);
There are two
ways we can make this more managable. The first is gobject-style vararg
constructor coupled with a type safe wrapper. So...
ISASerialDevice *isa_serial_device_new(uint32_t index, uint32_t iobase,
uint32_t irq, CharDriverState *chr)
{
return isa_device_create_va(isa-seral, index, index, iobase,
iobase, irq, irq, chardev, chr, NULL);
}
Now this can be used in a reasonable fashion. However, we can do even
better if we change the way qdev is done. Consider the following:
SerialState *serial_init(int base, qemu_irq irq, int baudbase,
CharDriverState *chr)
{
SerialState *s;
s = qemu_mallocz(sizeof(SerialState));
s-irq = irq;
s-baudbase = baudbase;
s-chr = chr;
serial_init_core(s);
vmstate_register(NULL, base, vmstate_serial, s);
register_ioport_write(base, 8, 1, serial_ioport_write, s);
register_ioport_read(base, 8, 1, serial_ioport_read, s);
return s;
}
ISASerialDevice *isa_serial_new(uint32_t index, uint32_t iobase, uint32_t
irq, CharDriverState *chr)
{
static int index;
ISADevice *dev = isa_create(isa-serial);
ISASerialState *isa = DO_UPCAST(ISASerialState, dev, dev);
SerialState *s = isa-state;
if (index == -1)
index = index;
if (index = MAX_SERIAL_PORTS)
return NULL;
if (iobase == -1)
iobase = isa_serial_io[index];
if (isairq == -1)
isairq = isa_serial_irq[index];
index++;
s-baudbase = 115200;
isa_init_irq(dev, s-irq, isairq);
serial_init_core(s);
qdev_set_legacy_instance_id(dev-qdev, isa-iobase, 3);
register_ioport_write(isa-iobase, 8, 1,
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/14/2011 03:25 PM, Blue Swirl wrote: I'd still like to have the inline wrapper over the factory interface, probably with similar signature to isa_serial_new. Then there would be two functions, one going through qdev and the other bypassing it. I don't see how that would be useful. The callers of the direct interface would force linkage between them and so it would be impossible to build QEMU with that device. We don't need that flexibility for every device though, but I don't see any advantages for using the direct interface either. Why shouldn't we want all devices to be exposed to the user? For example, there are still devices which don't show up in 'info qtree', which is a shame. Showing up in info qtree is goodness, but I'm talking about allowing a user to directly instantiate a device. Any device we expose to the user through -device needs to maintain a compatible interface forever. For our own sanity, I think we should try to expose as little as possible. A good example of a device that we should model through qdev but not expose via -device is actually SerialState. Today, we have ISASerialState which embeds SerialState. We can also create a MMIO version of SerialState although there's no direct structure that wraps that. Ideally, SerialState would be a proper qdev device that is embedded in both ISASerialState and MMIOSerialState (or pick a better name). info qtree should show a has-a relationship for these devices. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Fri, Feb 11, 2011 at 08:14:16PM +0200, Blue Swirl wrote: On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori anth...@codemonkey.ws wrote: On 02/10/2011 03:20 PM, Gleb Natapov wrote: Jugging by how well all previous conversion went we will end up with one more way of creating devices. One legacy, another qdev and your new one. And what is the problem with qdev again (not that I am a big qdev fan)? We've really been arguing about probably the most minor aspect of the problem with qdev. Probably. But if this aspect affects the overall re-design of device tree it is not so minor after all. All I'm really saying is that we shouldn't tie device construction to a factory interface as we do with qdev. That simply means that we should be able to do: RTC *rtc_create(arg1, arg2, arg2); I don't see how that would help at all. Throwing qdev away and just calling various functions directly, with all states exposed would be like QEMU 0.9.0. That is my sentiment exactly. This is what we had before. What was the reason we wanted device tree (let alone specific implementation of it that was committed without much external input)? Why do you no longer want device tree abstraction? And that a separate piece of code decides which devices are exposed through -device or device_add. Which devices are exposed is really a minor detail. That said, qdev has a number of significant limitations in my mind. The first is that the only relationship between devices is through the BusState interface. There's also qemu_irq for arbitrary signals. I don't think we should even try to have a generic bus model. When you look at how badly broken PCI hotplug is current in qdev, I think this is symptomatic of this. And how should this be fixed? The API change would not help. There's also no way in qdev to really have polymorphism. Interfaces really aren't meaningful in qdev so you have things like PCIDevice where some methods are stored in the object instead of the class dispatch table and you have overuse of static class members. QEMU is developed in C, not C++. And it's all unrelated to VMState. Right, but this has also the good side that not all device state is automatically exported. If other devices would be allowed to muck with a devices internal state freely, bad things could happen. Device reset could also use standard register definitions, shared with VMState. And this is just the basic mechanisms of qdev. The actual implementation is worse. The use of qemu_irq as gpio in the base class and overuse of SystemBus is really quite insane. Maybe qemu_irq should be renamed to QEMUSignal (and I don't like typedeffing pointers), otherwise it looks quite sane to me. Could you point to examples of SystemBus overuse? And so far, the use of qdev has been entirely superficial. Devices still don't make use of bus level interfaces to do I/O so we don't have any better componentization than we did before qdev. The fact that there is no enough interest to convert all devices to it? I don't think there is any device that has been improved by qdev. -device is a nice feature, but it could have been implemented without qdev. We have 'info qtree' which can't be implemented easily without a generic device class. Avi (or who was it) sent patches to expose even more device state. With the patches I'm going to apply, if Redhat wants to disable building various devices, it can be done without #ifdeffery. This is not possible without a generic factory interface. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/11/2011 12:14 PM, Blue Swirl wrote: On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguorianth...@codemonkey.ws wrote: On 02/10/2011 03:20 PM, Gleb Natapov wrote: Jugging by how well all previous conversion went we will end up with one more way of creating devices. One legacy, another qdev and your new one. And what is the problem with qdev again (not that I am a big qdev fan)? We've really been arguing about probably the most minor aspect of the problem with qdev. All I'm really saying is that we shouldn't tie device construction to a factory interface as we do with qdev. That simply means that we should be able to do: RTC *rtc_create(arg1, arg2, arg2); I don't see how that would help at all. Throwing qdev away and just calling various functions directly, with all states exposed would be like QEMU 0.9.0. qdev doesn't expose any state today. qdev properties are construction-only properties that happen to be stored in each device state. What we really need is a full property framework that includes properties with hookable getters and setters along with the ability to mark properties as construct-only, read-only, or read-write. But I think it's reasonable to expose construct-only properties as just an initfn argument. And that a separate piece of code decides which devices are exposed through -device or device_add. Which devices are exposed is really a minor detail. That said, qdev has a number of significant limitations in my mind. The first is that the only relationship between devices is through the BusState interface. There's also qemu_irq for arbitrary signals. Yes, but qemu_irq is very restricted as it only models a signal bit of information and doesn't really have a mechanism to attach/detach in any generic way. I don't think we should even try to have a generic bus model. When you look at how badly broken PCI hotplug is current in qdev, I think this is symptomatic of this. And how should this be fixed? The API change would not help. Just as we have bus level creation functions, we should have bus level hotplug interfaces. There's also no way in qdev to really have polymorphism. Interfaces really aren't meaningful in qdev so you have things like PCIDevice where some methods are stored in the object instead of the class dispatch table and you have overuse of static class members. QEMU is developed in C, not C++. But we're trying to do object oriented programming in C so as long as we're doing that, we ought to do it right. And it's all unrelated to VMState. Right, but this has also the good side that not all device state is automatically exported. If other devices would be allowed to muck with a devices internal state freely, bad things could happen. Device reset could also use standard register definitions, shared with VMState. There's a way to have formally verifiable serialization/deserialization if we can satisfy two conditions 1) the devices rely on no global state (i.e. static variables) and 2) every field asssociated with a device is marshalled during serialization/deserialization. When we define a device, right now we say that certain state is writable during construction. It's not a stretch to want to have some properties writable during runtime. If we also had a mechanism to mark certain properties as read-only, but still were able to introspect them, we could implement serialization without having to have a second VMState definition. Compatibility will always require manipulating state, but once you have the state stored in a data structure, you can describe those transformations in a pretty high level fashion. And this is just the basic mechanisms of qdev. The actual implementation is worse. The use of qemu_irq as gpio in the base class and overuse of SystemBus is really quite insane. Maybe qemu_irq should be renamed to QEMUSignal (and I don't like typedeffing pointers), otherwise it looks quite sane to me. Any interfaces of a base class should make sense even for derived classes. That means if the base class is going to expose essentially a pin-out interface, that if I have a PCIDevice and cast it to Device, I should be able to interact with the GPIO interface to interact with the PCI device. Presumably, that means interfacing at the PCI signalling level. That's insane to model in QEMU :-) In reality, GPIO only makes sense for a small class of simple devices where modelling the pin-out interface makes sense (like a 7-segment LCD). That suggests that GPIO should not be in the DeviceState interface but instead should be in a SimpleDevice subclass or something like that. Could you point to examples of SystemBus overuse? anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l 73 anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l 56 SystemBus has become a catch-all for shallow qdev conversions.
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/10/2011 04:29 AM, Avi Kivity wrote: On 02/10/2011 09:47 AM, Anthony Liguori wrote: So very concretely, I'm suggesting we do the following to target-i386: 1) make the i440fx device have an embedded ide controller, piix3, and usb controller that get initialized automatically. The piix3 embeds the PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial, etc.). This I like. 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. No, it's not. The 440fx does not include an IOAPIC, for example. There may be other optional components, or differences in wiring, that make two machines with i440fx not identical. The IOAPIC is basically the only other component and I view it as part of the CPU interface to the chipset. But still, if we're creating a machine from scratch: qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device ioapic,id=ioapic,chipset=sb -device cpu,ioapic=ioapic,northbridge=nb Is not all that unreasonable and presents a fully functioning PC. 4) model the CPUs as devices that take a pointer to a host controller, for x86, the normal case would be giving it a pointer to i440fx. Surely the connection is via a bus? An x86 cpu talks to the bus, and there happens to be an 440fx north bridge at the end of it. It could also be a Q35 or something else. I see being on a bus as really just taking a pointer to an interface. So yes, the i440fx would implement a PentiumCpuInterface or something like that and the CPU would take a pointer to a PentiumCpuInterface[1]. This is part of why having proper polymorphism is important. We need it in order to be able to express concepts like interfaces. [1] This is just a Random Bad Name. Don't read anything into it. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/10/2011 04:29 AM, Avi Kivity wrote: On 02/10/2011 09:47 AM, Anthony Liguori wrote: So very concretely, I'm suggesting we do the following to target-i386: 1) make the i440fx device have an embedded ide controller, piix3, and usb controller that get initialized automatically. The piix3 embeds the PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial, etc.). This I like. 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. No, it's not. The 440fx does not include an IOAPIC, for example. There may be other optional components, or differences in wiring, that make two machines with i440fx not identical. The IOAPIC is basically the only other component and I view it as part of the CPU interface to the chipset. But still, if we're creating a machine from scratch: qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device ioapic,id=ioapic,chipset=sb -device cpu,ioapic=ioapic,northbridge=nb Is not all that unreasonable and presents a fully functioning PC. 4) model the CPUs as devices that take a pointer to a host controller, for x86, the normal case would be giving it a pointer to i440fx. Surely the connection is via a bus? An x86 cpu talks to the bus, and there happens to be an 440fx north bridge at the end of it. It could also be a Q35 or something else. I see being on a bus as really just taking a pointer to an interface. So yes, the i440fx would implement a PentiumCpuInterface or something like that and the CPU would take a pointer to a PentiumCpuInterface[1]. This is part of why having proper polymorphism is important. We need it in order to be able to express concepts like interfaces. [1] This is just a Random Bad Name. Don't read anything into it. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/13/2011 05:38 PM, Anthony Liguori wrote: 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. No, it's not. The 440fx does not include an IOAPIC, for example. There may be other optional components, or differences in wiring, that make two machines with i440fx not identical. The IOAPIC is basically the only other component and I view it as part of the CPU interface to the chipset. But it isn't. The IOAPIC is not per-core or per-socket. It's strictly board level. It's a board interface to the cpu. But still, if we're creating a machine from scratch: qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device ioapic,id=ioapic,chipset=sb -device cpu,ioapic=ioapic,northbridge=nb Is not all that unreasonable and presents a fully functioning PC. Sure. And -M blah is a shortcut. 4) model the CPUs as devices that take a pointer to a host controller, for x86, the normal case would be giving it a pointer to i440fx. Surely the connection is via a bus? An x86 cpu talks to the bus, and there happens to be an 440fx north bridge at the end of it. It could also be a Q35 or something else. I see being on a bus as really just taking a pointer to an interface. So yes, the i440fx would implement a PentiumCpuInterface or something like that and the CPU would take a pointer to a PentiumCpuInterface[1]. This is part of why having proper polymorphism is important. We need it in order to be able to express concepts like interfaces. The CPUs and northbridge are peers on the system bus. However, this isn't something good to model, since it keeps changing without any guest software impact. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/13/2011 09:56 AM, Avi Kivity wrote: On 02/13/2011 05:38 PM, Anthony Liguori wrote: 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. No, it's not. The 440fx does not include an IOAPIC, for example. There may be other optional components, or differences in wiring, that make two machines with i440fx not identical. The IOAPIC is basically the only other component and I view it as part of the CPU interface to the chipset. But it isn't. The IOAPIC is not per-core or per-socket. Yeah, I wasn't implying that it was. It's strictly board level. It's a board interface to the cpu. But still, if we're creating a machine from scratch: qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device ioapic,id=ioapic,chipset=sb -device cpu,ioapic=ioapic,northbridge=nb Is not all that unreasonable and presents a fully functioning PC. Sure. And -M blah is a shortcut. Exactly. Or better yet, blah is a config file that contains [device nb] driver=i440fx [device sb] driver=piix3 chipset=nb [device ioapic] driver=ioapic chipset=sb [device cpu] driver=cpu ioapic=ioapic northbridge=nb 4) model the CPUs as devices that take a pointer to a host controller, for x86, the normal case would be giving it a pointer to i440fx. Surely the connection is via a bus? An x86 cpu talks to the bus, and there happens to be an 440fx north bridge at the end of it. It could also be a Q35 or something else. I see being on a bus as really just taking a pointer to an interface. So yes, the i440fx would implement a PentiumCpuInterface or something like that and the CPU would take a pointer to a PentiumCpuInterface[1]. This is part of why having proper polymorphism is important. We need it in order to be able to express concepts like interfaces. The CPUs and northbridge are peers on the system bus. However, this isn't something good to model, since it keeps changing without any guest software impact. If we can move away from Bus abstraction and to a simpler interface mechanism, then we can express peer relationships by just having bidirection references. IOW: -device cpus,northbridge=nb,id=cpus,count=16 -device i440fx,cpus=cpus I don't think modelling each CPU makes sense. We should probably just model all cpus in a single device for the sake of simplicity. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Sun, Feb 13, 2011 at 10:56:30AM -0600, Anthony Liguori wrote: qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device ioapic,id=ioapic,chipset=sb -device cpu,ioapic=ioapic,northbridge=nb Is not all that unreasonable and presents a fully functioning PC. Sure. And -M blah is a shortcut. Exactly. Or better yet, blah is a config file that contains [device nb] driver=i440fx You are trying to model how particular (very ancient) HW looked like, instead of emulating guest visible functionality, but is dead end since things are changing constantly. Northbridge functionality moves onto cpu for instance. What CPU i440fx was designed for? Pentium? What if user runs QEMU with emulated CPU that in real life has internal memory controller? Does you config have sense for such setup? Should we allow to specify only Pentium CPU since this is how real HW worked? [device sb] driver=piix3 And piix3 refers to piix3.cfg which describe devices that present on the chipset. chipset=nb [device ioapic] driver=ioapic chipset=sb Here, for instance, IOAPIC is included in a chipset for a long time now. Why user should care that piix3 didn't have it. How this detail changes qemu functionality? If it doesn't why should we expose it? [device cpu] driver=cpu ioapic=ioapic Why ioapic here? Doesn't cpu talks to ioapic via northbridge? northbridge=nb -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguori anth...@codemonkey.ws wrote: On 02/11/2011 12:14 PM, Blue Swirl wrote: On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguorianth...@codemonkey.ws wrote: On 02/10/2011 03:20 PM, Gleb Natapov wrote: Jugging by how well all previous conversion went we will end up with one more way of creating devices. One legacy, another qdev and your new one. And what is the problem with qdev again (not that I am a big qdev fan)? We've really been arguing about probably the most minor aspect of the problem with qdev. All I'm really saying is that we shouldn't tie device construction to a factory interface as we do with qdev. That simply means that we should be able to do: RTC *rtc_create(arg1, arg2, arg2); I don't see how that would help at all. Throwing qdev away and just calling various functions directly, with all states exposed would be like QEMU 0.9.0. qdev doesn't expose any state today. qdev properties are construction-only properties that happen to be stored in each device state. What we really need is a full property framework that includes properties with hookable getters and setters along with the ability to mark properties as construct-only, read-only, or read-write. But I think it's reasonable to expose construct-only properties as just an initfn argument. Sounds OK. About read-write properties, what happens if we one day have extensive threading, and locks are pushed to device level? I can imagine a deadlock involving one thread running in IO thread for a device and another trying to access that device's properties. Maybe that is not different from function call version. And that a separate piece of code decides which devices are exposed through -device or device_add. Which devices are exposed is really a minor detail. That said, qdev has a number of significant limitations in my mind. The first is that the only relationship between devices is through the BusState interface. There's also qemu_irq for arbitrary signals. Yes, but qemu_irq is very restricted as it only models a signal bit of information and doesn't really have a mechanism to attach/detach in any generic way. Basic signals are already very useful for many purposes, since they match digital logic signals in real HW. In theory, whole machines could be constructed with just qemu_irq and NAND gate emulator. ;-) In the message passing IRQ discussion earlier, it was IIRC decided that the one bit version would not be changed but a separate message passing version would be created if ever needed. I don't think we should even try to have a generic bus model. When you look at how badly broken PCI hotplug is current in qdev, I think this is symptomatic of this. And how should this be fixed? The API change would not help. Just as we have bus level creation functions, we should have bus level hotplug interfaces. There's also no way in qdev to really have polymorphism. Interfaces really aren't meaningful in qdev so you have things like PCIDevice where some methods are stored in the object instead of the class dispatch table and you have overuse of static class members. QEMU is developed in C, not C++. But we're trying to do object oriented programming in C so as long as we're doing that, we ought to do it right. And it's all unrelated to VMState. Right, but this has also the good side that not all device state is automatically exported. If other devices would be allowed to muck with a devices internal state freely, bad things could happen. Device reset could also use standard register definitions, shared with VMState. There's a way to have formally verifiable serialization/deserialization if we can satisfy two conditions 1) the devices rely on no global state (i.e. static variables) and 2) every field asssociated with a device is marshalled during serialization/deserialization. When we define a device, right now we say that certain state is writable during construction. It's not a stretch to want to have some properties writable during runtime. If we also had a mechanism to mark certain properties as read-only, but still were able to introspect them, we could implement serialization without having to have a second VMState definition. Compatibility will always require manipulating state, but once you have the state stored in a data structure, you can describe those transformations in a pretty high level fashion. And this is just the basic mechanisms of qdev. The actual implementation is worse. The use of qemu_irq as gpio in the base class and overuse of SystemBus is really quite insane. Maybe qemu_irq should be renamed to QEMUSignal (and I don't like typedeffing pointers), otherwise it looks quite sane to me. Any interfaces of a base class should make sense even for derived classes. That means if the base class is going to expose essentially a pin-out interface, that if I have a
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/13/2011 12:08 PM, Gleb Natapov wrote: On Sun, Feb 13, 2011 at 10:56:30AM -0600, Anthony Liguori wrote: qemu -device i440fx,id=nb -device piix3,id=sb,chipset=nb -device ioapic,id=ioapic,chipset=sb -device cpu,ioapic=ioapic,northbridge=nb Is not all that unreasonable and presents a fully functioning PC. Sure. And -M blah is a shortcut. Exactly. Or better yet, blah is a config file that contains [device nb] driver=i440fx You are trying to model how particular (very ancient) HW looked like, instead of emulating guest visible functionality, but is dead end since things are changing constantly. Northbridge functionality moves onto cpu for instance. What CPU i440fx was designed for? Pentium? What if user runs QEMU with emulated CPU that in real life has internal memory controller? Does you config have sense for such setup? Should we allow to specify only Pentium CPU since this is how real HW worked? Yes, how we structure the device tree will change over time. If users have to specify this stuff, we've already failed to start with. The i440fx is definitely guest visible. And yes, a guest could look at freak out that an i440fx is in use with a non-Pentium class CPU. We cheat here, and it works just fine. [device sb] driver=piix3 And piix3 refers to piix3.cfg which describe devices that present on the chipset. I disagree in this case that it's the best thing to do, but in general, yeah, we should provide a mechanism to have essentially device tree macros such that one high level device represents a larger tree of devices. This would be a good mechanism to support the concept of machines. But I don't think we should rely on having this tomorrow as doing this well is going to be challenging. chipset=nb [device ioapic] driver=ioapic chipset=sb Here, for instance, IOAPIC is included in a chipset for a long time now. Why user should care that piix3 didn't have it. How this detail changes qemu functionality? If it doesn't why should we expose it? Yeah, I'd be inclined to push the ioapic into the chipset here except it may be useful to have multiple ioapics at some point down the road. Yes, we're exposing gory details of the device model. No, I don't have a problem with that. [device cpu] driver=cpu ioapic=ioapic Why ioapic here? Doesn't cpu talks to ioapic via northbridge? The i440fx is the northbridge. For the i440fx, the I/O apic is a separate chip. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/13/2011 01:37 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguorianth...@codemonkey.ws wrote:
qdev doesn't expose any state today. qdev properties are construction-only
properties that happen to be stored in each device state.
What we really need is a full property framework that includes properties
with hookable getters and setters along with the ability to mark properties
as construct-only, read-only, or read-write.
But I think it's reasonable to expose construct-only properties as just an
initfn argument.
Sounds OK. About read-write properties, what happens if we one day
have extensive threading, and locks are pushed to device level? I can
imagine a deadlock involving one thread running in IO thread for a
device and another trying to access that device's properties. Maybe
that is not different from function call version.
You need hookable setters/getters that can acquire a lock and do the
right thing. It shouldn't be able to dead lock if the locking is
designed right.
Yes, but qemu_irq is very restricted as it only models a signal bit of
information and doesn't really have a mechanism to attach/detach in any
generic way.
Basic signals are already very useful for many purposes, since they
match digital logic signals in real HW. In theory, whole machines
could be constructed with just qemu_irq and NAND gate emulator. ;-)
It's not just in theory. In the C++ port of QEMU that I wrote, I
implemented an AND, OR, and XOR gate and implemented a full 32-bit adder
by just using a device config file.
If done correctly, using referencing can be extremely powerful. A full
adder is a good example. The gates really don't have any concept of bus
and the relationship between gates is definitely not a tree.
In the message passing IRQ discussion earlier, it was IIRC decided
that the one bit version would not be changed but a separate message
passing version would be created if ever needed.
C already has a message passing interface that supports type safety
called function pointers :-)
An object that implements multiple interfaces where the interface
becomes the message passing interface is exactly what I've been saying
we need. It's flexible and the compiler helps us enforce typing.
Any interfaces of a base class should make sense even for derived classes.
That means if the base class is going to expose essentially a pin-out
interface, that if I have a PCIDevice and cast it to Device, I should be
able to interact with the GPIO interface to interact with the PCI device.
Presumably, that means interfacing at the PCI signalling level. That's
insane to model in QEMU :-)
This would be doable, if we built buses from a bunch of signals, like
in VHDL or Verilog. It would simplify aliased MMIO addresses nicely,
the undecoded address pins would be ignored. I don't think it would be
useful, but a separate interface could be added for connecting to
PCIBus with just qemu_irqs.
Yeah, it's possible, but I don't want to spend my time doing this.
In reality, GPIO only makes sense for a small class of simple devices where
modelling the pin-out interface makes sense (like a 7-segment LCD). That
suggests that GPIO should not be in the DeviceState interface but instead
should be in a SimpleDevice subclass or something like that.
Could you point to examples of SystemBus overuse?
anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
73
anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
56
SystemBus has become a catch-all for shallow qdev conversions. We've got
Northbridges, RAM, and network devices sitting on the same bus...
On Sparc32 I have not bothered to create a SBus bus. Now it would be
useful to get bootindex corrected. Most devices (even on-board IO)
should use SBus.
The only other bus (MBus) would exist between CPU, IOMMU and memory.
But SysBus fitted the need until recently.
A good way to judge where a device is using a bus interface correct:
does all of it's interactions with any other part of the guest state
involve method calls to the bus?
Right now, the answer is no for just about every device in QEMU. This
is the problem that qdev really was meant to solve and we're not really
any further along solving it unfortunately.
I'm not arguing against a generic factory interface, I'm arguing that it
should be separate.
IOW:
SerialState *serial_create(int iobase, int irq, ...);
static DeviceState *qdev_serial_create(QemuOpts *opts);
static void serial_init(void)
{
qdev_register(serial, qdev_serial_create);
}
The key point is that when we create devices internally, we should have a
C-friendly, type-safe interface to interact with. This will encourage
composition and a richer device model than what we have today.
Isn't this what we have now in most cases?
No. The common pattern of shallow conversion is:
struct SerialState
{
// device
Re: [Qemu-devel] KVM call minutes for Feb 8
On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/13/2011 01:37 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
qdev doesn't expose any state today. qdev properties are
construction-only
properties that happen to be stored in each device state.
What we really need is a full property framework that includes properties
with hookable getters and setters along with the ability to mark
properties
as construct-only, read-only, or read-write.
But I think it's reasonable to expose construct-only properties as just
an
initfn argument.
Sounds OK. About read-write properties, what happens if we one day
have extensive threading, and locks are pushed to device level? I can
imagine a deadlock involving one thread running in IO thread for a
device and another trying to access that device's properties. Maybe
that is not different from function call version.
You need hookable setters/getters that can acquire a lock and do the right
thing. It shouldn't be able to dead lock if the locking is designed right.
Yes, but qemu_irq is very restricted as it only models a signal bit of
information and doesn't really have a mechanism to attach/detach in any
generic way.
Basic signals are already very useful for many purposes, since they
match digital logic signals in real HW. In theory, whole machines
could be constructed with just qemu_irq and NAND gate emulator. ;-)
It's not just in theory. In the C++ port of QEMU that I wrote, I
implemented an AND, OR, and XOR gate and implemented a full 32-bit adder by
just using a device config file.
If done correctly, using referencing can be extremely powerful. A full
adder is a good example. The gates really don't have any concept of bus and
the relationship between gates is definitely not a tree.
In the message passing IRQ discussion earlier, it was IIRC decided
that the one bit version would not be changed but a separate message
passing version would be created if ever needed.
C already has a message passing interface that supports type safety called
function pointers :-)
An object that implements multiple interfaces where the interface becomes
the message passing interface is exactly what I've been saying we need.
It's flexible and the compiler helps us enforce typing.
Any interfaces of a base class should make sense even for derived
classes.
That means if the base class is going to expose essentially a pin-out
interface, that if I have a PCIDevice and cast it to Device, I should be
able to interact with the GPIO interface to interact with the PCI device.
Presumably, that means interfacing at the PCI signalling level. That's
insane to model in QEMU :-)
This would be doable, if we built buses from a bunch of signals, like
in VHDL or Verilog. It would simplify aliased MMIO addresses nicely,
the undecoded address pins would be ignored. I don't think it would be
useful, but a separate interface could be added for connecting to
PCIBus with just qemu_irqs.
Yeah, it's possible, but I don't want to spend my time doing this.
In reality, GPIO only makes sense for a small class of simple devices
where
modelling the pin-out interface makes sense (like a 7-segment LCD). That
suggests that GPIO should not be in the DeviceState interface but instead
should be in a SimpleDevice subclass or something like that.
Could you point to examples of SystemBus overuse?
anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
73
anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
56
SystemBus has become a catch-all for shallow qdev conversions. We've got
Northbridges, RAM, and network devices sitting on the same bus...
On Sparc32 I have not bothered to create a SBus bus. Now it would be
useful to get bootindex corrected. Most devices (even on-board IO)
should use SBus.
The only other bus (MBus) would exist between CPU, IOMMU and memory.
But SysBus fitted the need until recently.
A good way to judge where a device is using a bus interface correct: does
all of it's interactions with any other part of the guest state involve
method calls to the bus?
Right now, the answer is no for just about every device in QEMU. This is
the problem that qdev really was meant to solve and we're not really any
further along solving it unfortunately.
I'm not arguing against a generic factory interface, I'm arguing that it
should be separate.
IOW:
SerialState *serial_create(int iobase, int irq, ...);
static DeviceState *qdev_serial_create(QemuOpts *opts);
static void serial_init(void)
{
qdev_register(serial, qdev_serial_create);
}
The key point is that when we create devices internally, we should have a
C-friendly, type-safe interface to interact with. This will encourage
composition and a richer device model than what we have today.
Isn't this what we have now in most cases?
No. The
Re: [Qemu-devel] KVM call minutes for Feb 8
On 13 February 2011 16:56, Anthony Liguori anth...@codemonkey.ws wrote: If we can move away from Bus abstraction and to a simpler interface mechanism, then we can express peer relationships by just having bidirection references. IOW: -device cpus,northbridge=nb,id=cpus,count=16 -device i440fx,cpus=cpus I don't think modelling each CPU makes sense. We should probably just model all cpus in a single device for the sake of simplicity. How would this work for systems with multiple CPUs which have different views of the world? (ie their memory maps differ so that eg some RAM is shared between them but some parts of the address space are different RAM for the two cores, some devices one core only, some devices shared between cores but the device can tell which core made an IO request) With a bus-style abstraction this is straightforward: each core has its own bus which is what defines its view of the world, some devices and RAM are wired up to both buses. I'm not sure how the bidirectional reference model would look for this? (Real world examples would be if we ever had any need to actually model any of the auxiliary cores in say an OMAP device, or the M3 in a versatile-express. Yes, most systems won't look that odd but it does come up, especially in testbench type designs, and our interface abstraction should be able to handle it.) -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/13/2011 03:00 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 9:57 PM, Anthony Liguorianth...@codemonkey.ws wrote:
On 02/13/2011 01:37 PM, Blue Swirl wrote:
On Sun, Feb 13, 2011 at 5:31 PM, Anthony Liguorianth...@codemonkey.ws
wrote:
qdev doesn't expose any state today. qdev properties are
construction-only
properties that happen to be stored in each device state.
What we really need is a full property framework that includes properties
with hookable getters and setters along with the ability to mark
properties
as construct-only, read-only, or read-write.
But I think it's reasonable to expose construct-only properties as just
an
initfn argument.
Sounds OK. About read-write properties, what happens if we one day
have extensive threading, and locks are pushed to device level? I can
imagine a deadlock involving one thread running in IO thread for a
device and another trying to access that device's properties. Maybe
that is not different from function call version.
You need hookable setters/getters that can acquire a lock and do the right
thing. It shouldn't be able to dead lock if the locking is designed right.
Yes, but qemu_irq is very restricted as it only models a signal bit of
information and doesn't really have a mechanism to attach/detach in any
generic way.
Basic signals are already very useful for many purposes, since they
match digital logic signals in real HW. In theory, whole machines
could be constructed with just qemu_irq and NAND gate emulator. ;-)
It's not just in theory. In the C++ port of QEMU that I wrote, I
implemented an AND, OR, and XOR gate and implemented a full 32-bit adder by
just using a device config file.
If done correctly, using referencing can be extremely powerful. A full
adder is a good example. The gates really don't have any concept of bus and
the relationship between gates is definitely not a tree.
In the message passing IRQ discussion earlier, it was IIRC decided
that the one bit version would not be changed but a separate message
passing version would be created if ever needed.
C already has a message passing interface that supports type safety called
function pointers :-)
An object that implements multiple interfaces where the interface becomes
the message passing interface is exactly what I've been saying we need.
It's flexible and the compiler helps us enforce typing.
Any interfaces of a base class should make sense even for derived
classes.
That means if the base class is going to expose essentially a pin-out
interface, that if I have a PCIDevice and cast it to Device, I should be
able to interact with the GPIO interface to interact with the PCI device.
Presumably, that means interfacing at the PCI signalling level. That's
insane to model in QEMU :-)
This would be doable, if we built buses from a bunch of signals, like
in VHDL or Verilog. It would simplify aliased MMIO addresses nicely,
the undecoded address pins would be ignored. I don't think it would be
useful, but a separate interface could be added for connecting to
PCIBus with just qemu_irqs.
Yeah, it's possible, but I don't want to spend my time doing this.
In reality, GPIO only makes sense for a small class of simple devices
where
modelling the pin-out interface makes sense (like a 7-segment LCD). That
suggests that GPIO should not be in the DeviceState interface but instead
should be in a SimpleDevice subclass or something like that.
Could you point to examples of SystemBus overuse?
anthony@titi:~/git/qemu/hw$ grep qdev_create *.c | wc -l
73
anthony@titi:~/git/qemu/hw$ grep 'qdev_create(NULL' *.c | wc -l
56
SystemBus has become a catch-all for shallow qdev conversions. We've got
Northbridges, RAM, and network devices sitting on the same bus...
On Sparc32 I have not bothered to create a SBus bus. Now it would be
useful to get bootindex corrected. Most devices (even on-board IO)
should use SBus.
The only other bus (MBus) would exist between CPU, IOMMU and memory.
But SysBus fitted the need until recently.
A good way to judge where a device is using a bus interface correct: does
all of it's interactions with any other part of the guest state involve
method calls to the bus?
Right now, the answer is no for just about every device in QEMU. This is
the problem that qdev really was meant to solve and we're not really any
further along solving it unfortunately.
I'm not arguing against a generic factory interface, I'm arguing that it
should be separate.
IOW:
SerialState *serial_create(int iobase, int irq, ...);
static DeviceState *qdev_serial_create(QemuOpts *opts);
static void serial_init(void)
{
qdev_register(serial, qdev_serial_create);
}
The key point is that when we create devices internally, we should have a
C-friendly, type-safe interface to interact with. This will encourage
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/13/2011 03:24 PM, Peter Maydell wrote: On 13 February 2011 16:56, Anthony Liguorianth...@codemonkey.ws wrote: If we can move away from Bus abstraction and to a simpler interface mechanism, then we can express peer relationships by just having bidirection references. IOW: -device cpus,northbridge=nb,id=cpus,count=16 -device i440fx,cpus=cpus I don't think modelling each CPU makes sense. We should probably just model all cpus in a single device for the sake of simplicity. How would this work for systems with multiple CPUs which have different views of the world? (ie their memory maps differ so that eg some RAM is shared between them but some parts of the address space are different RAM for the two cores, some devices one core only, some devices shared between cores but the device can tell which core made an IO request) With a bus-style abstraction this is straightforward: each core has its own bus which is what defines its view of the world, some devices and RAM are wired up to both buses. I'm not sure how the bidirectional reference model would look for this? Each core has it's own northbridge. You would do: -device arm-cpu,northbridge=nb1 -device dsp,northbridge=nb2 Or whatever. Regards, Anthony Liguori (Real world examples would be if we ever had any need to actually model any of the auxiliary cores in say an OMAP device, or the M3 in a versatile-express. Yes, most systems won't look that odd but it does come up, especially in testbench type designs, and our interface abstraction should be able to handle it.) -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 13 February 2011 22:43, Anthony Liguori anth...@codemonkey.ws wrote: On 02/13/2011 03:24 PM, Peter Maydell wrote: How would this work for systems with multiple CPUs which have different views of the world? (ie their memory maps differ so that eg some RAM is shared between them but some parts of the address space are different RAM for the two cores, some devices one core only, some devices shared between cores but the device can tell which core made an IO request) With a bus-style abstraction this is straightforward: each core has its own bus which is what defines its view of the world, some devices and RAM are wired up to both buses. I'm not sure how the bidirectional reference model would look for this? Each core has it's own northbridge. You would do: -device arm-cpu,northbridge=nb1 -device dsp,northbridge=nb2 I'm afraid I don't really understand what you mean here. Northbridge as I understand it is a very PC-architecture specific term; can you explain a bit more about what would actually be going on here? (ie what are the various components in this kind of system model and what are they doing?) -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, Feb 10, 2011 at 9:47 AM, Anthony Liguori anth...@codemonkey.ws wrote: On 02/09/2011 09:15 PM, Blue Swirl wrote: On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguorianth...@codemonkey.ws wrote: On 02/09/2011 06:48 PM, Blue Swirl wrote: ISASerialState dev; isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL); Do you mean that there should be a generic way of doing that, like sysbus_create_varargs() for qdev, or just add inline functions which hide qdev property setup? I still think that FDT should be used in the future. That would require that the properties can be set up mechanically, and I don't see how your proposal would help that. Yeah, I don't think that is a good idea anymore. I think this is part of why we're having so many problems with qdev. While (most?) hardware hierarchies can be represented by device tree syntax, not all valid device trees correspond to interface and/or useful hardware hierarchies. User creates a non-working machine and so gets to fix the problems? How is that a problem for us? It's not about creating a non-working machine. It's about what user-level abstraction we need to provide. It's a whole lot easier to implement an i440fx device with a fixed set of parameters than it is to make every possible subdevice have a proper factory interface along with mechanisms to hook everything together. Basically, we're making things much harder for ourselves than we should. We want to have an interface to create large chunks of hardware (like an i440fx) which then results in a significant portion of a device tree. But how would this affect interface to devices? I don't see how that would be any different with current model and the function call model. If all composition is done through a factory interface, it doesn't. But my main argument here is that we shouldn't try to make all composition done through a factory interface--only where it makes sense. So very concretely, I'm suggesting we do the following to target-i386: 1) make the i440fx device have an embedded ide controller, piix3, and usb controller that get initialized automatically. The piix3 embeds the PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial, etc.). This makes sense. 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. This doesn't make so much sense. There's still memory and the PCI devices plugged to PCI bus created by i440fx. The various drives need to be connected IDE channels, chardevs to serial ports etc., the devices can't claim them in order of creation. The connections must be managed at board level. But I don't disagree completely, some time ago I proposed that machines should be qdevified and also some of host functions. 3) just use the existing -device infrastructure to support all of this. A very simple device config corresponds to a very complex device tree but that's the desired effect. This depends on the above. 4) model the CPUs as devices that take a pointer to a host controller, for x86, the normal case would be giving it a pointer to i440fx. For more precision, each CPUs should connect to its cache controller, which should connect to local APIC, that to global bus for IOAPIC, that to northbridge, which connects to both memory and southbridge. Anyway, all of the above points 1 to 4 are orthogonal to qdev and its API, they can be done either way. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, Feb 10, 2011 at 6:05 PM, Anthony Liguori anth...@codemonkey.ws wrote: On 02/10/2011 03:20 PM, Gleb Natapov wrote: Jugging by how well all previous conversion went we will end up with one more way of creating devices. One legacy, another qdev and your new one. And what is the problem with qdev again (not that I am a big qdev fan)? We've really been arguing about probably the most minor aspect of the problem with qdev. All I'm really saying is that we shouldn't tie device construction to a factory interface as we do with qdev. That simply means that we should be able to do: RTC *rtc_create(arg1, arg2, arg2); I don't see how that would help at all. Throwing qdev away and just calling various functions directly, with all states exposed would be like QEMU 0.9.0. And that a separate piece of code decides which devices are exposed through -device or device_add. Which devices are exposed is really a minor detail. That said, qdev has a number of significant limitations in my mind. The first is that the only relationship between devices is through the BusState interface. There's also qemu_irq for arbitrary signals. I don't think we should even try to have a generic bus model. When you look at how badly broken PCI hotplug is current in qdev, I think this is symptomatic of this. And how should this be fixed? The API change would not help. There's also no way in qdev to really have polymorphism. Interfaces really aren't meaningful in qdev so you have things like PCIDevice where some methods are stored in the object instead of the class dispatch table and you have overuse of static class members. QEMU is developed in C, not C++. And it's all unrelated to VMState. Right, but this has also the good side that not all device state is automatically exported. If other devices would be allowed to muck with a devices internal state freely, bad things could happen. Device reset could also use standard register definitions, shared with VMState. And this is just the basic mechanisms of qdev. The actual implementation is worse. The use of qemu_irq as gpio in the base class and overuse of SystemBus is really quite insane. Maybe qemu_irq should be renamed to QEMUSignal (and I don't like typedeffing pointers), otherwise it looks quite sane to me. Could you point to examples of SystemBus overuse? And so far, the use of qdev has been entirely superficial. Devices still don't make use of bus level interfaces to do I/O so we don't have any better componentization than we did before qdev. The fact that there is no enough interest to convert all devices to it? I don't think there is any device that has been improved by qdev. -device is a nice feature, but it could have been implemented without qdev. We have 'info qtree' which can't be implemented easily without a generic device class. Avi (or who was it) sent patches to expose even more device state. With the patches I'm going to apply, if Redhat wants to disable building various devices, it can be done without #ifdeffery. This is not possible without a generic factory interface. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 10 February 2011 07:47, Anthony Liguori anth...@codemonkey.ws wrote: So very concretely, I'm suggesting we do the following to target-i386: 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. Does that make any sense for anything other than target-i386? The concept of a machine model seems a pretty obvious one for ARM boards, for instance, and I'm not sure we'd gain much by having i386 be different to the other architectures... -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/10/2011 09:16 AM, Peter Maydell wrote: On 10 February 2011 07:47, Anthony Liguorianth...@codemonkey.ws wrote: So very concretely, I'm suggesting we do the following to target-i386: 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. Does that make any sense for anything other than target-i386? The concept of a machine model seems a pretty obvious one for ARM boards, for instance, and I'm not sure we'd gain much by having i386 be different to the other architectures... Yes, it makes a lot of sense, I just don't know the component names as well so bear with me :-) There are two types of Versatile machines today, Versatile/AB and Versatile/PB. They are both made with the same core, ARM926EJ-S, with different expansions. So you would model arm926ej-s as the chipset and then build up the machines by modifying parameters of the chipset (like the board id) and/or adding different components on top of it. A good way to think about what I'm proposing is that machine-init really should be a constructor for a device object. Regards, Anthony Liguori -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, Feb 10, 2011 at 08:47:12AM +0100, Anthony Liguori wrote: On 02/09/2011 09:15 PM, Blue Swirl wrote: On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguorianth...@codemonkey.ws wrote: On 02/09/2011 06:48 PM, Blue Swirl wrote: ISASerialState dev; isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL); Do you mean that there should be a generic way of doing that, like sysbus_create_varargs() for qdev, or just add inline functions which hide qdev property setup? I still think that FDT should be used in the future. That would require that the properties can be set up mechanically, and I don't see how your proposal would help that. Yeah, I don't think that is a good idea anymore. I think this is part of why we're having so many problems with qdev. While (most?) hardware hierarchies can be represented by device tree syntax, not all valid device trees correspond to interface and/or useful hardware hierarchies. User creates a non-working machine and so gets to fix the problems? How is that a problem for us? It's not about creating a non-working machine. It's about what user-level abstraction we need to provide. It's a whole lot easier to implement an i440fx device with a fixed set of parameters than it is to make every possible subdevice have a proper factory interface along with mechanisms to hook everything together. So what if it is easier, it doesn't mean it is correct thing to do. What you are proposing is just a huge step backwards. May be we shouldn't support hooking everything together in completely arbitrary ways, but we shouldn't force isa/pci devices upon our users just because they are non-removable on real chip. Basically, we're making things much harder for ourselves than we should. We want to have an interface to create large chunks of hardware (like an i440fx) which then results in a significant portion of a device tree. But how would this affect interface to devices? I don't see how that would be any different with current model and the function call model. If all composition is done through a factory interface, it doesn't. But my main argument here is that we shouldn't try to make all composition done through a factory interface--only where it makes sense. So very concretely, I'm suggesting we do the following to target-i386: 1) make the i440fx device have an embedded ide controller, piix3, and usb controller that get initialized automatically. The piix3 embeds the PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial, etc.). This may be a problem even from security point of view. What if usb code (ide, serial, parallel) has guest exploitable bug? Currently I can happily continue running guests if they do not need affected subsystem. If we'll get it your way I will no longer be able to do so. 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. 3) just use the existing -device infrastructure to support all of this. A very simple device config corresponds to a very complex device tree but that's the desired effect. 4) model the CPUs as devices that take a pointer to a host controller, for x86, the normal case would be giving it a pointer to i440fx. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/10/2011 10:07 AM, Gleb Natapov wrote: So what if it is easier, it doesn't mean it is correct thing to do. If we spend the next 10 years trying to do the correct thing for some arbitrary definition of correct, that's not terribly useful. It's really simple actually. Let's do the least clever thing and model how hardware actual works. Once we have that, we can try to be better than real hardware (if it's possible). If all composition is done through a factory interface, it doesn't. But my main argument here is that we shouldn't try to make all composition done through a factory interface--only where it makes sense. So very concretely, I'm suggesting we do the following to target-i386: 1) make the i440fx device have an embedded ide controller, piix3, and usb controller that get initialized automatically. The piix3 embeds the PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial, etc.). This may be a problem even from security point of view. What if usb code (ide, serial, parallel) has guest exploitable bug? Currently I can happily continue running guests if they do not need affected subsystem. If we'll get it your way I will no longer be able to do so. qemu -device i440fx,ide=off If you really care to do this. But this desire to remove devices is silly IMHO. Concerns about security are misplaced. If you have to change the way a guest is invoked in order to eliminate security problems, then there's something seriously wrong. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote: On 02/10/2011 10:07 AM, Gleb Natapov wrote: So what if it is easier, it doesn't mean it is correct thing to do. If we spend the next 10 years trying to do the correct thing for some arbitrary definition of correct, that's not terribly useful. Changing direction by 180 every 2 years even less useful. It's really simple actually. Let's do the least clever thing and model how hardware actual works. Once we have that, we can try to be better than real hardware (if it's possible). I think out understanding on how HW actually works is very different. You are placing to much value on were device resides physically, for me it is completely unimportant detail. Not worth even mentioning. If all composition is done through a factory interface, it doesn't. But my main argument here is that we shouldn't try to make all composition done through a factory interface--only where it makes sense. So very concretely, I'm suggesting we do the following to target-i386: 1) make the i440fx device have an embedded ide controller, piix3, and usb controller that get initialized automatically. The piix3 embeds the PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial, etc.). This may be a problem even from security point of view. What if usb code (ide, serial, parallel) has guest exploitable bug? Currently I can happily continue running guests if they do not need affected subsystem. If we'll get it your way I will no longer be able to do so. qemu -device i440fx,ide=off So you still need to support arbitrary composition. What's the difference? So why do you like -device i440fx over what we have now? In current speak you propose will be implement by using i440fx machine type. Qdev will build it for you. If you really care to do this. But this desire to remove devices is silly IMHO. Concerns about security are misplaced. If you have to change the way a guest is invoked in order to eliminate security problems, then there's something seriously wrong. No I do not. I do not create guest with unneeded devices from the beginning. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/10/2011 10:04 AM, Peter Maydell wrote: On 10 February 2011 08:36, Anthony Liguorianth...@codemonkey.ws wrote: On 02/10/2011 09:16 AM, Peter Maydell wrote: On 10 February 2011 07:47, Anthony Liguorianth...@codemonkey.wswrote: 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. Does that make any sense for anything other than target-i386? The concept of a machine model seems a pretty obvious one for ARM boards, for instance, and I'm not sure we'd gain much by having i386 be different to the other architectures... Yes, it makes a lot of sense, I just don't know the component names as well so bear with me :-) There are two types of Versatile machines today, Versatile/AB and Versatile/PB. They are both made with the same core, ARM926EJ-S, with different expansions. So you would model arm926ej-s as the chipset and then build up the machines by modifying parameters of the chipset (like the board id) and/or adding different components on top of it. Er, ARM926 is the CPU, it's not a chipset. The board ID is definitely not a property of an ARM926, it's a property of the board (clue is in the name :-)). I don't think versatile boards have a chipset really... As I said, I'm not well versed in the component names in ARM. But that said, an actual processor doesn't connect directly to a bunch of devices. It almost always go through some chipset and that chipset implements a lot of functionality typically. I think the name of the component I'm trying to refer to PL300 which I believe is the Northbridge used for the Versatile boards. In my understanding the machine is the thing that says I need a 926, and an MMC controller at this address, and some UARTS, and... ie it is the thing that does the modifying parameters and adding different components. So if we'd still be doing that I don't see how we've got rid of the concept. I guess I'm missing the point somehow. A machine today is basically the northbridge, southbridge, plus a bunch of default components to make the virtual hardware useful. I'm suggesting that we model a proper northbridge/southbridge. A good way to think about what I'm proposing is that machine-init really should be a constructor for a device object. If you mean that you want machines to be implemented under the hood as a single huge device you can only have one of that spans the entire memory map, well I guess that's an implementation detail. But conceptually machines really do exist, and we definitely still want users to be able to say I want a beagle machine; I want a versatile; I want an n900. An n900 is a very specific hardware configuration that is best represented by some sort of configuration file vs. something hard coded in QEMU. The question is, what level of component modelling do we need to do in order to make it practical to create such configurations from a file. Regards, Anthony Liguori -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/10/2011 11:10 AM, Gleb Natapov wrote: On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote: On 02/10/2011 10:07 AM, Gleb Natapov wrote: So what if it is easier, it doesn't mean it is correct thing to do. If we spend the next 10 years trying to do the correct thing for some arbitrary definition of correct, that's not terribly useful. Changing direction by 180 every 2 years even less useful. If we think through what we are doing and have a coherent architecture before changing direction, then we won't have this problem. It's really simple actually. Let's do the least clever thing and model how hardware actual works. Once we have that, we can try to be better than real hardware (if it's possible). I think out understanding on how HW actually works is very different. You are placing to much value on were device resides physically, for me it is completely unimportant detail. Not worth even mentioning. No, I place value on how things are modelled in the real world. There simply aren't PC's out there that lack an RTC so I have no interest in jumping through hoops in QEMU to make it possible to do this without modifying QEMU code. It might sound nice to a developer but it's of absolutely no use to users. If all composition is done through a factory interface, it doesn't. But my main argument here is that we shouldn't try to make all composition done through a factory interface--only where it makes sense. So very concretely, I'm suggesting we do the following to target-i386: 1) make the i440fx device have an embedded ide controller, piix3, and usb controller that get initialized automatically. The piix3 embeds the PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial, etc.). This may be a problem even from security point of view. What if usb code (ide, serial, parallel) has guest exploitable bug? Currently I can happily continue running guests if they do not need affected subsystem. If we'll get it your way I will no longer be able to do so. qemu -device i440fx,ide=off So you still need to support arbitrary composition. What's the difference? No, we don't. It's possible to have an 'rtc=off' option but I'm tremendously opposed to doing this. Arbitrary composition is not a useful goal IMHO. So why do you like -device i440fx over what we have now? Because I don't think tools like libvirt should be doing device composition to create an i440fx-like chipset. I think the current path we're on is pushing too much logic that belongs in QEMU into the management stack. In current speak you propose will be implement by using i440fx machine type. Qdev will build it for you. If you had an i440fx machine type, that had no non-optional components added, and you could specify options to the machine type, yes. But I think you'll agree that there's no reason to not just treat the i440fx as a device. If you really care to do this. But this desire to remove devices is silly IMHO. Concerns about security are misplaced. If you have to change the way a guest is invoked in order to eliminate security problems, then there's something seriously wrong. No I do not. I do not create guest with unneeded devices from the beginning. There is very little that isn't 'unneeded'. Regards, Anthony Liguori -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/10/2011 11:07 AM, Gleb Natapov wrote: On Thu, Feb 10, 2011 at 08:47:12AM +0100, Anthony Liguori wrote: On 02/09/2011 09:15 PM, Blue Swirl wrote: On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguorianth...@codemonkey.ws wrote: On 02/09/2011 06:48 PM, Blue Swirl wrote: ISASerialState dev; isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL); Do you mean that there should be a generic way of doing that, like sysbus_create_varargs() for qdev, or just add inline functions which hide qdev property setup? I still think that FDT should be used in the future. That would require that the properties can be set up mechanically, and I don't see how your proposal would help that. Yeah, I don't think that is a good idea anymore. I think this is part of why we're having so many problems with qdev. While (most?) hardware hierarchies can be represented by device tree syntax, not all valid device trees correspond to interface and/or useful hardware hierarchies. User creates a non-working machine and so gets to fix the problems? How is that a problem for us? It's not about creating a non-working machine. It's about what user-level abstraction we need to provide. It's a whole lot easier to implement an i440fx device with a fixed set of parameters than it is to make every possible subdevice have a proper factory interface along with mechanisms to hook everything together. So what if it is easier, it doesn't mean it is correct thing to do. What you are proposing is just a huge step backwards. May be we shouldn't support hooking everything together in completely arbitrary ways, but we shouldn't force isa/pci devices upon our users just because they are non-removable on real chip. I disagree. We don't want to deviate from the spec any more than we already do. The reason for wanting flexibility is because the code for the PIC or RTC, for example, can be used in other Super-IO chipsets or even standalone. If qemu only supported the 440FX chipset, we'd have no reason to make things flexible. So very concretely, I'm suggesting we do the following to target-i386: 1) make the i440fx device have an embedded ide controller, piix3, and usb controller that get initialized automatically. The piix3 embeds the PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial, etc.). This may be a problem even from security point of view. What if usb code (ide, serial, parallel) has guest exploitable bug? Currently I can happily continue running guests if they do not need affected subsystem. If we'll get it your way I will no longer be able to do so. You can't just remove a device from a guest. You have to shut it down. When you power it back up, you may end up with different IRQ assignments or expose some guest bug. If you have a security issue in code that is exposed to the guest, you have to fix it. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/10/2011 09:47 AM, Anthony Liguori wrote: So very concretely, I'm suggesting we do the following to target-i386: 1) make the i440fx device have an embedded ide controller, piix3, and usb controller that get initialized automatically. The piix3 embeds the PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial, etc.). This I like. 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. No, it's not. The 440fx does not include an IOAPIC, for example. There may be other optional components, or differences in wiring, that make two machines with i440fx not identical. 4) model the CPUs as devices that take a pointer to a host controller, for x86, the normal case would be giving it a pointer to i440fx. Surely the connection is via a bus? An x86 cpu talks to the bus, and there happens to be an 440fx north bridge at the end of it. It could also be a Q35 or something else. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 10 February 2011 10:13, Anthony Liguori anth...@codemonkey.ws wrote: On 02/10/2011 10:04 AM, Peter Maydell wrote: On 10 February 2011 08:36, Anthony Liguorianth...@codemonkey.ws wrote: So you would model arm926ej-s as the chipset and then build up the machines by modifying parameters of the chipset (like the board id) and/or adding different components on top of it. Er, ARM926 is the CPU, it's not a chipset. The board ID is definitely not a property of an ARM926, it's a property of the board (clue is in the name :-)). I don't think versatile boards have a chipset really... As I said, I'm not well versed in the component names in ARM. But that said, an actual processor doesn't connect directly to a bunch of devices. It almost always go through some chipset and that chipset implements a lot of functionality typically. I think the name of the component I'm trying to refer to PL300 which I believe is the Northbridge used for the Versatile boards. PL300 is just a bus interconnect (so you can connect multiple AXI bus masters (cores) to multiple AXI bus slaves (devices)). Versatile PB doesn't have anything in the documentation that claims to be a Northbridge (PBX does, VExpress doesn't). This is the system diagram for the Versatile Express: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0447d/I1007683.html I don't know what you'd want to claim is a northbridge there. Basically there's an FPGA with a pile of devices in it, and there's a test chip with the core and some other devices in it. But from a modelling perspective this is all completely irrelevant because regardless of where the hardware designer put the devices, they're just devices at a particular point in the memory map and with a particular set of interrupt wiring and so on. I don't see the point in modelling a concept that has no user-visible effects and doesn't actually make the model any clearer or simpler. In my understanding the machine is the thing that says I need a 926, and an MMC controller at this address, and some UARTS, and... ie it is the thing that does the modifying parameters and adding different components. So if we'd still be doing that I don't see how we've got rid of the concept. I guess I'm missing the point somehow. A machine today is basically the northbridge, southbridge, plus a bunch of default components to make the virtual hardware useful. This doesn't really correspond to ARM boards I've looked at, by and large (for instance there's no mention of the word northbridge in the whole 3700 page OMAP3 TRM). PCs may be best modelled that way, sure, but I don't think you can cram everything into that mould. If you mean that you want machines to be implemented under the hood as a single huge device you can only have one of that spans the entire memory map, well I guess that's an implementation detail. But conceptually machines really do exist, and we definitely still want users to be able to say I want a beagle machine; I want a versatile; I want an n900. An n900 is a very specific hardware configuration that is best represented by some sort of configuration file vs. something hard coded in QEMU. Yes, that's the whole point -- machine == specific hardware configuration. That's not getting rid of machine, it's just saying we should have some custom scripting language to define them rather than doing them in C. You still want, fundamentally, to be able to say qemu-system-arm -M machinename -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, Feb 10, 2011 at 11:19:48AM +0100, Anthony Liguori wrote: On 02/10/2011 11:10 AM, Gleb Natapov wrote: On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote: On 02/10/2011 10:07 AM, Gleb Natapov wrote: So what if it is easier, it doesn't mean it is correct thing to do. If we spend the next 10 years trying to do the correct thing for some arbitrary definition of correct, that's not terribly useful. Changing direction by 180 every 2 years even less useful. If we think through what we are doing and have a coherent architecture before changing direction, then we won't have this problem. I'd like to believe this :) It's really simple actually. Let's do the least clever thing and model how hardware actual works. Once we have that, we can try to be better than real hardware (if it's possible). I think out understanding on how HW actually works is very different. You are placing to much value on were device resides physically, for me it is completely unimportant detail. Not worth even mentioning. No, I place value on how things are modelled in the real world. Real world (physical HW) have consideration not relevant for our software emulation. Such as cost, physical dimension, power consumption and many other I am sure I missed. There simply aren't PC's out there that lack an RTC so I have no interest in jumping through hoops in QEMU to make it possible to do this without modifying QEMU code. It might sound nice to a developer but it's of absolutely no use to users. RTC is not good example. HPET suppose to replace it (and PIT too). AFAIC there are PCs without RTC already. Good example would be PIC or IOAPIC device and then I would agree with you that it is not worth it to make it possible to create x86 machine without them from command line if it means extra complexity. But how have you jumped from this to lets make usb mandatory? If all composition is done through a factory interface, it doesn't. But my main argument here is that we shouldn't try to make all composition done through a factory interface--only where it makes sense. So very concretely, I'm suggesting we do the following to target-i386: 1) make the i440fx device have an embedded ide controller, piix3, and usb controller that get initialized automatically. The piix3 embeds the PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial, etc.). This may be a problem even from security point of view. What if usb code (ide, serial, parallel) has guest exploitable bug? Currently I can happily continue running guests if they do not need affected subsystem. If we'll get it your way I will no longer be able to do so. qemu -device i440fx,ide=off So you still need to support arbitrary composition. What's the difference? No, we don't. It's possible to have an 'rtc=off' option but I'm tremendously opposed to doing this. Arbitrary composition is not a useful goal IMHO. IMHO is different. We should support composition where it makes sense. For PIC-less x86 it doesn't make it. For usb-less or even ide-less it does. So why do you like -device i440fx over what we have now? Because I don't think tools like libvirt should be doing device composition to create an i440fx-like chipset. I think the current path we're on is pushing too much logic that belongs in QEMU into the management stack. I can agree with that. But from this it doesn't follow that we should get rid of composition. We shouldn't push composition of common HW to libvirt. Looking at libvirt command line I do not think we do it though. Typical libvirt command line specifies disks, networks, usb, vga. How -device i440fx will simplified that? Well usb could be omitted (but not -usbdevice table), disks are not property of i440fx so they will stay, since user may want to use virtio controller (which is not part of i440fx) this should stay too. Network obviously will have to be specified by libvirt too, vga may go to i440fx, but since libvirt supports qxl we will have to have a way to disable default vga and enable qxl instead. So will we really simplify libvirt's life by introducing -device i440fx? In current speak you propose will be implement by using i440fx machine type. Qdev will build it for you. If you had an i440fx machine type, that had no non-optional components added, and you could specify options to the machine type, yes. But I think you'll agree that there's no reason to not just treat the i440fx as a device. I do not agree. There is not such device as i440fx. This is just packaging. If you really care to do this. But this desire to remove devices is silly IMHO. Concerns about security are misplaced. If you have to change the way a guest is invoked in order to eliminate security problems, then there's something seriously wrong. No I do not. I do not create guest with unneeded devices from the beginning. There is very little that isn't 'unneeded'. That depends
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, Feb 10, 2011 at 12:25:38PM +0200, Avi Kivity wrote: On 02/10/2011 11:07 AM, Gleb Natapov wrote: On Thu, Feb 10, 2011 at 08:47:12AM +0100, Anthony Liguori wrote: On 02/09/2011 09:15 PM, Blue Swirl wrote: On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguorianth...@codemonkey.ws wrote: On 02/09/2011 06:48 PM, Blue Swirl wrote: ISASerialState dev; isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL); Do you mean that there should be a generic way of doing that, like sysbus_create_varargs() for qdev, or just add inline functions which hide qdev property setup? I still think that FDT should be used in the future. That would require that the properties can be set up mechanically, and I don't see how your proposal would help that. Yeah, I don't think that is a good idea anymore. I think this is part of why we're having so many problems with qdev. While (most?) hardware hierarchies can be represented by device tree syntax, not all valid device trees correspond to interface and/or useful hardware hierarchies. User creates a non-working machine and so gets to fix the problems? How is that a problem for us? It's not about creating a non-working machine. It's about what user-level abstraction we need to provide. It's a whole lot easier to implement an i440fx device with a fixed set of parameters than it is to make every possible subdevice have a proper factory interface along with mechanisms to hook everything together. So what if it is easier, it doesn't mean it is correct thing to do. What you are proposing is just a huge step backwards. May be we shouldn't support hooking everything together in completely arbitrary ways, but we shouldn't force isa/pci devices upon our users just because they are non-removable on real chip. I disagree. We don't want to deviate from the spec any more than we already do. Which spec? Even in this discussion we completely mixed different things. 440FX is not a chipset. It is memory controller/pci host bridge. PIIX3/4 is the chipset which is just an arbitrary combination of devices put on the same chip. We do not deviate from spec when we implement those devices. The reason for wanting flexibility is because the code for the PIC or RTC, for example, can be used in other Super-IO chipsets or even standalone. If qemu only supported the 440FX chipset, we'd have no reason to make things flexible. Again you probably mean PIIX3. Even then removing unused ide will free one more PCI slot for my cool virtio disk array. The things is, from code point of view, it does not cost you extra to allow composition of ide since it is just a regular PCI device and we need to support composing those anyway. So very concretely, I'm suggesting we do the following to target-i386: 1) make the i440fx device have an embedded ide controller, piix3, and usb controller that get initialized automatically. The piix3 embeds the PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial, etc.). This may be a problem even from security point of view. What if usb code (ide, serial, parallel) has guest exploitable bug? Currently I can happily continue running guests if they do not need affected subsystem. If we'll get it your way I will no longer be able to do so. You can't just remove a device from a guest. You have to shut it down. When you power it back up, you may end up with different IRQ assignments or expose some guest bug. As I answered to Anthony already I am not talking about changing HW configuration after guest is created rather about creating minimal HW setup for the task from the start. This means no soundcard or usb for Windows exchange server for instance. If you have a security issue in code that is exposed to the guest, you have to fix it. Of course. That is why it is a good idea to expose as little code to guest as possible. Don't you think so? -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, Feb 10, 2011 at 10:38:53AM +, Peter Maydell wrote: This is the system diagram for the Versatile Express: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0447d/I1007683.html I don't know what you'd want to claim is a northbridge there. Basically there's an FPGA with a pile of devices in it, and there's a test chip with the core and some other devices in it. But from a modelling perspective this is all completely irrelevant because regardless of where the hardware designer put the devices, they're just devices at a particular point in the memory map and with a particular set of interrupt wiring and so on. I don't see the point in modelling a concept that has no user-visible effects and doesn't actually make the model any clearer or simpler. Exactly. This is really the same with x86. The fact that some company put several devices on the same chip and gave it commercial name shouldn't govern our design. A machine today is basically the northbridge, southbridge, plus a bunch of default components to make the virtual hardware useful. This doesn't really correspond to ARM boards I've looked at, by and large (for instance there's no mention of the word northbridge in the whole 3700 page OMAP3 TRM). PCs may be best modelled that way, sure, but I don't think you can cram everything into that mould. Even on x86 this model is falling apart. Memory controller moves to cpu. PCI controller will follow. If you mean that you want machines to be implemented under the hood as a single huge device you can only have one of that spans the entire memory map, well I guess that's an implementation detail. But conceptually machines really do exist, and we definitely still want users to be able to say I want a beagle machine; I want a versatile; I want an n900. An n900 is a very specific hardware configuration that is best represented by some sort of configuration file vs. something hard coded in QEMU. Yes, that's the whole point -- machine == specific hardware configuration. That's not getting rid of machine, it's just saying we should have some custom scripting language to define them rather than doing them in C. You still want, fundamentally, to be able to say qemu-system-arm -M machinename +1 -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/10/2011 11:38 AM, Peter Maydell wrote: On 10 February 2011 10:13, Anthony Liguorianth...@codemonkey.ws wrote: On 02/10/2011 10:04 AM, Peter Maydell wrote: On 10 February 2011 08:36, Anthony Liguorianth...@codemonkey.wswrote: So you would model arm926ej-s as the chipset and then build up the machines by modifying parameters of the chipset (like the board id) and/or adding different components on top of it. Er, ARM926 is the CPU, it's not a chipset. The board ID is definitely not a property of an ARM926, it's a property of the board (clue is in the name :-)). I don't think versatile boards have a chipset really... As I said, I'm not well versed in the component names in ARM. But that said, an actual processor doesn't connect directly to a bunch of devices. It almost always go through some chipset and that chipset implements a lot of functionality typically. I think the name of the component I'm trying to refer to PL300 which I believe is the Northbridge used for the Versatile boards. PL300 is just a bus interconnect (so you can connect multiple AXI bus masters (cores) to multiple AXI bus slaves (devices)). Versatile PB doesn't have anything in the documentation that claims to be a Northbridge (PBX does, VExpress doesn't). This is the system diagram for the Versatile Express: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0447d/I1007683.html I don't know what you'd want to claim is a northbridge there. Basically there's an FPGA with a pile of devices in it, and there's a test chip with the core and some other devices in it. But from a modelling perspective this is all completely irrelevant because regardless of where the hardware designer put the devices, they're just devices at a particular point in the memory map and with a particular set of interrupt wiring and so on. But something interacts with each processor and dispatches the I/O operations in the address space, no? I can't believe there are 2^32 address lines coming off of every arm chip that each device connects. This relationship of how I/O fans out through various devices is important because occasionally platforms do weird things during I/O fan out like implement an IOMMU. If we don't model this I/O dispatch model within QEMU, then it's extremely difficult to implement things like IOMMUs. It might be the case that a platform has a chipset that is a pile of well isolated devices that are crammed in the same silicon space but that otherwise have very well defined interactions with each other. This is the exception though, not the rule. Particularly when looking at the relationship between certain devices on the PC (like the role the pckbd plays in address translation), things are simply not so idealized in practice. But if it makes sense for ARM to describe every single platform device through a factory interface, that's fine. Even in this case, you still want to model things like the distinction between the UART16650A and the ISA bus bridge for the serial device. In this case, you want to be able to do composition without going through a factory. An n900 is a very specific hardware configuration that is best represented by some sort of configuration file vs. something hard coded in QEMU. Yes, that's the whole point -- machine == specific hardware configuration. That's not getting rid of machine, it's just saying we should have some custom scripting language to define them rather than doing them in C. You still want, fundamentally, to be able to say qemu-system-arm -M machinename No, qemu-system-arm -M /path/to/n900.cfg But yeah, no disagreement there. But today, the machine concept in QEMU is definitely not a specific hardware configuration. Regards, Anthony Liguori -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/10/2011 11:49 AM, Gleb Natapov wrote: On Thu, Feb 10, 2011 at 11:19:48AM +0100, Anthony Liguori wrote: On 02/10/2011 11:10 AM, Gleb Natapov wrote: On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote: On 02/10/2011 10:07 AM, Gleb Natapov wrote: So what if it is easier, it doesn't mean it is correct thing to do. If we spend the next 10 years trying to do the correct thing for some arbitrary definition of correct, that's not terribly useful. Changing direction by 180 every 2 years even less useful. If we think through what we are doing and have a coherent architecture before changing direction, then we won't have this problem. I'd like to believe this :) It's really simple actually. Let's do the least clever thing and model how hardware actual works. Once we have that, we can try to be better than real hardware (if it's possible). I think out understanding on how HW actually works is very different. You are placing to much value on were device resides physically, for me it is completely unimportant detail. Not worth even mentioning. No, I place value on how things are modelled in the real world. Real world (physical HW) have consideration not relevant for our software emulation. Such as cost, physical dimension, power consumption and many other I am sure I missed. There simply aren't PC's out there that lack an RTC so I have no interest in jumping through hoops in QEMU to make it possible to do this without modifying QEMU code. It might sound nice to a developer but it's of absolutely no use to users. RTC is not good example. HPET suppose to replace it (and PIT too). HPET's embed RTCs to provide support for legacy implementations. This is extremely good example of where our modelling breaks down. Take a close look at how the HPET and RTC emulations interact for an example of why we'd be much better off just implementing an RTC within an HPET. AFAIC there are PCs without RTC already. RTC also provides CMOS functionality and no PC can boot without CMOS. So no, there's nothing we'd consider a PC today that doesn't have an RTC. Good example would be PIC or IOAPIC device and then I would agree with you that it is not worth it to make it possible to create x86 machine without them from command line if it means extra complexity. But how have you jumped from this to lets make usb mandatory? USB is mandatory in the PIIX3 but the only significant difference between the piix2 and piix3 is the addition of USB. Consequentially, the main difference between an i440fx and i440bx is the use of a piix2 vs. a piix3. So if you really want to create the same PC we have today w/o USB, the right way to do it would be to have: -device i440,model=fx // with USB -device i440,model=bx // w/o USB No, we don't. It's possible to have an 'rtc=off' option but I'm tremendously opposed to doing this. Arbitrary composition is not a useful goal IMHO. IMHO is different. We should support composition where it makes sense. For PIC-less x86 it doesn't make it. For usb-less or even ide-less it does. The right way to do a USB-less PC is to have an option to create an i440bx. An IDE-less PC is a bit more difficult because IDE is really baked into the concept of a PC. Chances are, there are more than a few guests out there that would have issues from there being no IDE bus present. So why do you like -device i440fx over what we have now? Because I don't think tools like libvirt should be doing device composition to create an i440fx-like chipset. I think the current path we're on is pushing too much logic that belongs in QEMU into the management stack. I can agree with that. But from this it doesn't follow that we should get rid of composition. We shouldn't push composition of common HW to libvirt. Looking at libvirt command line I do not think we do it though. Typical libvirt command line specifies disks, networks, usb, vga. How -device i440fx will simplified that? Well usb could be omitted (but not -usbdevice table), disks are not property of i440fx so they will stay, since user may want to use virtio controller (which is not part of i440fx) this should stay too. Network obviously will have to be specified by libvirt too, vga may go to i440fx, but since libvirt supports qxl we will have to have a way to disable default vga and enable qxl instead. So will we really simplify libvirt's life by introducing -device i440fx? libvirt also uses -no-defaults which prevents much of the PC's machine init from creating anything but stuff that really belongs in the main chipset. But I bet if you asked 5 different QEMU developers what belongs in machine init and what the role of -no-defaults is, you'd get different answers. OTOH, skipping any notion of machine and explicitly creating a chipset provides a very consistent
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/10/2011 12:13 PM, Gleb Natapov wrote: Which spec? Even in this discussion we completely mixed different things. 440FX is not a chipset. Yes, it is. It's a single silicon package with a defined pinout. If you don't believe me, re-read the spec. It's a MCM with the PIIX3 being internally connected. The connection between the i440fx and PIIX3 happens to be PCI but that's not always the case. Sometimes it's a proprietary bus. Again you probably mean PIIX3. Even then removing unused ide will free one more PCI slot for my cool virtio disk array. The things is, from code point of view, it does not cost you extra to allow composition of ide since it is just a regular PCI device and we need to support composing those anyway. If this is useful, and it doesn't break guests, you can always do -device i440fx,ide=off. However, it's an exception where we're deviating from how hardware works. And that's okay, but the base modelling ought to follow real hardware closely with deviations being the exception. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/10/2011 02:51 PM, Anthony Liguori wrote: On 02/10/2011 12:13 PM, Gleb Natapov wrote: Which spec? Even in this discussion we completely mixed different things. 440FX is not a chipset. Yes, it is. It's a single silicon package with a defined pinout. If you don't believe me, re-read the spec. It's a MCM with the PIIX3 being internally connected. The connection between the i440fx and PIIX3 happens to be PCI but that's not always the case. Sometimes it's a proprietary bus. Aren't they two distinct chips, together comprising the chip-set? One (the northbridge) converts the system bus to PCI + some extra wires, the other (southbridge) bridges PCI to ISA and contains some embedded ISA devices. IIRC there are some wires between them that are not PCI. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 10 February 2011 12:23, Anthony Liguori anth...@codemonkey.ws wrote: But something interacts with each processor and dispatches the I/O operations in the address space, no? I can't believe there are 2^32 address lines coming off of every arm chip that each device connects. Well, the AXI bus is kind of complicated and definitely not my area of expertise, but as I understand it you have an interconnect like a PL300 that effectively implements the memory map and defines where the slaves (devices) appear. But unless you actually want to be modelling bus transactions at a pretty low level this isn't really a visible difference from these devices appear at this address in the memory map on this bus. (And there might be a bridge down from AXI to AHB or APB between the core and any particular device, but that's not programmer visible either.) This relationship of how I/O fans out through various devices is important because occasionally platforms do weird things during I/O fan out like implement an IOMMU. If we don't model this I/O dispatch model within QEMU, then it's extremely difficult to implement things like IOMMUs. Yes, but what does this have to do with chipsets and getting rid of machines? Getting I/O fanout through devices is a matter of modelling some sort of conceptual bus, and having the right APIs so you can do it fast in the common case and still allow IOMMUs and other interesting devices to intercept and change transactions. Any particular board might have to wire up the bus so it goes through an IOMMU, or it might not. Whether you want to bundle up a collection of devices and bus wiring and call it a chipset or not should be a matter of whether that makes sense and is a usefully reusable conceptual unit for whatever board you're modelling, I think. (For instance an OMAP3 is an obvious reusable unit which any OMAP3-based board model is going to want to use.) Some of the I/O fanout and bus wiring might be internal to a qemu core model, for that matter -- for instance M profile ARM cores have several output buses which deal with different bits of the memory space (which are predefined as being for devices, or memory, or whatever), and the A9MP's internal timers and interrupt controller and so on ought to all be inside the core (at the moment we rely on all A9MP boards instantiating them as a separate device, which is ugly). -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, Feb 10, 2011 at 01:47:06PM +0100, Anthony Liguori wrote: On 02/10/2011 11:49 AM, Gleb Natapov wrote: On Thu, Feb 10, 2011 at 11:19:48AM +0100, Anthony Liguori wrote: On 02/10/2011 11:10 AM, Gleb Natapov wrote: On Thu, Feb 10, 2011 at 11:00:50AM +0100, Anthony Liguori wrote: On 02/10/2011 10:07 AM, Gleb Natapov wrote: So what if it is easier, it doesn't mean it is correct thing to do. If we spend the next 10 years trying to do the correct thing for some arbitrary definition of correct, that's not terribly useful. Changing direction by 180 every 2 years even less useful. If we think through what we are doing and have a coherent architecture before changing direction, then we won't have this problem. I'd like to believe this :) It's really simple actually. Let's do the least clever thing and model how hardware actual works. Once we have that, we can try to be better than real hardware (if it's possible). I think out understanding on how HW actually works is very different. You are placing to much value on were device resides physically, for me it is completely unimportant detail. Not worth even mentioning. No, I place value on how things are modelled in the real world. Real world (physical HW) have consideration not relevant for our software emulation. Such as cost, physical dimension, power consumption and many other I am sure I missed. There simply aren't PC's out there that lack an RTC so I have no interest in jumping through hoops in QEMU to make it possible to do this without modifying QEMU code. It might sound nice to a developer but it's of absolutely no use to users. RTC is not good example. HPET suppose to replace it (and PIT too). HPET's embed RTCs to provide support for legacy implementations. This is extremely good example of where our modelling breaks down. Take a close look at how the HPET and RTC emulations interact for an example of why we'd be much better off just implementing an RTC within an HPET. Yes HPET can provide legacy RTC timer functionality. No I do not see why we should implement RTC withing HPET. In your model we should remove HPET code completely since HPET is not present in chipset emulated by QEMU. AFAIC there are PCs without RTC already. RTC also provides CMOS functionality and no PC can boot without CMOS. So no, there's nothing we'd consider a PC today that doesn't have an RTC. CMOS may be present even if RTC functionality is absent. Does EFI base machine still need CMOS though? Good example would be PIC or IOAPIC device and then I would agree with you that it is not worth it to make it possible to create x86 machine without them from command line if it means extra complexity. But how have you jumped from this to lets make usb mandatory? USB is mandatory in the PIIX3 but the only significant difference between the piix2 and piix3 is the addition of USB. Consequentially, the main difference between an i440fx and i440bx is the use of a piix2 vs. a piix3. So if you really want to create the same PC we have today w/o USB, the right way to do it would be to have: -device i440,model=fx // with USB -device i440,model=bx // w/o USB Why not qemu -config piix2.cfg or qemu -config piix3.cfg? No need to make data into code. No, we don't. It's possible to have an 'rtc=off' option but I'm tremendously opposed to doing this. Arbitrary composition is not a useful goal IMHO. IMHO is different. We should support composition where it makes sense. For PIC-less x86 it doesn't make it. For usb-less or even ide-less it does. The right way to do a USB-less PC is to have an option to create an i440bx. Why is this the right way? An IDE-less PC is a bit more difficult because IDE is really baked into the concept of a PC. Chances are, there are more than a few guests out there that would have issues from there being no IDE bus present. Non of my modern PCs have IDE. Many high end PC had SCSI instead of IDE in the past. If guest can't run without IDE you do not run it without IDE. So why do you like -device i440fx over what we have now? Because I don't think tools like libvirt should be doing device composition to create an i440fx-like chipset. I think the current path we're on is pushing too much logic that belongs in QEMU into the management stack. I can agree with that. But from this it doesn't follow that we should get rid of composition. We shouldn't push composition of common HW to libvirt. Looking at libvirt command line I do not think we do it though. Typical libvirt command line specifies disks, networks, usb, vga. How -device i440fx will simplified that? Well usb could be omitted (but not -usbdevice table), disks are not property of i440fx so they will stay, since user may want to use virtio controller (which is not part of i440fx) this should stay too. Network obviously will have to be specified by libvirt too, vga may go to i440fx, but since libvirt
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, Feb 10, 2011 at 01:51:14PM +0100, Anthony Liguori wrote: On 02/10/2011 12:13 PM, Gleb Natapov wrote: Which spec? Even in this discussion we completely mixed different things. 440FX is not a chipset. Yes, it is. It's a single silicon package with a defined pinout. If you don't believe me, re-read the spec. It's a MCM with the PIIX3 being internally connected. The connection between the i440fx and PIIX3 happens to be PCI but that's not always the case. Sometimes it's a proprietary bus. Which one? 29054901.pdf describes memory controller and PCI host bridge only. Again you probably mean PIIX3. Even then removing unused ide will free one more PCI slot for my cool virtio disk array. The things is, from code point of view, it does not cost you extra to allow composition of ide since it is just a regular PCI device and we need to support composing those anyway. If this is useful, and it doesn't break guests, you can always do -device i440fx,ide=off. However, it's an exception where we're deviating from how hardware works. I don't care how command line will look like, but I do not see how you will support ide=off without device composition unless you put ad-hoc ifs all over your i440fx device code. And I don't understand what do you mean by saying that this is not how hardware works. Presence or absence of PCI device does not change how hardware works. And that's okay, but the base modelling ought to follow real hardware closely with deviations being the exception. You keep saying this without explaining why. But with device composition you will have exactly that, you will compose real chipsets using config files, not code. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, Feb 10, 2011 at 03:00:05PM +0200, Avi Kivity wrote: On 02/10/2011 02:51 PM, Anthony Liguori wrote: On 02/10/2011 12:13 PM, Gleb Natapov wrote: Which spec? Even in this discussion we completely mixed different things. 440FX is not a chipset. Yes, it is. It's a single silicon package with a defined pinout. If you don't believe me, re-read the spec. It's a MCM with the PIIX3 being internally connected. The connection between the i440fx and PIIX3 happens to be PCI but that's not always the case. Sometimes it's a proprietary bus. Aren't they two distinct chips, together comprising the chip-set? One (the northbridge) converts the system bus to PCI + some extra wires, the other (southbridge) bridges PCI to ISA and contains some embedded ISA devices. IIRC there are some wires between them that are not PCI. Yeah, 440fx is probably northbridge and PIIX3 southbridge. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/10/2011 02:00 PM, Avi Kivity wrote: On 02/10/2011 02:51 PM, Anthony Liguori wrote: On 02/10/2011 12:13 PM, Gleb Natapov wrote: Which spec? Even in this discussion we completely mixed different things. 440FX is not a chipset. Yes, it is. It's a single silicon package with a defined pinout. If you don't believe me, re-read the spec. It's a MCM with the PIIX3 being internally connected. The connection between the i440fx and PIIX3 happens to be PCI but that's not always the case. Sometimes it's a proprietary bus. Aren't they two distinct chips, together comprising the chip-set? One (the northbridge) converts the system bus to PCI + some extra wires, the other (southbridge) bridges PCI to ISA and contains some embedded ISA devices. IIRC there are some wires between them that are not PCI. Yes, you are correct. So I can understand an argument for: -device i440fx,id=pmc -device piix3,chipset=pmc Or something like that. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/10/2011 02:27 PM, Gleb Natapov wrote: I don't care how command line will look like, but I do not see how you will support ide=off without device composition unless you put ad-hoc ifs all over your i440fx device code. Yes, in the piix3 device code, the ide property would trigger an if(). BTW, I'm extremely sceptical that you really do have machines w/o IDE at all. Even the servers we ship with only SAS or SCSI support still have an integrated IDE controller. Since most servers are built from the same chipset design that has IDE, I don't really see how you could build a modern system without IDE. And that's okay, but the base modelling ought to follow rea hardware closely with deviations being the exception. You keep saying this without explaining why. But with device composition you will have exactly that, you will compose real chipsets using config files, not code. Yeah, that's been the direction we've been going in since qdev was introduced. I'm now convinced that this is overly ambitious. By simply reducing the scope of conversion, we get 99% of the benefit with 10% of the effort. Seems like a no brainer to me. Regards, Anthony Liguori -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, Feb 10, 2011 at 03:04:28PM +0100, Anthony Liguori wrote: On 02/10/2011 02:27 PM, Gleb Natapov wrote: I don't care how command line will look like, but I do not see how you will support ide=off without device composition unless you put ad-hoc ifs all over your i440fx device code. Yes, in the piix3 device code, the ide property would trigger an if(). BTW, I'm extremely sceptical that you really do have machines w/o IDE at all. Even the servers we ship with only SAS or SCSI support still have an integrated IDE controller. Since most servers are built from the same chipset design that has IDE, I don't really see how you could build a modern system without IDE. Well, this may be true. But since I can't find IDE (or ATA) nor in lspci neither in dmesg does it really matter that silicon that implement IDE functionality is present somewhere inside the box? And that's okay, but the base modelling ought to follow rea hardware closely with deviations being the exception. You keep saying this without explaining why. But with device composition you will have exactly that, you will compose real chipsets using config files, not code. Yeah, that's been the direction we've been going in since qdev was introduced. I'm now convinced that this is overly ambitious. By simply reducing the scope of conversion, we get 99% of the benefit with 10% of the effort. Seems like a no brainer to me. Jugging by how well all previous conversion went we will end up with one more way of creating devices. One legacy, another qdev and your new one. And what is the problem with qdev again (not that I am a big qdev fan)? The fact that there is no enough interest to convert all devices to it? How new way of doing things will solve this? Just to be clear I do not have problem with not having ability to compose x86 without pit or kbd controller. Basic things like RTC, pit, pic, ioapic, dma, kbd should be created unconditionally as part of x86 pc machine. But IMHO you are trying to take things to other extreme. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, 10 Feb 2011 08:16:15 + Peter Maydell peter.mayd...@linaro.org wrote: On 10 February 2011 07:47, Anthony Liguori anth...@codemonkey.ws wrote: So very concretely, I'm suggesting we do the following to target-i386: 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. Does that make any sense for anything other than target-i386? The concept of a machine model seems a pretty obvious one for ARM boards, for instance, and I'm not sure we'd gain much by having i386 be different to the other architectures... It makes a lot of sense for us on powerpc. Maybe it has to do with a longer tradition of using device trees versus opaque machine IDs -- I don't think the hardware itself makes any substantial difference. Currently we end up having everything pretend to be an mpc8544ds (with some differences described by the guest device tree that the user feeds in), which is ugly. -Scott -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 10 February 2011 19:17, Scott Wood scottw...@freescale.com wrote: On Thu, 10 Feb 2011 08:16:15 + Peter Maydell peter.mayd...@linaro.org wrote: On 10 February 2011 07:47, Anthony Liguori anth...@codemonkey.ws wrote: So very concretely, I'm suggesting we do the following to target-i386: 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. Does that make any sense for anything other than target-i386? It makes a lot of sense for us on powerpc. Maybe it has to do with a longer tradition of using device trees versus opaque machine IDs -- I don't think the hardware itself makes any substantial difference. Currently we end up having everything pretend to be an mpc8544ds (with some differences described by the guest device tree that the user feeds in), which is ugly. Hmm. Device tree is coming to ARM, but just at the moment it's generally one-kernel-one-machine still. (We've only just gained the ability to compile one kernel for both UP and SMP...) I kind of think you're still defining a machine, you're just doing it in your device tree blob rather than in C. -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Thu, 10 Feb 2011 19:22:38 + Peter Maydell peter.mayd...@linaro.org wrote: On 10 February 2011 19:17, Scott Wood scottw...@freescale.com wrote: On Thu, 10 Feb 2011 08:16:15 + Peter Maydell peter.mayd...@linaro.org wrote: On 10 February 2011 07:47, Anthony Liguori anth...@codemonkey.ws wrote: So very concretely, I'm suggesting we do the following to target-i386: 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. Does that make any sense for anything other than target-i386? It makes a lot of sense for us on powerpc. Maybe it has to do with a longer tradition of using device trees versus opaque machine IDs -- I don't think the hardware itself makes any substantial difference. Currently we end up having everything pretend to be an mpc8544ds (with some differences described by the guest device tree that the user feeds in), which is ugly. Hmm. Device tree is coming to ARM, but just at the moment it's generally one-kernel-one-machine still. (We've only just gained the ability to compile one kernel for both UP and SMP...) I kind of think you're still defining a machine, you're just doing it in your device tree blob rather than in C. Right, that's the point -- the definition is just a definition, it's not tied up with implementation. This reduces the amount of duplication in implementation (or inappropriate sharing, as in the use mpc8544ds for all 85xx case). -Scott -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
Anthony Liguori anth...@codemonkey.ws writes: On 02/08/2011 11:13 AM, Markus Armbruster wrote: Chris Wrightchr...@redhat.com writes: [...] - qdev/vmstate both examples of partially completed work that need more attention As far as qdev's concerned, I can see two kinds of to-dos: * Further develop qdev so that more of the machine init code can becomes qdev declarations. Specific ideas welcome. Patches even more, as always. I think we need to improve the i440fx modelling as a lot of the stuff done in the machine init for pc really belongs as part of the i440fx. In theory, creating an i440fx ought to be essentially equivalent to the machine init function today. * Convert the remaining devices. They are typically used only with oddball machines, which makes the conversion hard to test for anyone who's not already using them. I've said this before: at some point in time (sooner rather than later, if you ask me), we need to shoot the stragglers. I'm pretty optimistic that any victims worth keeping will receive timely attention then. Anything else? We need to unify the property model. We have QemuOpts, qdev properties, and QObject which basically reinvents variant typing three different ways. Make it four: QEMUOptionParameter. Now let me make it three again. Unlike the others, a qdev property describes a perfectly ordinary, non-variant struct member. It's poor man's reflection, not a variant type. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
Peter Maydell peter.mayd...@linaro.org writes: On 8 February 2011 17:13, Markus Armbruster arm...@redhat.com wrote: As far as qdev's concerned, I can see two kinds of to-dos: * Further develop qdev so that more of the machine init code can becomes qdev declarations. Specific ideas welcome. Patches even more, as always. * Convert the remaining devices. They are typically used only with oddball machines, which makes the conversion hard to test for anyone who's not already using them. I've said this before: at some point in time (sooner rather than later, if you ask me), we need to shoot the stragglers. I'm pretty optimistic that any victims worth keeping will receive timely attention then. So on IRC pbrook wrote: pbrook So we have a bunch of devices that nominally claim to use the qdev infrastructure, but are still making assumptions that qdev was supposed to remove, so break horribly when you actually try to use it as intended. ...and my question is: where is the documentation on how to do a good conversion of a device to qdev, how it works, what the assumptions you can/can't make are, etc ? I can't see anything relevant in the source tree or on the website, but maybe I'm just looking in the wrong places... Unfortunately, you're not. Paul created qdev. Others, including Gerd and myself, put it to use in targets we care for, working from the examples Paul set and not much else. We had to grow it some along the way. Still, the brain to pick for what assumptions qdev was supposed to remove is Paul's. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 9 February 2011 08:11, Markus Armbruster arm...@redhat.com wrote: Peter Maydell peter.mayd...@linaro.org writes: Markus Armbruster arm...@redhat.com wrote: I've said this before: at some point in time (sooner rather than later, if you ask me), we need to shoot the stragglers. ...and my question is: where is the documentation on how to do a good conversion of a device to qdev, how it works, what the assumptions you can/can't make are, etc ? I can't see anything relevant in the source tree or on the website, but maybe I'm just looking in the wrong places... Unfortunately, you're not. It seems to me that if you want the maintainers of the random oddball platforms and devices to do qdev conversion, this is much more likely to happen if it's clearly documented how to do it. Otherwise the only people who can do a good qdev conversion are the people who care about qdev and it has to be their responsibility to convert everybody over... -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
Aurelien Jarno aurel...@aurel32.net writes: On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote: Chris Wright chr...@redhat.com writes: [...] - qdev/vmstate both examples of partially completed work that need more attention As far as qdev's concerned, I can see two kinds of to-dos: * Further develop qdev so that more of the machine init code can becomes qdev declarations. Specific ideas welcome. Patches even more, as always. * Convert the remaining devices. They are typically used only with oddball machines, which makes the conversion hard to test for anyone who's not already using them. I've said this before: at some point in time (sooner rather than later, if you ask me), we need to shoot the stragglers. I'm pretty optimistic that any victims worth keeping will receive timely attention then. For those oddball machines, qdev doesn't really bring anything, that's why there is so little interest in converting them, and why I prefer to spend my time on the emulation correctness than converting those remaining to qdev. Of course I agree it's something to do, and with an unlimited amount of free time, I'll do them immediately. Let's take for example the SH4 target. It's nice to be able to create the whole machine from a script, except your kernel won't boot if the machine: - has a different cpu - doesn't a SM501 chipset - has not the correct memory size - doesn't have 2 serial port That basically only leaves the PCI and USB devices configurable, but those are already using qdev. I understand where you come from. Converting to qdev isn't free. But not doing so isn't free either. QEMU offers two interfaces to device models, legacy and qdev[*]. Maintaining the legacy interface isn't free. Users of the legacy interface serve as bad examples. If we don't pay attention, we can even get the two mixed up in the same device model. [*] The two overlap in places. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
Peter Maydell peter.mayd...@linaro.org writes: On 9 February 2011 08:11, Markus Armbruster arm...@redhat.com wrote: Peter Maydell peter.mayd...@linaro.org writes: Markus Armbruster arm...@redhat.com wrote: I've said this before: at some point in time (sooner rather than later, if you ask me), we need to shoot the stragglers. ...and my question is: where is the documentation on how to do a good conversion of a device to qdev, how it works, what the assumptions you can/can't make are, etc ? I can't see anything relevant in the source tree or on the website, but maybe I'm just looking in the wrong places... Unfortunately, you're not. It seems to me that if you want the maintainers of the random oddball platforms and devices to do qdev conversion, this is much more likely to happen if it's clearly documented how to do it. Otherwise the only people who can do a good qdev conversion are the people who care about qdev and it has to be their responsibility to convert everybody over... I regret the lack of proper qdev documentation as much as anyone. For what it's worth, the lone file on qdev in doc/ bears my fingerprints. Still, it's difficult for me to second-guess the original designer. Yes, it's quite fair to ask the folks calling for qdevification (read: *me*) to support that with better documentation. But I think it's also fair to ask the man who designed qdev and has been so critical much of its use (read: Paul) to provide a bit more guidance. Paul, please? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/09/2011 02:01 AM, Markus Armbruster wrote: Anthony Liguorianth...@codemonkey.ws writes: On 02/08/2011 11:13 AM, Markus Armbruster wrote: Chris Wrightchr...@redhat.com writes: [...] - qdev/vmstate both examples of partially completed work that need more attention As far as qdev's concerned, I can see two kinds of to-dos: * Further develop qdev so that more of the machine init code can becomes qdev declarations. Specific ideas welcome. Patches even more, as always. I think we need to improve the i440fx modelling as a lot of the stuff done in the machine init for pc really belongs as part of the i440fx. In theory, creating an i440fx ought to be essentially equivalent to the machine init function today. * Convert the remaining devices. They are typically used only with oddball machines, which makes the conversion hard to test for anyone who's not already using them. I've said this before: at some point in time (sooner rather than later, if you ask me), we need to shoot the stragglers. I'm pretty optimistic that any victims worth keeping will receive timely attention then. Anything else? We need to unify the property model. We have QemuOpts, qdev properties, and QObject which basically reinvents variant typing three different ways. Make it four: QEMUOptionParameter. Now let me make it three again. Unlike the others, a qdev property describes a perfectly ordinary, non-variant struct member. It's poor man's reflection, not a variant type. Except that construction of a device requires initialization from an array of variants (which is then type checked). The way we store the variants is lossy because we convert back and forth to a string. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/08/2011 01:30 PM, Aurelien Jarno wrote:
On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
Chris Wrightchr...@redhat.com writes:
[...]
- qdev/vmstate both examples of partially completed work that need more
attention
As far as qdev's concerned, I can see two kinds of to-dos:
* Further develop qdev so that more of the machine init code can becomes
qdev declarations. Specific ideas welcome. Patches even more, as
always.
* Convert the remaining devices. They are typically used only with
oddball machines, which makes the conversion hard to test for anyone
who's not already using them.
I've said this before: at some point in time (sooner rather than
later, if you ask me), we need to shoot the stragglers. I'm pretty
optimistic that any victims worth keeping will receive timely
attention then.
For those oddball machines, qdev doesn't really bring anything, that's
why there is so little interest in converting them, and why I prefer to
spend my time on the emulation correctness than converting those
remaining to qdev. Of course I agree it's something to do, and with an
unlimited amount of free time, I'll do them immediately.
Let's take for example the SH4 target. It's nice to be able to create
the whole machine from a script, except your kernel won't boot if the
machine:
- has a different cpu
- doesn't a SM501 chipset
- has not the correct memory size
- doesn't have 2 serial port
qdev needs a v2. The object model is very difficult to work with and it
offers little value for the scenario you describe.
A SoC should be modelled as a single object with parameters that can be
set. That object will then have other objects embedded through it with
composition or reference.
So for instance, you might have:
class SH4 {
SH4CPU cpu[n_vcpus];
SM501 chipset;
};
class SM501 : public PCIHostController {
PCIDevice *slots[32];
};
Having a script where you describe this is wrong. This ought to be an
object. For instance, what we really ought to have on x86 is:
qemu -no-machine -device i440fx,id=root -device
rtl8139,bus=/root/pci.0,addr=1.0 -device cpu,chipset=/root
Part of the problem with qdev v1 is that it doesn't allow for meaningful
object composition. The only relationship between devices is through
BusState which presents a hierarchical parent/child relationship.
We really need a way to do composition and referencing. For instance,
if you notice above, SM501 has 32 references to a PCIDevice as opposed
to having a linked list of children. The effect is that a PCIDevice
does not have the PCIHostController as it's parent because there's no
intrinsic parent/child hierarchy.
So really, we're talking about a device graph here instead of a tree.
Regards,
Anthony Liguori
That basically only leaves the PCI and USB devices configurable, but
those are already using qdev.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
Anthony Liguori anth...@codemonkey.ws writes: On 02/09/2011 02:01 AM, Markus Armbruster wrote: Anthony Liguorianth...@codemonkey.ws writes: [...] We need to unify the property model. We have QemuOpts, qdev properties, and QObject which basically reinvents variant typing three different ways. Make it four: QEMUOptionParameter. Now let me make it three again. Unlike the others, a qdev property describes a perfectly ordinary, non-variant struct member. It's poor man's reflection, not a variant type. Except that construction of a device requires initialization from an array of variants (which is then type checked). The way we store the variants is lossy because we convert back and forth to a string. Yes, there's overlap, but no, a qdev property isn't yet another variant type scheme. Exhibit A of the defense: qdev uses QemuOpts for variant types. Let me elaborate. qdev_device_add() uses QemuOpts as map from name to variant type value, uses the name to look up the property, then uses property methods to stuff the variant value it got from QemuOpts into the (non-variant) struct member described by the property. I figure QemuOpts was adopted for this purpose because it was already in use with command line and human monitor. With QMP added to the mix, there's friction: QMP uses QDict, not QemuOpts. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/09/2011 06:28 AM, Markus Armbruster wrote:
Except that construction of a device requires initialization from an
array of variants (which is then type checked). The way we store the
variants is lossy because we convert back and forth to a string.
Yes, there's overlap, but no, a qdev property isn't yet another variant
type scheme. Exhibit A of the defense: qdev uses QemuOpts for variant
types.
Let me elaborate. qdev_device_add() uses QemuOpts as map from name to
variant type value, uses the name to look up the property, then uses
property methods to stuff the variant value it got from QemuOpts into
the (non-variant) struct member described by the property.
I figure QemuOpts was adopted for this purpose because it was already in
use with command line and human monitor. With QMP added to the mix,
there's friction: QMP uses QDict, not QemuOpts.
I'm going to finish QMP before tackling qdev, but at a high level,
here's how I think we fix this.
Right now, qdev only really supports construction properties. In
GObject parlance, this would be properties with G_PARAM_CONSTRUCT_ONLY.
Instead of the current approach of having the construction properties
automagically set as part of the object prior to initfn() being invoked,
we should have an init function that takes the full set of construction
only properties in the native type.
With a schema description of the device's constructor, we can generate
code that invokes the native constructor based on a QemuOpts, or based
on a QDict.
So instead of:
static int serial_isa_initfn(ISADevice *dev);
static ISADeviceInfo serial_isa_info = {
.init = serial_isa_initfn,
.qdev.props = (Property[]) {
DEFINE_PROP_UINT32(index, ISASerialState, index, -1),
DEFINE_PROP_HEX32(iobase, ISASerialState, iobase, -1),
DEFINE_PROP_UINT32(irq, ISASerialState, isairq, -1),
DEFINE_PROP_CHR(chardev, ISASerialState, state.chr),
DEFINE_PROP_END_OF_LIST(),
},
};
We'd have:
void isa_serial_init(ISASerialState *obj, uint32_t index, uint32_t
iobase, uint32_t irq, CharDriverState *chardev, Error **errp);
// isa_serial.json
[ 'ISASerialState', {'index': 'uint32_t', 'iobase': 'uint32_t', 'irq':
'uint32_t', 'chardev': 'CharDriverState *'} ]
From this definition, we can generate code that handles the -device
argument doing conversion from string to the appropriate types while
also doing QObject/GVariant conversion to support the qmp_device_add()
interface.
Also, having a well typed constructor means that we can do safer
composition because instead of doing:
DeviceState *dev;
dev = qdev_create(NULL, isa-serial);
qdev_prop_set_uint32(dev, iobase, 0x274);
qdev_prop_set_uint32(dev, irq, 0x07);
qdev_init_nofail(dev);
We can just do:
ISASerialState dev;
isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL);
I think one of the reasons qdev has not been thoroughly embraced in much
of QEMU is that the interface is obnoxious to work with in C. By
addressing that, I think it'll be much more successful.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Wed, Feb 9, 2011 at 12:43 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/08/2011 01:30 PM, Aurelien Jarno wrote:
On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote:
Chris Wrightchr...@redhat.com writes:
[...]
- qdev/vmstate both examples of partially completed work that need more
attention
As far as qdev's concerned, I can see two kinds of to-dos:
* Further develop qdev so that more of the machine init code can becomes
qdev declarations. Specific ideas welcome. Patches even more, as
always.
* Convert the remaining devices. They are typically used only with
oddball machines, which makes the conversion hard to test for anyone
who's not already using them.
I've said this before: at some point in time (sooner rather than
later, if you ask me), we need to shoot the stragglers. I'm pretty
optimistic that any victims worth keeping will receive timely
attention then.
For those oddball machines, qdev doesn't really bring anything, that's
why there is so little interest in converting them, and why I prefer to
spend my time on the emulation correctness than converting those
remaining to qdev. Of course I agree it's something to do, and with an
unlimited amount of free time, I'll do them immediately.
Let's take for example the SH4 target. It's nice to be able to create
the whole machine from a script, except your kernel won't boot if the
machine:
- has a different cpu
- doesn't a SM501 chipset
- has not the correct memory size
- doesn't have 2 serial port
qdev needs a v2. The object model is very difficult to work with and it
offers little value for the scenario you describe.
A SoC should be modelled as a single object with parameters that can be set.
That object will then have other objects embedded through it with
composition or reference.
So for instance, you might have:
class SH4 {
SH4CPU cpu[n_vcpus];
SM501 chipset;
};
class SM501 : public PCIHostController {
PCIDevice *slots[32];
};
Having a script where you describe this is wrong. This ought to be an
object. For instance, what we really ought to have on x86 is:
qemu -no-machine -device i440fx,id=root -device
rtl8139,bus=/root/pci.0,addr=1.0 -device cpu,chipset=/root
Part of the problem with qdev v1 is that it doesn't allow for meaningful
object composition. The only relationship between devices is through
BusState which presents a hierarchical parent/child relationship.
That is actually how hardware is usually designed, usually multiple
active masters or cyclic graphs would be too complex.
We really need a way to do composition and referencing. For instance, if
you notice above, SM501 has 32 references to a PCIDevice as opposed to
having a linked list of children. The effect is that a PCIDevice does not
have the PCIHostController as it's parent because there's no intrinsic
parent/child hierarchy.
So really, we're talking about a device graph here instead of a tree.
I think the problem is that there are several semi-overlapping trees
when you take into consideration also IRQ routing, power lines, wakeup
signals etc. and this is not so easy to describe.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Wed, Feb 9, 2011 at 4:44 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 02/09/2011 06:28 AM, Markus Armbruster wrote:
Except that construction of a device requires initialization from an
array of variants (which is then type checked). The way we store the
variants is lossy because we convert back and forth to a string.
Yes, there's overlap, but no, a qdev property isn't yet another variant
type scheme. Exhibit A of the defense: qdev uses QemuOpts for variant
types.
Let me elaborate. qdev_device_add() uses QemuOpts as map from name to
variant type value, uses the name to look up the property, then uses
property methods to stuff the variant value it got from QemuOpts into
the (non-variant) struct member described by the property.
I figure QemuOpts was adopted for this purpose because it was already in
use with command line and human monitor. With QMP added to the mix,
there's friction: QMP uses QDict, not QemuOpts.
I'm going to finish QMP before tackling qdev, but at a high level, here's
how I think we fix this.
Right now, qdev only really supports construction properties. In GObject
parlance, this would be properties with G_PARAM_CONSTRUCT_ONLY.
Instead of the current approach of having the construction properties
automagically set as part of the object prior to initfn() being invoked, we
should have an init function that takes the full set of construction only
properties in the native type.
With a schema description of the device's constructor, we can generate code
that invokes the native constructor based on a QemuOpts, or based on a
QDict.
So instead of:
static int serial_isa_initfn(ISADevice *dev);
static ISADeviceInfo serial_isa_info = {
.init = serial_isa_initfn,
.qdev.props = (Property[]) {
DEFINE_PROP_UINT32(index, ISASerialState, index, -1),
DEFINE_PROP_HEX32(iobase, ISASerialState, iobase, -1),
DEFINE_PROP_UINT32(irq, ISASerialState, isairq, -1),
DEFINE_PROP_CHR(chardev, ISASerialState, state.chr),
DEFINE_PROP_END_OF_LIST(),
},
};
We'd have:
void isa_serial_init(ISASerialState *obj, uint32_t index, uint32_t iobase,
uint32_t irq, CharDriverState *chardev, Error **errp);
// isa_serial.json
[ 'ISASerialState', {'index': 'uint32_t', 'iobase': 'uint32_t', 'irq':
'uint32_t', 'chardev': 'CharDriverState *'} ]
From this definition, we can generate code that handles the -device argument
doing conversion from string to the appropriate types while also doing
QObject/GVariant conversion to support the qmp_device_add() interface.
Also, having a well typed constructor means that we can do safer composition
because instead of doing:
DeviceState *dev;
dev = qdev_create(NULL, isa-serial);
qdev_prop_set_uint32(dev, iobase, 0x274);
qdev_prop_set_uint32(dev, irq, 0x07);
qdev_init_nofail(dev);
We can just do:
ISASerialState dev;
isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL);
Do you mean that there should be a generic way of doing that, like
sysbus_create_varargs() for qdev, or just add inline functions which
hide qdev property setup?
I still think that FDT should be used in the future. That would
require that the properties can be set up mechanically, and I don't
see how your proposal would help that.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/09/2011 06:48 PM, Blue Swirl wrote:
We can just do:
ISASerialState dev;
isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL);
Do you mean that there should be a generic way of doing that, like
sysbus_create_varargs() for qdev, or just add inline functions which
hide qdev property setup?
qdev properties are construct-only right now.
What qdev is trying to do is provide a mechanism invoke constructors
through a factory interface where the inputs can come from many places.
Another way of doing this is to just have a normal constructor like:
void isa_serial_init(ISASerialState *dev, uint32_t iobase, ...)
{
dev-iobase = iobase;
}
And then have an (autogenerated) factory proxy:
static ISASerialState *isa_serial_factory(QemuOpts *opts)
{
ISASerialState *isa = qemu_mallocz(sizeof(*isa));
isa_serial_init(isa, qemu_opt_get_int(opts, iobase), ...);
return isa;
}
The advantage of this model is that you can have multiple factory
interfaces to create a device. For instance, you can have a QemuOpts
based factory for -device and a QDict based factory for QMP.
In addition, normal C code doesn't have to deal with any of the factory
interfaces. It can just invoke a normal C interface.
Building the factory interface as an intrinsic part of qdev was a
mistake IMHO.
Regards,
Anthony Liguori
I still think that FDT should be used in the future. That would
require that the properties can be set up mechanically, and I don't
see how your proposal would help that.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/09/2011 06:48 PM, Blue Swirl wrote: ISASerialState dev; isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL); Do you mean that there should be a generic way of doing that, like sysbus_create_varargs() for qdev, or just add inline functions which hide qdev property setup? I still think that FDT should be used in the future. That would require that the properties can be set up mechanically, and I don't see how your proposal would help that. Yeah, I don't think that is a good idea anymore. I think this is part of why we're having so many problems with qdev. While (most?) hardware hierarchies can be represented by device tree syntax, not all valid device trees correspond to interface and/or useful hardware hierarchies. We want to have an interface to create large chunks of hardware (like an i440fx) which then results in a significant portion of a device tree. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguori anth...@codemonkey.ws wrote: On 02/09/2011 06:48 PM, Blue Swirl wrote: ISASerialState dev; isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL); Do you mean that there should be a generic way of doing that, like sysbus_create_varargs() for qdev, or just add inline functions which hide qdev property setup? I still think that FDT should be used in the future. That would require that the properties can be set up mechanically, and I don't see how your proposal would help that. Yeah, I don't think that is a good idea anymore. I think this is part of why we're having so many problems with qdev. While (most?) hardware hierarchies can be represented by device tree syntax, not all valid device trees correspond to interface and/or useful hardware hierarchies. User creates a non-working machine and so gets to fix the problems? How is that a problem for us? We want to have an interface to create large chunks of hardware (like an i440fx) which then results in a significant portion of a device tree. But how would this affect interface to devices? I don't see how that would be any different with current model and the function call model. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/09/2011 09:15 PM, Blue Swirl wrote: On Wed, Feb 9, 2011 at 9:59 PM, Anthony Liguorianth...@codemonkey.ws wrote: On 02/09/2011 06:48 PM, Blue Swirl wrote: ISASerialState dev; isa_serial_init(dev, 0, 0x274, 0x07, NULL, NULL); Do you mean that there should be a generic way of doing that, like sysbus_create_varargs() for qdev, or just add inline functions which hide qdev property setup? I still think that FDT should be used in the future. That would require that the properties can be set up mechanically, and I don't see how your proposal would help that. Yeah, I don't think that is a good idea anymore. I think this is part of why we're having so many problems with qdev. While (most?) hardware hierarchies can be represented by device tree syntax, not all valid device trees correspond to interface and/or useful hardware hierarchies. User creates a non-working machine and so gets to fix the problems? How is that a problem for us? It's not about creating a non-working machine. It's about what user-level abstraction we need to provide. It's a whole lot easier to implement an i440fx device with a fixed set of parameters than it is to make every possible subdevice have a proper factory interface along with mechanisms to hook everything together. Basically, we're making things much harder for ourselves than we should. We want to have an interface to create large chunks of hardware (like an i440fx) which then results in a significant portion of a device tree. But how would this affect interface to devices? I don't see how that would be any different with current model and the function call model. If all composition is done through a factory interface, it doesn't. But my main argument here is that we shouldn't try to make all composition done through a factory interface--only where it makes sense. So very concretely, I'm suggesting we do the following to target-i386: 1) make the i440fx device have an embedded ide controller, piix3, and usb controller that get initialized automatically. The piix3 embeds the PCI-to-ISA bridge along with all of the default ISA devices (rtc, serial, etc.). 2) get rid of the entire concept of machines. Creating a i440fx is essentially equivalent to creating a bare machine. 3) just use the existing -device infrastructure to support all of this. A very simple device config corresponds to a very complex device tree but that's the desired effect. 4) model the CPUs as devices that take a pointer to a host controller, for x86, the normal case would be giving it a pointer to i440fx. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/08/2011 09:55 AM, Chris Wright wrote: Automated builds and testing - found broken 32-bit - luiz suggested running against maintainer trees - daniel gollub offered to take on maintenance - integration with kvm-autotest? - lucas, daniel, stefan... - testing each git commit is probably overkill and too expensive - current autotest run (each 48-hours to batch it up) - stefan currently running once a day, autotest run is 3 hours, so daily should work - need an integration tree to run build test on? - probably still too early The best types of tests are in-tree, built by default, and can be run in less than a few minutes with a simple command invocation and requires no external dependencies. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
Chris Wright chr...@redhat.com writes: [...] - qdev/vmstate both examples of partially completed work that need more attention As far as qdev's concerned, I can see two kinds of to-dos: * Further develop qdev so that more of the machine init code can becomes qdev declarations. Specific ideas welcome. Patches even more, as always. * Convert the remaining devices. They are typically used only with oddball machines, which makes the conversion hard to test for anyone who's not already using them. I've said this before: at some point in time (sooner rather than later, if you ask me), we need to shoot the stragglers. I'm pretty optimistic that any victims worth keeping will receive timely attention then. Anything else? -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 8 February 2011 17:13, Markus Armbruster arm...@redhat.com wrote: As far as qdev's concerned, I can see two kinds of to-dos: * Further develop qdev so that more of the machine init code can becomes qdev declarations. Specific ideas welcome. Patches even more, as always. * Convert the remaining devices. They are typically used only with oddball machines, which makes the conversion hard to test for anyone who's not already using them. I've said this before: at some point in time (sooner rather than later, if you ask me), we need to shoot the stragglers. I'm pretty optimistic that any victims worth keeping will receive timely attention then. So on IRC pbrook wrote: pbrook So we have a bunch of devices that nominally claim to use the qdev infrastructure, but are still making assumptions that qdev was supposed to remove, so break horribly when you actually try to use it as intended. ...and my question is: where is the documentation on how to do a good conversion of a device to qdev, how it works, what the assumptions you can/can't make are, etc ? I can't see anything relevant in the source tree or on the website, but maybe I'm just looking in the wrong places... -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On Tue, Feb 08, 2011 at 06:13:53PM +0100, Markus Armbruster wrote: Chris Wright chr...@redhat.com writes: [...] - qdev/vmstate both examples of partially completed work that need more attention As far as qdev's concerned, I can see two kinds of to-dos: * Further develop qdev so that more of the machine init code can becomes qdev declarations. Specific ideas welcome. Patches even more, as always. * Convert the remaining devices. They are typically used only with oddball machines, which makes the conversion hard to test for anyone who's not already using them. I've said this before: at some point in time (sooner rather than later, if you ask me), we need to shoot the stragglers. I'm pretty optimistic that any victims worth keeping will receive timely attention then. For those oddball machines, qdev doesn't really bring anything, that's why there is so little interest in converting them, and why I prefer to spend my time on the emulation correctness than converting those remaining to qdev. Of course I agree it's something to do, and with an unlimited amount of free time, I'll do them immediately. Let's take for example the SH4 target. It's nice to be able to create the whole machine from a script, except your kernel won't boot if the machine: - has a different cpu - doesn't a SM501 chipset - has not the correct memory size - doesn't have 2 serial port That basically only leaves the PCI and USB devices configurable, but those are already using qdev. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 08.02.2011, at 18:13, Markus Armbruster arm...@redhat.com wrote: Chris Wright chr...@redhat.com writes: [...] - qdev/vmstate both examples of partially completed work that need more attention As far as qdev's concerned, I can see two kinds of to-dos: * Further develop qdev so that more of the machine init code can becomes qdev declarations. Specific ideas welcome. Patches even more, as always. * Convert the remaining devices. They are typically used only with oddball machines, which makes the conversion hard to test for anyone who's not already using them. I've said this before: at some point in time (sooner rather than later, if you ask me), we need to shoot the stragglers. I'm pretty optimistic that any victims worth keeping will receive timely attention then. This is the wrong approach. If you were to change the syntax of kmalloc in Linux and only converted mainstream x86 users, leaving the rest for the subsystem maintainers to figure out, your patch would simply get rejected. Asking for help on conversions is one thing, forcing work on others another. I'd gladly give anyone access to 'oddball' machine images. Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/08/2011 11:13 AM, Markus Armbruster wrote: Chris Wrightchr...@redhat.com writes: [...] - qdev/vmstate both examples of partially completed work that need more attention As far as qdev's concerned, I can see two kinds of to-dos: * Further develop qdev so that more of the machine init code can becomes qdev declarations. Specific ideas welcome. Patches even more, as always. I think we need to improve the i440fx modelling as a lot of the stuff done in the machine init for pc really belongs as part of the i440fx. In theory, creating an i440fx ought to be essentially equivalent to the machine init function today. * Convert the remaining devices. They are typically used only with oddball machines, which makes the conversion hard to test for anyone who's not already using them. I've said this before: at some point in time (sooner rather than later, if you ask me), we need to shoot the stragglers. I'm pretty optimistic that any victims worth keeping will receive timely attention then. Anything else? We need to unify the property model. We have QemuOpts, qdev properties, and QObject which basically reinvents variant typing three different ways. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] KVM call minutes for Feb 8
On 02/08/2011 01:02 PM, Peter Maydell wrote: On 8 February 2011 17:13, Markus Armbrusterarm...@redhat.com wrote: As far as qdev's concerned, I can see two kinds of to-dos: * Further develop qdev so that more of the machine init code can becomes qdev declarations. Specific ideas welcome. Patches even more, as always. * Convert the remaining devices. They are typically used only with oddball machines, which makes the conversion hard to test for anyone who's not already using them. I've said this before: at some point in time (sooner rather than later, if you ask me), we need to shoot the stragglers. I'm pretty optimistic that any victims worth keeping will receive timely attention then. So on IRC pbrook wrote: pbrook So we have a bunch of devices that nominally claim to use the qdev infrastructure, but are still making assumptions that qdev was supposed to remove, so break horribly when you actually try to use it as intended. ...and my question is: where is the documentation on how to do a good conversion of a device to qdev, how it works, what the assumptions you can/can't make are, etc ? It's basically good OOP modelling and the way qdev is structured today makes it very easy to do bad OOP modelling. Regards, Anthony Liguori I can't see anything relevant in the source tree or on the website, but maybe I'm just looking in the wrong places... -- PMM -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
