Re: [Qemu-devel] scsi-generic and max request size
On 12/21/2010 04:52 AM, Benjamin Herrenschmidt wrote: > On Tue, 2010-12-21 at 14:38 +1100, ronnie sahlberg wrote: >> Ben, >> >> Since it is a scsi device you can try the Inquiry command with >> pagecode 0xb0 : Block Limit VPD Page. >> That pages show optimal and maximum request sizes. >> >> This is for SBC, in the Vital Product Data chapter. >> >> Unfortunately this page is not mandatory so some devices might not >> understand it. :-( >> >> sg_inq --page=0x00 /dev/sg? >> will show you what inq pages your device supports. > > Well, that won't help much figuring what the limit is since in most case > the limit seems to come from the host linux HBA (ie, usb-storage for > example artificially clamps the max request size to deal with bogus > USB-ATA bridges). > Indeed. The request size is pretty much limited by the driver/scsi layer, so the above page won't help much here. > As for using this to try to "inform" the guest OS as to what the limit > is, this could be done by "patching" the result of that command on the > fly in qemu, but that is nasty, and would only work if the guest OS > actually uses the said command in the first place. AFAIK, neither sr.c > nor sd.c do in Linux. > And you'll be getting yelled at by hch to boot. > So back to square 1 ... my vscsi (and virtio-blk too btw) can > technically pass a max size to the guest, but we don't have a way to > interrogate scsi-generic (and the underlying block driver) which is the > main issue (that plus the fact that the ioctl seems to be broken in > "compat" mode for /dev/sg specifically)... > Ah, the warm and fuzzy feeling knowing to be not alone in this ... This is basically the same issue I brought up with the first submission round of my megasas emulation. As we're passing scatter-gather lists directly to the underlying device we might end up sending a request which is improperly formatted. The linux block layer has three limits onto which a request has to be formatted: - Max length of the scatter-gather list (max_sectors) - Max overall request size (max_segments) - Max length of individual sg elements (max_segment_size) newer kernels export these limits; they have been exported with commit c77a5710b7e23847bfdb81fcaa10b585f65c960a. For older kernels, however, we're being left in the dark here. So on newer kernel we probably could be doing a quick check on the block queue limits and reformat the I/O if required. Instead of reformatting we could be sendiong each element of an eg list individually. Thereby we would be introducing some slowdown as the sg lists have to be reassembled again by the lower layers, but we would be insulated from any sg list mismatch. However, this won't cover requests with too large sg elements. For those we could probably use some simple divide-by-two algorithm on the element to make them fit. But seeing we have to split the I/O requests anyway we might as well use the divide-by-two algorithm for the sg lists, too. Easiest would be if we could just transfer the available bits and push the request back to the guest as a partial completion. Sadly the I/O stack on the guest will choose to interpret this as an I/O error instead of retrying the remainder :-( So in the long run I fear we have to implement some sort of I/O request splitting in Qemu, using the values from sysfs. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg)
[Qemu-devel] Re: Re: Z80 emulation updated again!
>>> Here's an update of the Z80 system emulator, which currently emulates >>> the ZX Spectrum only. [...] >> >> [...] do you think it's a valuable target to have in upstream qemu? > > The z80 was also used in the more modern TI-83 Plus programmable calculator > [1], for instance (chosen for school use in Baden-Württemberg in the early > 2000s). There was Yes, all Ti8x models except 89 (and 92 which are 68000 based) are z80 based. There are already several emulators to compare to. > an assembler toolchain integrated with Zilog Studio on Windows iirc. > Apparently there's also an open source C compiler toolchain at [2] for these > and other targets. > No Linux that I'm aware of. ;) http://sdcc.sourceforge.net/ ? I'm not sure if we ever had a ti-specific z80 compiler like tigcc was for 68k-based models, maybe check on http://www.ticalc.org/ François.
Re: [Qemu-devel] libqemu.a not made with version 0.13
On 12/20/2010 07:31 PM, Blue Swirl wrote: Are you aware of QEMU-SystemC: http://www.greensocs.com/projects/QEMUSystemC Perhaps that would be a better starting point than plain QEMU. Hi! Thank you! Sure I already checked this project! I googled all the web for QEMU technical documents:) Even Chinese pages :D QEMU-SystemC is great for electronic engineers, offering mixed simulation capabilities between QEMU devices and early SystemC designs (modules).. Engineers can test interaction of new devices since their first design with full systems .. Anyway that project simply allows QEMU to plug in a full architecture new SystemC modules through a bridge .. My goal is opposite, I want SystemC to use a little part of QEMU only as a binary translation engine between PPC and i386 machines .. Moreover that project is not updated to last QEMU version.. Surely I'll go back to it in case I don't manage to make SystemC sources compile fine with QEMU stuff .. Thank You! Best Regards! Stefano B.
Re: [Qemu-devel] [PATCH] Z80 emulation updated again!
On 21.12.2010, at 02:24, Andreas Färber wrote: > Am 21.12.2010 um 01:10 schrieb Alexander Graf: > >> On 21.12.2010, at 01:06, Andreas Färber wrote: >> >>> Am 20.12.2010 um 23:45 schrieb Alexander Graf: >>> On 31.05.2009, at 17:20, Stuart Brady wrote: > Here's an update of the Z80 system emulator, which currently emulates > the ZX Spectrum only. [...] [...] do you think it's a valuable target to have in upstream qemu? >>> >>> The z80 was also used in the more modern TI-83 Plus programmable calculator >>> [1], for instance >> >> The general I/O framework is heavily geared towards server and desktop use. >> The main use case of the Z80 that I'm aware of is the GameBoy. Not sure that >> one fits in there too well :). >> >> The Spectrum however does fit the desktop case, so it certainly has my >> blessings. > > Knowing the ZX Spectrum only from the attic, I agree that emulating game > consoles is not the primary purpose or strength of QEMU. > (Although I wouldn't mind if someone wanted to contribute a PS3 machine for > Cell B.E. emulation!) > > Fwiw mips, arm, m68k, cris, microblaze seem to form a growing third category > of QEMU targets though, embedded systems. Oh, sure. I'd count in embedded systems here too. My main point was that we don't have frameworks to deal with Joysticks, 3D or other stuff real game system emulation would need. To be honest, maybe creating a library out of the CPU emulation code that projects like MAME could then use might prove more beneficial. I've thought about this for plenty other projects too. GBA emulation could use ARM TCG, Dolphin could use PPC TCG, etc. But none of these actually require our device model - they already have their own. Alex
Re: [Qemu-devel] Re: [PATCH] sparc32: ledma extra registers
On Mon, Dec 20, 2010 at 6:33 PM, Bob Breuer wrote:
> Artyom Tarasenko wrote:
>> On Sun, Dec 19, 2010 at 8:37 PM, Bob Breuer wrote:
>>
>>> Andreas Färber wrote:
>>>
Am 18.12.2010 um 19:53 schrieb Blue Swirl:
> On Sat, Dec 18, 2010 at 5:09 PM, Bob Breuer wrote:
>
>> ledma has 0x20 bytes of registers according to OBP, and at least
>> Solaris9
>> reads the 5th register which is beyond what we've mapped. So let's
>> setup
>> a flag (inspired by a previous patch from Blue Swirl) to identify ledma
>> from espdma, and map another 16 bytes of registers which return 0.
>>
>> Signed-off-by: Bob Breuer
>>
I'm not familar with that part of code but...
>> diff --git a/hw/sparc32_dma.c b/hw/sparc32_dma.c
>> index e78f025..56be8c8 100644
>> --- a/hw/sparc32_dma.c
>> +++ b/hw/sparc32_dma.c
>>
>> @@ -165,6 +169,9 @@ static uint32_t dma_mem_readl(void *opaque,
>> target_phys_addr_t addr)
>> DMAState *s = opaque;
>> uint32_t saddr;
>>
>> + if (s->is_ledma && (addr > DMA_MAX_REG_OFFSET)) {
>> + return 0; /* extra mystery register(s) */
>>
Wouldn't it be a good idea to trace these "mystery" reads...
>> + }
>> saddr = (addr & DMA_MASK) >> 2;
>> trace_sparc32_dma_mem_readl(addr, s->dmaregs[saddr]);
>> return s->dmaregs[saddr];
>> @@ -175,6 +182,9 @@ static void dma_mem_writel(void *opaque,
>> target_phys_addr_t addr, uint32_t val)
>> DMAState *s = opaque;
>> uint32_t saddr;
>>
>> + if (s->is_ledma && (addr > DMA_MAX_REG_OFFSET)) {
>> + return; /* extra mystery register(s) */
>>
...and writes? We return just before the tracepoints fire.
>>> Ok, I'll put together a patch to add the trace calls just before the
>>> returns. How about I also call it undocumented instead of mystery.
>>> None of the BSD's or Linux know about or use anything beyond the 4
>>> registers.
>>>
>>
>> I'd use "aliased" instead of mystery. On a real SS-5:
>>
>> ok 78400020 20 spacel@ .
>> a4240050
>> ok 7840 20 spacel@ .
>> a4240050
>> ok 78400024 20 spacel@ .
>> fc004000
>> ok 7844 20 spacel@ .
>> fc004000
>>
> Verified that it also aliases on an SS-20.
>> Addresses 0x7840002x are aliases for 0x784x. As well as
>> 0x7840004x. And so on up to
>> ok 787fffe4 20 spacel@ .
>> fc004000
>> 7884 20 spacel@ .
>> 0
>>
>> Or a real SS-20 ef040 is aliased up to ef37fffe0
>>
>> Fwiw I think it's a bug in the later Solaris versions:
>> http://tyom.blogspot.com/2010/10/bug-in-all-solaris-versions-after-57.html
>>
>> On the bare metal it works because of address aliasing. If you want to
>> emulate the hw precisely, the Blue's generic aliasing patch can be
>> used here. The question is though do we want to do a generic aliasing
>> for all the SBUS devices, or just in the single case(es) where we know
>> is necessary.
>>
>> On the other hand Solaris seems to be fine with a 0 stub too.
>>
> I'll send a patch to update the comments. If it's accessing a wrong
> register because of a bug, then it may not matter what value is returned.
I think the value is important, but the tests show that 0 is fine.
--
Regards,
Artyom Tarasenko
solaris/sparc under qemu blog: http://tyom.blogspot.com/
Re: [Qemu-devel] Re: Re: Z80 emulation updated again!
On Tue, Dec 21, 2010 at 10:04:56AM +0100, François Revol wrote: > >>> Here's an update of the Z80 system emulator, which currently emulates > >>> the ZX Spectrum only. [...] > >> > >> [...] do you think it's a valuable target to have in upstream qemu? > > > > The z80 was also used in the more modern TI-83 Plus programmable calculator > > [1], for instance (chosen for school use in Baden-Württemberg in the early > > 2000s). There was > > Yes, all Ti8x models except 89 (and 92 which are 68000 based) are z80 based. > There are already several emulators to compare to. The TI-83 was a great calculator. At one point there was a community and quite a few games for it :). The issue with emulating it is that you need a proprietary ROM that can't be redistributed. I think the same goes for the other TI graphing calculators. Stefan
Re: [Qemu-devel] [PATCH] Z80 emulation updated again!
On Tue, Dec 21, 2010 at 1:06 AM, Andreas Färber wrote: > Am 20.12.2010 um 23:45 schrieb Alexander Graf: > >> On 31.05.2009, at 17:20, Stuart Brady wrote: >> >>> Here's an update of the Z80 system emulator, which currently emulates >>> the ZX Spectrum only. [...] >> >> [...] do you think it's a valuable target to have in upstream qemu? > > The z80 was also used in the more modern TI-83 Plus programmable calculator > [1], for instance (chosen for school use in Baden-Württemberg in the early > 2000s). There was an assembler toolchain integrated with Zilog Studio on > Windows iirc. > Apparently there's also an open source C compiler toolchain at [2] for these > and other targets. > No Linux that I'm aware of. ;) But there are UZI and UZIX - unix like environments with TCP/IP stack and Bourne Shell. UZIX requires a MSX2 computer though. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device
On Thu, Dec 16, 2010 at 10:36:08AM +0200, Michael S. Tsirkin wrote: > On Thu, Dec 16, 2010 at 04:08:16PM +0900, Isaku Yamahata wrote: > > On Wed, Dec 15, 2010 at 08:27:49AM -0700, Alex Williamson wrote: > > > On Wed, 2010-12-15 at 11:56 +0200, Michael S. Tsirkin wrote: > > > > On Tue, Dec 14, 2010 at 11:34:53AM -0700, Alex Williamson wrote: > > > > > On Tue, 2010-12-14 at 14:26 +0200, Michael S. Tsirkin wrote: > > > > > > On Mon, Dec 13, 2010 at 10:04:24PM -0700, Alex Williamson wrote: > > > > > > > > > > > > > > I've only ever seen config[PCI_SECONDARY_BUS] be non-zero for an > > > > > > > assigned device, so I'm pretty sure we're not going to hurt > > > > > > > migration, > > > > > > > but the code is clearly wrong and I'd like to make sure we don't > > > > > > > trip on > > > > > > > a migration failure for a minor device config space change. > > > > > > > > > > > > Which reminds me: maybe just mark nested bridges as non-migrateable > > > > > > for now? Care writing such a patch? > > > > > > > > > > Hmm, this is trickier than it sounds. > > > > > > > > Hmm, since 0 is put in the path instead of the bridge number, > > > > will the correct bridge be restored? > > > > > > > > > We're really only broken wrt > > > > > migration if a device under a bridge calls qemu_ram_alloc. > > > > > > > > I guess there's more broken-ness. What exactly breaks qemu_ram_alloc? > > > > > > You're right, it's more broken than that. Anything that calls > > > get_dev_path is broken for migration of bridges since the path is > > > determined before the guest updates bus numbers. That includes > > > qemu_ram_alloc and vmstate. I was only looking at the qemu_ram_alloc > > > side. So perhaps the right answer, for the moment, is to block > > > migration if there's a p2p bridge. > > > > Eww. That's bad. Anyway, I agree to disable it for the moment. > > Patch? Although I'm willing to create patch, how to disable the migration? As long as I know, Alex Williamson had tried to push the patch series "Save state error handling (kill off no_migrate)", they haven't been merged. If they are merged in, it seems quite easy to disable the migration. Anyway register_device_unmigratable() seems to need some clean up for DeviceInfo::vmsd. Any ideas? -- yamahata
Re: [Qemu-devel] Re: Re: Z80 emulation updated again!
Le 21 déc. 2010 à 10:41, Stefan Hajnoczi a écrit : >> >> Yes, all Ti8x models except 89 (and 92 which are 68000 based) are z80 based. >> There are already several emulators to compare to. > > The TI-83 was a great calculator. At one point there was a community > and quite a few games for it :). > > The issue with emulating it is that you need a proprietary ROM that > can't be redistributed. I think the same goes for the other TI graphing > calculators. Yes, though Ti never caused trouble with this on emulators AFAIK. OTH they did send a DMCA letter to those who breached their signing process to make their own flash app. François.
Re: [Qemu-devel] Re: [PATCH] PCI: Bus number from the bridge, not the device
On Tue, Dec 21, 2010 at 07:13:57PM +0900, Isaku Yamahata wrote: > On Thu, Dec 16, 2010 at 10:36:08AM +0200, Michael S. Tsirkin wrote: > > On Thu, Dec 16, 2010 at 04:08:16PM +0900, Isaku Yamahata wrote: > > > On Wed, Dec 15, 2010 at 08:27:49AM -0700, Alex Williamson wrote: > > > > On Wed, 2010-12-15 at 11:56 +0200, Michael S. Tsirkin wrote: > > > > > On Tue, Dec 14, 2010 at 11:34:53AM -0700, Alex Williamson wrote: > > > > > > On Tue, 2010-12-14 at 14:26 +0200, Michael S. Tsirkin wrote: > > > > > > > On Mon, Dec 13, 2010 at 10:04:24PM -0700, Alex Williamson wrote: > > > > > > > > > > > > > > > > I've only ever seen config[PCI_SECONDARY_BUS] be non-zero for an > > > > > > > > assigned device, so I'm pretty sure we're not going to hurt > > > > > > > > migration, > > > > > > > > but the code is clearly wrong and I'd like to make sure we > > > > > > > > don't trip on > > > > > > > > a migration failure for a minor device config space change. > > > > > > > > > > > > > > Which reminds me: maybe just mark nested bridges as > > > > > > > non-migrateable > > > > > > > for now? Care writing such a patch? > > > > > > > > > > > > Hmm, this is trickier than it sounds. > > > > > > > > > > Hmm, since 0 is put in the path instead of the bridge number, > > > > > will the correct bridge be restored? > > > > > > > > > > > We're really only broken wrt > > > > > > migration if a device under a bridge calls qemu_ram_alloc. > > > > > > > > > > I guess there's more broken-ness. What exactly breaks qemu_ram_alloc? > > > > > > > > You're right, it's more broken than that. Anything that calls > > > > get_dev_path is broken for migration of bridges since the path is > > > > determined before the guest updates bus numbers. That includes > > > > qemu_ram_alloc and vmstate. I was only looking at the qemu_ram_alloc > > > > side. So perhaps the right answer, for the moment, is to block > > > > migration if there's a p2p bridge. > > > > > > Eww. That's bad. Anyway, I agree to disable it for the moment. > > > > Patch? > > Although I'm willing to create patch, how to disable the migration? Set the no_migrate flag in SaveStateEntry. > As long as I know, Alex Williamson had tried to push the patch series > "Save state error handling (kill off no_migrate)", they haven't been > merged. > If they are merged in, it seems quite easy to disable the migration. These look unlikely to be merged: they seem to go contrary to the table-driver approach to migration that we are trying to take. > Anyway register_device_unmigratable() seems to need some clean up > for DeviceInfo::vmsd. Any ideas? So clean it up if you like. > -- > yamahata
[Qemu-devel] [PATCH] xio3130: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt diff --git a/hw/xio3130_downstream.c b/hw/xio3130_downstream.c index 1a2d258..fe16475 100644 --- a/hw/xio3130_downstream.c +++ b/hw/xio3130_downstream.c @@ -71,7 +71,7 @@ static int xio3130_downstream_initfn(PCIDevice *d) pcie_port_init_reg(d); pci_config_set_vendor_id(d->config, PCI_VENDOR_ID_TI); pci_config_set_device_id(d->config, PCI_DEVICE_ID_TI_XIO3130D); -d->config[PCI_REVISION_ID] = XIO3130_REVISION; +pci_config_set_revision(d->config, XIO3130_REVISION); rc = msi_init(d, XIO3130_MSI_OFFSET, XIO3130_MSI_NR_VECTOR, XIO3130_MSI_SUPPORTED_FLAGS & PCI_MSI_FLAGS_64BIT, diff --git a/hw/xio3130_upstream.c b/hw/xio3130_upstream.c index 387bf6c..bd2b452 100644 --- a/hw/xio3130_upstream.c +++ b/hw/xio3130_upstream.c @@ -67,7 +67,7 @@ static int xio3130_upstream_initfn(PCIDevice *d) pcie_port_init_reg(d); pci_config_set_vendor_id(d->config, PCI_VENDOR_ID_TI); pci_config_set_device_id(d->config, PCI_DEVICE_ID_TI_XIO3130U); -d->config[PCI_REVISION_ID] = XIO3130_REVISION; +pci_config_set_revision(d->config, XIO3130_REVISION); rc = msi_init(d, XIO3130_MSI_OFFSET, XIO3130_MSI_NR_VECTOR, XIO3130_MSI_SUPPORTED_FLAGS & PCI_MSI_FLAGS_64BIT,
[Qemu-devel] [PATCH] ioh3420: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt diff --git a/hw/ioh3420.c b/hw/ioh3420.c index 95adf09..25ed2eb 100644 --- a/hw/ioh3420.c +++ b/hw/ioh3420.c @@ -104,7 +104,7 @@ static int ioh3420_initfn(PCIDevice *d) return rc; } -d->config[PCI_REVISION_ID] = PCI_DEVICE_ID_IOH_REV; +pci_config_set_revision(d->config, PCI_DEVICE_ID_IOH_REV); pcie_port_init_reg(d); pci_config_set_vendor_id(d->config, PCI_VENDOR_ID_INTEL);
[Qemu-devel] [PATCH] dec_pci: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt diff --git a/hw/dec_pci.c b/hw/dec_pci.c index bf88f2a..75dd373 100644 --- a/hw/dec_pci.c +++ b/hw/dec_pci.c @@ -110,7 +110,7 @@ static int dec_21154_pci_host_init(PCIDevice *d) /* PCI2PCI bridge same values as PearPC - check this */ pci_config_set_vendor_id(d->config, PCI_VENDOR_ID_DEC); pci_config_set_device_id(d->config, PCI_DEVICE_ID_DEC_21154); -pci_set_byte(d->config + PCI_REVISION_ID, 0x02); +pci_config_set_revision(d->config, 0x02); pci_config_set_class(d->config, PCI_CLASS_BRIDGE_PCI); return 0; }
[Qemu-devel] [PATCH] apb_pci: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt diff --git a/hw/apb_pci.c b/hw/apb_pci.c index 84e9af7..97b3032 100644 --- a/hw/apb_pci.c +++ b/hw/apb_pci.c @@ -321,7 +321,7 @@ static int apb_pci_bridge_initfn(PCIDevice *dev) pci_set_word(dev->config + PCI_STATUS, PCI_STATUS_FAST_BACK | PCI_STATUS_66MHZ | PCI_STATUS_DEVSEL_MEDIUM); -pci_set_byte(dev->config + PCI_REVISION_ID, 0x11); +pci_config_set_revision(dev->config, 0x11); return 0; }
Re: [Qemu-devel] [PATCH] Z80 emulation updated again!
On Tue, Dec 21, 2010 at 10:25 AM, Alexander Graf wrote: > > On 21.12.2010, at 02:24, Andreas Färber wrote: > >> Am 21.12.2010 um 01:10 schrieb Alexander Graf: >> >>> On 21.12.2010, at 01:06, Andreas Färber wrote: >>> Am 20.12.2010 um 23:45 schrieb Alexander Graf: > On 31.05.2009, at 17:20, Stuart Brady wrote: > >> Here's an update of the Z80 system emulator, which currently emulates >> the ZX Spectrum only. [...] > > [...] do you think it's a valuable target to have in upstream qemu? The z80 was also used in the more modern TI-83 Plus programmable calculator [1], for instance >>> >>> The general I/O framework is heavily geared towards server and desktop use. >>> The main use case of the Z80 that I'm aware of is the GameBoy. Not sure >>> that one fits in there too well :). >>> >>> The Spectrum however does fit the desktop case, so it certainly has my >>> blessings. >> >> Knowing the ZX Spectrum only from the attic, I agree that emulating game >> consoles is not the primary purpose or strength of QEMU. >> (Although I wouldn't mind if someone wanted to contribute a PS3 machine for >> Cell B.E. emulation!) >> >> Fwiw mips, arm, m68k, cris, microblaze seem to form a growing third category >> of QEMU targets though, embedded systems. > > Oh, sure. I'd count in embedded systems here too. My main point was that we > don't have frameworks to deal with Joysticks, 3D or other stuff real game > system emulation would need. With the emulation of the ancient machine based game platform it is even more complicated: games expect some certain timings from the CPU, graphic and sound cards. So, I'm not sure if TCG can be used for it. > To be honest, maybe creating a library out of the CPU emulation code that > projects like MAME could then use might prove more beneficial. I've thought > about this for plenty other projects too. GBA emulation could use ARM TCG, > Dolphin could use PPC TCG, etc. But none of these actually require our device > model - they already have their own. > > > Alex > > > -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/
Re: [Qemu-devel] [PATCH] Z80 emulation updated again!
On 21.12.2010, at 12:14, Artyom Tarasenko wrote: > On Tue, Dec 21, 2010 at 10:25 AM, Alexander Graf wrote: >> >> On 21.12.2010, at 02:24, Andreas Färber wrote: >> >>> Am 21.12.2010 um 01:10 schrieb Alexander Graf: >>> On 21.12.2010, at 01:06, Andreas Färber wrote: > Am 20.12.2010 um 23:45 schrieb Alexander Graf: > >> On 31.05.2009, at 17:20, Stuart Brady wrote: >> >>> Here's an update of the Z80 system emulator, which currently emulates >>> the ZX Spectrum only. [...] >> >> [...] do you think it's a valuable target to have in upstream qemu? > > The z80 was also used in the more modern TI-83 Plus programmable > calculator [1], for instance The general I/O framework is heavily geared towards server and desktop use. The main use case of the Z80 that I'm aware of is the GameBoy. Not sure that one fits in there too well :). The Spectrum however does fit the desktop case, so it certainly has my blessings. >>> >>> Knowing the ZX Spectrum only from the attic, I agree that emulating game >>> consoles is not the primary purpose or strength of QEMU. >>> (Although I wouldn't mind if someone wanted to contribute a PS3 machine for >>> Cell B.E. emulation!) >>> >>> Fwiw mips, arm, m68k, cris, microblaze seem to form a growing third >>> category of QEMU targets though, embedded systems. >> >> Oh, sure. I'd count in embedded systems here too. My main point was that we >> don't have frameworks to deal with Joysticks, 3D or other stuff real game >> system emulation would need. > > With the emulation of the ancient machine based game platform it is > even more complicated: games expect some certain timings from the CPU, > graphic and sound cards. So, I'm not sure if TCG can be used for it. Yup, old ones probably won't work. More recent ones should. Uli actually did create a GBA emulator using TCG a few years back, so it definitely does work for some stuff. I'm fairly sure that the more recent the systems become, the more event driven they also are - which is good for dynamic recompilation. Either way, those really don't belong inside the Qemu source tree IMHO as development models don't match in general. Instead, a libtcg would be a lot more fitting for those cases. Alex
Re: [Qemu-devel] [PATCH 06/15] scsi: Update sense code handling
On 11/25/2010 03:33 PM, Kevin Wolf wrote:
> Am 24.11.2010 12:16, schrieb Hannes Reinecke:
>> The SCSI spec has a quite detailed list of sense codes available.
>> It even mandates the use of specific ones for some failure cases.
>> The current implementation just has one type of 'generic' error
>> which is actually a violation of the spec in certain cases.
>> This patch introduces various predefined sense codes to have the
>> sense code reporting more in line with the spec.
>>
>> Signed-off-by: Hannes Reinecke
>> Acked-by: Christoph Hellwig
>> ---
>> hw/scsi-bus.c | 92
>> hw/scsi-disk.c| 109
>> +++--
>> hw/scsi-generic.c | 76 ++---
>> hw/scsi.h | 38 ++
>> 4 files changed, 239 insertions(+), 76 deletions(-)
>>
>> diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
>> index 93f0e9a..afdf0ad 100644
>> --- a/hw/scsi-bus.c
>> +++ b/hw/scsi-bus.c
>> @@ -388,6 +388,98 @@ int scsi_req_parse(SCSIRequest *req, uint8_t *buf)
>> return 0;
>> }
>>
>> +/*
>> + * Predefined sense codes
>> + */
>> +
>> +/* No sense data available */
>> +const struct SCSISense sense_code_NO_SENSE = {
>> +.key = NO_SENSE , .asc = 0x00 , .ascq = 0x00
>> +};
>> +
>> +/* LUN not ready, Manual intervention required */
>> +const struct SCSISense sense_code_LUN_NOT_READY = {
>> +.key = NOT_READY, .asc = 0x04, .ascq = 0x03
>> +};
>> +
>> +/* LUN not ready, Medium not present */
>> +const struct SCSISense sense_code_NO_MEDIUM = {
>> +.key = NOT_READY, .asc = 0x3a, .ascq = 0x00
>> +};
>> +
>> +/* Hardware error, internal target failure */
>> +const struct SCSISense sense_code_TARGET_FAILURE = {
>> +.key = HARDWARE_ERROR, .asc = 0x44, .ascq = 0x00
>> +};
>> +
>> +/* Illegal request, invalid command operation code */
>> +const struct SCSISense sense_code_INVALID_OPCODE = {
>> +.key = ILLEGAL_REQUEST, .asc = 0x20, .ascq = 0x00
>> +};
>> +
>> +/* Illegal request, LBA out of range */
>> +const struct SCSISense sense_code_LBA_OUT_OF_RANGE = {
>> +.key = ILLEGAL_REQUEST, .asc = 0x21, .ascq = 0x00
>> +};
>> +
>> +/* Illegal request, Invalid field in CDB */
>> +const struct SCSISense sense_code_INVALID_FIELD = {
>> +.key = ILLEGAL_REQUEST, .asc = 0x24, .ascq = 0x00
>> +};
>> +
>> +/* Illegal request, LUN not supported */
>> +const struct SCSISense sense_code_LUN_NOT_SUPPORTED = {
>> +.key = ILLEGAL_REQUEST, .asc = 0x25, .ascq = 0x00
>> +};
>> +
>> +/* Command aborted, I/O process terminated */
>> +const struct SCSISense sense_code_IO_ERROR = {
>> +.key = ABORTED_COMMAND, .asc = 0x00, .ascq = 0x06
>> +};
>> +
>> +/* Command aborted, I_T Nexus loss occurred */
>> +const struct SCSISense sense_code_I_T_NEXUS_LOSS = {
>> +.key = ABORTED_COMMAND, .asc = 0x29, .ascq = 0x07
>> +};
>> +
>> +/* Command aborted, Logical Unit failure */
>> +const struct SCSISense sense_code_LUN_FAILURE = {
>> +.key = ABORTED_COMMAND, .asc = 0x3e, .ascq = 0x01
>> +};
>> +
>> +/*
>> + * scsi_build_sense
>> + *
>> + * Build a sense buffer
>> + */
>> +int scsi_build_sense(SCSISense sense, uint8_t *buf, int len, int fixed)
>> +{
>> +if (len < 8)
>> +return 0;
>> +if (fixed && len < 14)
>> +return 0;
>> +
>> +memset(buf, 0, len);
>> +if (fixed) {
>> +/* Return fixed format sense buffer */
>> +buf[0] = 0xf0;
>> +buf[2] = sense.key;
>> +buf[7] = 7;
>> +buf[12] = sense.asc;
>> +buf[13] = sense.ascq;
>> +len = 14;
>
> My spec says: "Device servers shall return at least 18 bytes of
> parameter data in response to a REQUEST SENSE command if the allocation
> length is 18 or greater and the DESC bit is set to zero."
>
> So should this be MIN(len, 18) instead?
>
Yes, you are correct.
And we should actually always return sense data, even if the length
is smaller than the minimum.
Fixed in my megasas git tree; will be included in the next round of
patches.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] Re: [PATCH 14/15] megasas: LSI Megaraid SAS emulation
On 11/25/2010 09:47 PM, Sebastian Herbszt wrote:
> Hannes Reinecke wrote:
>> +static int megasas_scsi_init(PCIDevice *dev)
>> +{
>> +MPTState *s = DO_UPCAST(MPTState, dev, dev);
>> +uint8_t *pci_conf;
>> +int i;
>> +
>> +pci_conf = s->dev.config;
>> +
>> +/* PCI Vendor ID (word) */
>> +pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_LSI_LOGIC);
>> +/* PCI device ID (word) */
>> +pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_LSI_SAS1078);
>> +/* PCI subsystem ID */
>> +pci_set_word(&pci_conf[PCI_SUBSYSTEM_VENDOR_ID], 0x1000);
>
> PCI_VENDOR_ID_LSI_LOGIC
>
Ok.
>> +pci_set_word(&pci_conf[PCI_SUBSYSTEM_ID], 0x1013);
>
> What is 0x1013?
>
That's the device ID for Megaraid SAS 8708EM2.
I'll be adding a #define for it.
>> +/* PCI base class code */
>> +pci_config_set_class(pci_conf, PCI_CLASS_STORAGE_RAID);
>> +
>> +/* PCI latency timer = 0 */
>> +pci_conf[0x0d] = 0;
>
> PCI_LATENCY_TIMER
>
Ok.
>> +/* Interrupt pin 1 */
>> +pci_conf[0x3d] = 0x01;
>
> pci_config_set_interrupt_pin()
>
Ok.
Fixed in my megasas git tree. Will be included in the next
round of patches.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
h...@suse.de +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] [PATCH 3/3] Use mmap() within code_gen_alloc() for OpenBSD.
Am 21.12.2010 um 03:25 schrieb Brad:
Signed-off-by: Brad Smith
---
exec.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/exec.c b/exec.c
index 42a35e0..e513d16 100644
--- a/exec.c
+++ b/exec.c
@@ -517,7 +517,8 @@ static void code_gen_alloc(unsigned long tb_size)
exit(1);
}
}
-#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
defined(__DragonFly__)
+#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) \
+|| defined(__DragonFly__) || defined(__OpenBSD__)
Brad, thanks for making me aware of this part of code! Haiku is not
handled here either, falling back to malloc(), which breaks there.
When using mmap() on Haiku, weird qemu_malloc() workarounds with BeOS
areas are no longer necessary.
As for a fix, shouldn't we do this the autoconf way and do feature
tests rather than testing for known platforms? I.e. #elif
defined(HAVE_MMAP) with HAVE_MMAP getting defined by configure?
Andreas
{
int flags;
void *addr = NULL;
--
1.7.3.2
Re: [Qemu-devel] [PATCH 3/3] Use mmap() within code_gen_alloc() for OpenBSD.
- Original message - > Am 21.12.2010 um 03:25 schrieb Brad: > > > Signed-off-by: Brad Smith > > > > --- > > exec.c | 3 ++- > > 1 files changed, 2 insertions(+), 1 deletions(-) > > > > diff --git a/exec.c b/exec.c > > index 42a35e0..e513d16 100644 > > --- a/exec.c > > +++ b/exec.c > > @@ -517,7 +517,8 @@ static void code_gen_alloc(unsigned long tb_size) > > exit(1); > > } > > } > > -#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || > > defined(__DragonFly__) > > +#elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) \ > > + || defined(__DragonFly__) || defined(__OpenBSD__) > > Brad, thanks for making me aware of this part of code! Haiku is not > handled here either, falling back to malloc(), which breaks there. > > When using mmap() on Haiku, weird qemu_malloc() workarounds with BeOS > areas are no longer necessary. > > As for a fix, shouldn't we do this the autoconf way and do feature > tests rather than testing for known platforms? I.e. #elif > defined(HAVE_MMAP) with HAVE_MMAP getting defined by configure? Well I think it would be nice if possible to try and eliminate such hardcoded lists of Operating Systems via ifdefs and try to test for the features instead. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
[Qemu-devel] Re: PATCH: document QEMU<->ACPIBIOS PCI hotplug interface (v2)
On 12/21/2010 04:41 PM, Marcelo Tosatti wrote: Document how QEMU communicates with ACPI BIOS for PCI hotplug. Signed-off-by: Marcelo Tosatti --- /dev/null 2010-12-14 09:23:48.414180082 -0200 +++ qemu/docs/specs/acpi_pci_hotplug.txt2010-12-20 15:00:26.0 -0200 @@ -0,0 +1,39 @@ +QEMU<->ACPI BIOS PCI hotplug interface +-- + +QEMU supports PCI hotplug via ACPI, for PCI bus 0. This document +describes the interface between QEMU and the ACPI BIOS. + +ACPI GPE block (IO ports 0xafe0-0xafe3): +- + +Generic ACPI GPE block. Bit 1 (GPE.1) used to notify PCI hotplug/eject +event to ACPI BIOS, via SCI interrupt. + +PCI slot injection notification pending (IO port 0xae00-0xae03): +--- +Slot injection notification pending. One bit per slot. + +Read by ACPI BIOS GPE.1 handler to notify OS of injection +events. + +PCI slot removal notification (IO port 0xae04-0xae07): +- +Slot removal notification pending. One bit per slot. + +Read by ACPI BIOS GPE.1 handler to notify OS of removal +events. + +PCI device eject (IO port 0xae08-0xae0b): + + +Used by ACPI BIOS _EJ0 method to request device removal. One bit per slot. +Reads return 0. + +PCI removability status (IO port 0xae0c-0xae0f): +--- + +Used by ACPI BIOS _RMV method to indicate removability status to OS. One +bit per slot. + + Do we support byte and word access to those ports, or just dword access? With this documentation, I'm fine with the _RMV DSDT patch. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] document QEMU<->ACPIBIOS PCI hotplug interface
On Mon, Dec 20, 2010 at 08:11:36PM +, Blue Swirl wrote: > On Mon, Dec 20, 2010 at 5:09 PM, Marcelo Tosatti wrote: > > > > Document how QEMU communicates with ACPI BIOS > > for PCI hotplug. > > > > Signed-off-by: Marcelo Tosatti > > > > --- /dev/null 2010-12-14 09:23:48.414180082 -0200 > > +++ qemu/docs/specs/acpi_pci_hotplug.txt 2010-12-20 > > 15:00:26.0 -0200 > > @@ -0,0 +1,39 @@ > > +QEMU<->ACPI BIOS PCI hotplug interface > > +-- > > + > > +QEMU supports PCI hotplug via ACPI, for PCI bus 0. This document > > +describes the interface between QEMU and the ACPI BIOS. > > + > > +ACPI GPE block (IO ports 0xafe00-0xafe04): > > 0xae00-0xae0f? 0xaf0-0xaf3, thanks.
[Qemu-devel] PATCH: document QEMU<->ACPIBIOS PCI hotplug interface (v2)
Document how QEMU communicates with ACPI BIOS for PCI hotplug. Signed-off-by: Marcelo Tosatti --- /dev/null 2010-12-14 09:23:48.414180082 -0200 +++ qemu/docs/specs/acpi_pci_hotplug.txt2010-12-20 15:00:26.0 -0200 @@ -0,0 +1,39 @@ +QEMU<->ACPI BIOS PCI hotplug interface +-- + +QEMU supports PCI hotplug via ACPI, for PCI bus 0. This document +describes the interface between QEMU and the ACPI BIOS. + +ACPI GPE block (IO ports 0xafe0-0xafe3): +- + +Generic ACPI GPE block. Bit 1 (GPE.1) used to notify PCI hotplug/eject +event to ACPI BIOS, via SCI interrupt. + +PCI slot injection notification pending (IO port 0xae00-0xae03): +--- +Slot injection notification pending. One bit per slot. + +Read by ACPI BIOS GPE.1 handler to notify OS of injection +events. + +PCI slot removal notification (IO port 0xae04-0xae07): +- +Slot removal notification pending. One bit per slot. + +Read by ACPI BIOS GPE.1 handler to notify OS of removal +events. + +PCI device eject (IO port 0xae08-0xae0b): + + +Used by ACPI BIOS _EJ0 method to request device removal. One bit per slot. +Reads return 0. + +PCI removability status (IO port 0xae0c-0xae0f): +--- + +Used by ACPI BIOS _RMV method to indicate removability status to OS. One +bit per slot. + +
[Qemu-devel] Re: [PATCH] qemu-kvm: Switch to upstream -enable-kvm semantics
On 12/15/2010 07:57 PM, Markus Armbruster wrote: > In the short term, it would be a good idea to modify qemu-kvm to > switch the -enable-kvm semantics to match upstream (fail if KVM isn't > available). That's what my patch does. Additionally, it changes the default to match upstream: KVM disabled. What do you want changed in my patch? The 'Additionally' bit. qemu-kvm users rely on the default enabling kvm. Likely they don't rely on -enable-kvm failing is kvm is not available (and indeed, they likely expect it to match upstream). So the patch should only change behaviour when -enable-kvm is specified. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Where is ehci hiding ?
Hi all, Google sees patches to hw/usb-ehci.c from time to time, in http://www.mail-archive.com/qemu-devel@nongnu.org/msg37741.html for instance. Where is that code hiding, since I just can't find it in the git tree? Best, OG.
[Qemu-devel] Re: KVM call agenda for Dec 21
* Chris Wright (chr...@redhat.com) wrote: > Please send in any agenda items you are interested in covering. No agenda, today's call is cancelled. Also, given people's holiday and vacation schedules, next week's call is cancelled. Talk again after the New Year. thanks, -chris
[Qemu-devel] Re: [PATCH] qemu-kvm: Switch to upstream -enable-kvm semantics
Avi Kivity writes: > On 12/15/2010 07:57 PM, Markus Armbruster wrote: >> > In the short term, it would be a good idea to modify qemu-kvm to >> > switch the -enable-kvm semantics to match upstream (fail if KVM isn't >> > available). >> >> That's what my patch does. >> >> Additionally, it changes the default to match upstream: KVM disabled. >> >> What do you want changed in my patch? > > The 'Additionally' bit. qemu-kvm users rely on the default enabling > kvm. Likely they don't rely on -enable-kvm failing is kvm is not > available (and indeed, they likely expect it to match upstream). So > the patch should only change behaviour when -enable-kvm is specified. Like this? upstream qemu | default |-enable-kvm +---+--- KVM available | disabled | enabled KVM unavailable | disabled |fail qemu-kvm| default |-enable-kvm| -no-kvm +---+---+--- KVM available | enabled* | enabled | disabled KVM unavailable | disabled |fail | disabled * differs from upstream
[Qemu-devel] Re: [PATCH] qemu-kvm: Switch to upstream -enable-kvm semantics
On 12/21/2010 05:41 PM, Markus Armbruster wrote: Avi Kivity writes: > On 12/15/2010 07:57 PM, Markus Armbruster wrote: >> > In the short term, it would be a good idea to modify qemu-kvm to >> > switch the -enable-kvm semantics to match upstream (fail if KVM isn't >> > available). >> >> That's what my patch does. >> >> Additionally, it changes the default to match upstream: KVM disabled. >> >> What do you want changed in my patch? > > The 'Additionally' bit. qemu-kvm users rely on the default enabling > kvm. Likely they don't rely on -enable-kvm failing is kvm is not > available (and indeed, they likely expect it to match upstream). So > the patch should only change behaviour when -enable-kvm is specified. Like this? upstream qemu | default |-enable-kvm +---+--- KVM available | disabled | enabled KVM unavailable | disabled |fail qemu-kvm| default |-enable-kvm| -no-kvm +---+---+--- KVM available | enabled* | enabled | disabled KVM unavailable | disabled |fail | disabled * differs from upstream Yes. -- error compiling committee.c: too many arguments to function
[Qemu-devel] Re: [PATCH] qemu-kvm: Switch to upstream -enable-kvm semantics
On Tue, Dec 21, 2010 at 04:41:03PM +0100, Markus Armbruster wrote: > Like this? > > upstream qemu | default |-enable-kvm > +---+--- > KVM available | disabled | enabled > KVM unavailable | disabled |fail > > qemu-kvm| default |-enable-kvm| -no-kvm > +---+---+--- > KVM available | enabled* | enabled | disabled > KVM unavailable | disabled |fail | disabled > > * differs from upstream libguestfs wants "best effort" behaviour, and libvirt wants "KVM or die" behaviour. Avi, can you comment on whether just opening /dev/kvm O_RDWR is a reasonable way to detect if KVM is available? Markus, any idea when we might get the -accel option appearing in released versions of qemu/KVM? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
[Qemu-devel] Re: [PATCH] qemu-kvm: Switch to upstream -enable-kvm semantics
On Tue, Dec 21, 2010 at 04:00:32PM +, Richard W.M. Jones wrote: > Markus, any idea when we might get the -accel option appearing in > released versions of qemu/KVM? Sorry, I thought this email wasn't going out to a public list. I should be more careful next time. I'll say instead: We really need both the -accel option and a working system of qemu capabilities. Both would be hugely helpful making it easier to work with qemu. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
[Qemu-devel] Re: [PATCH] qemu-kvm: Switch to upstream -enable-kvm semantics
"Richard W.M. Jones" writes: > On Tue, Dec 21, 2010 at 04:41:03PM +0100, Markus Armbruster wrote: >> Like this? >> >> upstream qemu | default |-enable-kvm >> +---+--- >> KVM available | disabled | enabled >> KVM unavailable | disabled |fail >> >> qemu-kvm| default |-enable-kvm| -no-kvm >> +---+---+--- >> KVM available | enabled* | enabled | disabled >> KVM unavailable | disabled |fail | disabled >> >> * differs from upstream > > libguestfs wants "best effort" behaviour, and libvirt wants "KVM or die" > behaviour. For what it's worth, default gives you exactly that with qemu-kvm. Maybe that's good enough, on the theory that if you have KVM, you most likely have libguestfs using qemu-kvm. > Avi, can you comment on whether just opening /dev/kvm O_RDWR is a > reasonable way to detect if KVM is available? > > Markus, any idea when we might get the -accel option appearing in > released versions of qemu/KVM? No idea. Anthony?
[Qemu-devel] Re: [PATCH] qemu-kvm: Switch to upstream -enable-kvm semantics
Avi Kivity writes: > On 12/21/2010 05:41 PM, Markus Armbruster wrote: >> Avi Kivity writes: >> >> > On 12/15/2010 07:57 PM, Markus Armbruster wrote: >> >> > In the short term, it would be a good idea to modify qemu-kvm to >> >> > switch the -enable-kvm semantics to match upstream (fail if KVM isn't >> >> > available). >> >> >> >> That's what my patch does. >> >> >> >> Additionally, it changes the default to match upstream: KVM disabled. >> >> >> >> What do you want changed in my patch? >> > >> > The 'Additionally' bit. qemu-kvm users rely on the default enabling >> > kvm. Likely they don't rely on -enable-kvm failing is kvm is not >> > available (and indeed, they likely expect it to match upstream). So >> > the patch should only change behaviour when -enable-kvm is specified. >> >> Like this? >> >> upstream qemu | default |-enable-kvm >> +---+--- >> KVM available | disabled | enabled >> KVM unavailable | disabled |fail >> >> qemu-kvm| default |-enable-kvm| -no-kvm >> +---+---+--- >> KVM available | enabled* | enabled | disabled >> KVM unavailable | disabled |fail | disabled >> >> * differs from upstream > > Yes. Thanks. I'll cook up a new patch.
Re: [Qemu-devel] Where is ehci hiding ?
On 12/21/10 08:16, Olivier Galibert wrote: > > Hi all, > > Google sees patches to hw/usb-ehci.c from time to time, in > http://www.mail-archive.com/qemu-devel@nongnu.org/msg37741.html for > instance. Where is that code hiding, since I just can't find it in > the git tree? git://git.kiszka.org/qemu.git ehci Not much has been done in the past 4+ months. David > > Best, > > OG. > > >
Re: [Qemu-devel] Re: [PATCH] qemu-kvm: Switch to upstream -enable-kvm semantics
On 12/21/2010 10:07 AM, Markus Armbruster wrote: "Richard W.M. Jones" writes: On Tue, Dec 21, 2010 at 04:41:03PM +0100, Markus Armbruster wrote: Like this? upstream qemu | default |-enable-kvm +---+--- KVM available | disabled | enabled KVM unavailable | disabled |fail qemu-kvm| default |-enable-kvm| -no-kvm +---+---+--- KVM available | enabled* | enabled | disabled KVM unavailable | disabled |fail | disabled * differs from upstream libguestfs wants "best effort" behaviour, and libvirt wants "KVM or die" behaviour. For what it's worth, default gives you exactly that with qemu-kvm. Maybe that's good enough, on the theory that if you have KVM, you most likely have libguestfs using qemu-kvm. Avi, can you comment on whether just opening /dev/kvm O_RDWR is a reasonable way to detect if KVM is available? Markus, any idea when we might get the -accel option appearing in released versions of qemu/KVM? No idea. Anthony? I see no problem with 0.15 if someone cooks up a patch. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] Z80 emulation updated again!
Am 21.12.2010 03:38, schrieb Natalia Portillo: Hi all, The Z80 CPU and its variants and clones are not only used in dozens of computers (ranging from a full range of CP/M compatible ones, and minicomputers mostly seen as general public as gaming devices -Amstrad, Speccy-), but also in hunders of embedded systems and even on Adaptec SCSI cards. I vote for inclusion on mainstream 100%, and maybe from that code an i8080 emulation can be easily extracted to cover the rest of 80s desktop/minis/micros ? Regards, Natalia Portillo I support this inclusion, too. Maybe I'll even add a system emulation for TRS-80 one day. Regards, Stefan Weil
Re: [Qemu-devel] [PATCH] Z80 emulation updated again!
Am 21.12.2010 um 03:47 schrieb John Williams: This is a really interesting discussion which goes to the heart of QEMU's identity. Right... A contemporary emulation and virtualisation platform (modern embedded, KVM etc)? An emulation platform for retro-computing nostalgia? How about as a unifying platform for MAME? The way I see it, QEMU has shifted from the "packaged" desktop emulation to a much more diversified emulation platform, say, a library of qdev devices of which boards are pieced together. So if someone contributes one particular machine, its devices can likely find reuse for other boards and archs as well. In the PReP case, for example the 40p's i82378. In the case at hands, I was seeing possible reuse for target-z80/ bits beyond nostalgia. QEMU can be a backend for many use cases as long as cycle-accurateness is not needed. The (lack of) frontends are its weekness though, which I guess makes it unsuitable for gaming. Game emulators on the contrary often oppose attempts to add more serious emulation features (e.g., LPT printing support in DOSBox). Cheers, Andreas
Re: [Qemu-devel] Re: [PATCH] qemu-kvm: Switch to upstream -enable-kvm semantics
On 21.12.2010, at 17:56, Anthony Liguori wrote: > On 12/21/2010 10:07 AM, Markus Armbruster wrote: >> "Richard W.M. Jones" writes: >> >> >>> On Tue, Dec 21, 2010 at 04:41:03PM +0100, Markus Armbruster wrote: >>> Like this? upstream qemu | default |-enable-kvm +---+--- KVM available | disabled | enabled KVM unavailable | disabled |fail qemu-kvm| default |-enable-kvm| -no-kvm +---+---+--- KVM available | enabled* | enabled | disabled KVM unavailable | disabled |fail | disabled * differs from upstream >>> libguestfs wants "best effort" behaviour, and libvirt wants "KVM or die" >>> behaviour. >>> >> For what it's worth, default gives you exactly that with qemu-kvm. >> Maybe that's good enough, on the theory that if you have KVM, you most >> likely have libguestfs using qemu-kvm. >> >> >>> Avi, can you comment on whether just opening /dev/kvm O_RDWR is a >>> reasonable way to detect if KVM is available? >>> >>> Markus, any idea when we might get the -accel option appearing in >>> released versions of qemu/KVM? >>> >> No idea. Anthony? >> > > I see no problem with 0.15 if someone cooks up a patch. Didn't Anthony do one? What happened to the Xen patch set anyways? :) Alex
Re: [Qemu-devel] Re: [PATCH V2 1/2] Introduce -machine command option.
On 02.12.2010, at 15:18, anthony.per...@citrix.com wrote: > From: Anthony PERARD > > This option gives the ability to switch one "accelerator" like kvm, xen > or the default one tcg. We can specify more than one accelerator by > separate them by a colon. QEMU will try each one and use the first whose > works. > > So, > ./qemu -machine accel=xen:kvm:tcg > > which would try Xen support first, then KVM and finally TCG if none of > the other works. > > By default, QEMU will use TCG. But we can specify another default in the > global configuration file. > > Signed-off-by: Anthony PERARD Something went wrong with this patch set. I only have mail 1/2. 2/2 is missing. Mind to resend? :) Alex
Re: [Qemu-devel] [PATCH] qdev: sysbus_get_default must not return a NULL pointer (fix regression)
On Thu, Dec 16, 2010 at 07:33:22PM +0100, Stefan Weil wrote:
> Every system should have some sort of main system bus,
> so sysbus_get_default should always return a valid bus.
>
> Without this patch, at least mipssim and malta no longer
> start but raise a null pointer access exception (caused by
> commit ec990eb622ad46df5ddcb1e94c418c271894d416).
>
> Cc: Anthony Liguori
> Signed-off-by: Stefan Weil
> ---
> hw/qdev.c |9 +
> 1 files changed, 5 insertions(+), 4 deletions(-)
Thanks, applied.
> diff --git a/hw/qdev.c b/hw/qdev.c
> index 10e28df..6fc9b02 100644
> --- a/hw/qdev.c
> +++ b/hw/qdev.c
> @@ -107,10 +107,7 @@ DeviceState *qdev_create(BusState *bus, const char *name)
> DeviceInfo *info;
>
> if (!bus) {
> -if (!main_system_bus) {
> -main_system_bus = qbus_create(&system_bus_info, NULL,
> "main-system-bus");
> -}
> -bus = main_system_bus;
> +bus = sysbus_get_default();
> }
>
> info = qdev_find_info(bus->info, name);
> @@ -311,6 +308,10 @@ static int qdev_reset_one(DeviceState *dev, void *opaque)
>
> BusState *sysbus_get_default(void)
> {
> +if (!main_system_bus) {
> +main_system_bus = qbus_create(&system_bus_info, NULL,
> + "main-system-bus");
> +}
> return main_system_bus;
> }
>
> --
> 1.7.2.3
>
>
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
Re: [Qemu-devel] QEMU forks survey
On 21.12.2010, at 19:28, Andreas Färber wrote: > Since Christmas and the New Year with its good intensions are approaching, > apart from z80 there's some more feature forks around: > > http://repo.or.cz/w/qemu.git/forks?o=age > > - hpoussin.git ppc contains the 40p machine that I'm reviewing for upstream > inclusion currently. > > * qemu-loongson.git I guess was fully upstreamed recently? > > * ar7.git: Stefan, what's the state and scope of your work? What about TCI? > > Apparently abandoned (no recent activity): > * avr32.git > * es40.git (alpha) > * hppa.git > * openrisc.git > * mmix.git > > Unclear to me: > * mini2440.git > * qemu-JZ.git > > > http://wiki.qemu.org/Links > > - OpenSolaris support was merged so can be disregarded. > > * I heard from François that one of the downstreams has added support for the > arm Beagle board? Maemo? > > > There's also many more forks on gitorious.com and github.com... * s390x emulation I'm currently working on that one. Already did some cleanups to the code and am now trying to get a kernel booting. Alex
Re: [Qemu-devel] Where is ehci hiding ?
On Tue, Dec 21, 2010 at 09:18:08AM -0700, David S. Ahern wrote: > > > On 12/21/10 08:16, Olivier Galibert wrote: > > > > Hi all, > > > > Google sees patches to hw/usb-ehci.c from time to time, in > > http://www.mail-archive.com/qemu-devel@nongnu.org/msg37741.html for > > instance. Where is that code hiding, since I just can't find it in > > the git tree? > > git://git.kiszka.org/qemu.git ehci > > Not much has been done in the past 4+ months. Thanks. Any idea what's missing to get it into mainline? Reading what little discussions I could find was unenlightening. OG.
[Qemu-devel] QEMU forks survey
Since Christmas and the New Year with its good intensions are approaching, apart from z80 there's some more feature forks around: http://repo.or.cz/w/qemu.git/forks?o=age - hpoussin.git ppc contains the 40p machine that I'm reviewing for upstream inclusion currently. * qemu-loongson.git I guess was fully upstreamed recently? * ar7.git: Stefan, what's the state and scope of your work? What about TCI? Apparently abandoned (no recent activity): * avr32.git * es40.git (alpha) * hppa.git * openrisc.git * mmix.git Unclear to me: * mini2440.git * qemu-JZ.git http://wiki.qemu.org/Links - OpenSolaris support was merged so can be disregarded. * I heard from François that one of the downstreams has added support for the arm Beagle board? Maemo? There's also many more forks on gitorious.com and github.com... Andreas
Re: [Qemu-devel] Re: [PATCH V2 1/2] Introduce -machine command option.
Am 21.12.2010 um 18:33 schrieb Alexander Graf: On 02.12.2010, at 15:18, anthony.per...@citrix.com wrote: From: Anthony PERARD This option gives the ability to switch one "accelerator" like kvm, xen or the default one tcg. We can specify more than one accelerator by separate them by a colon. QEMU will try each one and use the first whose works. So, ./qemu -machine accel=xen:kvm:tcg which would try Xen support first, then KVM and finally TCG if none of the other works. By default, QEMU will use TCG. But we can specify another default in the global configuration file. Signed-off-by: Anthony PERARD Something went wrong with this patch set. I only have mail 1/2. 2/2 is missing. Mind to resend? :) It seems to me this is v3 already - v2 2/2 was sent on Nov 23rd. Andreas
Re: [Qemu-devel] Re: [PATCH V2 1/2] Introduce -machine command option.
On 21.12.2010, at 19:57, Andreas Färber wrote: > Am 21.12.2010 um 18:33 schrieb Alexander Graf: > >> On 02.12.2010, at 15:18, anthony.per...@citrix.com wrote: >> >>> From: Anthony PERARD >>> >>> This option gives the ability to switch one "accelerator" like kvm, xen >>> or the default one tcg. We can specify more than one accelerator by >>> separate them by a colon. QEMU will try each one and use the first whose >>> works. >>> >>> So, >>> ./qemu -machine accel=xen:kvm:tcg >>> >>> which would try Xen support first, then KVM and finally TCG if none of >>> the other works. >>> >>> By default, QEMU will use TCG. But we can specify another default in the >>> global configuration file. >>> >>> Signed-off-by: Anthony PERARD >> >> Something went wrong with this patch set. I only have mail 1/2. 2/2 is >> missing. Mind to resend? :) > > It seems to me this is v3 already - v2 2/2 was sent on Nov 23rd. Ah - Alex screwup again :). Either way, any progress on -accel? :) Alex
Re: [Qemu-devel] QEMU forks survey
On 21 December 2010 18:28, Andreas Färber wrote: > Since Christmas and the New Year with its good intensions are approaching, > apart from z80 there's some more feature forks around: > * I heard from François that one of the downstreams has added support for > the arm Beagle board? Maemo? Yes (well it's Meego these days): http://meego.gitorious.org/qemu-maemo/qemu That fork includes OMAP3 support (needed for beagle) and also a large set of bugfixes for various ARM TCG issues which I've been trying to get reviewed and into upstream. (If anybody has suggestions on the best way to move forward with that I'd welcome them. So far I have been working on the "start at one end, test and submit patch series" basis...) -- PMM
Re: [Qemu-devel] Where is ehci hiding ?
On 12/21/10 11:39, Olivier Galibert wrote: > On Tue, Dec 21, 2010 at 09:18:08AM -0700, David S. Ahern wrote: >> >> >> On 12/21/10 08:16, Olivier Galibert wrote: >>> >>> Hi all, >>> >>> Google sees patches to hw/usb-ehci.c from time to time, in >>> http://www.mail-archive.com/qemu-devel@nongnu.org/msg37741.html for >>> instance. Where is that code hiding, since I just can't find it in >>> the git tree? >> >> git://git.kiszka.org/qemu.git ehci >> >> Not much has been done in the past 4+ months. > > Thanks. Any idea what's missing to get it into mainline? Reading > what little discussions I could find was unenlightening. > > OG. This is the summary of open items: http://www.mail-archive.com/qemu-devel@nongnu.org/msg46381.html David
Re: [Qemu-devel] QEMU forks survey
On Tue, Dec 21, 2010 at 6:28 PM, Andreas Färber wrote: > Since Christmas and the New Year with its good intensions are approaching, > apart from z80 there's some more feature forks around: > > http://repo.or.cz/w/qemu.git/forks?o=age > > - hpoussin.git ppc contains the 40p machine that I'm reviewing for upstream > inclusion currently. > > * qemu-loongson.git I guess was fully upstreamed recently? > > * ar7.git: Stefan, what's the state and scope of your work? What about TCI? > > Apparently abandoned (no recent activity): > * avr32.git > * es40.git (alpha) > * hppa.git > * openrisc.git > * mmix.git > > Unclear to me: > * mini2440.git I did that fully working mini2440 port, since last year or so. that include s3c2440 and many associated peripherals. Unfortunately it's hard to follow qemu's tree and I decided to keep my port as is instead of constantly trying to keep it up to date... I still use it a lot tho... Michael
Re: [Qemu-devel] NPTL support
On Mon, Dec 20, 2010 at 10:17:50PM -0800, maheen butt wrote: > hi I 'm working with fedora core 13(64 bit) x86_64 platform. I > configured QEMU with --enable-nptl switch but I'm not able to run > programs containing POSIX threads or fork system call. I run this > commandqemu-x86_64 thread it gives system call errorand qemu-x86_64 > forkfno child process createdwhat is reason behind it? is nptl support > is in its progressive mode or it is not for x86_64. Nobody's written the x86/x86_64-specific NPTL bits yet. -Nathan
[Qemu-devel] [RFC] ppc: qdev-ify CPU creation
From: Hervé Poussineau
v1:
* Coding style fixes.
Signed-off-by: Hervé Poussineau
Cc: Alexander Graf
Signed-off-by: Andreas Färber
---
Hello Alex,
Seeing the discussions about Leon3, is this the way to go for ppc? Is ppc.[hc]
right?
The unconditional use of 6xx looks suspicious to me, no?
Should we rename cpu_device_irq_request() to cpu_device_irq_request_6xx()?
Regards,
Andreas
hw/ppc.c| 75 +++
hw/ppc.h|2 +
target-ppc/cpu.h|1 +
target-ppc/helper.c | 21 +++---
4 files changed, 94 insertions(+), 5 deletions(-)
diff --git a/hw/ppc.c b/hw/ppc.c
index 968aec1..0927326 100644
--- a/hw/ppc.c
+++ b/hw/ppc.c
@@ -30,6 +30,8 @@
#include "loader.h"
#include "kvm.h"
#include "kvm_ppc.h"
+#include "hw/qdev.h"
+#include "hw/sysbus.h"
//#define PPC_DEBUG_IRQ
//#define PPC_DEBUG_TB
@@ -1286,3 +1288,76 @@ int PPC_NVRAM_set_params (nvram_t *nvram, uint16_t
NVRAM_size,
return 0;
}
+
+DeviceState *cpu_ppc_create_simple(const char *cpu_model)
+{
+DeviceState *dev;
+
+dev = qdev_create(NULL, "cpu-ppc");
+if (!dev) {
+return NULL;
+}
+qdev_prop_set_string(dev, "model", qemu_strdup(cpu_model));
+if (qdev_init(dev) < 0) {
+return NULL;
+}
+return dev;
+}
+
+typedef struct CPUPPC {
+SysBusDevice busdev;
+char *model;
+CPUPPCState state;
+} CPUPPC;
+
+static void cpu_device_irq_request(void *opaque, int pin, int level)
+{
+CPUPPC* cpu = opaque;
+CPUPPCState* env = &cpu->state;
+ppc6xx_set_irq(env, pin, level);
+}
+
+static int cpu_device_init(SysBusDevice *dev)
+{
+CPUPPC* cpu = FROM_SYSBUS(CPUPPC, dev);
+CPUPPCState* env = &cpu->state;
+
+if (cpu_ppc_init_inplace(env, cpu->model) < 0) {
+return -1;
+}
+
+if (env->flags & POWERPC_FLAG_RTC_CLK) {
+/* POWER / PowerPC 601 RTC clock frequency is 7.8125 MHz */
+cpu_ppc_tb_init(env, 7812500UL);
+} else {
+/* Set time-base frequency to 100 Mhz */
+cpu_ppc_tb_init(env, 100UL * 1000UL * 1000UL);
+}
+
+qdev_init_gpio_in(&dev->qdev, cpu_device_irq_request, PPC6xx_INPUT_NB);
+return 0;
+}
+
+static void cpu_device_reset(DeviceState *d)
+{
+CPUPPC *s = FROM_SYSBUS(CPUPPC, sysbus_from_qdev(d));
+cpu_reset(&s->state);
+}
+
+static SysBusDeviceInfo cpu_device_info = {
+.qdev.name = "cpu-ppc",
+.qdev.size = sizeof(CPUPPC),
+.qdev.reset = cpu_device_reset,
+.init = cpu_device_init,
+.qdev.props = (Property[]) {
+DEFINE_PROP_STRING("model", CPUPPC, model),
+DEFINE_PROP_END_OF_LIST(),
+},
+};
+
+static void ppc_register_devices(void)
+{
+sysbus_register_withprop(&cpu_device_info);
+}
+
+device_init(ppc_register_devices)
diff --git a/hw/ppc.h b/hw/ppc.h
index 34f54cf..ae8dd97 100644
--- a/hw/ppc.h
+++ b/hw/ppc.h
@@ -37,6 +37,8 @@ void ppce500_irq_init (CPUState *env);
void ppc6xx_irq_init (CPUState *env);
void ppc970_irq_init (CPUState *env);
+DeviceState *cpu_ppc_create_simple(const char *cpu_model);
+
/* PPC machines for OpenBIOS */
enum {
ARCH_PREP = 0,
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index deb8d7c..0f56d45 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -721,6 +721,7 @@ struct mmu_ctx_t {
/*/
CPUPPCState *cpu_ppc_init (const char *cpu_model);
+int cpu_ppc_init_inplace(CPUPPCState *env, const char *cpu_model);
void ppc_translate_init(void);
int cpu_ppc_exec (CPUPPCState *s);
void cpu_ppc_close (CPUPPCState *s);
diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index 4b49101..99af1f6 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -2794,22 +2794,33 @@ void cpu_reset(CPUPPCState *env)
tlb_flush(env, 1);
}
-CPUPPCState *cpu_ppc_init (const char *cpu_model)
+int cpu_ppc_init_inplace(CPUPPCState *env, const char *cpu_model)
{
-CPUPPCState *env;
const ppc_def_t *def;
def = cpu_ppc_find_by_name(cpu_model);
-if (!def)
-return NULL;
+if (!def) {
+return -1;
+}
-env = qemu_mallocz(sizeof(CPUPPCState));
cpu_exec_init(env);
ppc_translate_init();
env->cpu_model_str = cpu_model;
cpu_ppc_register_internal(env, def);
qemu_init_vcpu(env);
+return 0;
+}
+
+CPUPPCState *cpu_ppc_init(const char *cpu_model)
+{
+CPUPPCState *env;
+
+env = qemu_mallocz(sizeof(CPUPPCState));
+if (cpu_ppc_init_inplace(env, cpu_model) < 0) {
+qemu_free(env);
+return NULL;
+}
return env;
}
--
1.7.3.4
[Qemu-devel] PCIe Transaction handling in Qemu
Hello,
I have a question regarding how Qemu PCIe devices handle Config Transactions vs
Memory Transactions (assuming the PCI device is setup to act as
PCI_BASE_ADDRESS_SPACE_MEMORY).
I'm using portions of hw/cirrus_vga.c to make my point,
static PCIDeviceInfo cirrus_vga_info = {
.qdev.name= "cirrus-vga",
.qdev.desc= "Cirrus CLGD 54xx VGA",
.qdev.size= sizeof(PCICirrusVGAState),
.qdev.vmsd= &vmstate_pci_cirrus_vga,
.init = pci_cirrus_vga_initfn,
.romfile = VGABIOS_CIRRUS_FILENAME,
.config_write = pci_cirrus_write_config,
};
PCIDeviceInfo allows for custom .config_write (& config_read) handler as shown
above. Any pci config operations operations initiated via legacy I/O operations
will use these config handlers.
The MMIO regions and handlers are mapped as shown below:
static uint32_t cirrus_vga_mem_readb(void *opaque, target_phys_addr_t addr)
{
:
} and so on for the other mmio handlers
static CPUReadMemoryFunc * const cirrus_vga_mem_read[3] = {
cirrus_vga_mem_readb,
cirrus_vga_mem_readw,
cirrus_vga_mem_readl,
};
static CPUWriteMemoryFunc * const cirrus_vga_mem_write[3] = {
cirrus_vga_mem_writeb,
cirrus_vga_mem_writew,
cirrus_vga_mem_writel,
};
static void cirrus_init_common(CirrusVGAState * s, int device_id, int is_pci)
{
:
:
s->vga.vga_io_memory = cpu_register_io_memory(cirrus_vga_mem_read,
cirrus_vga_mem_write, s);
:
}
static void cirrus_pci_mmio_map(PCIDevice *d, int region_num,
pcibus_t addr, pcibus_t size, int type)
{
CirrusVGAState *s = &DO_UPCAST(PCICirrusVGAState, dev, d)->cirrus_vga;
cpu_register_physical_memory(addr, CIRRUS_PNPMMIO_SIZE,
s->cirrus_mmio_io_addr);
}
static int pci_cirrus_vga_initfn(PCIDevice *dev)
{
:
:
cirrus_init_common(..)
:
if (device_id == CIRRUS_ID_CLGD5446) {
pci_register_bar((PCIDevice *)d, 1, CIRRUS_PNPMMIO_SIZE,
PCI_BASE_ADDRESS_SPACE_MEMORY, cirrus_pci_mmio_map);
}
return 0;
}
I have some questions about PCIe operations sssuming the device has MMIO
handlers involved (as shown above).
1. Will all PCIe config operations ALWAYS use the installed config handlers? Or
can PCIe config operations use the MMIO handlers?
2. Assuming that both PCI config and MMIO operations can use the MMIO handlers,
is there any way I can identify if a transaction is a config or a memory
transaction?
3.a. What address is passed on the MMIO handlers for config and MMIO
operations? From pci_data_write in pci_host.c, it appears that config
operations send only the offset into the config region. I couldn't determine
what address is passed for MMIO operations.
b. Is it an offset from the BAR for MMIO operations?
c. How do I get the full physical address?
d. What address does a PCIe device expect to see - physical or offset for?
e. Is there anyway I can find out what the bus and device numbers are once
inside the config and MMIO handlers? i.e once the execution has reached the
pci_cirrus_write_config() or cirrus_vga_mem_readb(..) from the code above?
Thanks
Adnan
Re: [Qemu-devel] QEMU forks survey
Le 21 déc. 2010 à 19:28, Andreas Färber a écrit : > Since Christmas and the New Year with its good intensions are approaching, > apart from z80 there's some more feature forks around: There is also a 68k trunk around IIRC: http://gitorious.org/qemu-m68k/qemu-m68k > * I heard from François that one of the downstreams has added support for the > arm Beagle board? Maemo? Yes it seemed to start booting Haiku's loader built for overo btw (also an OMAP IIRC). François.
Re: [Qemu-devel] [PATCH 1/3] Add support for OpenBSD to QEMU's tap driver.
Thanks, applied all three.
On Tue, Dec 21, 2010 at 2:23 AM, Brad wrote:
> Signed-off-by: Brad Smith
>
> ---
> net/tap-bsd.c | 8 ++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/net/tap-bsd.c b/net/tap-bsd.c
> index efccfe0..2f3efde 100644
> --- a/net/tap-bsd.c
> +++ b/net/tap-bsd.c
> @@ -43,8 +43,8 @@ int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
> int vnet_hdr_required
> char *dev;
> struct stat s;
>
> -#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
> - /* if no ifname is given, always start the search from tap0. */
> +#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) ||
> defined(__OpenBSD__)
> + /* if no ifname is given, always start the search from tap0/tun0. */
> int i;
> char dname[100];
>
> @@ -52,7 +52,11 @@ int tap_open(char *ifname, int ifname_size, int *vnet_hdr,
> int vnet_hdr_required
> if (*ifname) {
> snprintf(dname, sizeof dname, "/dev/%s", ifname);
> } else {
> +#if defined(__OpenBSD__)
> + snprintf(dname, sizeof dname, "/dev/tun%d", i);
> +#else
> snprintf(dname, sizeof dname, "/dev/tap%d", i);
> +#endif
> }
> TFR(fd = open(dname, O_RDWR));
> if (fd >= 0) {
> --
> 1.7.3.2
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>
Re: [Qemu-devel] QEMU forks survey
Peter, Am 21.12.2010 um 20:04 schrieb Peter Maydell: http://meego.gitorious.org/qemu-maemo/qemu That fork includes OMAP3 support (needed for beagle) and also a large set of bugfixes for various ARM TCG issues which I've been trying to get reviewed and into upstream. (If anybody has suggestions on the best way to move forward with that I'd welcome them. So far I have been working on the "start at one end, test and submit patch series" basis...) Your work is much appreciated. ARM patches seem to have been neglected for some time. My suggestion would be to set up an official feature repository somewhere (like Kevin's "block" branch) and queue the patches there for Anthony or someone to pull and to let downstreams rebase against that. If you don't get review comments within, say, two weeks, just queue them for the next pull. That should keep things moving. You should also submit a patch to add yourself to MAINTAINERS [1] to be cc'ed on future ARM patches. Regards, Andreas [1] While the file header documents the 'T:' section, nobody seems to be using it yet. Would be nice to document that info there as well.
Re: [Qemu-devel] Re: [PATCH V2 1/2] Introduce -machine command option.
On Tue, 21 Dec 2010, Alexander Graf wrote: > > On 21.12.2010, at 19:57, Andreas Färber wrote: > > > Am 21.12.2010 um 18:33 schrieb Alexander Graf: > > > >> On 02.12.2010, at 15:18, anthony.per...@citrix.com wrote: > >> > >>> From: Anthony PERARD > >>> > >>> This option gives the ability to switch one "accelerator" like kvm, xen > >>> or the default one tcg. We can specify more than one accelerator by > >>> separate them by a colon. QEMU will try each one and use the first whose > >>> works. > >>> > >>> So, > >>> ./qemu -machine accel=xen:kvm:tcg > >>> > >>> which would try Xen support first, then KVM and finally TCG if none of > >>> the other works. > >>> > >>> By default, QEMU will use TCG. But we can specify another default in the > >>> global configuration file. > >>> > >>> Signed-off-by: Anthony PERARD > >> > >> Something went wrong with this patch set. I only have mail 1/2. 2/2 is > >> missing. Mind to resend? :) > > > > It seems to me this is v3 already - v2 2/2 was sent on Nov 23rd. > > Ah - Alex screwup again :). > > Either way, any progress on -accel? :) Actually, I sent the v2 1/2 a second time (by reply to the first patch sent) with a little fix (I forgot to initialise p in the function configure_accelerator). After this, I don't do anything more. So it's my final version. Also, the only use of the default_machine_opts (patch 2/2) is in the xen device modele support patch set, because xenpv don't rely on this. And now, it is not anymore -accel, just -machine accel=$accel. -- Anthony PERARD
Re: [Qemu-devel] QEMU forks survey
Am 21.12.2010 19:28, schrieb Andreas Färber: Since Christmas and the New Year with its good intensions are approaching, apart from z80 there's some more feature forks around: http://repo.or.cz/w/qemu.git/forks?o=age - hpoussin.git ppc contains the 40p machine that I'm reviewing for upstream inclusion currently. * qemu-loongson.git I guess was fully upstreamed recently? * ar7.git: Stefan, what's the state and scope of your work? What about TCI? ar7.git (see http://wiki.qemu.org/User:Stefan_Weil) contains * mips ar7 emulation (telekom sinus dsl and avm fritz box), working. This was my first qemu application used to debug openwrt ar7 code, and I still run it often. * tci, working (I'm still looking for new hosts to run tests), disassembler is work in progress (but maybe less important for tci). * several arm based system emulations (partially collected from qemu-devel, qdev support / bug fixes / updates / enhancements from me) * new ethernet drivers Regards, Stefan Apparently abandoned (no recent activity): * avr32.git * es40.git (alpha) * hppa.git * openrisc.git * mmix.git Unclear to me: * mini2440.git * qemu-JZ.git http://wiki.qemu.org/Links - OpenSolaris support was merged so can be disregarded. * I heard from François that one of the downstreams has added support for the arm Beagle board? Maemo? There's also many more forks on gitorious.com and github.com... Andreas
Re: [Qemu-devel] scsi-generic and max request size
> > So back to square 1 ... my vscsi (and virtio-blk too btw) can > > technically pass a max size to the guest, but we don't have a way to > > interrogate scsi-generic (and the underlying block driver) which is the > > main issue (that plus the fact that the ioctl seems to be broken in > > "compat" mode for /dev/sg specifically)... > > > Ah, the warm and fuzzy feeling knowing to be not alone in this ... > > This is basically the same issue I brought up with the first > submission round of my megasas emulation. heh. > As we're passing scatter-gather lists directly to the underlying > device we might end up sending a request which is improperly > formatted. The linux block layer has three limits onto which a > request has to be formatted: > - Max length of the scatter-gather list (max_sectors) > - Max overall request size (max_segments) Didn't you swap the 2 above ? max_sectors is the max overall req. size and max_segments the max number of SG elements afaik :-) > - Max length of individual sg elements (max_segment_size) > newer kernels export these limits; they have been exported with > commit c77a5710b7e23847bfdb81fcaa10b585f65c960a. > For older kernels, however, we're being left in the dark here. Well, first of all, "sg" is not there so that doesn't help with the scsi-generic problem much, then parsing sysfs... yuck. > So on newer kernel we probably could be doing a quick check on the > block queue limits and reformat the I/O if required. Maybe but then, "sg" isn't there. We "could" I suppose use "sr" as an indication tho when we know it's a cdrom. > Instead of reformatting we could be sendiong each element of an eg > list individually. Thereby we would be introducing some slowdown as > the sg lists have to be reassembled again by the lower layers, but > we would be insulated from any sg list mismatch. > However, this won't cover requests with too large sg elements. > For those we could probably use some simple divide-by-two algorithm > on the element to make them fit. How can we ? We need a single request to match a single sg list anyways no ? Let's say you get a READ10 from the guest for 200Kb and your underlying max_sectors is 128Kb. How do you want to "break that up" ? The only way would be to make it two different READ10's and that's a can of worms especially if you start putting tags into the picture... > But seeing we have to split the I/O requests anyway we might as well > use the divide-by-two algorithm for the sg lists, too. > > Easiest would be if we could just transfer the available bits and > push the request back to the guest as a partial completion. > Sadly the I/O stack on the guest will choose to interpret this as an > I/O error instead of retrying the remainder :-( > > So in the long run I fear we have to implement some sort of I/O > request splitting in Qemu, using the values from sysfs. So in my case, I'm happy for the time being to continue doing bounce buffering and so my only problem at the moment is the max request size (aka max_sectors). Also I -can- tell the guest what my limitation is, it's part of the vscsi login protocol. I can look into doing DMA directly to the guest SG lists later maybe. However, I can't quite figure out how to reliably obtain that information in my driver since on one hand, the ioctl doesn't seem to work in mixed 32/64-bit environments, and on the other hand, sysfs doesn't seem to have anything for "sg" in /sys/class/block... Besides, those are both Linux-isms... so we'd have to be extra careful there too. Cheers, Ben. > Cheers, > > Hannes > -- > Dr. Hannes Reinecke zSeries & Storage > h...@suse.de+49 911 74053 688 > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: Markus Rex, HRB 16746 (AG Nürnberg)
Re: [Qemu-devel] [PATCH] MIPS interrupts and -icount
On Sun, Jul 25, 2010 at 07:46:49AM +0200, Edgar E. Iglesias wrote: > On Sun, Jul 25, 2010 at 05:08:07AM +0200, Aurelien Jarno wrote: > > On Sun, Jul 25, 2010 at 02:07:54AM +0200, Edgar E. Iglesias wrote: > > > On Sun, Jul 25, 2010 at 12:55:45AM +0200, Aurelien Jarno wrote: > > > > On Thu, Jul 22, 2010 at 01:32:18PM +0200, Edgar E. Iglesias wrote: > > > > > Hi, > > > > > > > > > > I'm seeing an error when emulating MIPS guests with -icount. > > > > > In cpu_interrupt: > > > > > cpu_abort(env, "Raised interrupt while not in I/O function"); > > > > > > > > I am not able to reproduce the issue. Do you have more details how to > > > > reproduce the problem? > > > > > > You need a machine with devices that raise the hw interrupts. I didn't > > > see the error on the images on the wiki though. But I've got a machine > > > here that trigs it easily. Will check if I can publish it and an image. > > > > > > > That would be nice if you can share it. > > > > > > > It seems to me like the MIPS interrupt glue logic between interrupt > > > > > controllers and the MIPS core is not modeled correctly. > > > > > > > > It seems indeed that sometimes interrupt are triggered while not in > > > > I/O functions, your patch addresses part of the problem. > > > > > > > > > When hw interrupt pending bits in CP0_Cause are set, the CPU should > > > > > see the hw interrupt line as active. The CPU may or may not take the > > > > > interrupt based on internal state (global irq mask etc) but the glue > > > > > logic shouldn't care about that. Am I missing something here? > > > > > > > > I don't think it is correct. On the real hardware, the interrupt line is > > > > actually active only when all conditions are fulfilled. > > > > > > > > The thing to remember is that the interrupts are level triggered. So if > > > > an interrupt is masked, it should be rejected by the CPU, but could be > > > > triggered again as soon as the interrupt mask is changed. > > > > > > Agreed, that behaviour is what I'm trying to acheive. The problem now > > > is that the the level triggered line, prior to CPU masking is beeing > > > masked > > > by external logic. IMO it shouldnt. See hw/mips_int.c and cpu-exec.c prior > > > to the patch. > > > > Actually all depends if you consider the MIPS interrupt controller part > > of the CPU or not. It could be entirely modeled in the CPU, that is in > > cpu-exec.c or entirely modeled as a separate controller, that is in > > mips_int.c. > > > > IMHO it should be in mips_int.c. It is an interrupt controller like > > another that combines a few interrupt lines into a single one that feeds > > the CPU. It is like for example the i8259, with the exception that the > > configuration is not done by load/store into MMIO area, but directly > > using CPU special registers. We should probably mark these instructions > > as I/O. > > > Hi, > > I agree that it's not obvious where things should be modeled, I'll try to > explain my view. > > As a first step I'm trying to model a MIPS configured with Vectored > Interrupts. We've got external interrupt logic feeding the hw > interrupt lines. These lines are level triggered, held active by > the external logic as long as interrupts are pending. Regardless > of wether the CPU want's to take the interrupt now or later. In fact, > there is no way to access the internal flags from RTL logic located > here (AFAIK). In my mind, this layers pretty much ends in hw/mips_int.c. > > Internally in the MIPS core, I'm guessing there is logic that simpliy > applies the internal CPU masks, outputing a single internal IRQ line > that decides wether the CPU should take the IRQ or not. Here, things like > IE flags etc matter. I don't have access to RTL on the MIPS side so I'm > just guessing here. > > In my mind, we should model this latter part by asserting INTERRUPT_HARD > from hw/mips_int.c whenever any hw lines are active and letting the > CPU in cpu-exec.c decide when to take the interrupt by applying it's > internal masking. > Sorry to come back so long after this discussion, but I now have another argument. This commit causes a regression, the host CPU is now always at 100%. QEMU spent all its time looping because the CPU interrupt line is asserted. Not asserting the CPU interrupt line when interrupts are disabled fixes the issue. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
[Qemu-devel] [PATCH, RFC] pci: allow PCI devices to fix address space
From: Hervé Poussineau
v1:
* Rebased.
Signed-off-by: Hervé Poussineau
Cc: Michael S. Tsirkin
Signed-off-by: Andreas Färber
---
Hello Michael,
Could you please take a look at this? I'm out of my field here.
The intention of the first part appears to be to save (val & ~mask),
whereas the inline helper would've returned (val & mask).
The second part makes existing code conditional on that value.
Regards,
Andreas
hw/pci.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index ef00d20..4db4b1f 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -140,6 +140,7 @@ static void pci_update_irq_status(PCIDevice *dev)
static void pci_device_reset(PCIDevice *dev)
{
int r;
+uint16_t cmd;
/* TODO: call the below unconditionally once all pci devices
* are qdevified */
if (dev->qdev.info) {
@@ -149,9 +150,10 @@ static void pci_device_reset(PCIDevice *dev)
dev->irq_state = 0;
pci_update_irq_status(dev);
/* Clear all writeable bits */
-pci_word_test_and_clear_mask(dev->config + PCI_COMMAND,
- pci_get_word(dev->wmask + PCI_COMMAND) |
- pci_get_word(dev->w1cmask + PCI_COMMAND));
+cmd = pci_get_word(dev->config + PCI_COMMAND);
+cmd &= ~(pci_get_word(dev->wmask + PCI_COMMAND) |
+ pci_get_word(dev->w1cmask + PCI_COMMAND));
+pci_set_word(dev->config + PCI_COMMAND, cmd);
pci_word_test_and_clear_mask(dev->config + PCI_STATUS,
pci_get_word(dev->wmask + PCI_STATUS) |
pci_get_word(dev->w1cmask + PCI_STATUS));
@@ -163,11 +165,15 @@ static void pci_device_reset(PCIDevice *dev)
continue;
}
-if (!(region->type & PCI_BASE_ADDRESS_SPACE_IO) &&
-region->type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
-pci_set_quad(dev->config + pci_bar(dev, r), region->type);
-} else {
-pci_set_long(dev->config + pci_bar(dev, r), region->type);
+if ((region->type == PCI_BASE_ADDRESS_SPACE_IO && !(cmd &
PCI_COMMAND_MEMORY)) ||
+(region->type == PCI_BASE_ADDRESS_SPACE_MEMORY && !(cmd &
PCI_COMMAND_IO))) {
+/* Reset region address, as it it is not read-only */
+if (!(region->type & PCI_BASE_ADDRESS_SPACE_IO) &&
+region->type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
+pci_set_quad(dev->config + pci_bar(dev, r), region->type);
+} else {
+pci_set_long(dev->config + pci_bar(dev, r), region->type);
+}
}
}
pci_update_mappings(dev);
--
1.7.3.4
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
Am 21.12.2010 um 01:46 schrieb Alexander Graf: On 21.12.2010, at 01:33, Andreas Färber wrote: OpenHack'Ware never worked for me before. Supposedly patched Linux kernels loaded via -kernel, still searching for a working one though... $ qemu-system-ppc -M prep -nographic ERROR: BUG caught... BIOS execution exception nip=0x0580 msr=0x2000 dar=0x dsisr=0x Stopping execution $ qemu-system-ppc -M prep -kernel .../vmlinuz-2.4.25 -nographic # http://www.olifantasia.com/qemu/ ERROR: BUG caught... BIOS execution exception nip=0x0580 msr=0x2000 dar=0x dsisr=0x Stopping execution $ qemu-system-ppc -M prep -kernel .../vmlinuz-2.4.25 -append 'ide0=0x1f0,0x3f6,13 ide1=0x170,0x376,13 netdev=9,0x300,eth0 console=ttyS0 console=tty0 root=/dev/hda' -nographic ERROR: BUG caught... BIOS execution exception nip=0x0580 msr=0x2000 dar=0x dsisr=0x Stopping execution This one boots for me on qemu from SLES10SP3 (0.8.2): http://www.oszoo.org/wiki/index.php/Debian_Etch_ppc_(PowerPC)_-_Qemu_Ready $ qemu-system-ppc -m 256 -M prep -kernel .../zImage.prep -hda .../ debian-ppc-qemu.qcow -nographic shows same error as above. Could this be due to the IRQ issue? The older kernel did expect IRQ 13 twice. I would expect it to get a little further before running into such an error... Andreas
Re: [Qemu-devel] [PATCH v2] hw/virtio-9p-local.c: Remove unnecessary null char in symlink file
On 12/20/2010 11:51 PM, Stefan Hajnoczi wrote: > On Tue, Dec 21, 2010 at 5:20 AM, Harsh Prateek Bora > wrote: >> This patch removes the addition of null char in symlink file >> which is being appended to file in case of mapped security model. >> Without this patch, the extra null char causes LTP testcase lstat03 >> to fail and hence this fix is required. > > Looks good. > > Related note: local_readlink() with fs_sm == SM_MAPPED reads the > contents of *any* file. I don't see a check that the file is actually > a symlink. What if an application relies on the EINVAL return value > when calling readlink() on something that is not a file (not sure how > this maps through to 9p though)? Stefan, yes. This is a bug we realized .. fix will be on the way shortly. :) Thanks, JV > > Stefan >
Re: [Qemu-devel] [PATCH, RFC] pci: allow PCI devices to fix address space
On Wed, Dec 22, 2010 at 12:20:23AM +0100, Andreas Färber wrote:
> From: Hervé Poussineau
>
> v1:
> * Rebased.
>
> Signed-off-by: Hervé Poussineau
> Cc: Michael S. Tsirkin
> Signed-off-by: Andreas Färber
> ---
>
> Hello Michael,
>
> Could you please take a look at this? I'm out of my field here.
>
> The intention of the first part appears to be to save (val & ~mask),
> whereas the inline helper would've returned (val & mask).
Such behavior is intended.
The returned value is just discarded in this case.
test-and-clear means
clear the bits
return if those cleared bits were really set.
> The second part makes existing code conditional on that value.
What issue are you addressing?
Although the spec doesn't says about the default value of BAR registers
after reset, the current code assumes that almost all the pci devices clear
those registers.
Anyway after cold/warm reset firmware sets up BARs, so it doesn't matter.
You, however, seem to want to keep BARs over resets.
thanks,
>
> Regards,
> Andreas
>
> hw/pci.c | 22 ++
> 1 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/hw/pci.c b/hw/pci.c
> index ef00d20..4db4b1f 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -140,6 +140,7 @@ static void pci_update_irq_status(PCIDevice *dev)
> static void pci_device_reset(PCIDevice *dev)
> {
> int r;
> +uint16_t cmd;
> /* TODO: call the below unconditionally once all pci devices
> * are qdevified */
> if (dev->qdev.info) {
> @@ -149,9 +150,10 @@ static void pci_device_reset(PCIDevice *dev)
> dev->irq_state = 0;
> pci_update_irq_status(dev);
> /* Clear all writeable bits */
> -pci_word_test_and_clear_mask(dev->config + PCI_COMMAND,
> - pci_get_word(dev->wmask + PCI_COMMAND) |
> - pci_get_word(dev->w1cmask + PCI_COMMAND));
> +cmd = pci_get_word(dev->config + PCI_COMMAND);
> +cmd &= ~(pci_get_word(dev->wmask + PCI_COMMAND) |
> + pci_get_word(dev->w1cmask + PCI_COMMAND));
> +pci_set_word(dev->config + PCI_COMMAND, cmd);
> pci_word_test_and_clear_mask(dev->config + PCI_STATUS,
> pci_get_word(dev->wmask + PCI_STATUS) |
> pci_get_word(dev->w1cmask + PCI_STATUS));
> @@ -163,11 +165,15 @@ static void pci_device_reset(PCIDevice *dev)
> continue;
> }
>
> -if (!(region->type & PCI_BASE_ADDRESS_SPACE_IO) &&
> -region->type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> -pci_set_quad(dev->config + pci_bar(dev, r), region->type);
> -} else {
> -pci_set_long(dev->config + pci_bar(dev, r), region->type);
> +if ((region->type == PCI_BASE_ADDRESS_SPACE_IO && !(cmd &
> PCI_COMMAND_MEMORY)) ||
> +(region->type == PCI_BASE_ADDRESS_SPACE_MEMORY && !(cmd &
> PCI_COMMAND_IO))) {
> +/* Reset region address, as it it is not read-only */
> +if (!(region->type & PCI_BASE_ADDRESS_SPACE_IO) &&
> +region->type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> +pci_set_quad(dev->config + pci_bar(dev, r), region->type);
> +} else {
> +pci_set_long(dev->config + pci_bar(dev, r), region->type);
> +}
> }
> }
> pci_update_mappings(dev);
> --
> 1.7.3.4
>
>
--
yamahata
[Qemu-devel] [PATCH] pci: disable migration of p2p bridge
Right now pcibus_get_dev_path() isn't migration save because bus number/secondary bus number are set by guest OS. So it can't be used reliably for qemu internal id. For 0.14 release, disable p2p bridge migration at the moment. Once pcibus_get_dev_path() is fixed, this patch should be reverted. It will be addressed for 0.15 release. Cc: "Michael S. Tsirkin" Cc: Alex Williamson Cc: Blue Swirl Signed-off-by: Isaku Yamahata --- hw/apb_pci.c|9 + hw/dec_pci.c|6 ++ hw/ioh3420.c|4 hw/xio3130_downstream.c |4 hw/xio3130_upstream.c |4 5 files changed, 27 insertions(+), 0 deletions(-) diff --git a/hw/apb_pci.c b/hw/apb_pci.c index 84e9af7..c456d8d 100644 --- a/hw/apb_pci.c +++ b/hw/apb_pci.c @@ -368,6 +368,11 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base, qdev_init_nofail(&pci_dev->qdev); *bus2 = pci_bridge_get_sec_bus(br); +/* TODO: p2p bridge migration. pcibus_get_dev_path() isn't migration-safe. + remove this once p2p bridge migration is supported */ +register_device_unmigratable(&pci_dev->qdev, "pbm-bridge", &pci_dev->qdev); + + pci_dev = pci_create_multifunction(d->bus, PCI_DEVFN(1, 1), true, "pbm-bridge"); br = DO_UPCAST(PCIBridge, dev, pci_dev); @@ -376,6 +381,10 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base, qdev_init_nofail(&pci_dev->qdev); *bus3 = pci_bridge_get_sec_bus(br); +/* TODO: p2p bridge migration. pcibus_get_dev_path() isn't migration-safe. + remove this once p2p bridge migration is supported */ +register_device_unmigratable(&pci_dev->qdev, "pbm-bridge", &pci_dev->qdev); + return d->bus; } diff --git a/hw/dec_pci.c b/hw/dec_pci.c index bf88f2a..3710984 100644 --- a/hw/dec_pci.c +++ b/hw/dec_pci.c @@ -86,6 +86,12 @@ PCIBus *pci_dec_21154_init(PCIBus *parent_bus, int devfn) br = DO_UPCAST(PCIBridge, dev, dev); pci_bridge_map_irq(br, "DEC 21154 PCI-PCI bridge", dec_map_irq); qdev_init_nofail(&dev->qdev); + +/* TODO: p2p bridge migration. pcibus_get_dev_path() isn't migration-safe. + remove this once p2p bridge migration is supported */ +register_device_unmigratable(&dev->qdev, "dec-21154-p2p-bridge", + &dev->qdev); + return pci_bridge_get_sec_bus(br); } diff --git a/hw/ioh3420.c b/hw/ioh3420.c index 95adf09..b1a5c96 100644 --- a/hw/ioh3420.c +++ b/hw/ioh3420.c @@ -188,6 +188,10 @@ PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool multifunction, qdev_prop_set_uint16(qdev, "slot", slot); qdev_init_nofail(qdev); +/* TODO: p2p bridge migration. pcibus_get_dev_path() isn't migration-safe. + remove this once p2p bridge migration is supported */ +register_device_unmigratable(qdev, "ioh3420", qdev); + return DO_UPCAST(PCIESlot, port, DO_UPCAST(PCIEPort, br, br)); } diff --git a/hw/xio3130_downstream.c b/hw/xio3130_downstream.c index 1a2d258..83394ab 100644 --- a/hw/xio3130_downstream.c +++ b/hw/xio3130_downstream.c @@ -153,6 +153,10 @@ PCIESlot *xio3130_downstream_init(PCIBus *bus, int devfn, bool multifunction, qdev_prop_set_uint16(qdev, "slot", slot); qdev_init_nofail(qdev); +/* TODO: p2p bridge migration. pcibus_get_dev_path() isn't migration-safe. + remove this once p2p bridge migration is supported */ +register_device_unmigratable(qdev, "x3130-downstream", qdev); + return DO_UPCAST(PCIESlot, port, DO_UPCAST(PCIEPort, br, br)); } diff --git a/hw/xio3130_upstream.c b/hw/xio3130_upstream.c index 387bf6c..cbd126a 100644 --- a/hw/xio3130_upstream.c +++ b/hw/xio3130_upstream.c @@ -134,6 +134,10 @@ PCIEPort *xio3130_upstream_init(PCIBus *bus, int devfn, bool multifunction, qdev_prop_set_uint8(qdev, "port", port); qdev_init_nofail(qdev); +/* TODO: p2p bridge migration. pcibus_get_dev_path() isn't migration-safe. + remove this once p2p bridge migration is supported */ +register_device_unmigratable(qdev, "x3130-upstream", qdev); + return DO_UPCAST(PCIEPort, br, br); } -- 1.7.1.1
[Qemu-devel] [PATCH] pc/piix: fix mismerge of b1aeb92666d2fde413c34578b3b42bbfe5f2a506
The change set of b1aeb92666d2fde413c34578b3b42bbfe5f2a506 in pci branch
was mismerged. The compatibility should be kept for 0.13, not for 0.14.
Signed-off-by: Isaku Yamahata
---
hw/pc_piix.c | 12
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index a2fb554..f82508d 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -217,14 +217,6 @@ static QEMUMachine pc_machine = {
.desc = "Standard PC",
.init = pc_init_pci,
.max_cpus = 255,
-.compat_props = (GlobalProperty[]) {
-{
-.driver = "PCI",
-.property = "command_serr_enable",
-.value= "off",
-},
-{ /* end of list */ }
-},
.is_default = 1,
};
@@ -246,6 +238,10 @@ static QEMUMachine pc_machine_v0_13 = {
.driver = "vmware-svga",
.property = "rombar",
.value= stringify(0),
+},{
+.driver = "PCI",
+.property = "command_serr_enable",
+.value= "off",
},
{ /* end of list */ }
},
--
1.7.1.1
[Qemu-devel] [PATCH] pcie: add flr support
support flr.
Signed-off-by: Isaku Yamahata
---
hw/pci.c|6 +-
hw/pci.h|1 +
hw/pcie.c | 11 +--
hw/pcie.h |2 --
hw/xio3130_downstream.c |2 +-
hw/xio3130_upstream.c |3 ---
6 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 0cb4117..eb21848 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -137,7 +137,11 @@ static void pci_update_irq_status(PCIDevice *dev)
}
}
-static void pci_device_reset(PCIDevice *dev)
+/*
+ * This function is called on #RST and FLR.
+ * FLR if PCI_EXP_DEVCTL_BCR_FLR is set
+ */
+void pci_device_reset(PCIDevice *dev)
{
int r;
/* TODO: call the below unconditionally once all pci devices
diff --git a/hw/pci.h b/hw/pci.h
index 17744dc..6e80b08 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -237,6 +237,7 @@ void pci_bus_hotplug(PCIBus *bus, pci_hotplug_fn hotplug,
DeviceState *dev);
PCIBus *pci_register_bus(DeviceState *parent, const char *name,
pci_set_irq_fn set_irq, pci_map_irq_fn map_irq,
void *irq_opaque, int devfn_min, int nirq);
+void pci_device_reset(PCIDevice *dev);
void pci_bus_reset(PCIBus *bus);
void pci_bus_set_mem_base(PCIBus *bus, target_phys_addr_t base);
diff --git a/hw/pcie.c b/hw/pcie.c
index d1f0086..b93fba4 100644
--- a/hw/pcie.c
+++ b/hw/pcie.c
@@ -380,10 +380,6 @@ void pcie_cap_root_reset(PCIDevice *dev)
pci_set_word(dev->config + dev->exp.exp_cap + PCI_EXP_RTCTL, 0);
}
-/*
- * TODO: implement FLR:
- * Right now sets the bit which indicates FLR is supported.
- */
/* function level reset(FLR) */
void pcie_cap_flr_init(PCIDevice *dev)
{
@@ -403,8 +399,11 @@ void pcie_cap_flr_write_config(PCIDevice *dev,
uint32_t addr, uint32_t val, int len)
{
uint8_t *devctl = dev->config + dev->exp.exp_cap + PCI_EXP_DEVCTL;
-if (pci_word_test_and_clear_mask(devctl, PCI_EXP_DEVCTL_BCR_FLR)) {
-/* TODO: implement FLR */
+if (pci_get_word(devctl) & PCI_EXP_DEVCTL_BCR_FLR) {
+/* don't clear PCI_EXP_DEVCTL_BCR_FLR to tell reset handler
+ that this reset is FLR */
+pci_device_reset(dev);
+pci_word_test_and_clear_mask(devctl, PCI_EXP_DEVCTL_BCR_FLR);
}
}
diff --git a/hw/pcie.h b/hw/pcie.h
index 7baa813..bc909e2 100644
--- a/hw/pcie.h
+++ b/hw/pcie.h
@@ -63,8 +63,6 @@ struct PCIExpressDevice {
/* Offset of express capability in config space */
uint8_t exp_cap;
-/* TODO FLR */
-
/* SLOT */
unsigned int hpev_intx; /* INTx for hot plug event (0-3:INT[A-D]#)
* default is 0 = INTA#
diff --git a/hw/xio3130_downstream.c b/hw/xio3130_downstream.c
index 1a2d258..5aa6a6b 100644
--- a/hw/xio3130_downstream.c
+++ b/hw/xio3130_downstream.c
@@ -89,7 +89,7 @@ static int xio3130_downstream_initfn(PCIDevice *d)
if (rc < 0) {
goto err_msi;
}
-pcie_cap_flr_init(d); /* TODO: implement FLR */
+pcie_cap_flr_init(d);
pcie_cap_deverr_init(d);
pcie_cap_slot_init(d, s->slot);
pcie_chassis_create(s->chassis);
diff --git a/hw/xio3130_upstream.c b/hw/xio3130_upstream.c
index 387bf6c..a7640f5 100644
--- a/hw/xio3130_upstream.c
+++ b/hw/xio3130_upstream.c
@@ -85,10 +85,7 @@ static int xio3130_upstream_initfn(PCIDevice *d)
if (rc < 0) {
goto err_msi;
}
-
-/* TODO: implement FLR */
pcie_cap_flr_init(d);
-
pcie_cap_deverr_init(d);
rc = pcie_aer_init(d, XIO3130_AER_OFFSET);
if (rc < 0) {
--
1.7.1.1
Re: [Qemu-devel] [PATCH, RFC] pci: allow PCI devices to fix address space
On Wed, Dec 22, 2010 at 11:50:14AM +0900, Isaku Yamahata wrote:
> On Wed, Dec 22, 2010 at 12:20:23AM +0100, Andreas Färber wrote:
> > From: Hervé Poussineau
> >
> > v1:
> > * Rebased.
> >
> > Signed-off-by: Hervé Poussineau
> > Cc: Michael S. Tsirkin
> > Signed-off-by: Andreas Färber
> > ---
> >
> > Hello Michael,
> >
> > Could you please take a look at this? I'm out of my field here.
> >
> > The intention of the first part appears to be to save (val & ~mask),
> > whereas the inline helper would've returned (val & mask).
>
> Such behavior is intended.
> The returned value is just discarded in this case.
> test-and-clear means
> clear the bits
> return if those cleared bits were really set.
>
>
> > The second part makes existing code conditional on that value.
>
> What issue are you addressing?
Yes I'd like to know that too:
> Although the spec doesn't says about the default value of BAR registers
> after reset, the current code assumes that almost all the pci devices clear
> those registers.
> Anyway after cold/warm reset firmware sets up BARs, so it doesn't matter.
> You, however, seem to want to keep BARs over resets.
>
> thanks,
>
>
> >
> > Regards,
> > Andreas
> >
> > hw/pci.c | 22 ++
> > 1 files changed, 14 insertions(+), 8 deletions(-)
> >
> > diff --git a/hw/pci.c b/hw/pci.c
> > index ef00d20..4db4b1f 100644
> > --- a/hw/pci.c
> > +++ b/hw/pci.c
> > @@ -140,6 +140,7 @@ static void pci_update_irq_status(PCIDevice *dev)
> > static void pci_device_reset(PCIDevice *dev)
> > {
> > int r;
> > +uint16_t cmd;
> > /* TODO: call the below unconditionally once all pci devices
> > * are qdevified */
> > if (dev->qdev.info) {
> > @@ -149,9 +150,10 @@ static void pci_device_reset(PCIDevice *dev)
> > dev->irq_state = 0;
> > pci_update_irq_status(dev);
> > /* Clear all writeable bits */
> > -pci_word_test_and_clear_mask(dev->config + PCI_COMMAND,
> > - pci_get_word(dev->wmask + PCI_COMMAND) |
> > - pci_get_word(dev->w1cmask + PCI_COMMAND));
> > +cmd = pci_get_word(dev->config + PCI_COMMAND);
> > +cmd &= ~(pci_get_word(dev->wmask + PCI_COMMAND) |
> > + pci_get_word(dev->w1cmask + PCI_COMMAND));
> > +pci_set_word(dev->config + PCI_COMMAND, cmd);
> > pci_word_test_and_clear_mask(dev->config + PCI_STATUS,
> > pci_get_word(dev->wmask + PCI_STATUS) |
> > pci_get_word(dev->w1cmask + PCI_STATUS));
> > @@ -163,11 +165,15 @@ static void pci_device_reset(PCIDevice *dev)
> > continue;
> > }
> >
> > -if (!(region->type & PCI_BASE_ADDRESS_SPACE_IO) &&
> > -region->type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> > -pci_set_quad(dev->config + pci_bar(dev, r), region->type);
> > -} else {
> > -pci_set_long(dev->config + pci_bar(dev, r), region->type);
> > +if ((region->type == PCI_BASE_ADDRESS_SPACE_IO && !(cmd &
> > PCI_COMMAND_MEMORY)) ||
> > +(region->type == PCI_BASE_ADDRESS_SPACE_MEMORY && !(cmd &
> > PCI_COMMAND_IO))) {
You want to make memory/io bits in the command register read-only
and hardwired to 1? This seems out of spec, no?
> > +/* Reset region address, as it it is not read-only */
> > +if (!(region->type & PCI_BASE_ADDRESS_SPACE_IO) &&
> > +region->type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> > +pci_set_quad(dev->config + pci_bar(dev, r), region->type);
> > +} else {
> > +pci_set_long(dev->config + pci_bar(dev, r), region->type);
> > +}
> > }
> > }
> > pci_update_mappings(dev);
> > --
> > 1.7.3.4
> >
> >
>
> --
> yamahata
[Qemu-devel] Re: [PATCH] pc/piix: fix mismerge of b1aeb92666d2fde413c34578b3b42bbfe5f2a506
On Wed, Dec 22, 2010 at 03:13:43PM +0900, Isaku Yamahata wrote:
> The change set of b1aeb92666d2fde413c34578b3b42bbfe5f2a506 in pci branch
> was mismerged. The compatibility should be kept for 0.13, not for 0.14.
>
> Signed-off-by: Isaku Yamahata
Applied.
> ---
> hw/pc_piix.c | 12
> 1 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/hw/pc_piix.c b/hw/pc_piix.c
> index a2fb554..f82508d 100644
> --- a/hw/pc_piix.c
> +++ b/hw/pc_piix.c
> @@ -217,14 +217,6 @@ static QEMUMachine pc_machine = {
> .desc = "Standard PC",
> .init = pc_init_pci,
> .max_cpus = 255,
> -.compat_props = (GlobalProperty[]) {
> -{
> -.driver = "PCI",
> -.property = "command_serr_enable",
> -.value= "off",
> -},
> -{ /* end of list */ }
> -},
> .is_default = 1,
> };
>
> @@ -246,6 +238,10 @@ static QEMUMachine pc_machine_v0_13 = {
> .driver = "vmware-svga",
> .property = "rombar",
> .value= stringify(0),
> +},{
> +.driver = "PCI",
> +.property = "command_serr_enable",
> +.value= "off",
> },
> { /* end of list */ }
> },
> --
> 1.7.1.1
Re: [Qemu-devel] [PATCH, RFC] pci: allow PCI devices to fix address space
Isaku Yamahata a écrit :
On Wed, Dec 22, 2010 at 12:20:23AM +0100, Andreas Färber wrote:
From: Hervé Poussineau
v1:
* Rebased.
Signed-off-by: Hervé Poussineau
Cc: Michael S. Tsirkin
Signed-off-by: Andreas Färber
---
Hello Michael,
Could you please take a look at this? I'm out of my field here.
The intention of the first part appears to be to save (val & ~mask),
whereas the inline helper would've returned (val & mask).
Such behavior is intended.
The returned value is just discarded in this case.
test-and-clear means
clear the bits
return if those cleared bits were really set.
The second part makes existing code conditional on that value.
What issue are you addressing?
Although the spec doesn't says about the default value of BAR registers
after reset, the current code assumes that almost all the pci devices clear
those registers.
Anyway after cold/warm reset firmware sets up BARs, so it doesn't matter.
You, however, seem to want to keep BARs over resets.
thanks,
As you have seen, the intend here is to be able to keep BARs over resets.
It is required for some really specific devices, like a PCI to ISA
bridge, where MMIO is always at the same address.
In that case, the device keeps PCI_COMMAND_MEMORY and/or PCI_COMMAND_IO
flags as read-only.
Hervé
Regards,
Andreas
hw/pci.c | 22 ++
1 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index ef00d20..4db4b1f 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -140,6 +140,7 @@ static void pci_update_irq_status(PCIDevice *dev)
static void pci_device_reset(PCIDevice *dev)
{
int r;
+uint16_t cmd;
/* TODO: call the below unconditionally once all pci devices
* are qdevified */
if (dev->qdev.info) {
@@ -149,9 +150,10 @@ static void pci_device_reset(PCIDevice *dev)
dev->irq_state = 0;
pci_update_irq_status(dev);
/* Clear all writeable bits */
-pci_word_test_and_clear_mask(dev->config + PCI_COMMAND,
- pci_get_word(dev->wmask + PCI_COMMAND) |
- pci_get_word(dev->w1cmask + PCI_COMMAND));
+cmd = pci_get_word(dev->config + PCI_COMMAND);
+cmd &= ~(pci_get_word(dev->wmask + PCI_COMMAND) |
+ pci_get_word(dev->w1cmask + PCI_COMMAND));
+pci_set_word(dev->config + PCI_COMMAND, cmd);
pci_word_test_and_clear_mask(dev->config + PCI_STATUS,
pci_get_word(dev->wmask + PCI_STATUS) |
pci_get_word(dev->w1cmask + PCI_STATUS));
@@ -163,11 +165,15 @@ static void pci_device_reset(PCIDevice *dev)
continue;
}
-if (!(region->type & PCI_BASE_ADDRESS_SPACE_IO) &&
-region->type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
-pci_set_quad(dev->config + pci_bar(dev, r), region->type);
-} else {
-pci_set_long(dev->config + pci_bar(dev, r), region->type);
+if ((region->type == PCI_BASE_ADDRESS_SPACE_IO && !(cmd &
PCI_COMMAND_MEMORY)) ||
+(region->type == PCI_BASE_ADDRESS_SPACE_MEMORY && !(cmd &
PCI_COMMAND_IO))) {
+/* Reset region address, as it it is not read-only */
+if (!(region->type & PCI_BASE_ADDRESS_SPACE_IO) &&
+region->type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
+pci_set_quad(dev->config + pci_bar(dev, r), region->type);
+} else {
+pci_set_long(dev->config + pci_bar(dev, r), region->type);
+}
}
}
pci_update_mappings(dev);
--
1.7.3.4
[Qemu-devel] Re: [PATCH] pci: disable migration of p2p bridge
On Wed, Dec 22, 2010 at 12:13:43PM +0900, Isaku Yamahata wrote: > Right now pcibus_get_dev_path() isn't migration save because > bus number/secondary bus number are set by guest OS. > So it can't be used reliably for qemu internal id. > > For 0.14 release, disable p2p bridge migration at the moment. > Once pcibus_get_dev_path() is fixed, this patch should be reverted. > It will be addressed for 0.15 release. > > Cc: "Michael S. Tsirkin" > Cc: Alex Williamson > Cc: Blue Swirl > Signed-off-by: Isaku Yamahata Hmm, haven't looked into this deeply - can we do this in one place when the bridge is created? > --- > hw/apb_pci.c|9 + > hw/dec_pci.c|6 ++ > hw/ioh3420.c|4 > hw/xio3130_downstream.c |4 > hw/xio3130_upstream.c |4 > 5 files changed, 27 insertions(+), 0 deletions(-) > > diff --git a/hw/apb_pci.c b/hw/apb_pci.c > index 84e9af7..c456d8d 100644 > --- a/hw/apb_pci.c > +++ b/hw/apb_pci.c > @@ -368,6 +368,11 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base, > qdev_init_nofail(&pci_dev->qdev); > *bus2 = pci_bridge_get_sec_bus(br); > > +/* TODO: p2p bridge migration. pcibus_get_dev_path() isn't > migration-safe. > + remove this once p2p bridge migration is supported */ > +register_device_unmigratable(&pci_dev->qdev, "pbm-bridge", > &pci_dev->qdev); > + > + > pci_dev = pci_create_multifunction(d->bus, PCI_DEVFN(1, 1), true, > "pbm-bridge"); > br = DO_UPCAST(PCIBridge, dev, pci_dev); > @@ -376,6 +381,10 @@ PCIBus *pci_apb_init(target_phys_addr_t special_base, > qdev_init_nofail(&pci_dev->qdev); > *bus3 = pci_bridge_get_sec_bus(br); > > +/* TODO: p2p bridge migration. pcibus_get_dev_path() isn't > migration-safe. > + remove this once p2p bridge migration is supported */ > +register_device_unmigratable(&pci_dev->qdev, "pbm-bridge", > &pci_dev->qdev); > + > return d->bus; > } > > diff --git a/hw/dec_pci.c b/hw/dec_pci.c > index bf88f2a..3710984 100644 > --- a/hw/dec_pci.c > +++ b/hw/dec_pci.c > @@ -86,6 +86,12 @@ PCIBus *pci_dec_21154_init(PCIBus *parent_bus, int devfn) > br = DO_UPCAST(PCIBridge, dev, dev); > pci_bridge_map_irq(br, "DEC 21154 PCI-PCI bridge", dec_map_irq); > qdev_init_nofail(&dev->qdev); > + > +/* TODO: p2p bridge migration. pcibus_get_dev_path() isn't > migration-safe. > + remove this once p2p bridge migration is supported */ > +register_device_unmigratable(&dev->qdev, "dec-21154-p2p-bridge", > + &dev->qdev); > + > return pci_bridge_get_sec_bus(br); > } > > diff --git a/hw/ioh3420.c b/hw/ioh3420.c > index 95adf09..b1a5c96 100644 > --- a/hw/ioh3420.c > +++ b/hw/ioh3420.c > @@ -188,6 +188,10 @@ PCIESlot *ioh3420_init(PCIBus *bus, int devfn, bool > multifunction, > qdev_prop_set_uint16(qdev, "slot", slot); > qdev_init_nofail(qdev); > > +/* TODO: p2p bridge migration. pcibus_get_dev_path() isn't > migration-safe. > + remove this once p2p bridge migration is supported */ > +register_device_unmigratable(qdev, "ioh3420", qdev); > + > return DO_UPCAST(PCIESlot, port, DO_UPCAST(PCIEPort, br, br)); > } > > diff --git a/hw/xio3130_downstream.c b/hw/xio3130_downstream.c > index 1a2d258..83394ab 100644 > --- a/hw/xio3130_downstream.c > +++ b/hw/xio3130_downstream.c > @@ -153,6 +153,10 @@ PCIESlot *xio3130_downstream_init(PCIBus *bus, int > devfn, bool multifunction, > qdev_prop_set_uint16(qdev, "slot", slot); > qdev_init_nofail(qdev); > > +/* TODO: p2p bridge migration. pcibus_get_dev_path() isn't > migration-safe. > + remove this once p2p bridge migration is supported */ > +register_device_unmigratable(qdev, "x3130-downstream", qdev); > + > return DO_UPCAST(PCIESlot, port, DO_UPCAST(PCIEPort, br, br)); > } > > diff --git a/hw/xio3130_upstream.c b/hw/xio3130_upstream.c > index 387bf6c..cbd126a 100644 > --- a/hw/xio3130_upstream.c > +++ b/hw/xio3130_upstream.c > @@ -134,6 +134,10 @@ PCIEPort *xio3130_upstream_init(PCIBus *bus, int devfn, > bool multifunction, > qdev_prop_set_uint8(qdev, "port", port); > qdev_init_nofail(qdev); > > +/* TODO: p2p bridge migration. pcibus_get_dev_path() isn't > migration-safe. > + remove this once p2p bridge migration is supported */ > +register_device_unmigratable(qdev, "x3130-upstream", qdev); > + > return DO_UPCAST(PCIEPort, br, br); > } > > -- > 1.7.1.1
[Qemu-devel] Re: [PATCH] pcie: add flr support
On Wed, Dec 22, 2010 at 03:14:35PM +0900, Isaku Yamahata wrote:
> support flr.
>
> Signed-off-by: Isaku Yamahata
Applied.
> ---
> hw/pci.c|6 +-
> hw/pci.h|1 +
> hw/pcie.c | 11 +--
> hw/pcie.h |2 --
> hw/xio3130_downstream.c |2 +-
> hw/xio3130_upstream.c |3 ---
> 6 files changed, 12 insertions(+), 13 deletions(-)
>
> diff --git a/hw/pci.c b/hw/pci.c
> index 0cb4117..eb21848 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -137,7 +137,11 @@ static void pci_update_irq_status(PCIDevice *dev)
> }
> }
>
> -static void pci_device_reset(PCIDevice *dev)
> +/*
> + * This function is called on #RST and FLR.
> + * FLR if PCI_EXP_DEVCTL_BCR_FLR is set
> + */
> +void pci_device_reset(PCIDevice *dev)
> {
> int r;
> /* TODO: call the below unconditionally once all pci devices
> diff --git a/hw/pci.h b/hw/pci.h
> index 17744dc..6e80b08 100644
> --- a/hw/pci.h
> +++ b/hw/pci.h
> @@ -237,6 +237,7 @@ void pci_bus_hotplug(PCIBus *bus, pci_hotplug_fn hotplug,
> DeviceState *dev);
> PCIBus *pci_register_bus(DeviceState *parent, const char *name,
> pci_set_irq_fn set_irq, pci_map_irq_fn map_irq,
> void *irq_opaque, int devfn_min, int nirq);
> +void pci_device_reset(PCIDevice *dev);
> void pci_bus_reset(PCIBus *bus);
>
> void pci_bus_set_mem_base(PCIBus *bus, target_phys_addr_t base);
> diff --git a/hw/pcie.c b/hw/pcie.c
> index d1f0086..b93fba4 100644
> --- a/hw/pcie.c
> +++ b/hw/pcie.c
> @@ -380,10 +380,6 @@ void pcie_cap_root_reset(PCIDevice *dev)
> pci_set_word(dev->config + dev->exp.exp_cap + PCI_EXP_RTCTL, 0);
> }
>
> -/*
> - * TODO: implement FLR:
> - * Right now sets the bit which indicates FLR is supported.
> - */
> /* function level reset(FLR) */
> void pcie_cap_flr_init(PCIDevice *dev)
> {
> @@ -403,8 +399,11 @@ void pcie_cap_flr_write_config(PCIDevice *dev,
> uint32_t addr, uint32_t val, int len)
> {
> uint8_t *devctl = dev->config + dev->exp.exp_cap + PCI_EXP_DEVCTL;
> -if (pci_word_test_and_clear_mask(devctl, PCI_EXP_DEVCTL_BCR_FLR)) {
> -/* TODO: implement FLR */
> +if (pci_get_word(devctl) & PCI_EXP_DEVCTL_BCR_FLR) {
> +/* don't clear PCI_EXP_DEVCTL_BCR_FLR to tell reset handler
> + that this reset is FLR */
Rewritten this comment:
> /* Clear PCI_EXP_DEVCTL_BCR_FLR after invoking the reset handler
>so the handler can detect FLR by looking at this bit. */
This was the intent, yes?
> +pci_device_reset(dev);
> +pci_word_test_and_clear_mask(devctl, PCI_EXP_DEVCTL_BCR_FLR);
> }
> }
>
> diff --git a/hw/pcie.h b/hw/pcie.h
> index 7baa813..bc909e2 100644
> --- a/hw/pcie.h
> +++ b/hw/pcie.h
> @@ -63,8 +63,6 @@ struct PCIExpressDevice {
> /* Offset of express capability in config space */
> uint8_t exp_cap;
>
> -/* TODO FLR */
> -
> /* SLOT */
> unsigned int hpev_intx; /* INTx for hot plug event (0-3:INT[A-D]#)
> * default is 0 = INTA#
> diff --git a/hw/xio3130_downstream.c b/hw/xio3130_downstream.c
> index 1a2d258..5aa6a6b 100644
> --- a/hw/xio3130_downstream.c
> +++ b/hw/xio3130_downstream.c
> @@ -89,7 +89,7 @@ static int xio3130_downstream_initfn(PCIDevice *d)
> if (rc < 0) {
> goto err_msi;
> }
> -pcie_cap_flr_init(d); /* TODO: implement FLR */
> +pcie_cap_flr_init(d);
> pcie_cap_deverr_init(d);
> pcie_cap_slot_init(d, s->slot);
> pcie_chassis_create(s->chassis);
> diff --git a/hw/xio3130_upstream.c b/hw/xio3130_upstream.c
> index 387bf6c..a7640f5 100644
> --- a/hw/xio3130_upstream.c
> +++ b/hw/xio3130_upstream.c
> @@ -85,10 +85,7 @@ static int xio3130_upstream_initfn(PCIDevice *d)
> if (rc < 0) {
> goto err_msi;
> }
> -
> -/* TODO: implement FLR */
> pcie_cap_flr_init(d);
> -
> pcie_cap_deverr_init(d);
> rc = pcie_aer_init(d, XIO3130_AER_OFFSET);
> if (rc < 0) {
> --
> 1.7.1.1
Re: [Qemu-devel] [PATCH, RFC] pci: allow PCI devices to fix address space
On Wed, Dec 22, 2010 at 07:30:33AM +0100, Hervé Poussineau wrote:
> Isaku Yamahata a écrit :
> >On Wed, Dec 22, 2010 at 12:20:23AM +0100, Andreas Färber wrote:
> >>From: Hervé Poussineau
> >>
> >>v1:
> >>* Rebased.
> >>
> >>Signed-off-by: Hervé Poussineau
> >>Cc: Michael S. Tsirkin
> >>Signed-off-by: Andreas Färber
> >>---
> >> Hello Michael,
> >> Could you please take a look at this? I'm out of my field here.
> >> The intention of the first part appears to be to save (val & ~mask),
> >> whereas the inline helper would've returned (val & mask).
> >
> >Such behavior is intended.
> >The returned value is just discarded in this case.
> >test-and-clear means
> > clear the bits
> > return if those cleared bits were really set.
> >
What about this first chunk? Is it necessary.
> >> The second part makes existing code conditional on that value.
> >
> >What issue are you addressing?
> >Although the spec doesn't says about the default value of BAR registers
> >after reset, the current code assumes that almost all the pci devices clear
> >those registers.
> >Anyway after cold/warm reset firmware sets up BARs, so it doesn't matter.
> >You, however, seem to want to keep BARs over resets.
> >
> >thanks,
> >
> >
> As you have seen, the intend here is to be able to keep BARs over resets.
> It is required for some really specific devices, like a PCI to ISA
> bridge, where MMIO is always at the same address.
> In that case, the device keeps PCI_COMMAND_MEMORY and/or
> PCI_COMMAND_IO flags as read-only.
>
> Hervé
Aha. Are the BARs still writeable? If not maybe that's the right thing
to check? If yes maybe the device simply should have a reset
handler to rewrite them?
Also I would like the above text (maybe a bit shortened) to replace the comment:
/* Reset region address, as it it is not read-only */
the general idea is to document the reason the code
is what it is, not restate what it does.
Something similar should also go into the commit message I think.
> >> Regards,
> >> Andreas
> >> hw/pci.c | 22 ++
> >> 1 files changed, 14 insertions(+), 8 deletions(-)
> >>
> >>diff --git a/hw/pci.c b/hw/pci.c
> >>index ef00d20..4db4b1f 100644
> >>--- a/hw/pci.c
> >>+++ b/hw/pci.c
> >>@@ -140,6 +140,7 @@ static void pci_update_irq_status(PCIDevice *dev)
> >> static void pci_device_reset(PCIDevice *dev)
> >> {
> >> int r;
> >>+uint16_t cmd;
> >> /* TODO: call the below unconditionally once all pci devices
> >> * are qdevified */
> >> if (dev->qdev.info) {
> >>@@ -149,9 +150,10 @@ static void pci_device_reset(PCIDevice *dev)
> >> dev->irq_state = 0;
> >> pci_update_irq_status(dev);
> >> /* Clear all writeable bits */
> >>-pci_word_test_and_clear_mask(dev->config + PCI_COMMAND,
> >>- pci_get_word(dev->wmask + PCI_COMMAND) |
> >>- pci_get_word(dev->w1cmask + PCI_COMMAND));
> >>+cmd = pci_get_word(dev->config + PCI_COMMAND);
> >>+cmd &= ~(pci_get_word(dev->wmask + PCI_COMMAND) |
> >>+ pci_get_word(dev->w1cmask + PCI_COMMAND));
> >>+pci_set_word(dev->config + PCI_COMMAND, cmd);
> >> pci_word_test_and_clear_mask(dev->config + PCI_STATUS,
> >> pci_get_word(dev->wmask + PCI_STATUS) |
> >> pci_get_word(dev->w1cmask + PCI_STATUS));
> >>@@ -163,11 +165,15 @@ static void pci_device_reset(PCIDevice *dev)
> >> continue;
> >> }
> >>-if (!(region->type & PCI_BASE_ADDRESS_SPACE_IO) &&
> >>-region->type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> >>-pci_set_quad(dev->config + pci_bar(dev, r), region->type);
> >>-} else {
> >>-pci_set_long(dev->config + pci_bar(dev, r), region->type);
> >>+if ((region->type == PCI_BASE_ADDRESS_SPACE_IO && !(cmd &
> >>PCI_COMMAND_MEMORY)) ||
> >>+(region->type == PCI_BASE_ADDRESS_SPACE_MEMORY && !(cmd &
> >>PCI_COMMAND_IO))) {
These lines are too long.
> >>+/* Reset region address, as it it is not read-only */
Checking wmask would be more straight-forward?
> >>+if (!(region->type & PCI_BASE_ADDRESS_SPACE_IO) &&
> >>+region->type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
> >>+pci_set_quad(dev->config + pci_bar(dev, r), region->type);
> >>+} else {
> >>+pci_set_long(dev->config + pci_bar(dev, r), region->type);
> >>+}
> >> }
> >> }
> >> pci_update_mappings(dev);
> >>--
> >>1.7.3.4
> >>
> >>
> >
Re: [Qemu-devel] QEMU forks survey
On Tue, Dec 21, 2010 at 7:28 PM, Andreas Färber wrote: > Since Christmas and the New Year with its good intensions are approaching, > apart from z80 there's some more feature forks around: > > http://repo.or.cz/w/qemu.git/forks?o=age They are also the gold plateform aka the android qemu port (see a previous thread) Bastien
