uergen Gross writes:
>
>> Mails to chr...@sous-sol.org are not deliverable since several months.
>> Drop him as PARAVIRT_OPS maintainer.
>>
>> Signed-off-by: Juergen Gross
Acked-by: Chris Wright
;)
thanks,
-chris
>> ---
>> MAINTAINERS | 1 -
>>
Acked-by: Chris Wright
;)
thanks,
-chris
On Oct 26, 2017 7:41 PM, "Rusty Russell" wrote:
> Chris CC'd: He wasn't that hard to find.
>
> (linkedin says he's CTO of RedHat now. I feel like an underachiever!)
>
> Cheers,
> Rusty.
>
> Juergen
Hi all,
This list is run as a moderated list to minimize spam (gets a decent
amount despite filtering). I've tended to this for years, and I'd
like to add some folks from community to help so that posts are
quickly approved. Please let me know if you'd like to help.
thanks,
-chris
_
Following on the heels of a successful KVM Forum and oVirt Workshop,
FOSDEM will be hosting a Virtualization DevRoom in February. If you've
been to FOSDEM before, you know this is about developers and code, not
products.
Presentation proposals are due by December 16th 2012.
The full details are
er
>
> And, Stephen, I think Chris Wright and virtualizat...@lists.osdl.org
> are stale entries in the MAINTAINERS file for Xen development,
> so you are unlikely to receive replies from him/them.
> (Chris, virtualizat...@lists.osdl.org ... please feel free
> to correct me if I
* Chris Wright (chr...@redhat.com) wrote:
> We were also able to video the speakers, and will send a note when the
> videos are available.
> (and thanks again to Andrew Cathrow for making this happen)
I don't think a note went out yet. The videos are available as well.
KVM Forum 2010 was quite a success, many thanks to all who participated!
For those who couldn't attend, the presentations are available online now:
(thanks to Andrew Cathrow for pushing them all up)
http://www.linux-kvm.org/page/KVM_Forum_2010#Presentations
We were also able to video the speaker
* Pankaj Thakkar (pthak...@vmware.com) wrote:
> We intend to upgrade the upstreamed vmxnet3 driver to implement NPA so that
> Linux users can exploit the benefits provided by passthrough devices in a
> seamless manner while retaining the benefits of virtualization. The document
> below tries to ans
Trivial change, just for readability. The filp is not installed on
failure, so the current code is not incorrect (also vhost_dev_init
currently has no failure case). This just treats setting f->private_data
as something with global scope (sure, true only after fd_install).
Signed-off-by: Ch
This looks like an error case, but it's just a special case to shutdown
the backend. Clarify with a comment.
Signed-off-by: Chris Wright
---
drivers/vhost/net.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 22
isors that support such devices.
>
> Signed-off-by: Alok N Kataria
Looks in good shape to me.
Reviewed-by: Chris Wright
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
* Bhavesh Davda (bhav...@vmware.com) wrote:
> > > Thanks a bunch for your really thorough review! I'll answer some of
> > your questions here. Shreyas can respond to your comments about some of
> > the coding style/comments/etc. in a separate mail.
> >
> > The style is less important at this stage
* Bhavesh Davda (bhav...@vmware.com) wrote:
> Hi Chris,
>
> Thanks a bunch for your really thorough review! I'll answer some of your
> questions here. Shreyas can respond to your comments about some of the coding
> style/comments/etc. in a separate mail.
The style is less important at this stag
* Alok Kataria (akata...@vmware.com) wrote:
> Mark VMI for removal in feature-removal-schedule.txt.
>
> From: Alok N Kataria
>
> Add text in feature-removal.txt and also modify Kconfig to disable
> vmi by default.
>
> Signed-off-by: Alok N Kataria
* Alok Kataria (akata...@vmware.com) wrote:
>
> On Mon, 2009-09-28 at 19:25 -0700, H. Peter Anvin wrote:
> > On 09/28/2009 05:45 PM, Alok Kataria wrote:
> > > + bool "VMI Guest support [will be deprecated soon]"
> > > + default n
> >
> > This is incorrect use of the word "deprecated"... it's *alr
* Shreyas Bhatewara (sbhatew...@vmware.com) wrote:
> Some of the features of vmxnet3 are :
> PCIe 2.0 compliant PCI device: Vendor ID 0x15ad, Device ID 0x07b0
> INTx, MSI, MSI-X (25 vectors) interrupts
> 16 Rx queues, 8 Tx queues
Driver doesn't appear to actually support mo
* Stephen Hemminger (shemmin...@vyatta.com) wrote:
> On Mon, 21 Sep 2009 16:37:22 +0930
> Rusty Russell wrote:
>
> > > > Actually this framework can apply to traditional network adapters which
> > > > have
> > > > just one tx/rx queue pair. And applications using the same user/kernel
> > > > in
* Jeremy Fitzhardinge (jer...@goop.org) wrote:
> On 09/17/09 17:34, Chris Wright wrote:
> >> One of the options that I am contemplating is to drop the code from the
> >> tip tree in this release cycle, and given that this should be a low risk
> >> change we can remove
* Alok Kataria (akata...@vmware.com) wrote:
> We ran a few experiments to compare performance of VMware's
> paravirtualization technique (VMI) and hardware MMU technologies (HWMMU)
> on VMware's hypervisor.
>
> To give some background, VMI is VMware's paravirtualization
> specification which tries
These functions
> have been around since the beginning, so are backwards compatible with
> all older kernel versions.
>
> Cc: xen-de...@lists.xensource.com
> Cc: virtualizat...@lists.osdl.org
> Cc: Chris Wright
> Cc: Jeremy Fitzhardinge
> Signed-off-by: Greg
* Greg KH (g...@kroah.com) wrote:
> On Thu, Apr 30, 2009 at 03:35:35PM -0700, Chris Wright wrote:
> > * Greg Kroah-Hartman (gre...@suse.de) wrote:
> > > In the near future, the driver core is going to not allow direct access
> > > to the driver_data pointer in s
nd since the beginning, so are backwards compatible with
> all older kernel versions.
>
> Cc: xen-de...@lists.xensource.com
> Cc: virtualizat...@lists.osdl.org
> Cc: Chris Wright
> Cc: Jeremy Fitzhardinge
> Signed-off-by: Greg Kroah-Hartman
Acked-by: Chris Wright
after...
>
* Arkadiusz Miskiewicz (a.miskiew...@gmail.com) wrote:
> On Friday 03 of April 2009, Chris Wright wrote:
> > * Arkadiusz Miskiewicz (a.miskiew...@gmail.com) wrote:
> > > What about 9ea09af3bd3090e8349ca2899ca2011bd94cda85 ?
> > >
> > > stop_machine: i
* Ingo Molnar (mi...@elte.hu) wrote:
>
> * Chris Wright wrote:
>
> > * Arkadiusz Miskiewicz (a.miskiew...@gmail.com) wrote:
> > > On Friday 03 of April 2009, Chris Wright wrote:
> > > > * Arkadiusz Miskiewicz (a.miskiew...@gm
* Arkadiusz Miskiewicz (a.miskiew...@gmail.com) wrote:
> What about 9ea09af3bd3090e8349ca2899ca2011bd94cda85 ?
>
> stop_machine: introduce stop_machine_create/destroy.
That is later fixed in a0e280e0f33f6c859a235fb69a875ed8f3420388.
Can you please verify if 2.6.29 works for you? Your bisects ar
* Rafael J. Wysocki (r...@sisk.pl) wrote:
> Sorry for the misunderstanding, I thought the breakage might be introduced
> between 15f7176eb1cccec0a332541285ee752b935c1c85 and
> 0a0c5168df270a50e3518e4f12bddb31f8f5f38f, so I thought it would be a good
> idea to verify if 0a0c5168df270a50e3518e4f12bdd
* Rafael J. Wysocki (r...@sisk.pl) wrote:
> On Wednesday 01 April 2009, Chris Wright wrote:
> > * Rafael J. Wysocki (r...@sisk.pl) wrote:
> > > This may be caused by the recent PM changes. Can you please test if
> > > commit
> > > 8efb8c76fcdccf5050c0ea059dac3
* Rafael J. Wysocki (r...@sisk.pl) wrote:
> This may be caused by the recent PM changes. Can you please test if commit
> 8efb8c76fcdccf5050c0ea059dac392789baaff2 is fine?
I just tested on my t400, it's not[1]. See same symptoms as Arkadiusz.
Seems as if it responds to initial apci event, I see s
* Arkadiusz Miskiewicz (a.miskiew...@gmail.com) wrote:
> and this as bad commit:
>
> 7f7ace0cda64c99599c23785f8979a072e118058 is first bad commit
Does it make any difference if you roll fwd a couple commits to:
802bf931f2688ad125b73db597ce63cc842fb27a
That fixes a possible problem with the cpum
n a 64MB guest causes reproducible
pagetable corruption.
Signed-off-by: Rusty Russell
Cc: jer...@xensource.com
Cc: virtualizat...@lists.osdl.org
Cc: sta...@kernel.org
Signed-off-by: Chris Wright
---
arch/x86/lguest/boot.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
--- a/a
ectors to
improve throughput. This (along with 2/2) are tested and showing nice numbers.
Acked-by: Chris Wright <[EMAIL PROTECTED]>
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/m
* Greg KH ([EMAIL PROTECTED]) wrote:
> > +static int
> > +igb_virtual(struct pci_dev *pdev, int nr_virtfn)
> > +{
> > + unsigned char my_mac_addr[6] = {0x00, 0xDE, 0xAD, 0xBE, 0xEF, 0xFF};
> > + struct net_device *netdev = pci_get_drvdata(pdev);
> > + struct igb_adapter *adapter = netdev_
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> + /* No real sector limit. */
> + blk_queue_max_sectors(vblk->disk->queue, -1U);
> +
Is that actually legitimate? I think it'd still work out, but seems
odd, e.g. all the spots that do:
q->max_hw_sectors << 9
will just toss the upper
mented by my colleagues has separate
> > drivers for the PF (aka native) and VF devices. I don't personally
> > believe this is the correct path, but I'm reserving judgement until I
> > see some code.
>
> Hm, I would like to see that code before we can properly ev
* Rusty Russell ([EMAIL PROTECTED]) wrote:
> On Thursday 09 October 2008 06:34:59 Mark McLoughlin wrote:
> > From: Herbert Xu <[EMAIL PROTECTED]>
> >
> > If segmentation offload is enabled by the host, we currently allocate
> > maximum sized packet buffers and pass them to the host. This uses up
>
* Anthony Liguori ([EMAIL PROTECTED]) wrote:
> And arguably, storing TSC frequency in CPUID is a terrible interface
> because the TSC frequency can change any time a guest is entered. It
True for older hardware, newer hardware should fix this. I guess the
point is, the are numbers that are e
* Anthony Liguori ([EMAIL PROTECTED]) wrote:
> We've already gone down the road of trying to make standard paravirtual
> interfaces (via virtio). No one was sufficiently interested in
> collaborating. I don't see why other paravirtualizations are going to
> be much different.
The point is
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> "What hypervisor is this?" isn't a very interesting question; if you're
> even asking it then it suggests that something has gone wrong.
It's essentially already happening. Everyone wants to be a better
hyperv than hyperv ;-)
__
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> lookup_address() receives two parameters, but efi_64.c call
> is passing only one. It's actually preventing the tree from compiling
>
> Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
Good catch, I know I don't test with CONFIG
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> On Thu, 3 Jan 2008, Chris Wright wrote:
> > Yes, paravirt ops have a well-specified calling convention (register
> > based). There was a cleanup that Andi did that caused the problem
> > because it removed all the "f
* Steven Rostedt ([EMAIL PROTECTED]) wrote:
> Hmm, I know paravirt-ops had an issue with mcount in the RT tree. I can't
> remember the exact issues, but it did have something to do with the way
> parameters were passed in.
>
> Chris, do you remember what the issues were?
Yes, paravirt ops have a
* James Courtier-Dutton ([EMAIL PROTECTED]) wrote:
> Ok, so I need to get a new CPU like the Intel Core Duo that has VT
> features? I have an old Pentium 4 at the moment, without any VT features.
Depends on your goals. You can certainly give a paravirt Xen guest[1]
physical hardware without any V
* James Courtier-Dutton ([EMAIL PROTECTED]) wrote:
> If one could directly expose a device to the guest, this feature could
> be extremely useful for me.
> Is it possible? How would it manage to handle the DMA bus mastering?
Yes it's possible (Xen supports pci pass through). Without an IOMMU
(lik
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> Only caveat, is that it has to be done before smp gets in the game, and
> with interrupts disabled. (which makes the function in vsmp.c not eligible).
>
> My current option is to force VSMP to use PARAVIRT, as said before, and
> then fill
* Glauber de Oliveira Costa ([EMAIL PROTECTED]) wrote:
> As alternatives what we have now, we can either keep the paravirt_ops as
> it is now for the native case, just hooking the vsmp functions in place
> of the normal one, (there are just three ops anyway), refill the
> paravirt_ops entirely i
* Randy Dunlap ([EMAIL PROTECTED]) wrote:
> On Mon, 13 Aug 2007 11:55:36 -0700 Chris Wright wrote:
> > * [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> > > +F: arch/i386/xen/
> > > +F: drivers/*/xen-*front.c
> > > +F: drivers/xen/
> >
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e4e1cc3..8395aba 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5153,6 +5153,11 @@ M: [EMAIL PROTEC
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
> Add file pattern to MAINTAINER entry
>
> Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2166416..44768ce 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -3519,6 +3519,9 @@ M: [EMAIL PROTEC
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Zachary Amsden wrote:
> >I'd rather keep it, even with bitrot - it was non-trivial to get
> >correct, and found many surprises in the code; most notably, it can
> >detect
> >
> >1) PTE writes to pages not declared as page tables
> >2) Failure to
t (already has !CONFIG_NEED_MULTIPLE_NODES dependency,
dunno if VMI has the same limitation). It definitely should not have
a misleading Kconfig name. I'd nuke it all rather than #if 0.
thanks,
-chris
--
Subject: [PATCH] VMI: remove CONFIG_DEBUG_PAGE_TYPE and associated bitrotted
code
Fro
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> I'm implementing a more efficient version of the Xen iret paravirt_op,
> so that it can use the real iret instruction where possible. I really
> need to get access to per-cpu variables, so I can set the event mask
> state in the vcpu_info structur
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Yep, this patch gets rid of my spinning thread. I can't find this patch
> or any discussion on marc.info; is there a better netdev list archive?
See the "linkwatch bustage in git-net" thread on netdev
http://thread.gmane.org/gmane.linux.network/
* Herbert Xu ([EMAIL PROTECTED]) wrote:
> Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> > ===
> > --- a/drivers/net/xen-netfront.c
> > +++ b/drivers/net/xen-netfront.c
> > @@ -1213,10 +1213,10 @@ static int netif_poll(struct net_dev
If you are interested in trying the new paravirt_ops kernels, I've
created some packages and uploaded them to:
http://et.redhat.com/~chrisw/paravirt_ops/
There you'll find a yum repo (see yum.README for details) and an
INSTALL file for getting started. With this package you can use a
single ke
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Eric W. Biederman wrote:
> > Then why you had to allocate enough pages to cause a failure has me stumped.
> > Perhaps there is some other bug?
>
> Perhaps, but nothing comes to mind. I'll see what happens when I boot
> this kernel on real hardware
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Seems to work OK for native and Xen. I had to play a bit with the
> paravirt-sched-clock patch to deal with the VMI changes. Zach, can you
> check that it still works?
Here's what's working for me on UP. The boot cpu on UP is never getting
the
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> Jeremy Fitzhardinge wrote:
> >Seems to work OK for native and Xen. I had to play a bit with the
> >paravirt-sched-clock patch to deal with the VMI changes. Zach, can you
> >check that it still works?
>
> I'm on it.
Not sure about cycles_2_ns...
arc
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Seems to work OK for native and Xen. I had to play a bit with the
> paravirt-sched-clock patch to deal with the VMI changes. Zach, can you
> check that it still works?
Cool, thanks for the rebase. Here's some small fixes.
Minor issue with CONF
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> Jeremy Fitzhardinge wrote:
> >Why not submit a patch to do what you need here? (The Geode comment is
> >a bit worrying though.)
>
> Why should VMI add workaround into PIT code?
I'm not sure it's a workaround, seems more like a subtle diff (perhaps
it
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> Yes, but unfortunately that is a nop:
>
> /*
> * Avoid unnecessary state transitions, as it confuses
> * Geode / Cyrix based boxen.
> */
> case CLOCK_EVT_MODE_SHUTDOWN:
> if (evt->mode == CLOCK
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> >>+void __init vmi_time_init(void)
> >>+{
> >>+ /* Disable PIT: BIOSes start PIT CH0 with 18.2hz peridic. */
> >>+ outb_p(0x3a, PIT_MODE); /* binary, mode 5, LSB/MSB, ch 0 */
> >
> >That shouldn't be necessary using clockevents.
>
> Actually, I'm n
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> diff -r c02ab981c99c arch/i386/kernel/vmiclock.c
> --- /dev/null Thu Jan 01 00:00:00 1970 +
> +++ b/arch/i386/kernel/vmiclock.c Mon Apr 09 15:47:17 2007 -0700
> @@ -0,0 +1,318 @@
> +/*
> + * VMI paravirtual timer support routines.
> + *
> + * Co
* Zachary Amsden ([EMAIL PROTECTED]) wrote:
> H. Peter Anvin wrote:
> >
> >I actually expect rdmsr/wrmsr to have a higher likelihood of weird
> >things. I don't know how many hypervisors can trap and handle those.
>
> Or implement anything useful at all ... perhaps it might be useful to
> simpl
* Christoph Lameter ([EMAIL PROTECTED]) wrote:
> Acked-by: Christoph Lameter <[EMAIL PROTECTED]>
>
> for all thats worth since I am not a i386 specialist.
>
> How much of the issues with page struct sharing between slab and arch code
> does this address?
I think the answer is 'none yet.' It us
* H. Peter Anvin ([EMAIL PROTECTED]) wrote:
> I have finally gotten off the pot and finished writing up my new
> CPUID/MSR driver, which contains support for registers that need
> arbitrary GPRs touched. For i386 vs x86-64 compatibility, both use an
> x86-64 register image (16 64-bit register f
* Eric W. Biederman ([EMAIL PROTECTED]) wrote:
> Is it truly critical to inline any of these instructions?
I don't have any current measurements. But we'd been aiming
at getting irq_{en,dis}able to a simple memory write to pda.
But simplicity, maintenance, etc. win over trimming a couple
cycles,
* Eric W. Biederman ([EMAIL PROTECTED]) wrote:
> Chris Wright <[EMAIL PROTECTED]> writes:
>
> > * Ingo Molnar ([EMAIL PROTECTED]) wrote:
> >> > ENTRY(swapper_pg_dir)
> >> > +.align PAGE_SIZE_asm
> >> > .fill 1024,
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > Consistently wrap paravirt ops callsites
> > "ugh" - mingo
>
> Had a thought. What if we do a kind of reverse/two-way module linkage?
> Somehow compile each pv-op implementation
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > I mean like this (bunch of work, for a type check that we're really ignoring
> > anwyay, but this is the idea...)
>
> Oh, I see. I think this is the best argument yet for the current
> arr
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Chris Wright wrote:
> > how about __paravirt_nop_start < func < __paravirt_nop_end and preserve
> > the types?
> >
>
> Er? The reason for the (void *) cast is to stop gcc complaining about
> mismatched poi
The Linux Foundation is hosting this list now. Mailing to
virtualization@lists.osdl.org will continue to work,
but you may need to update your procmail, etc. filters,
I know I did.
thanks,
-chris
___
Virtualization mailing list
[EMAIL PROTECTED]
https:/
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> Ingo Molnar wrote:
> > but only as a cleanup of the current open-coded (void *) casts. My
> > problem with this is that it loses the types. Not that there is much to
> > check for, but still, this adds some assumptions about how function
> > cal
72 matches
Mail list logo
