On Wed, Oct 23, 2024, at 19:47, Alex Bennée wrote:
>> On Sun, Oct 20, 2024, at 17:39, Naresh Kamboju wrote:
>> On non-LPAE arm32, this broke the existing behavior for
>> large 32-bit memory sizes. The obvious fix is to change
>> back the PAGE_MASK definition for 32-bit arm to a signed
>> number.
>
On Sun, Oct 20, 2024, at 17:39, Naresh Kamboju wrote:
> On Fri, 18 Oct 2024 at 12:35, Naresh Kamboju
> wrote:
>>
>> The QEMU-ARMv7 boot has failed with the Linux next-20241017 tag.
>> The boot log is incomplete, and no kernel crash was detected.
>> However, the system did not proceed far enough t
may carry an
> address value that is not representable in 32 bits.
>
> Fixes: f3639a64f602ea ("target/arm: Use softmmu tlbs for page table walking")
> Reported-by: Arnd Bergmann
> Signed-off-by: Ard Biesheuvel
Thanks for the fix, I now confirmed that this addresses the pr
>> there is an established process for obsoleting/removing support in other
>> components; besides binutils, GDB, and GLIBC, there's QEMU, newlib/libgloss,
>> and the Linux kernel. But, we need to get the ball rolling somewhere.
>
> CC:ing Arnd Bergmann regarding the obs
On Thu, Feb 15, 2024, at 09:31, Andreas Kemnade wrote:
> On Wed, 14 Feb 2024 23:42:58 +0100
> "Arnd Bergmann" wrote:
>> On Wed, Feb 14, 2024, at 13:26, Dmitry Baryshkov wrote:
>> > On Tue, 13 Feb 2024 at 23:22, Linus Walleij
>> > wrote:
>> &g
On Wed, Feb 14, 2024, at 13:26, Dmitry Baryshkov wrote:
> On Tue, 13 Feb 2024 at 23:22, Linus Walleij wrote:
>> On Tue, Feb 13, 2024 at 9:12 PM Arnd Bergmann wrote:
>> > On Tue, Feb 13, 2024, at 16:36, Guenter Roeck wrote:
>> > > On Tue, Feb 13, 2024 at 03:14:2
On Wed, Feb 14, 2024, at 02:27, Aaro Koskinen wrote:
> On Tue, Feb 13, 2024 at 09:11:38PM +0100, Arnd Bergmann wrote:
>
> I'm one of the OMAP1 Linux kernel maintainers, and I have Palm TE which
> I have been using for testing and development (and reporting bugs,
> regressio
On Tue, Feb 13, 2024, at 22:21, Linus Walleij wrote:
> The Collie is popular because it is/was easy to get hold of and
> easy to hack. PXA was in candybar phones (right?) which
> are just veritable fortresses and really hard to hack so that is why
> there is no interest (except for the occasional
On Tue, Feb 13, 2024, at 16:36, Guenter Roeck wrote:
> On Tue, Feb 13, 2024 at 03:14:21PM +, Peter Maydell wrote:
>> On Mon, 12 Feb 2024 at 14:36, Guenter Roeck wrote:
>> > On 2/12/24 04:32, Peter Maydell wrote:
>> > > The machines I have in mind are:
>> > >
>> > > PXA2xx machines:
>> > >
>> >
On Fri, Dec 16, 2022, at 19:08, Michael Tokarev wrote:
> Both system calls are exactly the same, the only difference is the
> (optional) timespec conversion. Consolidate the two, and check which
> syscall being emulated in the timespec conversion place.
>
> This is just a PoC. But this brings at le
On Tue, Sep 6, 2022, at 7:22 PM, Alex Bennée wrote:
>
> index 3099b38e32..59d5278868 100644
> --- a/target/arm/cpu_tcg.c
> +++ b/target/arm/cpu_tcg.c
> @@ -588,7 +588,9 @@ static void cortex_a15_initfn(Object *obj)
> set_feature(&cpu->env, ARM_FEATURE_EL3);
> set_feature(&cpu->env, ARM_FE
On Tue, Jun 7, 2022 at 2:12 PM Stafford Horne wrote:
> On Tue, Jun 07, 2022 at 11:43:08AM +0100, Peter Maydell wrote:
>
> However, in a followup mail from Laurent we see:
>
> https://lore.kernel.org/lkml/cb884368-0226-e913-80d2-62d2b7b2e...@vivier.eu/
>
> The reference document[1] doesn't defi
On Tue, Jun 7, 2022 at 11:47 AM Stafford Horne wrote:
> On Tue, Jun 07, 2022 at 10:42:08AM +0200, Arnd Bergmann wrote:
> > Goldfish is a very old platform, as far as I know only the kernel port is
> > new.
> > I don't know when qemu started shipping goldfish,
On Tue, Jun 7, 2022 at 10:11 AM Geert Uytterhoeven wrote:
> On Sun, Jun 5, 2022 at 9:32 AM Stafford Horne wrote:
> > On Sun, Jun 05, 2022 at 10:58:14AM +0900, Stafford Horne wrote:
> > It might be a good idea to revisit the qemu implementation and make
> > sure that the extra byteswap is
On Thu, Oct 7, 2021 at 4:32 PM Alex Bennée wrote:
>
> Are there any other approaches you could take? Which do you think has
> the most merit?
Reading through the ELF loader code in the kernel, I had another idea:
If qemu-user could be turned into a replacement for /lilb/ld.so and act
as an ELF in
On Thu, Oct 7, 2021 at 4:32 PM Alex Bennée wrote:
>
> I came across a use-case this week for ARM although this may be also
> applicable to architectures where QEMU's emulation is ahead of the
> hardware currently widely available - for example if you want to
> exercise SVE code on AArch64. When th
On Tue, Apr 20, 2021 at 1:52 PM Philippe Mathieu-Daudé wrote:
> On 4/19/21 3:42 PM, Peter Maydell wrote:
> >>
> >> I suspect PCI-ISA bridges to provide an EISA bus.
> >
> > I'm not sure what you mean here -- there isn't an ISA bridge
> > or an EISA bus involved here. This is purely about the behav
On Fri, Mar 26, 2021 at 7:01 AM Viresh Kumar wrote:
> On 25-03-21, 17:16, Arnd Bergmann wrote:
> > On Wed, Mar 24, 2021 at 8:33 AM Viresh Kumar
> > wrote:
> >
> > > +static uint8_t vi2c_xfer(VuDev *dev, struct i2c_msg *msg)
> > > +{
> > > +
On Fri, Mar 26, 2021 at 8:14 AM Viresh Kumar wrote:
> On 25-03-21, 17:16, Arnd Bergmann wrote:
> > On Wed, Mar 24, 2021 at 8:33 AM Viresh Kumar
> > wrote:
> >
> > It looks like you are not handling endianness conversion here. As far as I
> > can tell, the pro
On Wed, Mar 24, 2021 at 8:33 AM Viresh Kumar wrote:
> +static uint8_t vi2c_xfer(VuDev *dev, struct i2c_msg *msg)
> +{
> +VuI2c *i2c = container_of(dev, VuI2c, dev.parent);
> +struct i2c_rdwr_ioctl_data data;
> +VI2cAdapter *adapter;
> +
> +adapter = vi2c_find_adapter(i2c, msg->add
6On Mon, Mar 22, 2021 at 9:13 PM Peter Maydell wrote:
>
> Currently the gpex PCI controller implements no special behaviour for
> guest accesses to areas of the PIO and MMIO where it has not mapped
> any PCI devices, which means that for Arm you end up with a CPU
> exception due to a data abort.
>
That seems correct, and could probably be improved. In this case, I know
that _outb() only writes within the PCI PIO virtual address between
fbfffe80 and fb80, which according to the boot log
(https://gist.githubusercontent.com/dvyukov/084890d9b4aa7cd54f468e652a9b5881/raw/54c122
My best guess is that the PCI I/O port handling in qemu only returns
data for ports that are connected to an actual device.
In this case, the kernel attempts to access a 8250 serial port at an
address where none exists. While this is also a bug in the kernel, a
real PCI implementation would not ca
On Wed, Nov 18, 2020 at 12:38 AM Linus Walleij wrote:
>
> On Tue, Oct 13, 2020 at 11:22 AM Dave Martin wrote:
>
> > > case F_SETFD:
> > > err = 0;
> > > set_close_on_exec(fd, arg & FD_CLOEXEC);
> > > + if (arg & FD_32BIT_MODE)
> > > +
On Fri, Jan 17, 2020 at 9:50 PM Aleksandar Markovic
wrote:
> Alexandre (and Arnd too, or any other person knowledgeable in the area),
>
> I just need to clarify a couple of details with you, please.
>
> Firstly, here is what man page rtc(4) says:
>
> "The /dev/rtc (or /dev/rtc0, /dev/rtc1, etc.)
On Thu, Jan 16, 2020 at 12:27 PM Aleksandar Markovic
wrote:
> On Thursday, January 16, 2020, Aleksandar Markovic
> wrote:
>> On Wednesday, January 15, 2020, Laurent Vivier wrote:
>>> Le 15/01/2020 à 20:17, Filip Bozuta a écrit :
>>> > On 15.1.20. 17:37, Arnd B
On Wed, Jan 15, 2020 at 8:17 PM Filip Bozuta wrote:
> On 15.1.20. 17:37, Arnd Bergmann wrote:
> > On Wed, Jan 15, 2020 at 5:32 PM Laurent Vivier wrote:
> >> Le 15/01/2020 à 17:18, Arnd Bergmann a écrit :
> >>> On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta
> >
On Wed, Jan 15, 2020 at 5:32 PM Laurent Vivier wrote:
>
> Le 15/01/2020 à 17:18, Arnd Bergmann a écrit :
> > On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta wrote:
> >>
> >> This patch implements functionality of following ioctl:
> >>
> >> SNDR
On Wed, Jan 15, 2020 at 4:53 PM Filip Bozuta wrote:
>
> This patch implements functionality of following ioctl:
>
> SNDRV_TIMER_IOCTL_TREAD - Setting enhanced time read
>
> Sets enhanced time read which is used for reading time with timestamps
> and events. The third ioctl's argument is a
P_OLD or SIOCGSTAMP_NEW as appropriate. If
> SIOCGSTAMP_NEW is used, then the tv_sec field is 64-bit even
> on 32-bit architectures
>
> To cope with this we must now convert the old and new type from
> the target to the host one.
>
> Signed-off-by: Daniel P. Berrangé
> Signed-off-by: Laurent Vivier
Looks good to me now
Reviewed-by: Arnd Bergmann
On Sun, Jul 14, 2019 at 12:41 PM Richard Henderson
wrote:
>
> On 7/12/19 3:55 PM, Arnd Bergmann wrote:
> > glibc will have to create a definition that matches the kernel, which uses
> >
> > struct __kernel_timespec {
> > __s64 tv_sec;
> > __s64 tv_ns
On Fri, Jul 12, 2019 at 3:50 PM Laurent Vivier wrote:
> Le 12/07/2019 à 15:36, Arnd Bergmann a écrit :
> >> We don't do memcopy() but we set each field one by one, so the padding
> >> doesn't
> >> seem needed if we define correctly the user stru
On Fri, Jul 12, 2019 at 3:23 PM Laurent Vivier wrote:
>
> Le 12/07/2019 à 14:47, Arnd Bergmann a écrit :
> > On Fri, Jul 12, 2019 at 2:17 PM Laurent Vivier wrote:
> >>
> >> Le 11/07/2019 à 23:05, Arnd Bergmann a écrit :
> >>> On Thu, Jul
On Fri, Jul 12, 2019 at 2:17 PM Laurent Vivier wrote:
>
> Le 11/07/2019 à 23:05, Arnd Bergmann a écrit :
> > On Thu, Jul 11, 2019 at 7:32 PM Laurent Vivier wrote:
> >
> >>
> >> Notes:
> >> v4: [lv] timeval64 and timespec64 are { long
On Thu, Jul 11, 2019 at 7:32 PM Laurent Vivier wrote:
>
> Notes:
> v4: [lv] timeval64 and timespec64 are { long long , long }
>
> +STRUCT(timeval64, TYPE_LONGLONG, TYPE_LONG)
> +
> +STRUCT(timespec64, TYPE_LONGLONG, TYPE_LONG)
> +
This still doesn't look right, see my earlier comment about
On Mon, Jun 17, 2019 at 3:11 PM Daniel P. Berrangé wrote:
>
> The SIOCGSTAMP symbol was previously defined in the
> asm-generic/sockios.h header file. QEMU sees that header
> indirectly via sys/socket.h
>
> In linux kernel commit 0768e17073dc527ccd18ed5f96ce85f9985e9115
> the asm-generic/sockios.h
_venc.c:42:40: error: array type has
incomplete element type 'struct platform_device_id'
This adds the inclusion where needed.
Fixes: ac3167257b9f ("headers: separate linux/mod_devicetable.h from
linux/platform_device.h")
Signed-off-by: Arnd Bergmann
---
drivers/firmware
rol)
This moves it into the #ifdef section that hides its caller to avoid the
warning.
Fixes: 47e78bfb5426 ("fw_cfg: write vmcoreinfo details")
Signed-off-by: Arnd Bergmann
---
drivers/firmware/qemu_fw_cfg.c | 60 +-
1 file changed, 30 inserti
On Friday 05 December 2014 19:08:46 Peter Maydell wrote:
> On 5 December 2014 at 19:04, Laszlo Ersek wrote:
> > On 12/05/14 19:57, Peter Maydell wrote:
> >> On 30 November 2014 at 16:51, Laszlo Ersek wrote:
> >>> +Example:
> >>> +
> >>> +/ {
> >>> + #size-cells = <0x2>;
> >>> + #addre
On Friday 28 November 2014 13:26:44 Laszlo Ersek wrote:
> +Example:
> +
> +/ {
> + #size-cells = <0x2>;
> + #address-cells = <0x2>;
> +
> + fw-cfg@902 {
> + reg = <0x0 0x902 0x0 0x2 0x0 0x9020002 0x0 0x1>;
> + compatible = "fw-cfg,mmio";
> +
On Wednesday 12 November 2014 17:04:30 Paolo Bonzini wrote:
> On 12/11/2014 16:57, Arnd Bergmann wrote:
> > > > It seems to me like complicated stuff like that definitely belongs
> > > > in the UEFI/bootloader blob, though. I'd rather QEMU just modelled
> >
On Wednesday 12 November 2014 16:52:25 Paolo Bonzini wrote:
> On 12/11/2014 16:39, Peter Maydell wrote:
> > > Definitely, I think having the OS manually program the BARs only makes
> > > sense
> > > in an environment where you don't have a full-featured boot loader or you
> > > don't trust it. In
On Wednesday 12 November 2014 16:01:14 Claudio Fontana wrote:
>
> Would the last step you mention allow for guests to start with an already
> existing PCI interrupt map
> and the BAR registers preprogrammed to point to somewhere sane?
>
> I ask because on OSv at the moment, the situation is that
On Wednesday 12 November 2014 13:27:14 Paolo Bonzini wrote:
> On 12/11/2014 13:18, Mark Rutland wrote:
> > On Wed, Nov 12, 2014 at 11:48:27AM +, Paolo Bonzini wrote:
> >> Perhaps you could treat it as a shared level-triggered interrupt in DT?
> >> I don't know.
> >
> > Putting an interrupt in
On Wednesday 12 November 2014 12:34:01 Christoffer Dall wrote:
> On Wed, Nov 12, 2014 at 12:15:08PM +0100, Arnd Bergmann wrote:
> > On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
> > >
> > > For the features which ACPI provides which device trees do
On Wednesday 12 November 2014 10:56:40 Mark Rutland wrote:
> On Wed, Nov 12, 2014 at 09:08:55AM +, Claudio Fontana wrote:
> > On 11.11.2014 16:29, Mark Rutland wrote:
> >
> > I tend to mostly agree with this, we might look for alternative
> > solutions for speeding up guest startup in the futu
On Thursday 06 November 2014 13:30:01 Mark Rutland wrote:
>
> There is no way of doing this with DT. There has been work into DT
> fragments/overlays where portions can be added to the tree dynamically,
> but that's controlled by the OS rather than the hypervisor, and there's
> no standard for com
On Tuesday 22 April 2014 19:38:55 Russell King - ARM Linux wrote:
> On Tue, Apr 22, 2014 at 08:32:10PM +0200, Arnd Bergmann wrote:
> > @@ -1943,6 +1953,7 @@ config DEPRECATED_PARAM_STRUCT
> > # TEXT and BSS so we preserve their values in the config files.
> > config ZBOOT_R
g on DEBUG_LL, as that breaks all other machines. A couple of
other things are in the same category.
Arnd
>From c9917a4a1b3f326e84932d7e860597413a98643b Mon Sep 17 00:00:00 2001
From: Arnd Bergmann
Date: Mon, 24 Feb 2014 16:38:34 +0100
Subject: [PATCH] ARM: add CONFIG_BROKEN_MUL
On Wednesday 15 May 2013, Linus Walleij wrote:
> On Tue, May 14, 2013 at 5:33 PM, Peter Maydell
> wrote:
>
> > The reworking of the versatile PCI controller model so that it actually
> > behaved like hardware included an attempt to autodetect whether the
> > guest Linux kernel was assuming the o
On Tuesday 26 March 2013, Peter Maydell wrote:
>
> On 26 March 2013 10:54, Arnd Bergmann wrote:
> > Yes, very good. We will probably introduce sparse irq support on
> > versatile in the near future, and then the value we write into the
> > PCI_INTERRUPT_LINE field wi
On Tuesday 26 March 2013, Peter Maydell wrote:
>
> Implement the correct IRQ mapping for the Versatile PCI controller; it
> differs between realview and versatile boards, but the previous QEMU
> implementation was correct only for the first PCI card on a versatile
> board, since we weren't swizzli
On Sunday 24 March 2013, Michael S. Tsirkin wrote:
> For future kernels, let's build in some hook that let
> qemu detect a non broken guest. How about writing
> some magic value into revision ID or some other
> readonly field?
Yes, makes sense.
On Sunday 24 March 2013, Peter Maydell wrote:
> OK, I'll give that a go tomorrow.
>
> While you're here, do you know what the point of the PCI_SELFID
> register is? The h/w docs are clear that the OS has to write
> the slot number of the board itself in to this register, but
> again I don't see wh
On Sunday 24 March 2013, Peter Maydell wrote:
> Yeah, ideally being able to detect the buggy kernel would be good;
> I can't see anything at the controller level that would do though,
> and I don't really know enough about PCI to know about generic
> PCI stuff that would work. (Why would the OS nee
On Tuesday 07 February 2012, Alexander Graf wrote:
> >>
> >> Not sure we'll ever get there. For PPC, it will probably take another 1-2
> >> years until we get the 32-bit targets stabilized. By then we will have new
> >> 64-bit support though. And then the next gen will come out giving us even
>
On Tuesday 07 February 2012, Alexander Graf wrote:
> On 07.02.2012, at 07:58, Michael Ellerman wrote:
>
> > On Mon, 2012-02-06 at 13:46 -0600, Scott Wood wrote:
> >> You're exposing a large, complex kernel subsystem that does very
> >> low-level things with the hardware. It's a potential source o
On Tuesday 03 May 2011 19:57:18 Scott Wood wrote:
> > I agree, it doesn't feel quite right to bring in the headers. I don't have
> > any alternative suggestions (besides better HOWTOs/Documentation) though.
>
> If you try to use the non-sanitized kernel headers, you'll get this warning
> from lin
On Tuesday 03 May 2011, Jan Kiszka wrote:
> This helps reducing our build-time checks for feature support in the
> available Linux kernel headers. And it helps users that do not have
> sufficiently recent headers installed on their build machine.
>
> Header upstate is triggered via 'make update-li
On Thursday 24 February 2011, Jan Kiszka wrote:
> On 2011-02-24 07:49, Gerhard Wiesinger wrote:
> > On Wed, 23 Feb 2011, Jan Kiszka wrote:
> >> Right, but if I set IP(eth0) == IP(macvlan0), I'm able to communicate
> >> between macvlan0 and mactapX, thus between guest and host. Just
> >> re-checked
On Wednesday 23 February 2011, Gerhard Wiesinger wrote:
> After some further tests and looking at the iproute ip and kernel code I
> finally gave up because I thing such a setup it is not possible without
> breaking up/reconfiguring eth0. When I have to reconfigure eth0 I think a
> better approa
On Monday 21 February 2011, Jan Kiszka wrote:
> > Now I think I tried all useful possible combinations:
> > 1.) macvtap0 and macvlan0 in bridged and non bridge mode
> > 2.) macvlan0 based on eth0 or based on macvtap0
> > 3.) Using and ip address on macvlan0 or not (tried both for 7b mac and
> > 7c
On Sunday 20 February 2011, Gerhard Wiesinger wrote:
> >> qemu-system-x86_64 ... some params ... -net
> >> nic,model=e1000,macaddr=1a:46:0b:ca:bc:7c -net tap,fd=3 3<>/dev/tap10
> >>
> >> Seems to me quite logically because macvtap0 (and not macvlan0) is
> >> associated with /dev/tap10 but with anot
On Sunday 20 February 2011, Gerhard Wiesinger wrote:
> >
> > Not sure if this is by design or due to internals of the networking
> > stack, but it looks unintuitive from user perspective. Maybe Arnd can
> > shed a light on this.
The lower device cannot be in bridge mode, because that would make th
On Friday 15 October 2010, Michael S. Tsirkin wrote:
> On Thu, Oct 14, 2010 at 11:40:52PM +0200, Dragos Tatulea wrote:
> > Hi,
> >
> > I'm starting a thread related to the TODO item mentioned in the
> > subject. Currently still gathering info and trying to make kvm &
> > macvtap play nicely t
On Friday 15 October 2010, Alex Williamson wrote:
> We can't let the compiler define the alignment for qemu_cfg data.
>
> Signed-off-by: Alex Williamson
> ---
>
> v2: Adjust alignment to help non-x86 hosts per Arnd's suggestion
Ok, looks good now. Thanks!
Arnd
On Thursday 14 October 2010 22:59:04 Alex Williamson wrote:
> The structs in question only contain 4 & 8 byte elements, so there
> shouldn't be any change on x86-32 using one-byte aligned packing.
I'm talking about the alignment of the structure, not the members
within the structure. The data stru
On Thursday 14 October 2010 21:58:08 Alex Williamson wrote:
> If it works anywhere (I assume it works on 32bit), then it's only
> because it happened to get the alignment right. This just makes 64bit
> hosts get it right too. I don't see any compatibility issues,
> non-packed + 64bit = broken. T
On Thursday 26 August 2010, Gleb Natapov wrote:
> You forgot about developers. Developer may want to use latest kvm kernel
> headers to compile code that he added to qemu to use new kernel feature.
In that case, you already need to install the kernel in order to test
it, so you might as well insta
On Wednesday 25 August 2010, Hollis Blanchard wrote:
> > We only recently fixed the kernel to have this warning in types.h, which
> > triggers more often than kernel.h, where it used to be before. In 2.6.35
> > and before, you consequently would not have noticed the problem.
> >
>
> Thanks Arn
On Wednesday 25 August 2010, Hollis Blanchard wrote:
> The problem seems to be that jump from /usr/include/bits/sigcontext.h to
> asm/sigcontext.h inside rather than inside /usr/include. It
> seems like adding -Ikerneldir/arch/foo/include will always be a problem,
> since it will always be use
On Sunday 25 July 2010, Loïc Minier wrote:
> On ARMv7, ignore writes to cp15 with crm == 12; these are to setup perf
> counters which we don't have.
Thanks Loïc, I have tested this and can confirm that I'm able to boot
a CONFIG_PERF_EVENTS kernel now.
Arnd
On Wednesday 16 June 2010, Markus Armbruster wrote:
> Can't hurt reviewer motivation. Could it be automated? Find replies,
> extract tags. If you want your acks to be picked up, you better make
> sure your References header works, and your tags are formatted
> correctly.
I think pwclient (https
On Thursday 11 March 2010, Avi Kivity wrote:
> >> That would be much slower. The current scheme allows for an
> >> ioeventfd/irqfd short circuit which allows one guest to interrupt
> >> another without involving their qemus at all.
> >>
> > Yes, the serial line approach would be much slower,
On Thursday 11 March 2010, Avi Kivity wrote:
> > A totally different option that avoids this whole problem would
> > be to separate the signalling from the shared memory, making the
> > PCI shared memory device a trivial device with a single memory BAR,
> > and using something a higher-level concep
On Tuesday 09 March 2010, Cam Macdonell wrote:
> >
> > We could make the masking in RAM, not in registers, like virtio, which would
> > require no exits. It would then be part of the application specific
> > protocol and out of scope of of this spec.
> >
>
> This kind of implementation would be p
On Monday 08 March 2010, Cam Macdonell wrote:
> enum ivshmem_registers {
> IntrMask = 0,
> IntrStatus = 2,
> Doorbell = 4,
> IVPosition = 6,
> IVLiveList = 8
> };
>
> The first two registers are the interrupt mask and status registers.
> Interrupts are triggered when a message
On Sunday 14 February 2010, Michael S. Tsirkin wrote:
> > @@ -473,7 +477,7 @@ static struct socket *get_socket(int fd)
> > sock = get_raw_socket(fd);
> > if (!IS_ERR(sock))
> > return sock;
> > - sock = get_tun_socket(fd);
> > + sock = get_tap_socket(fd);
> >
This adds support for passing a macvtap file descriptor into
vhost-net, much like we already do for tun/tap.
Most of the new code is taken from the respective patch
in the tun driver and may get consolidated in the future.
Signed-off-by: Arnd Bergmann
---
drivers/net/macvtap.c | 98
the lifetime of macvtap_queue to always
depend on the open file solves all these. The
RCU reference simply moves one step down to
the reference on the macvlan_dev, which we
only need for nonblocking operations.
Signed-off-by: Arnd Bergmann
---
drivers/net/macvtap.c | 170
On Thursday 28 January 2010, Alexander Graf wrote:
> > That option IMHO should just show up as identical to the host cpu, with
> > the exception of features that are not supported in the guest.
>
> That's exactly what -cpu host is. IIRC it's the default now.
Ah, cool. Sorry for my ignorance here.
On Monday 25 January 2010, Dor Laor wrote:
> x86 qemu64
> x86 phenom
> x86 core2duo
> x86kvm64
> x86 qemu32
> x86 coreduo
> x86 486
> x86 pentium
> x86 pentium2
> x86 pentium3
> x86 athlon
> x
On Wednesday 27 January 2010, Anthony Liguori wrote:
> > The raw backend can be attached to a physical device
>
> This is equivalent to bridging with tun/tap except that it has the
> unexpected behaviour of unreliable host/guest networking (which is not
> universally consistent across platforms
On Monday 18 January 2010, john cooper wrote:
> +.name = "Conroe",
> +.level = 2,
> +.vendor1 = CPUID_VENDOR_INTEL_1,
> +.vendor2 = CPUID_VENDOR_INTEL_2,
> +.vendor3 = CPUID_VENDOR_INTEL_3,
> +.family = 6, /* P6 */
> +.model = 2,
On Wednesday 16 December 2009, Leonid Grossman wrote:
> > > 3. Doing the bridging in the NIC using macvlan in passthrough
> > > mode. This lowers the CPU utilization further compared to 2,
> > > at the expense of limiting throughput by the performance of
> > > the PCIe interconnect to the adapter.
On Friday 11 December 2009, Anthony Liguori wrote:
> Arnd Bergmann wrote:
> >> 3) given an fd, treat a vhost-style interface
> >
> > This could mean two things, not sure which one you mean. Either the
> > file descriptor could be the vhost file descriptor,
On Thursday 10 December 2009 19:14:28 Alexander Graf wrote:
> > This is something I also have been thinking about, but it is not what
> > I was referring to above. I think it would be good to keep the three
> > cases (macvlan, VMDq, SR-IOV) as similar as possible from the user
> > perspective, so u
On Thursday 10 December 2009, Fischer, Anna wrote:
> >
> > 3. Doing the bridging in the NIC using macvlan in passthrough
> > mode. This lowers the CPU utilization further compared to 2,
> > at the expense of limiting throughput by the performance of
> > the PCIe interconnect to the adapter. Whethe
On Wednesday 09 December 2009, Anthony Liguori wrote:
> While we go over all of these things one thing is becoming clear to me.
> We need to get qemu out of the network configuration business. There's
> too much going on here.
Agreed.
> What I'd like to see is the following interfaces support
On Wednesday 09 December 2009, Anthony Liguori wrote:
> This isn't really a generic thing and I dislike pretending it is. This
> is specifically for macvtap.
Well, depending how how things work out with VMD-q and SR-IOV,
I might move the tap interface stuff into a library module and add more
use
On Wednesday 09 December 2009, Michael S. Tsirkin wrote:
> On Wed, Dec 09, 2009 at 03:49:04PM +0100, Arnd Bergmann wrote:
> >
> > -TFR(fd = open("/dev/net/tun", O_RDWR));
> > +if (!*dev)
> > +dev = "/dev/net/tun";
> > +
>
&
any macvtap specific code in qemu, only a natural extension to
the existing interface.
Signed-off-by: Arnd Bergmann
Acked-by: Mark McLoughlin
Cc: "Michael S. Tsirkin"
---
Hopefully addressed all comments from Michael. I did compile-test
the non-linux files I touched (the solaris file
On Wednesday 09 December 2009, Michael S. Tsirkin wrote:
> On Tue, Dec 08, 2009 at 06:41:44PM +0100, Arnd Bergmann wrote:
> > --- a/net/tap-bsd.c
> > +++ b/net/tap-bsd.c
> > @@ -40,7 +40,8 @@
> > #include
> > #endif
> >
> > -int tap_open(char
In order to support macvtap, we need a way to select the actual
tap endpoint. While it would be nice to pass it by network interface
name, passing the character device is more flexible, and we can
easily do both in the long run.
Signed-off-by: Arnd Bergmann
---
diff --git a/net.c b/net.c
index
As promised, here is my small writeup on which setups I feel
are important in the long run for server-type guests. This
does not cover -net user, which is really for desktop kinds
of applications where you do not want to connect into the
guest from another IP address.
I can see four separate setup
On Wednesday 02 December 2009, Anthony Liguori wrote:
> Arnd Bergmann wrote:
> > With the upcoming macvtap, we will want to open devices other than
> > /dev/net/tun but no longer need to call TUNSETIFF.
> >
>
> What are the names of these devices and how do you t
ter which documented to have a similar purpose but not
currently implemented at all.
Signed-off-by: Arnd Bergmann
diff --git a/net/tap-linux.c b/net/tap-linux.c
index 0f621a2..21f0167 100644
--- a/net/tap-linux.c
+++ b/net/tap-linux.c
@@ -36,10 +36,20 @@ int tap_open(char *ifname, int if
On Wednesday 25 November 2009, Carsten Otte wrote:
> Anthony Liguori wrote:
> > Oh, that's bad :-)
> >
> > That should really be it's own character device. We don't really have a
> > way to connect two character devices like that. Maybe muxing?
> It will be a character device, once the device t
On Sunday 08 November 2009 08:27:41 Avi Kivity wrote:
> On 11/08/2009 12:11 AM, Anthony Liguori wrote:
> >
> >> You don't need root privileges to use a tap device.
> >
> > You can access a preconfigured tap device but you cannot allocate a
> > tap device and connect it to a bridge without CAP_NET
On Saturday 07 November 2009, Anthony Liguori wrote:
> Avi Kivity wrote:
> > On 11/07/2009 11:14 AM, Avi Kivity wrote:
> >> I'd welcome -net bridge as one of them. But we shouldn't try to
> >> invent access control systems or install suid helpers.
> >
> > We can make the helper a script that does
100 matches
Mail list logo
