On Wed, Jul 14, 2010 at 02:53:03PM +0100, Paul Brook wrote:
Memory accesses must go through the IOMMU layer.
No. Devices should not know or care whether an IOMMU is present.
There are real devices that care very much about an IOMMU. Basically all
devices supporting ATS care about
+ --enable-amd-iommu-emul) amd_iommu=yes
+#ifdef CONFIG_AMD_IOMMU
+amd_iommu_init(pci_bus);
+#endif
This should not be a configure option.
Paul
Blue Swirl wrote:
On Sat, Jul 3, 2010 at 7:39 AM, Jan Kiszka jan.kis...@web.de wrote:
Paul Brook wrote:
I really see no tangible objection to Jan's patches. They don't
impact any other code. They don't inhibit flexibility in the
infrastructure. You might consider it to be a hack
Since it solves existing problem and is rejected without any rational
explanation and without proposing alternative solution (in form of code)
it should be committed.
No. This is not sufficient justification for applying a patch. We should not
be accepting patches just because they exist.
If
I really see no tangible objection to Jan's patches. They don't impact
any other code. They don't inhibit flexibility in the infrastructure.
You might consider it to be a hack but so what. QEMU is filled with
hacks. It would be useless without them because there would be very
little code.
Here is the patch again. There may be more work to be done on top of this,
but this patch staying out of tree hasn't noticeably accelerated that work
in the past year and change. Could it please be merged?
As mentioned previously, V5 should be split into its component parts.
Paul
On 06/28/2010 10:29 PM, Paul Brook wrote:
diff --git a/exec-all.h b/exec-all.h
index a775582..ebe88ad 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -353,4 +353,8 @@ extern int singlestep;
/* cpu-exec.c */
extern volatile sig_atomic_t exit_request;
+#ifdef NEED_GLOBAL_ENV
On 06/29/2010 03:51 PM, Paolo Bonzini wrote:
On 06/29/2010 01:30 PM, Paul Brook wrote:
I don't understand what this is supposed to achieve. The inclusion
of exec.h is what defines whether this global variable is
available. Just as importantly, it also prevents code clobbering
this value
BTW, this may be useful for one thing: being able to include exec.h
without bringing in the global variable.
I'd argue that's not a desirable feature. I'd much rather have exec.h be
the controlling factor than have all files include the same set of
headers and have semantics
diff --git a/exec-all.h b/exec-all.h
index a775582..ebe88ad 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -353,4 +353,8 @@ extern int singlestep;
/* cpu-exec.c */
extern volatile sig_atomic_t exit_request;
+#ifdef NEED_GLOBAL_ENV
+register CPUState *env asm(AREG0);
+#endif
Wouldn't it
So I've been looking for a way to obtain things like a PCIDevice from a
more generic structure (say from hw/qdev.h),
If you're having to figure out what kind of a device you have then I think
you're already doing something else wrong. I'd expect the bits of code that
needs to identify devices
Thanks for your reply. This isn't about a specific IOMMU. Let me
describe the situation better:
1. I'm implementing the AMD IOMMU, which is a PCI IOMMU (not in the CPU).
2. Devices need address translation and checking through this IOMMU.
3. But in the future there might be other IOMMU
The user basically can specify two things:
- a transport protocol. Normally this is just the filesystem
interface, but it can also be nbd, http or for really sick people
vvfat. This is a setting which can't be guessed, btw - it needs
to be explicitly set in some way, with file
$ qemu-system-arm -semihosting -cpu cortex-a9 -nographic -kernel
./input.exe
-nographic implies -monitor stdio -serial stdio. Don't do that if you want to
access stdio via semihosting.
Paul
### Paul proposes to require all buses to define bus addresses. Make
one up if necessary.
That seems arbitrary and prone to breakage. How do we handle a subtle
change in device instantiation order and still allow migration? If by
code change or command line ordering my frobnitz
* Else, use TYPE.NUM, where TYPE is derived from the bus type, and NUM
is the bus number, as above.
### Paul proposes to either drop TYPE.NUM (and require drivers to
provide bus names), or make NUM count separately for each bus type.
I revised this proposal: Drop the .NUM part, and
Markus Armbruster wrote:
A number of changes to qdev paths have been proposed in various threads.
It's becoming harder to keep track of them, so let me sum them up in one
place. Please correct me if I misrepresent your ideas.
I'm going to describe the current state of things, and the
Teach strace code about linux specific mprotect flags.
Signed-off-by: Paul Brook p...@codesourcery.com
---
linux-user/strace.c |3 +++
linux-user/syscall_defs.h |6 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/linux-user/strace.c b/linux-user/strace.c
index
Report exit status to GDB when a semihosted application exits.
Signed-off-by: Paul Brook p...@codesourcery.com
---
arm-semi.c |1 +
gdbstub.c | 34 --
gdbstub.h |2 +-
m68k-semi.c |1 +
4 files changed, 23 insertions(+), 15 deletions(-)
diff
When loading a shared library that requires an executable stack,
glibc uses the mprotext PROT_GROWSDOWN flag to achieve this.
We don't support PROT_GROWSDOWN.
Add a special case to handle changing the stack permissions in this way.
Signed-off-by: Paul Brook p...@codesourcery.com
---
linux-user
Bus names are chosen by the system as follows:
* If the driver of the parent device model provides a name, use that.
* Else, if the parent device has id ID, use ID.NUM, where NUM is the bus
number, counting from zero in creation order.
* Else, use TYPE.NUM, where TYPE is
In fact what you really want to do is transfer the device tree
(including properties), and create the machine from scratch, not load
state into a pre-supplied device tree.
Well, I agree, but that's a lot more of an overhaul, and once again
we're changing the problem.
I think it's you
Alex proposed to disambiguate by adding identified properties of the
immediate parent bus and device to the path component. For PCI, these
are dev.fn. Likewise for any other bus where devices have unambigous
bus address. The driver name carries no information!
From user POV, driver
From user POV, driver names are very handly to address a device
intuitively - except for the case you have tones of devices on the same
bus that are handled by the same driver. For that case we need to
augment the device name with a useful per-bus ID, derived from the bus
address where
Paul Brook wrote:
From user POV, driver names are very handly to address a device
intuitively - except for the case you have tones of devices on the
same bus that are handled by the same driver. For that case we need
to augment the device name with a useful per-bus ID, derived from
Works for serial, but fails for ISA devices not occupying an address.
An ISA device without an IO/MMIO capabilities seems extremely unlikely.
What exactly would such a device do?
Inject interrupts via that bus (while exposing registers in some other
way). The m48t59 seems to fall in
Every hotplug-capable bus must have a proper addressing scheme, I think
this is a reasonable and achievable requirement. Then we don't need
instance numbers for those buses.
What about USB?
USB has useful device addresses (physical ports).
These aren't used by most of the higher-level
Every hotplug-capable bus must have a proper addressing scheme, I think
this is a reasonable and achievable requirement. Then we don't need
instance numbers for those buses.
What about USB?
USB has useful device addresses (physical ports).
These aren't used by most of the
On Tue, 2010-06-15 at 12:28 +0100, Paul Brook wrote:
Alex proposed to disambiguate by adding identified properties of the
immediate parent bus and device to the path component. For PCI,
these are dev.fn. Likewise for any other bus where devices have
unambigous bus address
I find this argument contradictory. The migration code already needs to
check whether a device is compatible before it allows migration. The
driver name is not sufficient to ensure compatibility, so I see no
benefit in including it in the device address.
See my comment above, I'm not
* Paul Brook (p...@codesourcery.com) wrote:
I find this argument contradictory. The migration code already needs
to check whether a device is compatible before it allows migration.
The driver name is not sufficient to ensure compatibility, so I see
no benefit in including
See my comment above, I'm not seeing a sufficient argument about
why driver name matching is a false sense of security.
I still say it should be the migration code that checks that both
vmstate structures are for the same type of device. i.e. if
necessary the device name
/main-system-bus/pci.0,addr=09.0/virtio-blk-pci
There's a device missing between the main system bus and the pci bus. Should
be something like:
/main-system-bus/piix4-pcihost/pci.0/_09.0
Could you explain why you add identified properties of the immediate
parent bus and device? They
On Mon, 2010-06-14 at 14:09 +0100, Paul Brook wrote:
/main-system-bus/pci.0,addr=09.0/virtio-blk-pci
There's a device missing between the main system bus and the pci bus.
Should be something like:
/main-system-bus/piix4-pcihost/pci.0/_09.0
Ok, I can easily come up
On Mon, 2010-06-14 at 18:49 +0200, Jan Kiszka wrote:
Alex Williamson wrote:
On Mon, 2010-06-14 at 18:00 +0200, Jan Kiszka wrote:
And instead of introducing another hierarchy level with the bus
address, I would also prefer to add this as prefix or suffix to the
device name, e.g.
Ok, I can get it down to something like:
/i440FX-pcihost/pci.0/virtio-blk-pci,09.0
The addr on the device is initially a little non-intuitive to me since
it's a property of the bus, but I guess it make sense if we think of
that level as slot, which includes an address and
This suggests we are incorrectly coalescing writes, and we should
actually be
notifying qemu when (at least) he first write occurs. If we aren't
outputting
anything we don't want to be waking up periodically just to flush an
empty
MMIO buffer.
That is completely unrelated to
-static void ioapic_reset(void *opaque)
+static void ioapic_reset(DeviceState *d)
{
-IOAPICState *s = opaque;
+IOAPICState *s = container_of(d, IOAPICState, busdev.qdev);
DO_UPCAST()? I hate it, but it's what the other devices do...
Both are used:
grep container_of
Could we just have qemu build the hpet tables and pass them through to
seabios? Perhaps using the qemu_cfg_acpi_additional_tables() method.
Possible, and I considered that. I personally prefer to pass minimum
information required for seabios to discover underlying HW and leave
ACPI
I think we could solve all problems (well, maybe not world peace, yet)
by switching to message based system for all of DMA and IRQs.
Each device would have a message input port and way to output messages.
Examples:
Zero copy memory access from device D1 to D2 to host memory (D3) with
TBH I preferred the original system whereby the source can query the state
of the sink (i.e are you ignoring this line?). Note that conceptually
this should be *querying* state, not responding to an event.
People are still pushing qemu_irq as an message passing interface, so I'm
going to
Move inclusion of stdbool.h to common header files, instead of including
in an ad-hoc manner.
Signed-off-by: Paul Brook p...@codesourcery.com
---
block/blkdebug.c |2 --
check-qjson.c|1 -
dyngen-exec.h|1 +
hw/9p.h |2 --
hw/eepro100.c
For the memory access case, in practice the interface could be
sysbus_memory_rw(DeviceState *parent, target_phys_addr_t addr,
target_phys_addr_t size)
Why parent?
Parent device or bus host bridge device. Alternatively there could be
a bus handle.
A device has no way of knowing
And I think we can move the capability setup into init. But this is not
directly related to this patch, would just avoid adding this hunk to
hpet_reset.
I actually did that initially and tried to init hpet_cfg there too, but
then noticed that mmio[0].addr below is not initialized at init
This patch allows to optionally attach a message to an IRQ event. The
message can contain a payload reference and a callback that the IRQ
handler may invoke to report the delivery result. The former can be used
to model message signaling interrupts, the latter to cleanly implement
IRQ
On Sat, Jun 12, 2010 at 12:21 PM, Paul Brook p...@codesourcery.com wrote:
This patch allows to optionally attach a message to an IRQ event. The
message can contain a payload reference and a callback that the IRQ
handler may invoke to report the delivery result. The former can be used
I think message passing interrupts
are only used in bus based systems, like PCI or UPA/JBUS etc. I don't
know how LAPIC/IOAPIC bus works, it could be similar.
PCI Message Signalled Interrupts use a regular data write, and we model it
exactly that way. Under normal circumstances you program
[*] A simple unidirectional dma request line is suitable for qmu_irq. A
DMA system that transfers data outside of memory read/write transactions
is not. e.g. ISA effectively defines a regular memory bus plus 8
bidirectional data streams (aka DMA channels). These are multiplexed
over the
Note that I *only* object to case 2 (derive bus name from parent
device's ID). Case 3 (derive bus name from bus type) is fine with me.
Using a single counter for all busses is also wrong. The order of bus
creation is a device implementation detail, under no circumstances
should it be
The trouble I'm running into is that the SaveStateEntry.instance_id is
effectively private, and there's no easy way to associate a
SaveStateEntry to a device since it passes an opaque pointer, which
could be whatever the driver decides it wants. I'm wondering if we
should pass the
When combining multiple values as part of a NEON array load, do explcit
shift/or rather than using gen_bfi. This voids redundant mask
operations.
Signed-off-by: Paul Brook p...@codesourcery.com
---
target-arm/translate.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff
+tcg_gen_shli_i32(tmp2, tmp, 16);
+tcg_gen_or_i32(tmp, tmp, tmp2);
Which if you're paying attention is incorrect. Actual committed patch is
correct - tcg_gen_shli_i32(tmp2, tmp2, 16);
Paul
+} else if (timer_fsb_route(timer)) {
+apic_send_msi(timer-fsb 32, timer-fsb 0x);
This should use a regular memory write, like the PCI MSI-X code does.
Paul
For usb hid devices: No idea how they work and whenever we can put them
into sleep somehow (with/without guest cooperation).
The issue with USB is that it is (by design) a polled system. The UHCI adapter
has to wakeup every 1ms to read transfer descriptors from guest RAM.
Until recently there
On Thu, 2010-06-10 at 10:23 +0200, Gerd Hoffmann wrote:
I may have been a bit misleading here. What we really want to do is use
the same matching algorithm as is used by the rest of the device
state. Currently this is a vmstate name and [arbitrary] numeric id. I
don't remember whether
to the identify the device. It should probably do this the same way
that we identify the saved state for the device. Currently I think
this is an arbitrary vmstate name/id, but I expect this to change to a
qdev address (e.g. /i440FX-pcihost/pci.0/_addr_04.0).
Ok, that seems
Not all ram is associated with a device.
Maybe not, but where it is we should be using that information.
Absolute minimum we should be using the existing qdev address rather than
inventing a new one. Duplicating this logic inside every device seems
like a bad idea so I suggest
* Alex Williamson (alex.william...@redhat.com) wrote:
+// XXX check duplicates
Yes, definitely. You created a notion of a hierarchical namespace,
can this be formalized any more?
We already have one: The qdev tree.
Paul
Keep in mind, this has to be a stable string across versions of qemu
since this is savevm/migration. Are we absolutely confident that the
full qdev path isn't going to change? I'm more confident that a unique
device name is going to be static across qemu versions.
The actual representation
Because at some point the base tree will have to be written in C.
No. You can start with a completely empty machine.
We don't/shouldn't need any machine specific C code.
I think you're missing the argument. I should be possible to create a
machine entirely from a FDT or via -device
Not really. This identifier is device and bus independent, which is why
I suggested passing the device to qemu_ram_alloc. This can then figure
out how to the identify the device. It should probably do this the same
way that we identify the saved state for the device. Currently I think
I'm undecided how much parameterisation it's worth trying to support in
the device tree. IMO the current code has way too much magic, because
creating a new variant involves hacking and rebuilding pc.c.
See patch 22/22. There is really no magic involved, even though the
compat machines
I see three possible options to handle this.
(1) Write a hub (or morph the current vlan code into this). Then
you can do something like:
qemu -netdev socket,id=p1 \
-netdev user,id=p2 \
-netdev dump,id=p3 \
The problem I was trying to address can be seen with something like:
-drive file=foo.img,if=virtio,file=bar.img
You get no error, and foo.img is what gets used. It's fair to argue
this is a silly use case but what I'm trying to achieve is to make it
possible to do:
-drive
Once you eliminate machine_register_core that knowledge has
somehow got to come from your device tree description file. Having a
single device tree that can morph into significantly different machines
seems like unnecessary complexity given this is a user-specified file.
99% of
Once you eliminate machine_register_core that knowledge has
somehow got to come from your device tree description file. Having a
single device tree that can morph into significantly different machines
seems like unnecessary complexity given this is a user-specified file.
99% of
The offset given to a block created via qemu_ram_alloc/map() is arbitrary,
let the caller specify a name so we can make a positive match.
@@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev)
+snprintf(name, sizeof(name), pci:%02x.%x.rom,
+
On 06/08/2010 09:30 PM, Paul Brook wrote:
The offset given to a block created via qemu_ram_alloc/map() is
arbitrary, let the caller specify a name so we can make a positive
match.
@@ -1924,7 +1925,9 @@ static int pci_add_option_rom(PCIDevice *pdev)
+snprintf(name, sizeof(name
Kill nographic timer. Have a global gui_timer instead. Have the gui
timer enabled unconditionally. We need a timer running anyway for mmio
flush, so the whole have-gui-timer-only-when-needed logic is pretty
pointless. It also simplifies displaylisteners coming and going at
runtime, we
With -netdev, there now seems to be little need to support vlans,
enabling them leads to user confusion and bad performance.
Disable support for vlans by default, add config option to enable.
No. If you want to remove vlans, then actually do that.
As I've said before if you want a point-point
On Mon, Jun 07, 2010 at 05:16:30PM +0100, Paul Brook wrote:
With -netdev, there now seems to be little need to support vlans,
enabling them leads to user confusion and bad performance.
Disable support for vlans by default, add config option to enable.
No. If you want to remove vlans
diff --git a/hw/realview.c b/hw/realview.c
index a36bdbe..8dcef80 100644
--- a/hw/realview.c
+++ b/hw/realview.c
@@ -444,9 +444,9 @@ static QEMUMachine realview_eb_mpcore_machine = {
.init = realview_eb_mpcore_init,
.opts_default = (QemuOptValue[]) {
This series introduces a rather radical change in the way we deal with
machine definitions in QEMU.
I think we should aim to eliminate machine_register_core, and design
appropriately. In particular I'd try and avoid adding options that become
trivially redundant once you can easily change
Paul Brook p...@codesourcery.com writes:
Also require IDs to start with a letter to provide for possible future
extensions.
I'd go further than that, and require that user specified IDs match
[A-Za-z][A-Za-z0-9_-]*
I talked with Dan (cc'ed) to make sure we don't trample on existing
Also require IDs to start with a letter to provide for possible future
extensions.
I'd go further than that, and require that user specified IDs match
[A-Za-z][A-Za-z0-9_-]*
Paul
I'm trying to get arm big endian support to work. I patched the 2.6.33
kernel to pretend that good old versatilepb can have a big endian CPU
plugged into it (attached), and then I built a kernel with the attached
.config, and qemu went boing:
That's about the result I'd expect. The fact that
the irqchip option, if you note, is not x86-specific, in any case.
Any machine has an irqchip. The first idea was to use something like
apic=in_kernel|userspace which would be, that, very x86-centric.
How is this not x86-pc specific? All you're doing is creating two different
machines, one
The problem is that the ID names of default devices in machines are ABI
sensitive. Management apps need to know what the ID of these default
devices are. The x86 machines have already used 'pci.0' as their name
in the previous 0.12 release and libvirt is using this naming. We later
discovered
Paul Brook p...@codesourcery.com writes:
The system emulators for each arch are using inconsistent
naming for the default PCI bus pci vs pci.0. Since it
is conceivable we'll have multiple PCI buses in the future
standardize on pci.0 for all architectures. This ensures
mgmt apps can rely
Re: 68a1c816868b3e35a1da698af412b29e61b1948a
In general, I like the idea (especially since I've proposed it before. ;-)
However:
+if (have_guest_base) {
+flags |= MAP_FIXED;
+}
I think this is broken. If the user specifies -G n -R m they're hoping
or
Hi,
I disagree. Anything that depends on device creation order is
fundamentally broken. If you want to create globally unique
user-friendly tags for devices or busses then that is a completely
different problem, and should be done via explicit aliases.
For anything created via
From pthread man:
These functions manipulate the calling thread's stack of
thread-cancellation clean-up handlers. A clean-up handler is
a function that is automatically executed when a thread is canceled
[...] it might, for example, unlock a mutex so that it becomes
available to
From: Jan Kiszka jan.kis...@siemens.com
As long as we allow /dev.1 as shortcut for /dev1/bus1, we also have to
make sure that /dev1/dev2 works for /dev1/bus1/dev2/bus2 - as long as
there is only one child bus per device.
How about we make this explicit in the syntax by having a different
On Fri, May 28, 2010 at 7:34 PM, Paul Brook p...@codesourcery.com wrote:
Use a qemu_irq to request CPU exit.
Needing to request a CPU exit at all is just wrong. See previous
discussions about how any use of qemu_bh_schedule_idle is fundamentally
broken.
I agree for the device case
Try to pci hotplug a vga card, watch qemu die with hw_error().
This patch fixes it.
I think this is wrong. There's no reason why VGA adapters shouldn't be
hotplugged. You should fix the underlying problems that prevent hotplugging
(or make them fail gracefully).
Paul
The problem is that this path is never used as tsr_retry is never 0
initially. So if qemu_chr_write() fails, we never try again but drop
qemu_chr_write is a blocking interface. It should only fail if an
unrecoverable error occurs. In that case there's noting useful we can do, and
no reason
Use a qemu_irq to request CPU exit.
Needing to request a CPU exit at all is just wrong. See previous discussions
about how any use of qemu_bh_schedule_idle is fundamentally broken.
Paul
The system emulators for each arch are using inconsistent
naming for the default PCI bus pci vs pci.0. Since it
is conceivable we'll have multiple PCI buses in the future
standardize on pci.0 for all architectures. This ensures
mgmt apps can rely on a name when assigning PCI devices an
The basic device interface looks like
...
+
+/* Register a memory region at START_ADDR/SIZE. The REGION structure will
+ be initialized appropriately for DEV using CB as the operation set. */
+extern void cpu_register_memory_region(MemoryRegion *region,
+
[Hit send too early on previous mail...]
The basic device interface looks like
...
+
+/* Register a memory region at START_ADDR/SIZE. The REGION structure will
+ be initialized appropriately for DEV using CB as the operation set. */
+extern void cpu_register_memory_region(MemoryRegion
In some cases we don't even do that, and just reschedule the event some
arbitrarily small amount of time later. This assumes the guest to do
useful work in that time. In a single threaded environment this is
probably true - qemu got enough CPU to inject the first interrupt, so
will
Then the amount
of CPU cycles between timer interrupts would increase and hopefully
the guest can keep up. If the guest sleeps, time base could be
accelerated to catch up with wall clock and then set back to 1:1 rate.
Can't follow you ATM, sorry. What should be slowed down then? And
At the other extreme, would it be possible to make the educated guests
aware of the virtualization also in clock aspect: virtio-clock?
The guest doesn't even need to be aware of virtualization. It just needs to be
able to accommodate the lack of guaranteed realtime behavior.
The fundamental
for (i = 0; i 24; i++) {
sysbus_connect_irq(sysbus_from_qdev(hpet), i, isa_irq[i]);
}
+rtc_irq = qemu_allocate_feedback_irqs(hpet_handle_rtc_irq,
+ sysbus_from_qdev(hpet), 1);
}
This is wrong. The hpet
+static SysBusDeviceInfo hpet_device_info = {
+.qdev.name= hpet,
+.qdev.size= sizeof(HPETState),
+.qdev.no_user = 1,
Why shouldn't the user create HPET devices? I thought you'd removed all the
global state.
Paul
This is wrong. The hpet device should expose this as an IO pin.
Will look into this.
BTW, I just realized that the GPIO handling is apparently lacking
support for attaching an output to multiple inputs. Or am I missing
something?
Use an explicit mux.
Incidentally I suspect your
Paul Brook wrote:
This is wrong. The hpet device should expose this as an IO pin.
Will look into this.
BTW, I just realized that the GPIO handling is apparently lacking
support for attaching an output to multiple inputs. Or am I missing
something?
Use an explicit mux
I realise that. However I'd expect things to break if the guest OS
devices to share an IRQ line between the HPET and some other device.
The guest would share IRQ8, not the RTC output. So there would be no
difference to the current situation.
The difference is that you've removed the check
+int is_ioport_assigned(pio_addr_t addr)
Shouldn't we move this into register_ioport_{read,write}, and have that fail
if the port has already been assigned?
Paul
Notice that this patch was sent against hpet as one example, if we agree
that this way of disabling devices is ok, we could disable more
devices/have more flexibility. Notice that in general, we (RHEL/KVM)
are interested in a small subset of qemu devices.
IMO this patch is a backwards step.
301 - 400 of 1522 matches
Mail list logo
