here 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 obsolescence in
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,
> regressions) a
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
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(>env, ARM_FEATURE_EL3);
> set_feature(>env,
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
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, but
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
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
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
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,
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
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
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
STAMP_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 structure:
>
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
: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/qemu_fw_cfg.c
)
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 <a...@arndb.de>
---
drivers/firmware/qemu_fw_cfg.c | 60 +-
1 file changed, 30 i
On Friday 05 December 2014 19:08:46 Peter Maydell wrote:
On 5 December 2014 at 19:04, Laszlo Ersek ler...@redhat.com wrote:
On 12/05/14 19:57, Peter Maydell wrote:
On 30 November 2014 at 16:51, Laszlo Ersek ler...@redhat.com wrote:
+Example:
+
+/ {
+ #size-cells = 0x2;
+
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 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 future but
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 DT is
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 for
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 servers and
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
the hardware and let the guest (or the firmware
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
are in the same category.
Arnd
From c9917a4a1b3f326e84932d7e860597413a98643b Mon Sep 17 00:00:00 2001
From: Arnd Bergmann a...@arndb.de
Date: Mon, 24 Feb 2014 16:38:34 +0100
Subject: [PATCH] ARM: add CONFIG_BROKEN_MULTIPLATFORM
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/arch
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_ROM_TEXT
hex
On Wednesday 15 May 2013, Linus Walleij wrote:
On Tue, May 14, 2013 at 5:33 PM, Peter Maydell peter.mayd...@linaro.org
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
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 swizzling
On Tuesday 26 March 2013, Peter Maydell wrote:
On 26 March 2013 10:54, Arnd Bergmann a...@arndb.de 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 will become arbitrary
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 need
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 why the
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 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 of
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
more new
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
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
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 here, still
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 approach
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 mac)
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 the
logic
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 another mac address
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 together. I
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 alex.william...@redhat.com
---
v2: Adjust alignment to help non-x86 hosts per Arnd's suggestion
Ok, looks good now. Thanks!
Arnd
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.
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
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 Arnd, that
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
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 kerneldir rather than inside /usr/include. It
seems like adding -Ikerneldir/arch/foo/include will always be a problem,
since it will always
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
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 concept like
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, but my point
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 possible now
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 is
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);
if
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 a...@arndb.de
---
drivers/net/macvtap.c | 170
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 a...@arndb.de
---
drivers/net/macvtap.c
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
x86
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 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. Whether or
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, or the socket or tap
file
descriptor from
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 using
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
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 supported:
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. Whether or not
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 util.h
#endif
-int tap_open(char *ifname, int ifname_size, int *vnet_hdr, int
any macvtap specific code in qemu, only a natural extension to
the existing interface.
Signed-off-by: Arnd Bergmann a...@arndb.de
Acked-by: Mark McLoughlin mar...@redhat.com
Cc: Michael S. Tsirkin m...@redhat.com
---
Hopefully addressed all comments from Michael. I did compile-test
the non-linux
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;
+
Did you test without dev parameter? I think dev will be NULL
so
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
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 a...@arndb.de
---
diff --git a/net.c b
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 the character devices
get created
a similar purpose but not
currently implemented at all.
Signed-off-by: Arnd Bergmann a...@arndb.de
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 ifname_size, int *vnet_hdr
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 tree is
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_ADMIN.
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
exec
96 matches
Mail list logo
